Security Symposium Talk: Measuring the Practical Impact of DNSSEC Deployment

I'm lucky enough to be able to catch the last day of the USENIX Security Symposium here in Washington, DC, and as soon as I hopped off the plane, I jumped into a session that was just starting, Measuring the Practical Impact of DNSSEC Deployment. The authors of the paper were Wilson Lian, Eric Rescorla, Hovav Schacham, and Stefan Savage, and Wilson Lian gave the presentaiton.

DNSSEC is, essentially, the application of PKI to verify the authenticity of DNS records. Much like the security underpinnings of HTTPS, correctly verifying DNSSEC records requires a complete certificate chain with a trusted root server. This does not encrypt the response, it only verifies that it has been unaltered, similar to how a file's MD5 or SHA-1 fingerprint being the same in two places guarantees that it wasn't altered in transit.

According to presenter Wilson Lian, this was the first scientifically conducted study to evaluate the effects on browsers when domains provide DNSSEC.

In conducting their study, the four researchers purchased 10,000 ad image impressions every two hours for a week, and ended up with over 529,000 clients, more than 35,000 unique resolvers, and traffic from 6446 unique ASes. As impressive as this is, it only cost a bit over $400. That in itself is a little scary. 

The methods of testing were to provide one of 26 DNS responses to the ad's name lookup. One was correct, but without any DNSSEC signature. Another was correct, with the correct DNSSEC signature. Then there were 24 different permutations of a DNSSEC response, each one altered in a slightly different way. Some had bad signatures, some had missing signatures, and so on.

The results of the research were surprising (to me, anyway). It turns out that the vast majority of resolvers aren't paying much attention to DNSSEC at all. Altered DNSSEC responses (the very attack that DNSSEC is designed to prevent) only have a 2.6% failure rate. So 97.5% of clients out there get DNSSEC responses that are cryptographically compromised, and don't care.

If you're interested in reading more, make sure to check out the paper. USENIX has a free conference publication policy so that you can read what's being presented even if you aren't at the conference.

Check it out, though. Personally, I'm going to look more into DNSSEC, because I'm curious about its failure modes. How should a browser respond when it gets a "hijacked" response? How will this affect things like captive portals or ISP-customized NX response search pages? There are lots of questions that I have, so it's time to find answers.