Given that modern websites often pull content from a variety of different sites to build a single page, what impact does that have on DNSSEC and providing the security that it does?
That was one of the questions raised in a recent post by the DNSSEC Deployment Initiative titled “Are You Secure?” This key point was emphasized in this paragraph:
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.
The way we build websites today does very often involve pulling in content from a variety of different sites. Sometimes it is something as simple as the latest jquery JavaScript library. Sometimes it is images or advertisements. Sometimes it is the latest tweets or other content from social networks.
The article goes on to talk about the value of moving DNSSEC validation directly into the application, such as the web browser, so that all DNS queries can be properly validated. The author ends on this note:
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.
We certainly share that hope that DNSSEC capability in browsers and other applications will become more commonplace. A goal of this entire Deploy360 Programme is to help bring that widespread availability about.
Application developers… have you checked out the developer libraries available now to help add DNSSEC support to your applications? Have you looked at what is available in the DNSSEC Tools project?
What else can we do to help you build DNSSEC into your applications?
P.S. In my case, I did see the correct image on the DNSSEC Deployment Initiative web pages, but that is because I’m running a local DNSSEC-validating DNS resolver on my MacBook Pro laptop. I’m using the excellent DNSSEC-Trigger tool from NLnet Labs – it’s available for Mac OS X, Windows or Linux.
Looking for a good concise guide to the security issues and procedures related to deploying DNSSEC? Back in March 2010, the European Network and Information Security Agency (ENISA) issued their “Good Practices Guide For Deploying DNSSEC” with the abstract:
The goal of the DNSSEC-Tools Project is “to create a set of software tools, patches, applications, wrappers, extensions, and plugins that will help ease the deployment of DNSSEC related technologies.” The project website is at:
