If you reached this site without the benefit of DNSSEC validation, you may have noticed that the website banner contains an icon declaring that “DNSSEC is Off.”  If you see a green check mark instead, you can pat yourself (or your ISP) on the back for protecting your hosts against DNS-based attacks, and for a job well done.

The difference is on account of a name that is resolved while trying to render the site.  The web browser tries to pull in a Cascading Style Sheet (CSS) file from a domain name (badsign-a.testsub.dnssec-deployment.org) that has deliberately broken DNSSEC signatures. This CSS file’s only purpose is to set the “DNSSEC is off” image on the DNSSEC Deployment website banner. With DNSSEC validation enabled, the browser does not load the CSS from badsign-a.testsub.dnssec-deployment.org, and the default header image with the green check mark shows up instead.

It shouldn’t come as a surprise to you that your browser was trying to load content from badsign-a.testsub.dnssec-deployment.org although you had not typed that in the address bar. More generally, it shouldn’t be surprising that it requires more than a single DNS lookup to fill the contents of a page. In fact, as the query trace from loading a relatively simple page such as www.dnssec-deployment.org illustrates below, an un-primed resolver easily performs in excess of a hundred lookups before the browser renders the complete page. Some of these queries are not even for names under the dnssec-deployment.org domain. For more content-packed sites the number of names looked up is even higher.

You might be somewhat surprised, though, that content that was pulled remotely (from badsign-a.testsub.dnssec-deployment.org in this example, but really could have been from anywhere) was able to modify the contents of the www.dnssec-deployment.org page so easily. Javascript and CSS are extraordinarily powerful in that respect. Would you even notice if only a portion of the website you were looking at was actually modified using one of these vectors? You might think that if you were validating all your DNS responses you would probably have been safe from this type of attack. However, consider widely-used software such as google-analytics, which relies on the browser fetching remote javascript, but does so from under a zone that is not signed (google-analytics.com is not signed). The zone is “provably insecure” so there is no way for your resolver to validate that name. There is no doubt that for the benefits of DNSSEC to be truly realized, we need zone owners to continue to sign their zones in earnest in order to allow DNSSEC-capable clients to protect themselves against different types of name-based attacks.

When zone owners sign their zones, enabling validation either within the application or through a trusted recursive name server mitigates the threats discussed above.  Moving DNSSEC validation into the application (in this case, the browser) provides three additional advantages:

1. It shifts the responsibility of determining the validity of DNS answers to the entity that will use the answers, so the DNSSEC last mile shrinks considerably.
2. It allows the application to provide the user with intuitive error messages, thus enabling the user to recognize that the problem lies with the zone in question and not an intermediary, such as an ISP.
3. It allows the application to make its own determination on what types of answers it is willing to trust. For instance, DANE-related lookups will require answers to be validated (and nothing short of it), while answers that have been shown to be provably insecure (but not bogus!) would be perfectly acceptable for normal browsing activity.

Moving validation into the application leads to the possibility that applications vendors will then want to expose the ability to enable and disable the DNSSEC validation function to the end-user. The point about “click-through insecurity” is well-made; however this is functionally no different than a user knowingly adding a security exception for certificates in current browser implementations. The browser vendor must make it hard for the user to add exceptions, without doubt, but the functionality to circumvent certain problems (such as ignoring the signature inception/expiration times on zones that remain published with expired signatures) is useful, especially while many zone operators are still fine-tuning their DNSSEC workflow.

It is also important, given that web pages are typically composed of a number of discrete elements, that validation be performed for all lookups initiated by the browser and not just for the name typed in the address bar. Many browser plugins for DNSSEC support will validate only the latter; while that capability is certainly useful, the real benefit of local validation is realized only when the browser (or the OS) completely integrates DNSSEC validation capability into its internal resolver library and enables validation for all queries.

The good news is that browser vendors (and their user communities) have been showing increased interest in seeing DNSSEC capability extended to the end-applications. Proof-of-concept implementations of browsers with DNSSEC validation support (e.g., the DNSSEC-Tools Firefox patch) have been available for a while, and with DNSSEC validation capability being continuously extended to new platforms and devices, there is hope that DNSSEC capability in browsers will eventually become more commonplace.