Archive for category Uncategorized

• Germany-based InterNetX announced it now offers DNSSEC for the .ch (Switzerland) and .li (Lichtenstein) domains; it is the first partner of SWITCH, a provider of internet services for universities and users, to do so.
• Denmark’s .dk country-code top-level domain has deployed DNSSEC (announcement in Danish).
• The U.S. federal government announced new IPv6 requirements for U.S. federal agencies, which must “run native IPv6 on their Web, email, ISP, and DNS servers and services by the end of fiscal year 2012, and their internal client applications by fiscal year 2014,” according to Dark Reading.
• Nominet, which manages .uk, issued this incident report on the accidental release of a new Zone-signing-key into its live zone file. The report includes a diagnosis of what occurred and procedures being put in place to avoid a similiar incident in the future.
• Government Computer News reported on a new study on DNSSEC deployment by U.S. federal agencies which showed slow adoption of DNSSEC. Conducted for the Internet security company Internet Identity, the study “found that 38 percent of the federal domains tested had been digitally signed using the DNSSEC by mid-September.”
• Patches have been issued by the Internet Systems Consortium (ISC) for a DNSSEC-validation vulnerability found in “the widely deployed BIND DNS server’s DNSSEC implementation,” according to eSecurity Planet. Infoblox vice president Cricket Liu said the vulnerability has a low severity rating from ISC and network administrators should simply upgrade to the latest version of BIND to achieve the needed protection.

Afilias Executive Vice President and Chief Technology Officer Ram Mohan recently shared what every CIO should do about DNS security, on SecurityWeek.com. From the article:

Companies may spend millions creating and promoting their brand in the offline world, forgetting that on the Internet their domain name is their brand. It’s often the case that it is only after a company’s DNS has come under attack, or after it has suffered downtime with a non-malicious cause, that CIOs start thinking about DNS strategically….When it comes to critical infrastructure such as DNS, the first step for CIOs is recognizing the fact that a company’s domain name is not only the online ambassador for its brand, but also the glue that holds the whole Internet-based business together. From there, the appropriate strategic decisions will surely follow.

AFNIC, the French registry, has kicked off DNSSEC deployment with a series of activities this month. It announced it has DNSSEC-signed the country-code top-level domains (ccTLDs) .fr and .re for France and the Reunion Islands, and that it has published the DNSSEC keys for .yt and .tf in the root zone, the ccTLDs for Mayotte and the Territory of the French Southern and Antarctic Lands, respectively.

This week, beginning on September 20, AFNIC will release version 3 of “ZoneCheck,” its DNS configuration test tool, a free software tool that integrates DNSSEC configuration tests. It is available on www.zonecheck.fr.  You can read AFNIC’s issue paper on DNSSEC here.

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