DNSSEC, from an end-user perspective, part 2

In our previous blog post, we have discussed some of the threats against current DNS systems, where the result was that the victim landed on a different resource/website as he/she originally supposed to visit.

Since this is not a guide for DNS server operators about DNSSEC implementation, let's jump to the user side and see what you should know if you visit a website where DNSSEC validation fails (like the test site http://www.dnssec-failed.org/) and you use a DNS server which validates the DNSSEC responses (e.g., 8.8.8.8 - Google public DNS server):

So far, so good :-) The malicious attacker's evil plan has failed. But what should you see when the server is protected with DNSSEC, and the DNSSEC response is valid/trusted?

Please note that this "green key" stuff is for experimental purposes only. I hope the users should not have to look for another SSL-like padlock in their browser in the future. The critical thing here is that the site has been rendered by the browser, and the response is protected by DNSSEC, thus eliminating lots of threats.

When you visit a site that is protected by DNSSEC, but your DNS server does not validate the DNSSEC, the site will be served and rendered in your browser. It does not matter if it has untrusted or invalid DNSSEC records. This is the same experience what you have today with no DNSSEC at all:

OK, so we, as end-users, need sites/domains which are protected with DNSSEC, and a DNS server which validates the DNSSEC records. We have the DNS server (thx Google!), so let's find some popular sites which are using DNSSEC!

To demonstrate my 133t h4cking skills, here is a small bash script. You give a file with the list of domains as a first parameter to the bash script, and it will give you back the areas protected with DNSSEC.

#!/bin/bash
dig . DNSKEY | grep -Ev '^($|;)' > root.keys
while read line
do
    if dig +sigchase +trusted-key=root.keys $line. A @8.8.8.8 | grep --quiet "DNSSEC validation is ok: SUCC"; then
        echo $line
    fi
done < $1

Alexa was not kind enough to give me a recent list of top sites in text format, so I have used http://moz.com/top500 for this test.

The results were quite shocking; the first result was at TOP40: gov.uk - but when you visit gov.uk via browser, it is redirected to a subdomain that is not protected with DNSSEC, so this kind of behavior is considered as FAIL.

TOP69: nih.gov  - so ironically, the winner is the National Institute of Health :P

Other interesting one where:

mozilla.org - FAIL 

cdc.gov - FAIL

nasa.gov - FAIL :(

ca.gov  - California homepage, don't mess with Arnie!

noaa.gov - National Oceanic and Atmospheric Administration :)

berkeley.edu - thank god the world of universities is saved

loc.gov - FAIL

whitehouse.gov - FAIL …

I think I have never ever visited these websites before, except the Berkeley one. If you can find a financial institution which website's domain is protected by DNSSEC, let me know. I was not able to find one… For example, paypal.com is a bad example. The main domain is protected with DNSSEC, but not the www.paypal.com.

In the next part of our DNSSEC series, I will write about the threats eliminated by DNSSEC and some other exciting things.