If you visit this site over an IPv6 connection, and your Web browser talks to a DNSSEC-validating DNS resolver, you should see the following on the top right of the page:
I've had the IPv6 indicator for a long time, and Peter twisted my arm recently to add a DNSSEC indicator, which is easier said than done: how does this Web site determine that your computer is using a DNSSEC-validating cache?
There are a number of DNSSEC checks (pages & widgets) floating around and, while most are very good, they either contain a bit too much functionality for my liking or they're hard to embed the way I'd want to. A few examples:
- SIDN's DNSSEC test is one that I mention in tutorials and talks
- Verisign Labs' Are you using DNSSEC
- DNSSEC Resolver Test of the University of Duisburg.
- a widget which is embeddable on Web pages, is NIC.cz's DNSSEC & IPv6 widget.
I wanted something small and lightweight to embed on this site, so I put on my thinking cap and got to work.
First off, it's not possible for a Web site (i.e. this page) to obtain information about your connection, other than the IP address (and port number) your client computer is using, both of which are useless in this case.
Basically the only thing that occurs to me is to try and load a small resource from a site which has broken DNSSEC. Yes, I repeat: broken DNSSEC. If I force your Web browser to load, say, a small image from a site with a broken chain of trust (or an expired RRSIG), and your Web browser is in a validating environment, it won't be able to load the resource, because the validating DNS server won't return the address record(s) for the bogus domain.
Comcast hosts http://www.dnssec-failed.org/, on a DNSSEC-signed zone
which is broken on purpose. (This means, that if you're visiting the site
querying a validating resolver, and you try to click on the previous link, your
SERVFAIL and your browser won't be able to connect to the
Let me show you: first a
dig via a non-validating DNS server: we get an answer --
an Address record:
$ dig www.dnssec-failed.org ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61564 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: www.dnssec-failed.org. 7137 IN A 220.127.116.11
and now via a validating server:
$ dig www.dnssec-failed.org ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50340 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
Note how the status is
SERVFAIL and we get no answer.
Comcast writes on
This site will be maintained permanently in support of this testing goal, so that developers and others can be assured of having a stable reference site with which to test DNSSEC validation failures, as a service to the community.
Taking that for granted, I thought I'd ask Comcast whether they'd be willing to host a minute 1x1-pixel image for me, which I could use to implement a DNSSEC checker. They readily accepted and what you find here is the result.
I've posted the code I use on Github, and this is basically what it does:
This page sets a timer and tries to load a
1x1-pixel graphic from
dnssec-failed.org. If that resource can be loaded, the
timer is stopped, and we know you're using a non-DNSSEC-validating cache
because your browser loaded the image, so we know it was able to resolve
www.dnssec-failed.org to an address record, and it connected to the site.
If, on the other hand, your browser is speaking to a validating cache, the cache will determine
that the DNSSEC-signed zone
www.dnssec-failed.org is bogus and will
it will not return the address of the site. When the timer
expires, we know (or hope?) DNSSEC is in use and can react accordingly. (Caveat: all
or any client-side failure to load the pixel
would also be considered as "resource not loaded", i.e. "have DNSSEC". I'll gladly accept
Be that as it may, it seems to work rather well, and I'm grateful to Jason and Chris at Comcast for having made this possible by hosting the small file.