Details of the DNS flaw revealed

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

DNSSEC does get you something today because an answer is not "correct" if it is unsigned, or
the signature is invalid, and you were expecting a signed response.

If your resolver can determine a chain of trust from an anchor (ideally the root servers, but
today it might be the Swedish ccTLD registry) down the DNS hierarchy to the requested address,
then it can (and if configured to do so) will authenticate the response.

At the anchor you use a locally configured key to verify the signed information about the next
level, and if that information contains a public key, you can use that to verify the next lot
of signed information, and so on until you've reached the point in the hierarchy you were
interested in, or you don't get a key and fall back to unauthenticated DNS.

If you install the Swedish TLD's DNSSEC public key and configure your resolver and/or
recursive server to use it, then you will have working DNSSEC today, for however many 2LDs
there are in their registry which have decided to use DNSSEC, and for any of their 3LDs and so
on as appropriate. Once you have set this up, any queries for these addresses will either give
you the authentic answer, or fail in some way (e.g. because the owner forgot to update their
key and doesn't have a system which handles it automatically), spoofing becomes impossible.

Details of the DNS flaw revealed

Posted Aug 13, 2008 21:21 UTC (Wed) by kh (guest, #19413) [Link] (2 responses)

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)