Details of the DNS flaw revealed

Posted Aug 13, 2008 21:21 UTC (Wed) by kh (guest, #19413)
In reply to: Details of the DNS flaw revealed by tialaramex
Parent article: Details of the DNS flaw revealed

No, even if you do all of those things, (at least with ISC BIND), you are still vulnerable to
an unsigned spoofed response that gets there before the signed response (which would then be
ignored.)

Details of the DNS flaw revealed

Posted Aug 14, 2008 12:15 UTC (Thu) by lysse (guest, #3190) [Link]

> No, even if you do all of those things, (at least with ISC BIND)

Well...

Details of the DNS flaw revealed

Posted Aug 14, 2008 22:00 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

I don't understand your scenario. Can you flesh it out a bit? It seems to me that I would
expect SERVFAIL in this type of scenario (spoofing is successful, the answer should be signed,
but the spoofed answer isn't signed).

What happens exactly, there's ISC BIND running somewhere, as a recursive server for the client
resolver ? What if anything in your scenario is actually configured as DNSSEC secured and has
a good trust anchor? What is it requesting? What does it receive?

Or maybe you have a link to a bug report which explains all this?

There are extensive test zones available, so you don't need to rely on hypotheticals, every
combination people could think of exists (in these test zones, and no doubt soon on the public
Internet due to ordinary incompetence). If your scenario requires a CNAME which is unsigned
but which points to a signed A record from the same zone, there's a test for that. How about a
correctly signed CNAME, plus an A record signed with an expired key and a TXT record which is
correctly signed but by a key which is not yet valid (DNSSEC pre-issues keys)? We can do that.

Nothing needs to be spoofed, because the test zones contain everything a spoofer might want to
send (and plenty of things no-one ever has any reason to send but which might conceivably
exist anyway)