Network Working Group E. Lewis Request for Comments: 3090 NAI Labs Category: Standards Track March 2001 DNS Security Extension Clarification on Zone Status Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThe definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated.
A name server performing dynamic updates needs to know whether a zone being updated is to have signatures added to the updated data, NXT records applied, and other required processing. In this case, it is conceivable that the name server is configured with the knowledge, but being able to determine the status of a zone by examining the data is a desirable alternative to configuration parameters. A delegating zone is required to indicate whether a child zone is secured. The reason for this requirement lies in the way in which a resolver makes its own determination about a zone (next paragraph). To shorten a long story, a parent needs to know whether a child should be considered secured. This is a two part question. Under what circumstances does a parent consider a child zone to be secure, and how does a parent know if the child conforms? A resolver needs to know if a zone is secured when the resolver is processing data from the zone. Ultimately, a resolver needs to know whether or not to expect a usable signature covering the data. How this determination is done is out of the scope of this document, except that, in some cases, the resolver will need to contact the parent of the zone to see if the parent states that the child is secured.
An island of security begins with one zone whose public key is pre- configured in resolvers. Within this island are subzones which are also secured. The "bottom" of the island is defined by delegations to unsecured zones. One island may also be on top of another - meaning that there is at least one unsecured zone between the bottom of the upper island and the root of the lower secured island. Although both subarea1.region1.test. and region2.test. have both been properly brought to a secured state by the administering staff, only the latter of the two is actually "globally" secured - in the sense that all DNSSEC resolvers can and will verify its data. The former, subarea1, will be seen as secured by a subset of those resolvers, just those appropriately configured. This document refers to such zones as being "locally" secured. In RFC 2535, there is a provision for "certification authorities," entities that will sign public keys for zones such as subarea1. There is another document, [RFC3008], that restricts this activity. Regardless of the other document, resolvers would still need proper configuration to be able to use the certification authority to verify the data for the subarea1 island.
Overlapping islands of security introduce no conceptually interesting ideas and do not impact the protocol in anyway. However, protocol implementers are advised to make sure their code is not thrown for a loop by overlaps. Overlaps are sure to be configuration problems as islands of security grow to encompass larger regions of the name space. RFC 2535, section 2.3.4, these words seem to conflict with the need to have the parent "state" something about a child: There MUST be a zone KEY RR, signed by its superzone, for every subzone if the superzone is secure. This will normally appear in the subzone and may also be included in the superzone. But, in the case of an unsecured subzone which can not or will not be modified to add any security RRs, a KEY declaring the subzone to be unsecured MUST appear with the superzone signature in the superzone, if the superzone is secure. The confusion here is that in RFC 2535, a secured parent states that a child is secured by SAYING NOTHING ("may also be" as opposed to "MUST also be"). This is counter intuitive, the fact that an absence of data means something is "secured." This notion, while acceptable in a theoretic setting has met with some discomfort in an operation setting. However, the use of "silence" to state something does indeed work in this case, so there hasn't been sufficient need demonstrated to change the definition.
RFC 2535. The definition of a secured zone is an update to section 3.4 of the RFC. Section 3.4 is updated to eliminate the definition of experimental keys and illustrate a way to still achieve the functionality they were designed to provide. Section 3.1.3 is updated by the specifying the value of the protocol octet in a zone key. RFC 2119]. Currently, only "MUST" is used in this document. RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value of DNSSEC (3) or ALL (255). The definition updates RFC 2535's definition of a zone key. The requirement that the protocol field be either DNSSEC or ALL is a new requirement (a change to section 3.1.3.) 2.b On-tree Validation - The authorization model in which only the parent zone is recognized to supply a DNSSEC-meaningful signature that is used by a resolver to build a chain of trust from the child's
keys to a recognized root of security. The term "on-tree" refers to following the DNS domain hierarchy (upwards) to reach a trusted key, presumably the root key if no other key is available. The term "validation" refers to the digital signature by the parent to prove the integrity, authentication and authorization of the child's key to sign the child's zone data. 2.c Off-tree Validation - Any authorization model that permits domain names other than the parent's to provide a signature over a child's zone keys that will enable a resolver to trust the keys. RFC 2535, section 3.2) and relies on a key certification chain that parallels the delegation tree (on- tree validation). Globally secured zones are defined by the following rules. 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least one zone signing KEY RR (2.a) of a mandatory to implement algorithm in the set. 2.1.b. The zone's apex KEY RR set MUST be signed by a private key belonging to the parent zone. The private key's public companion MUST be a zone signing KEY RR (2.a) of a mandatory to implement algorithm and owned by the parent's apex. If a zone cannot get a conforming signature from the parent zone, the child zone cannot be considered globally secured. The only exception to this is the root zone, for which there is no parent zone. 2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies RFC 2535, section 2.3.2.) Note: there is some operational discomfort with the current NXT record. This requirement is open to modification when two things happen. First, an alternate mechanism to the NXT is defined and second, a means by which a zone can indicate that it is using an alternate method. 2.1.d. Each RR set that qualifies for zone membership MUST be signed by a key that is in the apex's KEY RR set and is a zone signing KEY RR (2.a) of a mandatory to implement algorithm. (Updates 2535, section 2.3.1.) Mentioned earlier, the root zone is a special case. The root zone will be considered to be globally secured provided that if conforms to the rules for locally secured, with the exception that rule 2.1.a. be also met (mandatory to implement requirement).
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.