ISC Technical Note Series

This memo describes a methodology in use inside ISC which may be of use to other members of the Internet technical community.

Use of the methods and formats depicted herein is free of any and all licence or other encumberance.

Copyright Notice

Copyright (C) Internet Systems Consortium, Inc. (2006). All Rights Reserved.

Distribution of this memo is unlimited if full attribution is given.

Abstract

Domain Name System Security (DNSSEC) relies on a top-down certification chain whereby security information about each zone is introduced by its parent. This memo describes an instance of local policy whereby security information can be introduced by cooperating third parties, thus enabling deployment of DNSSEC in zones whose parents are not yet secure. This is an early deployment aid, and is not intended to replace DNSSEC's top-down certification chain.

1. Introduction and Overview

1.1. Domain Name System Security (DNSSEC) [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.)[RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.) relies on a top-down certification chain whereby security information about each zone is introduced by its parent. For example, the root zone introduces the security status of each top level domain (TLD) zones, and a top level domain zone introduces the security status of each of its subordinate zones, and so on. This model is sometimes referred to as "certification follows delegation", since a parent zone is already responsible for introducing the existence of child zones through "delegation", and DNSSEC simply adds new information (called "certification") to the delegation process.

1.2. A validating resolver is permitted to use external, non-DNSSEC certification data in its pursuit of trust. For example, the root zone has no parent, and so its certification must be external to the DNSSEC protocol. Current implementations use static configuration elements to introduce a "trust anchor" for the root zone or for other zones whose certification information is learned by external methods. In DNSSEC terminology, certification by external non-DNSSEC methods is called "local policy".

The authors are also aware of several proposals for updating a validating resolver's trust anchors dynamically, either by protocol extensions or by new out of band management tools. Such proposals are beyond the scope of this memo.

1.3. This memo describes an instance of local policy whereby certification information can be introduced and shared by cooperating parties, thus enabling deployment of DNSSEC in zones whose parents are not yet secure. This is desirable since in the early days of DNSSEC deployment, there are too few secure second level domain (SLD) zones to justify the cost and complexity of securing some of the larger top level domain (TLD) zones. "Not worth its deployment cost" could be a self-fulfilling prophesy unless something is done to break stiction and generate momentum.

1.4. The purpose of DLV processing is to discover certification information by means other than delegation-time DNSSEC metadata and static configuration data. A DLV-capable validator will have a way to specify a valid name in the real DNS (e.g., DLV.ISC.ORG). In the absence of available DNSSEC metadata from a delegating parent zone, a DLV capable validating resolver will use signed DLV Resource Records (RRs) from this trusted alternative security root to assess whether a zone is secured, and if so, by what keys.

1.5. It is expected that a DLV-capable, validating resolver will be configured with one or more alternate security roots, each corresponding to a distinct part of the real DNS namespace. This memo does not describe non-distinct or overlapping mappings of real DNS namespace to alternative security domains, but that may be a topic for future work in this area. In ISC BIND9 9.3.2 and BIND9 9.4.0 DLV can be enabled with the "dnssec-lookaside" view option, which could look like this:

          dnssec-lookaside "." trust-anchor "DLV.ISC.ORG";
          dnssec-lookaside "MIL" trust-anchor "DLV.NIC.MIL";

In this example, the alternative security domain for real DNS names under "MIL" is "DLV.NIC.MIL" (as that is the most enclosing), whereas for all other real DNS names, the alternate security root is simply "DLV.ISC.ORG".

1.6. This is an early deployment aid, not intended to permanently replace the "certification follows delegation" model, or to scale to the size of the Internet. Once the DNSSEC community has matured, the methods described in this memo are not expected to be of any further use.

2. Background

Certain aspects about DNSSEC's design which constrain the design of validating resolvers must be kept clearly in mind while evaluating the need for, and effectiveness of, DLV.

2.1. TRAVERSAL. Even though the delegation (NS) and certification (DS) hierarchies have the same shape, they are traversed very differently. A validating resolver might traverse an NS chain all the way from DNS's root down to a specific answer before being able to begin the process of validating DNSSEC signatures on both the answer and the certification (DS) chain.

2.2. COHABITATION. Because of opportunism in both the caching and response models, not all zone cuts (NS RRsets) will necessarily be exposed by every downward traversal from the root to a specific answer. Take for example a server who was authoritative for both the root and the top-level ARPA domains. In response to a query for 51.0.0.10.IN-ADDR.ARPA, such a server could expose (by a delegation response) the IN-ADDR.ARPA zone cut without also exposing the ARPA zone cut -- yet the ARPA zone cut and its associated DS RRset could be an essential part of the complete certification chain. It is sometimes necessary when validating a DS chain to iteratively "strip labels" in order to expose intermediate zone cuts (NS+DS) that were hidden during the downward traversal. This has been called "the grandparent problem."

2.3. SPOOFING. Because most DNS transactions use UDP, and because UDP source addresses are inherently untrustworthy, no unauthenticatable data received via UDP can ever be taken at face value. If a signature does not match, or if expected security metadata is not present, or if DS key hashes don't match, or indeed if anything other than completely successful validation occurs, then all missing or mismatched data should be re-fetched using a TCP transport, to ensure that it really is missing or mismatched and not merely the result of a "man in the middle" attack. Such re-fetching must be done at validation time, before the untrustworthy message is consumed, cached, or forwarded. This is a weakness in DNSSEC, unrelated to DLV.

