S. Weiler 22 May 2005 DNSSEC Lookaside Validation (DLV) draft-weiler-dnssec-dlv-pre00.txt Copyright Notice Copyright (C) Samuel Weiler (2005). Abstract DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNSSEC trust anchors outside of the DNS delegation chain. It allows resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or refuse to publish DS records for their children. 1. Introduction DNSSEC [RFC4033] authenticates DNS data by building public-key signature chains along the DNS delegation chain from a root of trust, ideally the DNS root. Due to a myriad of technical and political concerns, it appears unlikely that many delegation-heavy zones, including the root and most generic top level domains (gTLDs), will sign their zones in the near future, which leaves DNS resolvers with no means to validate data from the children of those zones without maintaining a large number of preconfigured keys. This document describes a way to publish trust anchors in the DNS but outside of the normal delegation chain. Some design trade-offs leading to the mechanism presented here are described in [INI19]. 2. Architecture DNSSEC Lookaside Validation allows a set of well-known domains, called "DLV domains", to publish secure entry points for zones that are not their own children. With DNSSEC, validators may expect a zone to be secure when they have one of two things: a preconfigured trust anchor for the zone or a validated DS for the zone in its parent. DLV adds a third mechanism: an entry in a DLV domain. Whenever a DLV domain publishes a DLV RRset for a zone, a resolver may expect the named zone to be signed. Absence of a DLV RRset for a zone does not necessarily mean that the zone should be expected to be insecure; if the resolver has another reason to believe the zone should be secured, validation of that zone's data should still be attempted. 3. DLV Domains A DLV domain includes trust statements about descendants of a single zone, called the 'target' zone. For example, the DLV domain trustbroker.example.com could target the .org zone and the DLV domain bar.example.com could target the root. A DLV domain contains one or more DLV records for each of the target's descendant zones that have registered security information with it. For a given zone, the corresponding name in the DLV domain is formed by replacing the target zone name with the DLV domain name. For example, assuming the DLV domain trustbroker.example.com targets the .org zone, any DLV records for the zone example.org can be found at example.trustbroker.example.com. DLV records for the org zone can be found at the apex of trustbroker.example.com. A DLV domain SHOULD NOT contain data other than DLV records, appropriate DNSSEC records validating that data, the apex NS and SOA records, and, optionally, delegations. To gain full benefit from aggressive negative caching, described in Section 6, a DLV domain SHOULD NOT use minimally-covering NSEC records, as described in [EPSILON]. 4. DLV Resource Record The DLV resource record has exactly the same wire and presentation formats as the DS resource record, defined in [RFC4034] and RFC3658. It uses the same IANA-assigned values in the algorithm and digest type fields as the DS record. (Those IANA registries are known as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm Numbers" registries.) Unlike the DS record, the DLV record MUST NOT appear on the parent's side of a zone cut. Consequently, DLV records to not require the special processing described in section 2.2.1 of RFC3658. DLV records MAY appear at the apex of a zone. 5. Resolver Behavior, Overview When configured with a trust anchor for a DLV domain, a resolver SHOULD attempt to validate all queries at and below the target of that DLV domain. To do validation using DLV, a resolver looks for a (validated) DLV RRset applicable to the query and uses it as though it were a DS RRset to validate the answer using the normal procedures in RFC4035 Section 5. The resolver continues to search for applicable DLV RRsets and attempt validation using them until either the answer is validated as Secure or all possible applicable DLV records have been checked. If any of the applicable DLV records led to a Secure result, the answer is treated as Secure. If all of the DLV records led to Insecure validation results, the answer is treated as Insecure. And if no DLV records led to Secure results and at least one led to a Bogus result, the answer is treated as Bogus. The choice of which DLV record(s) to use, and in what order, has a significant impact on the query load seen at DLV domain authoritative servers. Consequently, resolvers are advised to closely follow the algorithm in the following section. More detailed discussion of this algorithm and other possible choice can be found in [INI19]. 5.1 Resolver Behavior, Detail To minimize load on the DLV domain's authoritative servers as well as query response time, a resolver SHOULD accept any Secure validation result (as described in RFC4035 Section 4.3) as decisive and SHOULD NOT attempt to exhaustively search for all possible DLV RRsets applicable to the QNAME after a Secure result has been found. Furthermore, the resolver SHOULD use cached DLV RRsets and careful choice of queries to attempt to find a Secure validation result with the minimum number of queries to the DLV domain. Accordingly, a resolver SHOULD first attempt validation using any applicable (non-DLV) trust anchors. If the validation succeeds (with a result of Secure), DLV processing need not occur. If other (non-DLV) trust anchors failed to yield a Secure validation result, a resolver SHOULD then attempt to use any applicable cached DLV RRsets. For clarity, it may be possible for several DLV RRsets within a single DLV domain to be applicable to a given QNAME. Using the previous example of the bar.example.com DLV domain targeting the root and a QNAME of www.example.org, there could be four DLV RRsets of relevance: -- a DLV RRset at bar.example.com corresponding to the root's DNSKEY(s), -- a DLV RRset at org.bar.example.com, -- a DLV RRset at example.org.bar.example.com, and -- a DLV RRset at www.example.org.bar.example.com. If none of the cached DLV RRsets leads to a Secure result (or there are no applicable cached DLV RRsets), the resolver queries the DLV domain to attempt to find another of the applicable DLV RRsets. To minimize the number of queries to the DLV zone, it is suggested that the resolver start with a query for the least specific applicable DLV RRset (the one with the fewest labels), then progress to longer names. Section 8 discusses a slightly different strategy. Having found an applicable DLV RRset or received a proof that the requested record doesn't exist, the resolver MUST validate that RRset or non-existence proof using the normal procedures in Section 5 of RFC4035. In particular, any delegations within the DLV domain need to be followed, with normal DNSSEC validation applied. If validation of the DLV RRset leads to a result of Insecure (the DLV record is in an unsecured portion of the DLV tree), then it SHOULD NOT be used. If the validation of the DLV RRset leads to a result of Secure, then resolver then treats that DLV RRset as though it were a DS RRset for the applicable zone and attempts validation using the procedures described in RFC4035 Section 5. If any such validation returns a Secure result, the answer is treated as Secure and DLV processing ends. Otherwise, the resolver continues to query for other applicable DLV RRsets until a Secure validation results or all applicable DLV RRsets have been exhausted. To avoid confusing authors of resolvers and protocol specifications, a resolver SHOULD NOT attempt to validate data from a DLV domain using DLV. 6. Aggressive Negative Caching To minimize load on authoritative servers for DLV domains, particularly those with few entries, DLV resolvers SHOULD implement aggressive negative caching, as defined in this section. Previously, cached negative responses were indexed by QNAME, QCLASS, QTYPE, and the setting of the CD bit (see RFC4035 section 4.7) and only queries matching the index would be answered from the cache. With aggressive negative caching, the resolver, in addition to checking to see if the answer is in its cache before sending a query, checks to see whether any cached and validated NSEC record denies the existence of the sought record(s). Using aggressive negative caching, a resolver will not make queries for any name covered by a cached and validated NSEC record. Furthermore, a resolver answering queries from clients will synthesize a negative answer whenever it has an applicable validated NSEC in its cache [unless the CD bit was set on the incoming query?]. 7. Overlapping DLV Domains It is possible to have multiple DLV domains targeting overlapping portion of the DNS hierarchy. For example, two DLV domains, perhaps operated by different parties, might target the same zone, or one DLV domain might target the root while another targets .org. The choice of precedence in these cases is left up to the implementation and MAY be exposed as a configuration option to the user. As a default, it is suggested that the most specific DLV domain be given precedence. 8. Optimization This section proposes an immature and untested proposed optimization to further reduce query load on DLV servers. Resolver side: resolvers, when making a DLV query, should ask for the most specific DLV record first. Authoritative server side: authoritative servers, when processing a DLV query, should include all DLV RRsets potentially applicable to a query in the Additional[???] section of the response as well as NSEC records proving the non-existence of any other applicable DLV records with the DLV domain. This optimization may preclude the use the delegations within a DLV domain. 9. Security Considerations Resolvers MUST NOT use a DLV record unless it has been successfully authenticated. Normally, resolvers will have a trust anchor for the DLV domain and use DNSSEC to validate the data in it. Aggressive negative caching increases the need for resolvers do some basic validation of incoming NSEC records before caching them. In particular, the 'next name' field in the NSEC record must be within the zone that generated (and signed) the NSEC. Otherwise, a malicious zone operator could generate an NSEC that reaches out of its zone -- into its ancestor zones, even up into the root zone -- and use that NSEC to spoof away any name that sorts after the name of the NSEC. We call these overreaching NSECs. More insidiously, an attacker could use an overreaching NSEC in combination with a signed wildcard record to substitute a signed positive answer in place of the real data. This checking is not a new requirement -- these attacks are a risk even without aggressive negative caching. However, aggressive negative caching makes the checking more important. Before aggressive negative caching, NSECs were cached only as metadata associated with a particular query. An overreaching NSEC that resulted from a broken zone signing tool or some misconfiguration would only be used by a cache for those queries that it had specifically made before. Only an overreaching NSEC actively served by an attacker could cause misbehavior. With aggressive negative caching, an overreaching NSEC can cause more broader problems even in the absence of an active attacker. This threat can be easily mitigated by checking the bounds on the NSEC. As a reminder, resolvers MUST NOT use the mere presence of an RRSIG or apex DNSKEY RRset as a trigger for doing validation, whether through the normal DNSSEC hierarchy or DLV. Otherwise, an attacker might perpetrate a downgrade attack by stripping off those RRSIGs or DNSKEYs. 10. IANA Considerations IANA has assigned DNS type code X to the DLV resource record from the Specification Required portion of the DNS Resource Record Type registry, as defined in RFC2929. The DLV resource record reuses the same algorithm and digest type registries already used for the DS resource record, currently known as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm Numbers" registries. 11. References [INI19] Weiler, S. Deploying DNSSEC Without a Signed Root. Technical Report 1999-19, Information Networking Institute, Carnegie Mellon University, April 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [EPSILON] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", draft-ietf-dnsext-dnssec-online-signing-00 (work in progress), May 2005. Acknowledgements David Conrad is to blame for the general idea of off-tree publication of trust anchors. Paul Vixie, Suzanne Woolf, and Johan Ihren contributed significantly to the exploration of possible resolver algorithms that led to this design. More about those explorations is documented in [INI19]. Johan Ihren and the editor share the blame for aggressive negative caching.