User: Password:
Subscribe / Log in / New account

Details of the DNS flaw revealed

Details of the DNS flaw revealed

Posted Aug 13, 2008 17:45 UTC (Wed) by kh (subscriber, #19413)
Parent article: Details of the DNS flaw revealed

The other problem with DNSSEC is that it does not get you anything today - a first correct
answer sent as a plain DNS response will still cause the DNS server to ignore subsequent

It seems like there should be some way to block responses from a client after a given number
of incorrect UDP port injection attempts - at least then an attacker would have to distribute
his attack across many different attacking computers instead of sending millions of
unsolicited responses from a single computer.

(Log in to post comments)

Details of the DNS flaw revealed

Posted Aug 13, 2008 18:29 UTC (Wed) by njs (guest, #40338) [Link]

That doesn't help, because there's no way to securely work out the sender of a UDP packet.
The attacker just has to forge the source address on their UDP packets -- and if they forge it
to be the *real* DNS server, then they might even trick you into blacklisting the real server.

Details of the DNS flaw revealed

Posted Aug 13, 2008 19:02 UTC (Wed) by drag (subscriber, #31333) [Link]

The only thing that I could see working is to 'establish a tree of trust' going from 'trunk'
root dns servers to 'branches' to the 'leaves'. 

Each DNS server would have to register with the ones it communicates with and uses something
like TLS or PGP signing to communicate with one another so that the identify of the sender is
confirmed by the signature data contained in a packet (once you get a signature then you
wouldn't have to sign each packet, just as long as the data can be compiled and have it's
final checksum confirmed then that's fine). Then when a person requests a DNS address the
message will have to transverse up the tree to the nearest DNS system (or 'common link') in
the chain of trust and then back down (this would probably require a separate routing
protocol, or tying into existing protocols, for finding these paths).

The DNS server would have to establish it's identity with it's neighbors when it's first
brought up, and that's were the next window of vulnerability will be.

That's a lot of overhead, though.

Details of the DNS flaw revealed

Posted Aug 13, 2008 19:34 UTC (Wed) by rfunk (subscriber, #4054) [Link]

That sounds a lot like my understanding of what DNSSEC is, or wants to be.  
But it doesn't work if you don't have that whole chain of trust going all 
the way to the root.

Details of the DNS flaw revealed

Posted Aug 13, 2008 21:29 UTC (Wed) by hmh (subscriber, #3838) [Link]

Read up on DNSSEC and look-aside validation.

ISC and friends have worked around the politic crap about signing the root.  It is some other
pesky details that are causing issues for DNSSEC deployment.

And server/network performance IS one of them.

Details of the DNS flaw revealed

Posted Aug 15, 2008 12:00 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

The manual steps in DNSSEC deployment mean that even if by some miracle tomorrow the root
servers offered a signed zone and began accepting requests to sign KSKs from the TLDs, it
would be years before the majority of public domains were secured, so the increase in
resources required would be gradual, rather than overnight.

The root server operators seem to have made it plain that for /them/ at least the performance
is not a problem. Several ccTLDs have deployed as islands, so they obviously don't think
performance is a problem.

There is the enumeration problem, but again that doesn't affect the root because its contents
are public. Some ccTLDs have said that they don't believe this is a problem for them either,
because local regulations mean the list of domains and registrants is public anyway. And even
for some of the domains where enumeration isn't acceptable, there are solutions to deploy
today if the will existed, and better solutions on the horizon.

Details of the DNS flaw revealed

Posted Aug 13, 2008 21:14 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

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 (subscriber, #19413) [Link]

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

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)


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)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds