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.