Archive for category Uncategorized

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):

• DNSSEC Hardware Tester 
• DNSSEC Validator Extension for Web Browsers
• Knot Authoritative DNS Server

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

Sandia National Laboratories:

• DNSViz DNS visualization tool

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

• DNSSEC-Tools

Verisign Labs:

• DNSSEC Debugger DNSSEC analyzer

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.

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

[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):

Bind-9:

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.

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 comcast.net 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.