Archive for category Uncategorized

Labs around the world enabling DNSSEC

IBM705 from US Social Security Agency archives

In addition to planning for DNSSEC and applying metrics, Government and TLD registry labs around the world are producing tools that enable the deployment of DNSSEC.

In the case of the ccTLDs, these same countries are leading in the adoption of DNSSEC.  The rest of us benefit from their sharing their work.  Following are some of the labs and what they provide.

CZ.NIC Labs (ICANN 44 is being hosted by CZ.NIC):

NLnet Labs:

  • Unbound validating recursive and caching DNS resolver
  • Dnssec-Trigger local Unbound server for end-system validation
  • NSD authoritative only, high performance, simple and open source name server
  • DNS Check DNS server checking and error reporting

Sandia National Laboratories:

  • DNSViz DNS visualization tool

US DHS S&T Cyber Securtity R&D-funded:

Verisign Labs:

1 Comment

FCC recommendations promote DNSSEC capability

The US Federal Communications Commission‘s Communications Security, Reliability, and Interoperability Council (CSRIC) has come out with recommendations to ensure that end-users’ ability to use DNSSEC is not impaired by ISP infrastructure.  The report is not yet out, but there is a fact sheet and a press release  that states:

DNS Best Practices:

CSRIC recommended that ISPs implement best practices to better secure the Domain Name System. DNS works like a telephone book for the Internet, but lack of security for DNS has enabled spoofing, allowing Internet criminals to coax credit card numbers and personal data from users who do not realize they are on an illegitimate website. DNSSEC is a set of secure protocol extensions that prevent such fraudulent activity. This recommendation is a significant first step toward full DNSSEC implementation by ISPs and will allow users, with software applications like browsers, to validate that the destination they are trying to reach is authentic and not a spoofed website.

The slide presentation (2.7MB pptx) on DNSSEC from today’s meeting is available from the CSRIC III web site, as are FCC chairman Genachowski’s remarks.  A video of the meeting is also on the FCC’s web site.

No Comments

Menu for .UA DNSSEC deployment

Dmitry Kohmanyuk

Dmitry Kohmanyuk

At ICANN43, Steve Crocker, ICANN Board Chairman and DNSSEC Deployment Initiative memember, met with Dmitry Kohmanyuk, the .UA hostmaster.  On the back of  a menu for the Gala Dinner, Dmitry outlined the plans for .UA DNSSEC deployment.

Crocker notes

This makes the set of DNSSEC deployment maps I presented on the 14th obsolete, and I’m very happy about that.


Menu with schedule

Planned .UA DNSSEC a of 14 March 2012

(As with other menus, substitutions may occur)

  • Experimental:  1 March 2012
  • Announcement: 3 December 2011
  • Partial Operation: 1 April 2012
  • DS in Root: 15 April 2012
  • Full Operation: 1 December 2012




1 Comment

Have some DNSSEC with your Pi

Happy Pi Day (to the 36th digit)! by Mykl Roventine

If Pi Day (3/14 in month/day format) isn’t already enough to make this Wednesday a great day, the DNSSEC workshop at ICANN 43 will be streamed live.  The streaming information, detailed agenda, and presentations are all available on the DNSSEC Workshop page.  The workshop is scheduled to start at 8:30AM CST (UTC-6).


No Comments

DNSSEC in ccTLDs, Past, Present, and Future

This animated GIF shows announced, estimated, and actual DNSSEC adoption by ccTLDs from January 2006 through July 2014 as of March 6, 2012.  The map is a work in progress.  We’re pretty sure about the past and present.    If you manage a ccTLD and have a schedule for deployment or have updates/corrections, let us know at info @  We’d like to see a more colorful, even completely red, map in the future.

Animated GIF of DNSSEC adoption in TLDs

Animated GIF of DNSSEC adoption in TLDs


  • Experimental:  We have reason to believe the ccTLD is experimenting with DNSSEC.
  • Announced:  The ccTLD has announced that they will support DNSSEC.
  • Partial Operation:  The ccTLD is signed, though possibly doesn’t have its DS in the root or  isn’t taking signed delegations.
  • DS in Root:  The ccTLD has placed its DS in the root.
  • Operational :  The ccTLD is signed, its DS is in the root, and it is taking signed delegations.