2.4. AGGRESSIVE NEGATIVE CACHING. In normal DNSSEC processing, the NSEC RR does not affect caching-recursive operation. As we will see, DLV requires that cached NSEC RRs be visible to the modified validating resolver, even though they are not currently used to generate synthetic negative answers. We will refer to DLV's use of NSEC in this way as "off-the-wire aggressive negative caching" (OTWANC). With OTWANC, it becomes necessary to validate the target name of an NSEC RR, which is otherwise unconstrained by the protocol and could span a namespace beyond its zone of origin. Under OTWANC, an NSEC target name must fall within the same zone as its owner name, since no NSEC can logically speak for out-of-zone names.

2.5. READINESS. A validating resolver will always signal its desire to receive DNSSEC metadata. DLV prescribes a method of handling responses only when DNSSEC metadata is not expected in the response, which occurs if the parent's delegation included no security information and the validating resolver has no static configuration data indicating a zone's security status.

3. Validation

DLV processing is only possible in a minority of DNSSEC validation cases, which are detailed as follows:

3.1. SECURED. In any case where normal DNSSEC validation results in a confident assertion of data authenticity using a complete certification chain that terminates in a known trust anchor, that assertion is considered authoritative and no additional processing is described by this memo.

3.2. BOGUS. When security metadata is expected, either due to a parent DS RR, or to static configuration data, or to previously discovered DLV information, and that security metadata is missing or invalid, then a DNS data error or server configuration error has occurred, and no DLV processing is possible. If a validating resolver becomes confident that expected security metadata is indeed missing or mismatched, then this condition should be signalled to the application.

3.3. PROVABLY UNSECURED. A DNS answer is provably unsecured, from the resolver's perspective, when either there was no trusted-key at or above the QNAME or the trust chain encountered a DS RRset at a delegation point for which the resolver could not find a supports DS RR (based on algorithm and hash types) or encountered a delegation where there wasn't a DS RRset. In the first case the answer became unsecured at ".", in the later cases it became unsecured at the delegation point. DLV can occur in this case.

4. DLV Processing

4.1. A query name about which no security metadata is expected, and for which either none is available, or that which is available has no certification chain to a trust key, will be used as the starting point in a label-stripping search under each configured DLV alternate security root.

4.2. Label-stripping is the simple expedient of trying the original domain, then trying successive parent domains we reach the point where the normal DNSSEC validation became unsecured. The DLV alternate security root will be appended for each lookup.

For example, given an initial domain name WWW.VIX.COM, a DLV alternate security domain of DLV.ISC.ORG and a trusted-key for "." and an unsecured delegation for COM in the root zone the DLV lookups would be:

      WWW.VIX.COM.DLV.ISC.ORG.
          VIX.COM.DLV.ISC.ORG.
              COM.DLV.ISC.ORG.

This search can be short-circuited by OTWANC. For example, if a validating resolver had previously learned the following:

      $origin COM.DLV.ISC.ORG.
      VERISIGN nsec XIMIAN ( dlv )

then it would know that no names exist between VERISIGN.COM.DLV.ISC.ORG and XIMIAN.COM.DLV.ISC.ORG, and could avoid the first two queries in the above example. Note that in OTWANC, an NSEC targetname outside its ownername's zone would be treated as if it were equal to the ownername's zone name.

Normal negative caching would allow the validating resolver to avoid asking about COM.DLV.ISC.ORG more than once per TTL interval, but it is expected that OTWANC will be far more efficient than normal negative caching at suppressing DLV-related queries.

4.3. Security metadata held in a DLV alternate security root uses type code (DLV) 32769 whose RDATA format is described in [RFC4431] (Andrews, M. and S. Weiler, “The DNSSEC Lookaside Validation (DLV) DNS Resource Record,” February 2006.). All data in the DLV alternate security root will be signed using a key that participating validating resolvers will statically configure as a trusted-key. Note that a DLV alternate security root might have zone cuts under it for administrative reasons, and that full DNSSEC processing should be performed, including signed delegations using DS.

4.4. If data is encountered during DLV processing which is "UNSECURED" or "SECURED, CERT-CHAIN UNKNOWN" then DLV has failed. DLV will not be performed recursively to find missing metadata inside the DLV alternate security root. Validation failure is returned to the client in this case.

4.5. If it can provably be shown that no DLV RRset exists then "UNSECURED" returned to the caller.

4.6. Having found and verified the DLV RRset it can than be used to validate the corresponding DNSKEY RRset in a similar manner to how a DS RRset is used to validate a the DNSKEY RRset. Firstly look for suitable DS records with supported algorithms and hashes. If none are found return "UNSECURED" to the caller. Next look for a DNSKEY records which matches a remaining DLV record, if found and there is a RRSIG for the DNSKEY RRset which matches this DNSKEY the the DNSKEY RRset is proved to be valid. If a matching DLV record cannot be found, a DNSKEY pair with a good matching RRSIG then validation failure is returned to the client.

4.7. Having found and verified the DNSKEY RRset perform a normal DNSSEC validation using DNSKEY in the DNSKEY RRset as trust-anchors. The results of this validation process are returned to the client.

5. Acknowledgements

This idea originated with David Conrad, with significant detailed design work by Paul Vixie, Johan Ihren, Suzanne Woolf, Sam Weiler, Michael Graff, Mark Andrews, Mark Kosters, and Rob Austein. Document reviewers included Matt Larson, Bill Manning, and Mike St. Johns. Any remaining errors are the exclusive responsibility of the authors.

6. References

Authors' Addresses