Archive for August, 2010

(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.  

Twitter post by @miekg

SIDN has announced that it has implemented DNSSEC in .nl, the world’s third-largest country code top-level domain. The announcement describes next steps:

Early [in] October, SIDN will be offering registrants who have experience of using DNSSEC the opportunity to provide ‘trust anchors’ for their domain names. The small number of anchors involved will then be added to the .nl zone file by SIDN. This Friends and Fans Programme will continue until it is possible to secure all .nl domain names using DNSSEC. SIDN intends to pursue the gradual further rollout of DNSSEC with a view to guaranteeing the availability of the .nl zone. The whole process should be complete before the end of 2011.

SIDN CEO Roelof Meijer said, “After .org, ours is the second biggest zone to successfully implement DNSSEC. We waited until the root had been signed before going ahead, so that no interim solutions were needed and we could sign the entire chain in one go. We felt that this was the most efficient and secure way of bringing DNSSEC to the .nl zone.”

The Xlerance worldwide map of DNSSEC deployment has been updated to reflect the news.

DNS BE, which manages 1 million domain names, announced it has begun supporting DNSSEC in Belgium’s .be domain this week.  A test bed has been launched, and registrars will be able to register DNSSEC-supported domain names in October.

SC Magazine reports that a phased rollout of DNSSEC will begin in Australia next month. From the article:

Next month, regulator auDA (the .au Domain Administration) and its wholesale domain name provider AusRegistry will phase in the Domain Name Security (DNSSEC) protocol across Australian domain names such as those ending in com.au and net.au.  The regulator said the five-stage process will gradually bring domain name owners into the fold as it tests systems over coming months, before rolling out the technology to the mass market.

D-Link is boosting router security, announcing it is “the first in the industry to enhance its router security to a higher level of protection by incorporating both CAPTCHA and DNSSEC to guard against hacking, worms, viruses and other malicious Web attacks.”  From the announcement:

“Unlike other brands, the majority of currently shipping D-Link routers are more difficult to be compromised due to our advanced set of security features. We’re excited to be the first in the market to announce we have taken the initiative to implement both CAPTCHA and DNSSEC into our routers, thus providing yet another layer of security, and we’ll continue to provide our users with the latest in advanced security technologies,” said A.J. Wang, chief technology officer, D-Link.

DNSSEC, CAPTCHA and IPv6 features are available on “most currently shipping D-Link’s routers, with more being updated. Please consult www.dlink.com for availability of firmware updates,” the company advises.

In an effort to ” help United States government agencies simplify compliance with the Office of Management and Budget (OMB) mandate to adopt the DNSSEC standard,” Akamai Technologies, Inc., has announced support for DNSSEC, available immediately.

Two options will be available:  “sign and serve” or “serve only.”  From the announcement:

For example, customers that want to fully outsource their key management process can select the “sign and serve” option, which is as simple as checking a box on the Akamai EdgeControl portal. Alternatively, customers that prefer to manage their signing independently can select the “serve only” option.  Additionally, Akamai believes that with its DNSSEC support in place agencies can meet the OMB mandate even if the primary name server (master name server) is not DNSSEC ready.

Akamai Vice President of Sales Thomas Ruff noted “we believe [DNSSEC] is gaining traction with .gov and .org signed and with the announcement to fully deploy DNSSEC by the Root Zone operators.”  For more information about Akamai’s Enhanced DNS service and the new DNSSEC support offering, go here.