HAR: DNSSEC restoring trust in DNS by Roland van Rijswijk
Links from the HAR2009 site: Talk description and Slides.
Roland started off by explaining the basics of DNS Cache poisoning and the details of the trick discovered by Dan Kaminski last year. Explaining why you don’t have to wait for the answer to expire to in order to poison the cache.
Quite a bit of the patching done after the Kaminski attack became public is actually been undone by NAT-ing firewalls, who do not randomize the source ports the use to keep track of their NAT table.
The DNS resolvers put up by Rick and his team at HAR where attacked, but nobody was able to poison it as projected by Bert Hubert.
DNSSEC uses public/private key cryptography to sign DNS records. Because this makes the packets larger, you do not need a DDoS attack to cause a DoS, but you can do it with a single computer.
DNSSEC uses a two tiered key model. There is a key signing key (>= 2048 bit RSA) and a zone signing key (>= 1024 bit key). DNSSEC users additional resources records. For keys: DNSKEY, DS, Signatures: RRSIG and for authenticated denial-of-existance: NSEC or NSEC3. This will make zones quite a bit larger.
So how is the signature validated? Each answer has a signature in it. So we need to get the key in a way we can trust. The hash of the key of each domain is signed by the key of the domain below it.
DNSSEC on .com and .net will be signed by 2011. Signing of the root (.) zone is expected by the end of this year. Since only a few zones are signed we have islands of trust each with a trust anchor. There are interim solutions for this like https://itar.iana.org and ISC “DNSSEC look-a-side validation”. These solution all have their own trust issues like SSL or their reliance on DNS.
There is a lot of work going on at the moment because root zone signing is there.
Even tough there are a lot of problems with DNSSEC, but even the critics agree that it is the only solution we have available at the moment. The biggest lack at the moment is easy to use tools. Luckily a lot a people are working on this.
The alternatives to DNSSEC are maybe worse. Patching against vulnerabilities is an arms race. SSL and TLS is too heavy for the lightweight DNS protocol is not an issue, and SSL has its own issues. TSIG does not scale because it relies on shared secrets and DNScurve is just not available.
Surfnet has implemented DNSSEC for their resolvers and was able to validate 1% of the answer. 1% is a higher adoption rate then IPv6.
You can help by helping open source projects like PowerDNSSEC or OpenDNSSEC.