No Comments

DNSSEC in Higher Education — 1% isn’t enough

Institutions of higher education throughout the world have been key advocates of Internet technologies.  The .EDU gTLD is signed, however, a recent survey of .EDU  names shows that only about one percent are signed.  While this is a greater than the Internet as a whole, it is far less than TLDs that are requiring or otherwise strongly advocating DNSSEC.

On the pedestrian side, colleges and universities present a microcosm of the Internet as a whole, replete with cyber attacks, some of which could prevented by a combination of DNSSEC signing and validation.  On the academic side, DNSSEC adds to the authenticity of the academic work product.

If you teach at, work at, attend, or attended any of the following, congratulations — your school is signed:

We’re sorry if your school is signed and we missed it.  Our survey was limited to the .EDU gTLD.  We know that many schools outside of the US are under their countries’ academic second-level domains or directly under their countries’ ccTLDs.  If your school isn’t signed,  DNSSEC resources tailored to Higher Education are published by:

  • EDUCAUSE, the nonprofit association whose mission is to advance higher education by promoting the intelligent use of information technology, manages the .EDU TLD and worked to get it signed.   They have a collection of resources for their members and others throughout the Internet.
  • Internet2, the advanced networking consortium led by the U.S. research and education community, is also supporting DNSSEC within its membership.  They have a DNS SIG.

The DNSSEC Deployment Initiative is ready to help.  Contact us at info @ to discuss DNSSEC presentations for conferences and meetings.



, , ,

1 Comment

US Government Agencies will be required to validate

The US National Institute of Standards and Technology (NIST) announced the release of the fourth revision of Special Publication 800-53: Security and Privacy Controls for Federal Information Systems and Organizations last week.   NIST SP 800-53r4 (3.3MB PDF) is the latest revision of the FISMA controls that apply to all Federal information systems.  This revision includes changes to the two DNSSEC related security controls (SC-20 and SC-21).

SC-20 combines the previous Enhancement on provisioning of DS RR’s in the parent zone and make it part of the base control.

SC-21 is changed to require “[t]he information system requests and performs data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.”  This means that all Federal systems must either request and validate DNSSEC responses, or have a trusted link to a validator that can provide that service for the system. Control SC-21 is also changed to be required for all security levels (Low, Moderate and High).

As with previous revisions of NIST SP 800-53, the final set of controls are official twelve months from the final publication date (estimated to be July 2012). The public comment period for this draft ends on April 6th. Comments should be sent to the FISMA project team at [email protected]


No Comments

DNSSEC now available in .AT

After signing .AT,  providing registrars an opportunity to test DNSSEC enhancements, and performing their own testing, began accepting DNSSEC delegations on February 29.

No Comments

Can your links handle DNSSEC sized answers?

[This is an updated version of a blog post from about 2 years ago to reflect current situation and fix links].

According to various surveys a large majority of recursive resolvers and authoritative servers are DNSSEC ready.  This is measured by looking at the resolver  that sends queries with the ENDS0 and DO bit set.  Similarly, resolvers can measure this by seeing how many authoritative servers return answers with EDNS0 option.

When .GOV was signed some sites noticed that many queries for .GOV took a longer time and resulted in TCP queries.  When .ORG was signed there was a large spike in TCP queries to .ORG servers. Both of these spikes can be attributed to large DNSSEC answers that did not get through “narrow” DNS links. To be fair, in both cases the volume of TCP queries was amplified by “mistakes” in signing the zones.

Both zones are signed by NSEC3 (which is fine) but NSEC3 has certain properties that make some of the answers larger than if NSEC was used. GOV originally used 2048 bit RSA zone signing key; this means each signature was 287 bytes long.  In an NSEC3 signed zone each negative answer requires 4 signed RRsets, the SOA record plus 3 NSEC3 answers, resulting in answers over 1500 bytes long.  ORG’s mistake was to set the TTL of all records at the zone apex to 0, which effectively killed all negative caching for that zone. Once this was fixed, the TCP traffic volume fell. At the height of the TCP flood ORG’s servers were answering about 15% of all queries over TCP.

