"I found dnssec-tools.org, very simply."

Looking for how to get started with DNSSEC deployment–or for tools to make it easier? You’re not alone. A companion site to this blog, dnssec-tools.org and the DNSSEC Tools Project were designed to “create a set of software tools, patches, applications, wrappers, extensions, and plugins that will help ease the deployment of DNSSEC related technologies.”  The site includes:

• DNSSEC tutorials
• A wiki on DNSSEC deployment and related issues
• A directory of DNSSEC tools with short descriptions and screen shots
• Instructions for installing the full suite of DNSSEC tools

The tools are open source, and options for discussion or reporting bugs are provided.  The DNSSEC Tools Project is funded by Sparta, Inc. and the U.S. Department of Homeland Security Science and Technology Directorate.

Writing on the Imperial Violet blog, Google’ Chrome engineer Adam Langley recently looked at transport layer security (TLS) and DNSSEC. He noted:

Ever since the DNS root was signed on July 15^th, quite a few people have been wondering about the interaction of TLS and DNSSEC. On the one hand, trust in the CA system is lukewarm but, on the other, the deployment issues with getting DNSSEC to the client seem immense.

Those who saw Dan Kaminsky’s talk at BlackHat, which included a patched version of Chromium performing DNSSEC validation, have probably already guessed that Dan, myself and others have been working on this problem. In this blog post I’m going to try to explain the design space as I see it….In the long term, we want a stronger foundation of trust for the Internet. This means both pairing back the power of the 1500 root certificates and making TLS easier to deploy and thus more commonly used. So one of the goals is to serve sites which currently don’t have a CA signed certificate. We can do that by allowing them to publish fingerprints in DNS and having browsers accept those (DNSSEC secured) fingerprints.

The post considers several questions related to encoding the data, including:

• What type of record and where to put it
• Handling clients without DNSSEC resolution capability
• Fingerprints in records
• What to hash
• Whether to include a flag to perform CA validation
• TLS extensions

A collaborative effort between the ITESM (Instituto Tecnológico y de Estudios Superiores de Monterrey) and Mexico NIC has released the beta version of a new DNSSEC tool plug-in for Internet Explorer working on a Windows operating system.   The project website includes the beta plug-in, as well as an installer, technical and user manuals and videos.

Dark Reading and others are reporting that .info, the seventh-largest top-level domain, was DNSSEC-enabled by Afilias September 1.  The article notes:

…the signing of the .INFO zone represents the first step in Afilias’ recently announced “Project Safeguard” initiative, which will rollout DNSSEC across its registry and DNS platforms. Project Safeguard also includes an education and training program for Registrars to enable DNSSEC in their registration systems for website owners who intend to add DNSSEC signatures to their individual domains.

Now that the TLD is signed, Afilias will activate a “friends and family” period that will allow the public to gain experience with a select group of .INFO second level domain names that have also been signed. Shinkuro Inc. and Comcast have agreed to participate in this testing period. The list of “friends and family” domains includes: afilias.info, info.info, shinkuro.info, comcast.info, and 19 other domains from Comcast.

.info was was the first generic, unrestricted TLD to be launched since .com.

Neustar also announced that .biz, which it administers, was signed September 8; it notes it is ” the only registry to have fully deployed DNSSEC in two TLDs (.US and .BIZ).”

Do DNS clients request DNSSEC?  RIPE Labs says yes, based on a look at the RIPE NCC server that provides secondary service to a number of country-code top-level domains (ccTLDs), which answers an average 5,000 queries per second.  The chart above shows that more than 50 percent of queries requested DNSSEC information during August 2010, a month after the root was signed and TLDs began signing their zones.  RIPE is a membership organization supporting Internet infrastructure in in Europe, the Middle East and parts of Central Asia.  It is phasing out its DNSSEC reply-size tester as of October 11, 2010.

A survey conducted by SURFnet, a higher education information technology coalition in the Netherlands, concluded that “a large majority of the respondents attribute a high priority to DNSSEC…intends to tack action and deploy DNSSEC, most of them within a year.”  The report noted, however, that most respondents did not yet know which hardware and software solutions they would use to achieve deployment.  See the full report here.

(Editor’s note:  Scott Rose, a National Institute for Standards and Technology computer scientist, is a DNS and DNSSEC expert and NIST project lead for DNSSEC deployment.  He is a co-author of the DNSSEC RFCs and NIST Special Publication SP-800-81, which defines DNSSEC requirements in the federal system.  Here, he shares observations from reviewing signed delegations throughout the U.S. government as it continues deploying DNSSEC; the views presented here are his own and do not necessarily represent the views or policies of NIST.)

The .gov top-level domain (TLD) was the first to mandate signing for a portion of its delegated children (all Federal delegations).  Now, 18 months since the TLD was signed, deployment at the lower levels has been a mixed bag.  While the majority of the signed delegations (over 600 seen) have been operating without problems, a minority of zones appears to have some sort of problem.  These zones are vary from week to week and usually number around 12 to 20, with the number decreasing over time. The problems we have seen could be grouped into three categories:

