User: Password:
Subscribe / Log in / New account

Details of the DNS flaw revealed

Details of the DNS flaw revealed

Posted Aug 13, 2008 18:29 UTC (Wed) by njs (guest, #40338)
In reply to: Details of the DNS flaw revealed by kh
Parent article: Details of the DNS flaw revealed

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.

(Log in to post comments)

Details of the DNS flaw revealed

Posted Aug 13, 2008 19:02 UTC (Wed) by drag (guest, #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.

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