Both mistakes are actually a good thing, as they highlight certain important issues for future DNSSEC deployment and can help us avoid them in the future. GOV’s spike of TCP connections was primarily caused by “narrow” pipes; i.e. links that cannot handle DNS packets over certain size.  In this discussion we will focus on the size issue and how to address it.  ORG’s mistake further amplified TCP traffic from resolvers that are sitting behind “narrow” pipes and have ill-chosen fallback mechanisms when big packets cannot get through.

Some technical background: DNS, as defined 25+ years ago, specified a maximum payload size of 512 bytes over UDP.  This was appropriate at the time given the links available.  RFC2671, issued in August 1999, specifies a mechanism to extend DNS packets in various ways including specifying larger messages.  The RFC recommended larger message size of 4096 has become quite common, but because one of the ugly truths of the Internet is that no path is wider than the narrowest link, the large DNS answer does not get through all the time.

Question: “Why are there narrow links?”

There are number of reasons why large UDP messages cannot pass through links.  Most links close to edges use Ethernet frames that are about 1500 bytes long.  Thus, large TCP and UDP messages are broken up into units (fragments) smaller than 1500 bytes.  A large number of links do not allow UDP fragments to pass through or only the first fragment is passed on.  There are multiple reasons why this is the case:

– Some implementations in routers/NAT boxes do not know what to do with UDP fragments

– Some firewalls outlaw fragments as a security risk.

– Some firewalls “know” that all DNS are less than N bytes, thus any DNS packet larger that that is bad and is dropped.

If your site wants to use DNSSEC either as a consumer (in resolution) or as a producer (answering for signed zones) it is important that you know how large a message will get through your links, and if the path is restricted, tune your DNS systems to avoid transmission of packets that will not get through. The leading DNSSEC capable DNS resolver implementations – Bind, Unbound, CNS and MS DNS – have to set/change the advertised UDP size.  When DNS resolution problems occur it is human nature to want to point fingers at the remote site, but it is just as likely that the problem is local.  Fortunately, there are a number of tools that can be used to check resolvers and their paths:

–  DNS-OARC has a  tool and this Perl script (dns-path) can be used to check all the local resolvers to my code

– DNSFUNNEL is a sub tool in Vantage test tools

– NetAnzlr from UCB is a good network testing tool

Configuring DNS resolvers to ask for smaller answer (using 1480 as example):


in options set edns-udp-size=1480

Unbound: 1.4.0+ (older versions do not support) set parameter

edns-buffer-size: 1480

Update: 18 months after the root was signed, there are no reports about  big problems related to link sizes, this is a result of people checking their links and zone publishers being aware of the issue and keep their RRset’s small enough that the packet size does not become an issue.

No Comments

DNSSEC Validating Stub Resolver (vsResolver)

In order to experiment with validation and provide as simple a working example as possible to others, I have written vsResolver, a stub DNSSEC validator that can be run from the command line of any Windows, Mac or Linux end system. I hope you find it useful and that it helps you understand the complexities of DNSSEC validation.

vsResolver is a validating stub resolver that works in conjunction with a DNSSEC-aware recursive resolver to answer a DNS query with a validated result. vsResolver implements the DNSSEC validation protocol described in RFC’s RFC4033, RFC4034 and RFC4035.  vsResolver is not in itself a recursive resolver — it issues DNS queries to a specified DNS recursive resolver to do name resolution. vsResolver does however issue multiple additional queries that are necessary to perform DNSSEC validation. vsResolver works well with a validating recursive resolver such as the BIND recursive resolver from ISC or the Unbound recursive resolver from NLnet labs.

The audience for vsResolver is software developers and system administrators who are interested in an example of a DNSSEC validation algorithm, or who might be interested in a command line domain validation script. vsResolver is comparable to the tools available from Sandia Labs and Verisign Labs. vsResolver differs in that it is usable from the command line, and that it comes as BSD-licensed source code.