1. KSK rollover issues have been the most commonly seen error so far, accounting for roughly three out of four problematic zones.  The subzone has rolled its KSK, but has either failed to upload its new KSK, or did so incorrectly.  In this case, there are a couple of options:  Either the subzone operator can push up the correct KSK or resign the zone with the old KSK.  Both will mean that the zone will be invalid for a period of time.  On the parent side, one solution is to pull the subzone’s DS RR (that now points to a missing KSK).  This means the zone is now insecure (there is no secure delegation), but the zone is no longer invalid. 
2. Timing issues are the next-most common error. Either the signatures in the sub zone are all expired, or (in a few cases) published before they are valid.  If the zone signatures are expired (i.e. the RRSIG expiration time is in the past), the easy solution is to simply resign the zone with the current keys and republish the zones.  If it is the rare case that the signatures are published too soon (i.e. the inception time is in the future), the issue may be that the system used to sign the zone has an incorrect clock.  The solution there is to ensure that the signing system’s clock is correct before the zone is signed. 
3. Signed zones served on DNSSEC-unaware systems are (thankfully) becoming increasingly rare.  In this situation, the admin has correctly signed the zone, but has not configured the server to be DNSSEC-aware, or the server cannot serve a DNSSEC signed zone correctly.  In all of these cases, the zone returns traditional DNS responses, but if there is a DS RR in .gov, the lack of RRSIGs in a response results in a validation failure.  In all of these cases, the solution is to make sure all of the authoritative servers for the zone (primary and secondary servers) are DNSSEC capable and have been configured to send DNSSEC responses when queried. 

I believe most of these problems could have been prevented with better planning and education of operational staff before deployment.  Failing that, these issues are easily caught at the registry level via monitoring of signed delegations.  The registry could warn of issues before they happen, and it worst case, pull the DS RR’s from the delegation to prevent validation errors until the delegation is fixed. In the case of split registry/registrar models, the registrar could perform this function for delegations they handle.  It may not prevent all the problems since administrators still need to fix their own problems, but it prevents the zone from “going dark” for DNSSEC enabled clients.  Not a perfect situation, but workable until the problem is fixed.

The U.S. National Institute for Standards and Technology (NIST) has released Special Publication 800-81r1, the “Secure Domain Name System (DNS) Deployment Guide”.  This Special Publication (SP)  is a revision of the original SP 800-81 issued in May 2006.  This revision incorporates the following changes:

(1) Guidelines on procedures for migrating to a new cryptographic algorithm for signing of the zone (Section 11.5).
(2) Guidelines on procedures for migrating to NSEC3 specifications from NSEC for providing authenticated denial of existence (Section 11.6).
(3) Deployment guidelines for split-zone under different scenarios (Section 11.7).

The guide is available on the NIST Computer Security Resource Center website.  Supplemental material, including mappings for application-specific NIST SP 800-81r1 checklist items, is available on the NIST SNIP project website.

Writing on the Comcast Voices blog, Comcast manager of DNS engineering Chris Griffiths shares his experience at the recent ICANN key signing ceremonies, where he served as a backup crypto officer.  Griffiths also noted:

With all this momentum, several key top-level domains have also announced recently they are ready to support DNSSEC. The first was .ORG. The other major top-level-domain was .EDU. As these large Domain registries start to support DNSSEC, it allows domain holders like Comcast to sign our domains and make them secure.

Comcast maintains a DNSSEC information center with regular updates on its deployment progress, and it is a member of the DNSSEC Industry Coalition.  With more than 14 million high-speed Internet customers, it is one of the largest Internet service providers in the U.S.

With so many TLDs deploying DNSSEC in recent weeks, more sites are trying to track deployment progress. In addition to this Initiative’s table showing TLD deployment and the Xlerance worldwide map of DNSSEC deployment, Wikipedia’s list of Internet top-level domains now includes a DNSSEC column that indicates “yes” or “no” for each domain’s DNSSEC status, with color-coding for easy visibility, as seen below:

Entries cover generic top-level domains as well as country-code top-level domains. This list is not currently up-to-date, but the DNSSEC Deployment Coordination Initiative will be working to share information to make the listing complete and accurate.

Afilias has announced it will deploy DNSSEC across it registry platforms, signing 13 top-level domains, a move it says is “increasing DNSSEC deployment among domain registries by 50 percent.”  DNSSEC will be deployed first in the .info domain in September, with Afilias-supported TLDs in Asia, the Latin America/Caribbean, and Europe to follow.

The effort, dubbed “Project Safeguard,” will upgrade registries and DNS infrastructure to support DNSSEC and create a year-long across registrar training initiative focused on implementing DNSSEC in registrar-registry transactions.

Afilias also released a survey of domain name registrars on deployment issues. From the announcement, the Registrar DNSSEC Readiness Report findings include:

Registrars think DNSSEC is a good idea, but are not yet fully prepared to offer consumer services.  80 percent of registrars believe that top-level domain (TLD) registries should offer DNSSEC. However 90 percent of registrars currently feel completely unprepared or only somewhat prepared to actually offer DNSSEC services to their customers as this time.

69 percent of Registrars plan to offer DNSSEC services in 2011 or beyond. 32 percent have no plan to introduce DNSSEC within the next 12 months.

Consumer demand is the biggest challenge for registrars. 56 percent cite a lack of consumer demand as their biggest challenge impeding their DNSSEC implementation.

Registrars also cite issues with deploying DNSSEC technology:  For example, nearly 20 percent cite the management of DNSSEC keys as their number one concern, followed by more than 18 percent that cite overall DNSSEC technology and expertise.