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:

Partial creen shot

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:

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.

So it's your computer (i.e. Web browser) that has to tell you whether you're using DNSSEC (I have nothing to do with it. :-) but that too, is easier said than done: I'm not aware of a Javascript function that says "you're using DNSSEC validation on this network".

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 resolver will SERVFAIL and your browser won't be able to connect to the site.)

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       68.87.64.48

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 dnssec-failed.org:

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:

Flowchart

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 SERVFAIL; 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 of this is not 100% foolproof in the Javascript code I've created: a server-side HTTP 404 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 patches...)

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.

Flattr this
DNSSEC and Site :: 30 Jul 2012 :: e-mail

Comments

blog comments powered by Disqus