You might wonder why you would need vsResolver in addition to a validating recursive resolver. The simple answer is — you don’t. Unbound does validating recursive resolution all by itself. The point of vsResolver is to provide an example of DNSSEC validation that is as simple and straightforward as possible. vsResolver is written in python, a high-level language. (To use vsResolver, you need to have python, dnspython and pycrypto installed on a computer.) vsResolver leverages the dnspython DNS name resolution library and the pycrypto cryptography library and so does not re-implement any code unnecessarily. vsResolver is synchronous, so there are no confusing asynchronous interactions going on. vsResolver can generate diagnostic output that directly reflects the steps the algorithm takes to validate and determine the security outcome of a query. This output is directly comparable to the output from Verisign Labs’ DNSSEC debugger. This provides a way to verify the vsResolver’s security outcome or diagnose problems in the vsResolver validation algorithm.

vsResolver can function as either a utility program or as a software library. That is, vsResolver can run as a command line utility to determine the DNSSEC status of specific domains and resource record types. Alternately, the vsResolver API can be called from python code to do a DNS query and provide the results of that query along with its DNSSEC status, called a Security Outcome, in a variety of ways.

A DNS query is a request for a resource of a particular type from a particular domain. For example, a DNS query might ask for the A data (e.g., the IPV4 Address data) from the domain. The result of such a DNS query is the resource data contained in the resource records that resulted from the query. vsResolver provides an additional Security Outcome that indicates the answer’s validity.

The Security Outcome has one of three values: Secure, Provably Insecure, or Bogus. A Secure outcome means that the DNS data returned in the result has a cryptographically validated chain of trust back to a trust anchor. A Provably Insecure outcome means that the result has been verifiably proven to not have a chain of trust back to a trust anchor (in other words, the result is proven to not be signed). A Bogus outcome means that the result is verifiably proven to have a secure chain of trust back to a trust anchor, but the chain of trust fails validation for one reason or another (in other words, the result is proven to be signed but the chain of trust is not valid).

vsResolver provides results within the context of one of three behaviors. In SecureOnly behavior mode, vsResolver only provides a normal result (e.g., a function return) if the answer cryptographically validates to be secure. Otherwise, vsResolver raises a BadResult exception. The BadResult exception contains information to determine whether the answer was actually insecure or bogus. In NoBogus behavior mode, vsResolver provides a normal result if the answer validates to be secure or provably insecure. In Permissive behavior mode, vsResolver provides a normal result regardless of the security outcome.

SecureOnly would be the preferred mode of operation except that many domains are not yet signed. For that reason, NoBogus is the recommended mode of operation for the near term until domains are signed as a matter of course. Operating in Permissive mode is not recommended at all, except for debug, as there is no reason to accept a bogus DNS answer.

vsResolver can run with three modes of trust anchors specified:  root trust anchor only, root trust anchor plus additional trust anchors, or additional trust anchors only.  Root trust anchor only is the normal mode of operation.  In this mode vsResolver uses the root trust anchor as the root of the validation chain of trust.   Root trust anchor plus additional trust anchors allows for the validation of domains that validate to disconnected trust anchors as well as validation of domains that validate to the root trust anchor.  For example, this mode allows for the validation of a signed subdomain of a domain that is itself unsigned. Finally, additional trust anchors only mode only validates domains that have chains of trust to specific trust anchors; for example, organization A only trusts organization B and no other.

vsResolver can determine the key of the root trust anchor on its own, at least for the near term, as it contains the signature of the present root key. The user can specify alternate signatures for the root key, for use in cases such as when the root key changes, or the user can specify that the root key should not be used. In addition, the user can specify the keys for additional trust anchors, which can be used.

We hope that vsResolver will be helpful as an example of a DNSSEC validation algorithm that can be used directly, or that can serve as an outline for the implementation of DNSSEC validation in other applications.

vsResolver is available at SourceForge.

No Comments