Archive for category Uncategorized

We try to keep ourselves and you informed about all things related to the deployment of DNSSEC, but we can’t do it alone. There are other sites that also publish useful information from a variety of points of view, and we try to bring those to the attention of the community, but they too are incomplete. One source of information that is often overlooked in these blog posts and web sites is you. We appreciate that everyone involved in deploying DNSSEC is on the leading edge (yes, you are) and that you may have as many useful bits of information as questions.

Our solution, which hasn’t been given the spotlight that it deserves, is our wiki. Wander over to https://www.dnssec-deployment.org/wiki/, create an account, and help us document the DNSSEC world.  You’ll help others and may learn something in the process.

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.

The 43rd ICANN meeting, to be held in  San José, Costa Rica from the 11th to the 16th of March, will include a DNSSEC Workshop on Wednesday the 14th.

Tentative schedule is for the meeting to run from 08:30 a.m. to 1:00 p.m. with an agenda that will cover:

• DNSSEC Deployment Around the World
• Challenges and Benefits of DNSSEC for Latin America and Regional Update
• DNSSEC Operational Best Practices and Lessons from the Trenches
• Using DNSSEC to Protect Reputations
• DNSSEC Signer Implementation Hardware

The final agenda, speakers, and room will be posted on the meeting’s web site in the next couple weeks.

As more TLDs are signed and more ISPs provide validation, a greater focus is being placed on DNSSEC at the client. Client activities include DNSSEC-aware applications, DNSSEC-aware resolution libraries, and validating local resolvers for times when either the ISP doesn’t provide DNSSEC validation or the last mile between the ISP’s resolver and the client can’t be trusted.

The Internet Societys’s Deploy360 Programme has recently put up a list of developer libraries and is soliciting additional input from the community on other libraries.

Members of the DNSSEC Deployment Initiative have been using NLnet Labs’ Dnssec-Trigger on Mac and Windows systems to provide local DNSSEC validation.

so be good for goodness sake.

As reported on the DNSSEC-deployment mailing list (subscribe here), Comcast is analyzing the major DNSSEC failures they’re seeing and publishing the results for the benefit of the community.

The first such failure to be analyzed occurred on the 18th, coincident with the web-wide protests against SOPA and PIPA, with NASA.gov.  The report (770KB PDF) was published on Comcast’s DNSSEC Information Center.

As an early adopter of DNSSEC, we remain committed to helping other implementers learn from our experiences.

The Internet Society Deploy360 Programme is a new initiative that provides real-world IPv6, DNSSEC, etc. deployment information. Deploy360 aims to bridge the gap between the IETF standards process and final adoption of those standards by the global operations community. Deploy360 creates and promotes resources that are easy to understand and quickly actionable by the very IT professionals responsible for the implementation of new technologies and standards like IPv6 and DNSSEC.

Check out the Internet Society’s  Deploy360 Programme and its DNSSEC content.

The Internet is on strike.  Among the many web sites making their position known, Wikipedia’s English language site is offline (or, hard to get to):

Google has censored their name on their home page and in search results:

All this is in protest to the United States’ proposed Stop Online Piracy and Protect IP Acts.  Outside of the battle of free speech versus intellectual property and the potential chilling effects of these bills, the technical enforcement methods in these bills include monkeying with DNS in a way that breaks DNSSEC.

We’ve reported on the issue before, here and here.  On Saturday, the White House showed that they understand:

We must avoid creating new cybersecurity risks or disrupting the underlying architecture of the Internet. Proposed laws must not tamper with the technical architecture of the Internet through manipulation of the Domain Name System (DNS), a foundation of Internet security. Our analysis of the DNS filtering provisions in some proposed legislation suggests that they pose a real risk to cybersecurity and yet leave contraband goods and services accessible online. We must avoid legislation that drives users to dangerous, unreliable DNS servers and puts next-generation security policies, such as the deployment of DNSSEC, at risk.

We’ve reached another milestone in the deployment of DNSSEC.  Jason Livingood from Comcast writes:

I am pleased to announce that Comcast, the largest ISP in the U.S., is the first large ISP in the North America to have fully implemented Domain Name System Security Extensions (DNSSEC). As part of our ongoing efforts to protect our customers, DNSSEC is now automatically included as part of Comcast Constant Guard™ from Xfinity.

Read more on the Comcast Blog.