diff options
Diffstat (limited to 'contrib/bind9/doc/rfc')
| -rw-r--r-- | contrib/bind9/doc/rfc/index | 11 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3757.txt | 451 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc3901.txt | 283 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4025.txt | 675 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4033.txt | 1179 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4034.txt | 1627 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4035.txt | 2971 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4074.txt | 339 | ||||
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4159.txt | 171 |
9 files changed, 7706 insertions, 1 deletions
diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index index fb72ccc..5c588db 100644 --- a/contrib/bind9/doc/rfc/index +++ b/contrib/bind9/doc/rfc/index @@ -76,9 +76,9 @@ Addresses in the Domain Name System (DNS) 3364: Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) -3390: Internationalizing Domain Names In Applications (IDNA) 3425: Obsoleting IQUERY 3445: Limiting the Scope of the KEY Resource Record (RR) +3490: Internationalizing Domain Names In Applications (IDNA) 3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) 3492: Punycode:A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) @@ -90,5 +90,14 @@ Secret Key Transaction Authentication for DNS (GSS-TSIG) 3655: Redefinition of DNS Authenticated Data (AD) bit 3658: Delegation Signer (DS) Resource Record (RR) +3757: Domain Name System KEY (DNSKEY) Resource Record (RR) + Secure Entry Point (SEP) Flag 3833: Threat Analysis of the Domain Name System (DNS) 3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format +3901: DNS IPv6 Transport Operational Guidelines +4025: A Method for Storing IPsec Keying Material in DNS +4033: DNS Security Introduction and Requirements +4034: Resource Records for the DNS Security Extensions +4035: Protocol Modifications for the DNS Security Extensions +4074: Common Misbehavior Against DNS Queries for IPv6 Addresses +4159: Deprecation of "ip6.int" diff --git a/contrib/bind9/doc/rfc/rfc3757.txt b/contrib/bind9/doc/rfc/rfc3757.txt new file mode 100644 index 0000000..31890a4 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc3757.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group O. Kolkman +Request for Comments: 3757 RIPE NCC +Updates: 3755, 2535 J. Schlyter +Category: Standards Track NIC-SE + E. Lewis + ARIN + April 2004 + + + Domain Name System KEY (DNSKEY) Resource Record (RR) + Secure Entry Point (SEP) Flag + +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 (2004). All Rights Reserved. + +Abstract + + With the Delegation Signer (DS) resource record (RR), the concept of + a public key acting as a secure entry point (SEP) has been + introduced. During exchanges of public keys with the parent there is + a need to differentiate SEP keys from other public keys in the Domain + Name System KEY (DNSKEY) resource record set. A flag bit in the + DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. + The flag bit is intended to assist in operational procedures to + correctly generate DS resource records, or to indicate what DNSKEYs + are intended for static configuration. The flag bit is not to be + used in the DNS verification protocol. This document updates RFC + 2535 and RFC 3755. + + + + + + + + + + + + + + +Kolkman, et al. Standard Track [Page 1] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4 + 3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6 + 7. Internationalization Considerations. . . . . . . . . . . . . . 6 + 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 9.2. Informative References . . . . . . . . . . . . . . . . . 6 + 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + "All keys are equal but some keys are more equal than others" [6]. + + With the definition of the Delegation Signer Resource Record (DS RR) + [5], it has become important to differentiate between the keys in the + DNSKEY RR set that are (to be) pointed to by parental DS RRs and the + other keys in the DNSKEY RR set. We refer to these public keys as + Secure Entry Point (SEP) keys. A SEP key either used to generate a + DS RR or is distributed to resolvers that use the key as the root of + a trusted subtree [3]. + + In early deployment tests, the use of two (kinds of) key pairs for + each zone has been prevalent. For one kind of key pair the private + key is used to sign just the zone's DNSKEY resource record (RR) set. + Its public key is intended to be referenced by a DS RR at the parent + or configured statically in a resolver. The private key of the other + kind of key pair is used to sign the rest of the zone's data sets. + The former key pair is called a key-signing key (KSK) and the latter + is called a zone-signing key (ZSK). In practice there have been + usually one of each kind of key pair, but there will be multiples of + each at times. + + It should be noted that division of keys pairs into KSK's and ZSK's + is not mandatory in any definition of DNSSEC, not even with the + introduction of the DS RR. But, in testing, this distinction has + been helpful when designing key roll over (key super-cession) + schemes. Given that the distinction has proven helpful, the labels + KSK and ZSK have begun to stick. + + + + + + +Kolkman, et al. Standard Track [Page 2] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + + There is a need to differentiate the public keys for the key pairs + that are used for key signing from keys that are not used key signing + (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to + be sent for generating DS RRs, which DNSKEYs are to be distributed to + resolvers, and which keys are fed to the signer application at the + appropriate time. + + In other words, the SEP bit provides an in-band method to communicate + a DNSKEY RR's intended use to third parties. As an example we + present 3 use cases in which the bit is useful: + + The parent is a registry, the parent and the child use secured DNS + queries and responses, with a preexisting trust-relation, or plain + DNS over a secured channel to exchange the child's DNSKEY RR sets. + Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP + bit can be used to isolate the DNSKEYs for which a DS RR needs to + be created. + + An administrator has configured a DNSKEY as root for a trusted + subtree into security aware resolver. Using a special purpose + tool that queries for the KEY RRs from that domain's apex, the + administrator will be able to notice the roll over of the trusted + anchor by a change of the subset of KEY RRs with the DS flag set. + + A signer might use the SEP bit on the public key to determine + which private key to use to exclusively sign the DNSKEY RRset and + which private key to use to sign the other RRsets in the zone. + + As demonstrated in the above examples it is important to be able to + differentiate the SEP keys from the other keys in a DNSKEY RR set in + the flow between signer and (parental) key-collector and in the flow + between the signer and the resolver configuration. The SEP flag is + to be of no interest to the flow between the verifier and the + authoritative data store. + + The reason for the term "SEP" is a result of the observation that the + distinction between KSK and ZSK key pairs is made by the signer, a + key pair could be used as both a KSK and a ZSK at the same time. To + be clear, the term SEP was coined to lessen the confusion caused by + the overlap. (Once this label was applied, it had the side effect of + removing the temptation to have both a KSK flag bit and a ZSK flag + bit.) + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in BCP 14, RFC 2119 [1]. + + + + + +Kolkman, et al. Standard Track [Page 3] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +2. The Secure Entry Point (SEP) Flag + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags |S| protocol | algorithm | + | |E| | | + | |P| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + DNSKEY RR Format + This document assigns the 15th bit in the flags field as the secure + entry point (SEP) bit. If the bit is set to 1 the key is intended to + be used as secure entry point key. One SHOULD NOT assign special + meaning to the key if the bit is set to 0. Operators can recognize + the secure entry point key by the even or odd-ness of the decimal + representation of the flag field. + +3. DNSSEC Protocol Changes + + The bit MUST NOT be used during the resolving and verification + process. The SEP flag is only used to provide a hint about the + different administrative properties of the key and therefore the use + of the SEP flag does not change the DNS resolution protocol or the + resolution process. + +4. Operational Guidelines + + The SEP bit is set by the key-pair-generator and MAY be used by the + zone signer to decide whether the public part of the key pair is to + be prepared for input to a DS RR generation function. The SEP bit is + recommended to be set (to 1) whenever the public key of the key pair + will be distributed to the parent zone to build the authentication + chain or if the public key is to be distributed for static + configuration in verifiers. + + When a key pair is created, the operator needs to indicate whether + the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within + the data that is used to compute the 'key tag field' in the SIG RR, + changing the SEP bit will change the identity of the key within DNS. + In other words, once a key is used to generate signatures, the + setting of the SEP bit is to remain constant. If not, a verifier + will not be able to find the relevant KEY RR. + + + + +Kolkman, et al. Standard Track [Page 4] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + + When signing a zone, it is intended that the key(s) with the SEP bit + set (if such keys exist) are used to sign the KEY RR set of the zone. + The same key can be used to sign the rest of the zone data too. It + is conceivable that not all keys with a SEP bit set will sign the + DNSKEY RR set, such keys might be pending retirement or not yet in + use. + + When verifying a RR set, the SEP bit is not intended to play a role. + How the key is used by the verifier is not intended to be a + consideration at key creation time. + + Although the SEP flag provides a hint on which public key is to be + used as trusted root, administrators can choose to ignore the fact + that a DNSKEY has its SEP bit set or not when configuring a trusted + root for their resolvers. + + Using the SEP flag a key roll over can be automated. The parent can + use an existing trust relation to verify DNSKEY RR sets in which a + new DNSKEY RR with the SEP flag appears. + +5. Security Considerations + + As stated in Section 3 the flag is not to be used in the resolution + protocol or to determine the security status of a key. The flag is + to be used for administrative purposes only. + + No trust in a key should be inferred from this flag - trust MUST be + inferred from an existing chain of trust or an out-of-band exchange. + + Since this flag might be used for automating public key exchanges, we + think the following consideration is in place. + + Automated mechanisms for roll over of the DS RR might be vulnerable + to a class of replay attacks. This might happen after a public key + exchange where a DNSKEY RR set, containing two DNSKEY RRs with the + SEP flag set, is sent to the parent. The parent verifies the DNSKEY + RR set with the existing trust relation and creates the new DS RR + from the DNSKEY RR that the current DS RR is not pointing to. This + key exchange might be replayed. Parents are encouraged to implement + a replay defense. A simple defense can be based on a registry of + keys that have been used to generate DS RRs during the most recent + roll over. These same considerations apply to entities that + configure keys in resolvers. + + + + + + + + +Kolkman, et al. Standard Track [Page 5] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +6. IANA Considerations + + IANA has assigned the 15th bit in the DNSKEY Flags Registry (see + Section 4.3 of [4]) as the Secure Entry Point (SEP) bit. + +7. Internationalization Considerations + + Although SEP is a popular acronym in many different languages, there + are no internationalization considerations. + +8. Acknowledgments + + The ideas documented in this document are inspired by communications + we had with numerous people and ideas published by other folk. Among + others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, + Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler + have contributed ideas and provided feedback. + + This document saw the light during a workshop on DNSSEC operations + hosted by USC/ISI in August 2002. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer + (DS)", RFC 3755, April 2004. + +9.2. Informative References + + [5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy + Story", ISBN 0151002177 (50th anniversary edition), April 1996. + + + + + + + +Kolkman, et al. Standard Track [Page 6] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +10. Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Jakob Schlyter + NIC-SE + Box 5774 + SE-114 87 Stockholm + Sweden + + EMail: jakob@nic.se + URI: http://www.nic.se/ + + + Edward P. Lewis + ARIN + 3635 Concorde Parkway Suite 200 + Chantilly, VA 20151 + US + + Phone: +1 703 227 9854 + EMail: edlewis@arin.net + URI: http://www.arin.net/ + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Standard Track [Page 7] + +RFC 3757 DNSKEY RR SEP Flag April 2004 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Kolkman, et al. Standard Track [Page 8] + diff --git a/contrib/bind9/doc/rfc/rfc3901.txt b/contrib/bind9/doc/rfc/rfc3901.txt new file mode 100644 index 0000000..43b7356 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc3901.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group A. Durand +Request for Comments: 3901 SUN Microsystems, Inc. +BCP: 91 J. Ihren +Category: Best Current Practice Autonomica + September 2004 + + + DNS IPv6 Transport Operational Guidelines + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This memo provides guidelines and Best Current Practice for operating + DNS in a world where queries and responses are carried in a mixed + environment of IPv4 and IPv6 networks. + +1. Introduction to the Problem of Name Space Fragmentation: + following the referral chain + + A resolver that tries to look up a name starts out at the root, and + follows referrals until it is referred to a name server that is + authoritative for the name. If somewhere down the chain of referrals + it is referred to a name server that is only accessible over a + transport which the resolver cannot use, the resolver is unable to + finish the task. + + When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is + only a matter of time until this starts to happen. The complete DNS + hierarchy then starts to fragment into a graph where authoritative + name servers for certain nodes are only accessible over a certain + transport. The concern is that a resolver using only a particular + version of IP and querying information about another node using the + same version of IP can not do it because somewhere in the chain of + servers accessed during the resolution process, one or more of them + will only be accessible with the other version of IP. + + With all DNS data only available over IPv4 transport everything is + simple. IPv4 resolvers can use the intended mechanism of following + referrals from the root and down while IPv6 resolvers have to work + + + +Durand & Ihren Best Current Practice [Page 1] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + + through a "translator", i.e., they have to use a recursive name + server on a so-called "dual stack" host as a "forwarder" since they + cannot access the DNS data directly. + + With all DNS data only available over IPv6 transport everything would + be equally simple, with the exception of IPv4 recursive name servers + having to switch to a forwarding configuration. + + However, the second situation will not arise in the foreseeable + future. Instead, the transition will be from IPv4 only to a mixture + of IPv4 and IPv6, with three categories of DNS data depending on + whether the information is available only over IPv4 transport, only + over IPv6 or both. + + Having DNS data available on both transports is the best situation. + The major question is how to ensure that it becomes the norm as + quickly as possible. However, while it is obvious that some DNS data + will only be available over v4 transport for a long time it is also + obvious that it is important to avoid fragmenting the name space + available to IPv4 only hosts. For example, during transition it is + not acceptable to break the name space that we presently have + available for IPv4-only hosts. + +2. Terminology + + The phrase "IPv4 name server" indicates a name server available over + IPv4 transport. It does not imply anything about what DNS [1,2] data + is served. Likewise, "IPv6 [4,5,6] name server" indicates a name + server available over IPv6 transport. The phrase "dual-stack name + server" indicates a name server that is actually configured to run + both protocols, IPv4 and IPv6, and not merely a server running on a + system capable of running both but actually configured to run only + one. + +3. Policy Based Avoidance of Name Space Fragmentation + + Today there are only a few DNS "zones" on the public Internet that + are available over IPv6 transport, and most of them can be regarded + as "experimental". However, as soon as the root and top level + domains are available over IPv6 transport, it is reasonable to expect + that it will become more common to have zones served by IPv6 servers. + + Having those zones served only by IPv6-only name server would not be + a good development, since this will fragment the previously + unfragmented IPv4 name space and there are strong reasons to find a + mechanism to avoid it. + + + + + +Durand & Ihren Best Current Practice [Page 2] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + + The recommended approach to maintain name space continuity is to use + administrative policies, as described in the next section. + +4. DNS IPv6 Transport recommended Guidelines + + In order to preserve name space continuity, the following + administrative policies are recommended: + + - every recursive name server SHOULD be either IPv4-only or dual + stack, + + This rules out IPv6-only recursive servers. However, one might + design configurations where a chain of IPv6-only name server + forward queries to a set of dual stack recursive name server + actually performing those recursive queries. + + - every DNS zone SHOULD be served by at least one IPv4-reachable + authoritative name server. + + This rules out DNS zones served only by IPv6-only authoritative + name servers. + + Note: zone validation processes SHOULD ensure that there is at least + one IPv4 address record available for the name servers of any child + delegations within the zone. + +5. Security Considerations + + The guidelines described in this memo introduce no new security + considerations into the DNS protocol or associated operational + scenarios. + +6. Acknowledgment + + This document is the result of many conversations that happened in + the DNS community at IETF and elsewhere since 2001. During that + period of time, a number of Internet drafts have been published to + clarify various aspects of the issues at stake. This document + focuses on the conclusion of those discussions. + + The authors would like to acknowledge the role of Pekka Savola in his + thorough review of the document. + + + + + + + + + +Durand & Ihren Best Current Practice [Page 3] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + +7. Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + +8. Authors' Addresses + + Alain Durand + SUN Microsystems, Inc + 17 Network circle UMPK17-202 + Menlo Park, CA, 94025 + USA + + EMail: Alain.Durand@sun.com + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + EMail: johani@autonomica.se + + + + + + + + + + + + + +Durand & Ihren Best Current Practice [Page 4] + +RFC 3901 DNS IPv6 Transport Guidelines September 2004 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Durand & Ihren Best Current Practice [Page 5] + diff --git a/contrib/bind9/doc/rfc/rfc4025.txt b/contrib/bind9/doc/rfc/rfc4025.txt new file mode 100644 index 0000000..92e7f40 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4025.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group M. Richardson +Request for Comments: 4025 SSW +Category: Standards Track February 2005 + + + A Method for Storing IPsec Keying Material in DNS + +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 (2005). + +Abstract + + This document describes a new resource record for the Domain Name + System (DNS). This record may be used to store public keys for use + in IP security (IPsec) systems. The record also includes provisions + for indicating what system should be contacted when an IPsec tunnel + is established with the entity in question. + + This record replaces the functionality of the sub-type #4 of the KEY + Resource Record, which has been obsoleted by RFC 3445. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and + IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.3. Usage Criteria . . . . . . . . . . . . . . . . . . . . . 3 + 2. Storage Formats . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. IPSECKEY RDATA Format . . . . . . . . . . . . . . . . . 3 + 2.2. RDATA Format - Precedence . . . . . . . . . . . . . . . 4 + 2.3. RDATA Format - Gateway Type . . . . . . . . . . . . . . 4 + 2.4. RDATA Format - Algorithm Type . . . . . . . . . . . . . 4 + 2.5. RDATA Format - Gateway . . . . . . . . . . . . . . . . . 5 + 2.6. RDATA Format - Public Keys . . . . . . . . . . . . . . . 5 + 3. Presentation Formats . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Representation of IPSECKEY RRs . . . . . . . . . . . . . 6 + 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + + + +Richardson Standards Track [Page 1] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + 4.1. Active Attacks Against Unsecured IPSECKEY Resource + Records . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1.1. Active Attacks Against IPSECKEY Keying + Materials. . . . . . . . . . . . . . . . . . . . 8 + 4.1.2. Active Attacks Against IPSECKEY Gateway + Material. . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + Suppose a host wishes (or is required by policy) to establish an + IPsec tunnel with some remote entity on the network prior to allowing + normal communication to take place. In many cases, this end system + will be able to determine the DNS name for the remote entity (either + by having the DNS name given explicitly, by performing a DNS PTR + query for a particular IP address, or through some other means, e.g., + by extracting the DNS portion of a "user@FQDN" name for a remote + entity). In these cases, the host will need to obtain a public key + to authenticate the remote entity, and may also need some guidance + about whether it should contact the entity directly or use another + node as a gateway to the target entity. The IPSECKEY RR provides a + mechanism for storing such information. + + The type number for the IPSECKEY RR is 45. + + This record replaces the functionality of the sub-type #4 of the KEY + Resource Record, which has been obsoleted by RFC 3445 [11]. + +1.1. Overview + + The IPSECKEY resource record (RR) is used to publish a public key + that is to be associated with a Domain Name System (DNS) [1] name for + use with the IPsec protocol suite. This can be the public key of a + host, network, or application (in the case of per-port keying). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [3]. + + + + + + + +Richardson Standards Track [Page 2] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + +1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA) + + Often a security gateway will only have access to the IP address of + the node with which communication is desired and will not know any + other name for the target node. Because of this, frequently the best + way of looking up IPSECKEY RRs will be by using the IP address as an + index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or + IP6.ARPA for IPv6). + + The lookup is done in the fashion usual for PTR records. The IP + address' octets (IPv4) or nibbles (IPv6) are reversed and looked up + with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be + followed. + + Note: even when the IPsec function is contained in the end-host, + often only the application will know the forward name used. Although + the case where the application knows the forward name is common, the + user could easily have typed in a literal IP address. This storage + mechanism does not preclude using the forward name when it is + available but does not require it. + +1.3. Usage Criteria + + An IPSECKEY resource record SHOULD be used in combination with DNSSEC + [8] unless some other means of authenticating the IPSECKEY resource + record is available. + + It is expected that there will often be multiple IPSECKEY resource + records at the same name. This will be due to the presence of + multiple gateways and a need to roll over keys. + + This resource record is class independent. + +2. Storage Formats + +2.1. IPSECKEY RDATA Format + + The RDATA for an IPSECKEY RR consists of a precedence value, a + gateway type, a public key, algorithm type, and an optional gateway + address. + + + + + + + + + + + +Richardson Standards Track [Page 3] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | precedence | gateway type | algorithm | gateway | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + + ~ gateway ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + +2.2. RDATA Format - Precedence + + This is an 8-bit precedence for this record. It is interpreted in + the same way as the PREFERENCE field described in section 3.3.9 of + RFC 1035 [2]. + + Gateways listed in IPSECKEY records with lower precedence are to be + attempted first. Where there is a tie in precedence, the order + should be non-deterministic. + +2.3. RDATA Format - Gateway Type + + The gateway type field indicates the format of the information that + is stored in the gateway field. + + The following values are defined: + 0 No gateway is present. + 1 A 4-byte IPv4 address is present. + 2 A 16-byte IPv6 address is present. + 3 A wire-encoded domain name is present. The wire-encoded format is + self-describing, so the length is implicit. The domain name MUST + NOT be compressed. (See Section 3.3 of RFC 1035 [2].) + +2.4. RDATA Format - Algorithm Type + + The algorithm type field identifies the public key's cryptographic + algorithm and determines the format of the public key field. + + A value of 0 indicates that no key is present. + + The following values are defined: + 1 A DSA key is present, in the format defined in RFC 2536 [9]. + 2 A RSA key is present, in the format defined in RFC 3110 [10]. + + + + + + +Richardson Standards Track [Page 4] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + +2.5. RDATA Format - Gateway + + The gateway field indicates a gateway to which an IPsec tunnel may be + created in order to reach the entity named by this resource record. + + There are three formats: + + A 32-bit IPv4 address is present in the gateway field. The data + portion is an IPv4 address as described in section 3.4.1 of RFC 1035 + [2]. This is a 32-bit number in network byte order. + + A 128-bit IPv6 address is present in the gateway field. The data + portion is an IPv6 address as described in section 2.2 of RFC 3596 + [12]. This is a 128-bit number in network byte order. + + The gateway field is a normal wire-encoded domain name, as described + in section 3.3 of RFC 1035 [2]. Compression MUST NOT be used. + +2.6. RDATA Format - Public Keys + + Both the public key types defined in this document (RSA and DSA) + inherit their public key formats from the corresponding KEY RR + formats. Specifically, the public key field contains the + algorithm-specific portion of the KEY RR RDATA, which is all the KEY + RR DATA after the first four octets. This is the same portion of the + KEY RR that must be specified by documents that define a DNSSEC + algorithm. Those documents also specify a message digest to be used + for generation of SIG RRs; that specification is not relevant for + IPSECKEY RRs. + + Future algorithms, if they are to be used by both DNSSEC (in the KEY + RR) and IPSECKEY, are likely to use the same public key encodings in + both records. Unless otherwise specified, the IPSECKEY public key + field will contain the algorithm-specific portion of the KEY RR RDATA + for the corresponding algorithm. The algorithm must still be + designated for use by IPSECKEY, and an IPSECKEY algorithm type number + (which might be different from the DNSSEC algorithm number) must be + assigned to it. + + The DSA key format is defined in RFC 2536 [9] + + The RSA key format is defined in RFC 3110 [10], with the following + changes: + + The earlier definition of RSA/MD5 in RFC 2065 [4] limited the + exponent and modulus to 2552 bits in length. RFC 3110 extended that + limit to 4096 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no + length limit on RSA public keys, other than the 65535 octet limit + + + +Richardson Standards Track [Page 5] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + imposed by the two-octet length encoding. This length extension is + applicable only to IPSECKEY; it is not applicable to KEY RRs. + +3. Presentation Formats + +3.1. Representation of IPSECKEY RRs + + IPSECKEY RRs may appear in a zone data master file. The precedence, + gateway type, algorithm, and gateway fields are REQUIRED. The base64 + encoded public key block is OPTIONAL; if it is not present, the + public key field of the resource record MUST be construed to be zero + octets in length. + + The algorithm field is an unsigned integer. No mnemonics are + defined. + + If no gateway is to be indicated, then the gateway type field MUST be + zero, and the gateway field MUST be "." + + The Public Key field is represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see RFC 3548 [6], Section 5.2. + + The general presentation for the record is as follows: + + IN IPSECKEY ( precedence gateway-type algorithm + gateway base64-encoded-public-key ) + +3.2. Examples + + An example of a node, 192.0.2.38, that will accept IPsec tunnels on + its own behalf. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.38 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.2.38, that has published its key only. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 + . + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + + + + + + + + +Richardson Standards Track [Page 6] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + An example of a node, 192.0.2.38, that has delegated authority to the + node 192.0.2.3. + + 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 + 192.0.2.3 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 192.0.1.38 that has delegated authority to the + node with the identity "mygateway.example.com". + + 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 + mygateway.example.com. + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + + An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has + delegated authority to the node 2001:0DB8:c000:0200:2::1 + + $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. + 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 + 2001:0DB8:0:8002::2000:1 + AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) + +4. Security Considerations + + This entire memo pertains to the provision of public keying material + for use by key management protocols such as ISAKMP/IKE (RFC 2407) + [7]. + + The IPSECKEY resource record contains information that SHOULD be + communicated to the end client in an integral fashion; i.e., free + from modification. The form of this channel is up to the consumer of + the data; there must be a trust relationship between the end consumer + of this resource record and the server. This relationship may be + end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another + secure source, a secure local channel on the host, or some + combination of the above. + + The keying material provided by the IPSECKEY resource record is not + sensitive to passive attacks. The keying material may be freely + disclosed to any party without any impact on the security properties + of the resulting IPsec session. IPsec and IKE provide defense + against both active and passive attacks. + + Any derivative specification that makes use of this resource record + MUST carefully document its trust model and why the trust model of + DNSSEC is appropriate, if that is the secure channel used. + + + + + +Richardson Standards Track [Page 7] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + An active attack on the DNS that caused the wrong IP address to be + retrieved (via forged address), and therefore the wrong QNAME to be + queried, would also result in a man-in-the-middle attack. This + situation is independent of whether the IPSECKEY RR is used. + +4.1. Active Attacks Against Unsecured IPSECKEY Resource Records + + This section deals with active attacks against the DNS. These + attacks require that DNS requests and responses be intercepted and + changed. DNSSEC is designed to defend against attacks of this kind. + This section deals with the situation in which DNSSEC is not + available. This is not the recommended deployment scenario. + +4.1.1. Active Attacks Against IPSECKEY Keying Materials + + The first kind of active attack is when the attacker replaces the + keying material with either a key under its control or with garbage. + + The gateway field is either untouched or is null. The IKE + negotiation will therefore occur with the original end-system. For + this attack to succeed, the attacker must perform a man-in-the-middle + attack on the IKE negotiation. This attack requires that the + attacker be able to intercept and modify packets on the forwarding + path for the IKE and data packets. + + If the attacker is not able to perform this man-in-the-middle attack + on the IKE negotiation, then a denial of service will result, as the + IKE negotiation will fail. + + If the attacker is not only able to mount active attacks against DNS + but also in a position to perform a man-in-the-middle attack on IKE + and IPsec negotiations, then the attacker will be able to compromise + the resulting IPsec channel. Note that an attacker must be able to + perform active DNS attacks on both sides of the IKE negotiation for + this to succeed. + +4.1.2. Active Attacks Against IPSECKEY Gateway Material + + The second kind of active attack is one in which the attacker + replaces the gateway address to point to a node under the attacker's + control. The attacker then either replaces the public key or removes + it. If the public key were removed, then the attacker could provide + an accurate public key of its own in a second record. + + This second form creates a simple man-in-the-middle attacks since the + attacker can then create a second tunnel to the real destination. + Note that, as before, this requires that the attacker also mount an + active attack against the responder. + + + +Richardson Standards Track [Page 8] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + Note that the man-in-the-middle cannot just forward cleartext packets + to the original destination. While the destination may be willing to + speak in the clear, replying to the original sender, the sender will + already have created a policy expecting ciphertext. Thus, the + attacker will need to intercept traffic in both directions. In some + cases, the attacker may be able to accomplish the full intercept by + use of Network Address/Port Translation (NAT/NAPT) technology. + + This attack is easier than the first one because the attacker does + NOT need to be on the end-to-end forwarding path. The attacker need + only be able to modify DNS replies. This can be done by packet + modification, by various kinds of race attacks, or through methods + that pollute DNS caches. + + If the end-to-end integrity of the IPSECKEY RR is suspect, the end + client MUST restrict its use of the IPSECKEY RR to cases where the RR + owner name matches the content of the gateway field. As the RR owner + name is assumed when the gateway field is null, a null gateway field + is considered a match. + + Thus, any records obtained under unverified conditions (e.g., no + DNSSEC or trusted path to source) that have a non-null gateway field + MUST be ignored. + + This restriction eliminates attacks against the gateway field, which + are considered much easier, as the attack does not need to be on the + forwarding path. + + In the case of an IPSECKEY RR with a value of three in its gateway + type field, the gateway field contains a domain name. The subsequent + query required to translate that name into an IP address or IPSECKEY + RR will also be subject to man-in-the-middle attacks. If the + end-to-end integrity of this second query is suspect, then the + provisions above also apply. The IPSECKEY RR MUST be ignored + whenever the resulting gateway does not match the QNAME of the + original IPSECKEY RR query. + +5. IANA Considerations + + This document updates the IANA Registry for DNS Resource Record Types + by assigning type 45 to the IPSECKEY record. + + This document creates two new IANA registries, both specific to the + IPSECKEY Resource Record: + + This document creates an IANA registry for the algorithm type field. + + + + + +Richardson Standards Track [Page 9] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + Values 0, 1, and 2 are defined in Section 2.4. Algorithm numbers 3 + through 255 can be assigned by IETF Consensus (see RFC 2434 [5]). + + This document creates an IANA registry for the gateway type field. + + Values 0, 1, 2, and 3 are defined in Section 2.3. Gateway type + numbers 4 through 255 can be assigned by Standards Action (see RFC + 2434 [5]). + +6. Acknowledgements + + My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob + Austein, and Olafur Gudmundsson, who reviewed this document + carefully. Additional thanks to Olafur Gurmundsson for a reference + implementation. + +7. References + +7.1. Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + +7.2. Informative References + + [7] Piper, D., "The Internet IP Security Domain of Interpretation + for ISAKMP", RFC 2407, November 1998. + + [8] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [9] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + + +Richardson Standards Track [Page 10] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + + [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + +Author's Address + + Michael C. Richardson + Sandelman Software Works + 470 Dawson Avenue + Ottawa, ON K1Z 5V7 + CA + + EMail: mcr@sandelman.ottawa.on.ca + URI: http://www.sandelman.ottawa.on.ca/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Standards Track [Page 11] + +RFC 4025 Storing IPsec Keying Material in DNS February 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Richardson Standards Track [Page 12] + diff --git a/contrib/bind9/doc/rfc/rfc4033.txt b/contrib/bind9/doc/rfc/rfc4033.txt new file mode 100644 index 0000000..7f0a464 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4033.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4033 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + DNS Security Introduction and Requirements + +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 (2005). + +Abstract + + The Domain Name System Security Extensions (DNSSEC) add data origin + authentication and data integrity to the Domain Name System. This + document introduces these extensions and describes their capabilities + and limitations. This document also discusses the services that the + DNS security extensions do and do not provide. Last, this document + describes the interrelationships between the documents that + collectively describe DNSSEC. + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3 + 3. Services Provided by DNS Security . . . . . . . . . . . . . 7 + 3.1. Data Origin Authentication and Data Integrity . . . . 7 + 3.2. Authenticating Name and Type Non-Existence . . . . . . 9 + 4. Services Not Provided by DNS Security . . . . . . . . . . . 9 + 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9 + 6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10 + 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11 + 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12 + 8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13 + 8.2. New Temporal Dependency Issues for Zones . . . . . . . 13 + 9. Name Server Considerations . . . . . . . . . . . . . . . . . 13 + 10. DNS Security Document Family . . . . . . . . . . . . . . . . 14 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 14.1. Normative References . . . . . . . . . . . . . . . . . 17 + 14.2. Informative References . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21 + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents ([RFC4034] + and [RFC4035]) update, clarify, and refine the security extensions + defined in [RFC2535] and its predecessors. These security extensions + consist of a set of new resource record types and modifications to + the existing DNS protocol ([RFC1035]). The new records and protocol + modifications are not fully described in this document, but are + described in a family of documents outlined in Section 10. Sections + 3 and 4 describe the capabilities and limitations of the security + extensions in greater detail. Section 5 discusses the scope of the + document set. Sections 6, 7, 8, and 9 discuss the effect that these + security extensions will have on resolvers, stub resolvers, zones, + and name servers. + + This document and its two companions obsolete [RFC2535], [RFC3008], + [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and + [RFC3845]. This document set also updates but does not obsolete + [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], + [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with + DNSSEC. + + + + +Arends, et al. Standards Track [Page 2] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide confidentiality. + +2. Definitions of Important DNSSEC Terms + + This section defines a number of terms used in this document set. + Because this is intended to be useful as a reference while reading + the rest of the document set, first-time readers may wish to skim + this section quickly, read the rest of this document, and then come + back to this section. + + Authentication Chain: An alternating sequence of DNS public key + (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of + signed data, with each link in the chain vouching for the next. A + DNSKEY RR is used to verify the signature covering a DS RR and + allows the DS RR to be authenticated. The DS RR contains a hash + of another DNSKEY RR and this new DNSKEY RR is authenticated by + matching the hash in the DS RR. This new DNSKEY RR in turn + authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in + this set may be used to authenticate another DS RR, and so forth + until the chain finally ends with a DNSKEY RR whose corresponding + private key signs the desired DNS data. For example, the root + DNSKEY RRset can be used to authenticate the DS RRset for + "example." The "example." DS RRset contains a hash that matches + some "example." DNSKEY, and this DNSKEY's corresponding private + key signs the "example." DNSKEY RRset. Private key counterparts + of the "example." DNSKEY RRset sign data records such as + "www.example." and DS RRs for delegations such as + "subzone.example." + + Authentication Key: A public key that a security-aware resolver has + verified and can therefore use to authenticate data. A + security-aware resolver can obtain authentication keys in three + ways. First, the resolver is generally configured to know about + at least one public key; this configured data is usually either + the public key itself or a hash of the public key as found in the + DS RR (see "trust anchor"). Second, the resolver may use an + authenticated public key to verify a DS RR and the DNSKEY RR to + which the DS RR refers. Third, the resolver may be able to + determine that a new public key has been signed by the private key + corresponding to another public key that the resolver has + verified. Note that the resolver must always be guided by local + policy when deciding whether to authenticate a new public key, + even if the local policy is simply to authenticate any new public + key for which the resolver is able verify the signature. + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Authoritative RRset: Within the context of a particular zone, an + RRset is "authoritative" if and only if the owner name of the + RRset lies within the subset of the name space that is at or below + the zone apex and at or above the cuts that separate the zone from + its children, if any. All RRsets at the zone apex are + authoritative, except for certain RRsets at this domain name that, + if present, belong to this zone's parent. These RRset could + include a DS RRset, the NSEC RRset referencing this DS RRset (the + "parental NSEC"), and RRSIG RRs associated with these RRsets, all + of which are authoritative in the parent zone. Similarly, if this + zone contains any delegation points, only the parental NSEC RRset, + DS RRsets, and any RRSIG RRs associated with these RRsets are + authoritative for this zone. + + Delegation Point: Term used to describe the name at the parental side + of a zone cut. That is, the delegation point for "foo.example" + would be the foo.example node in the "example" zone (as opposed to + the zone apex of the "foo.example" zone). See also zone apex. + + Island of Security: Term used to describe a signed, delegated zone + that does not have an authentication chain from its delegating + parent. That is, there is no DS RR containing a hash of a DNSKEY + RR for the island in its delegating parent zone (see [RFC4034]). + An island of security is served by security-aware name servers and + may provide authentication chains to any delegated child zones. + Responses from an island of security or its descendents can only + be authenticated if its authentication keys can be authenticated + by some trusted means out of band from the DNS protocol. + + Key Signing Key (KSK): An authentication key that corresponds to a + private key used to sign one or more other authentication keys for + a given zone. Typically, the private key corresponding to a key + signing key will sign a zone signing key, which in turn has a + corresponding private key that will sign other zone data. Local + policy may require that the zone signing key be changed + frequently, while the key signing key may have a longer validity + period in order to provide a more stable secure entry point into + the zone. Designating an authentication key as a key signing key + is purely an operational issue: DNSSEC validation does not + distinguish between key signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. Key signing keys + are discussed in more detail in [RFC3757]. Also see zone signing + key. + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Non-Validating Security-Aware Stub Resolver: A security-aware stub + resolver that trusts one or more security-aware recursive name + servers to perform most of the tasks discussed in this document + set on its behalf. In particular, a non-validating security-aware + stub resolver is an entity that sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server that will + provide these services on behalf of the security-aware stub + resolver. See also security-aware stub resolver, validating + security-aware stub resolver. + + Non-Validating Stub Resolver: A less tedious term for a + non-validating security-aware stub resolver. + + Security-Aware Name Server: An entity acting in the role of a name + server (defined in section 2.4 of [RFC1034]) that understands the + DNS security extensions defined in this document set. In + particular, a security-aware name server is an entity that + receives DNS queries, sends DNS responses, supports the EDNS0 + ([RFC2671]) message size extension and the DO bit ([RFC3225]), and + supports the RR types and message header bits defined in this + document set. + + Security-Aware Recursive Name Server: An entity that acts in both the + security-aware name server and security-aware resolver roles. A + more cumbersome but equivalent phrase would be "a security-aware + name server that offers recursive service". + + Security-Aware Resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) that understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity that sends DNS queries, + receives DNS responses, supports the EDNS0 ([RFC2671]) message + size extension and the DO bit ([RFC3225]), and is capable of using + the RR types and message header bits defined in this document set + to provide DNSSEC services. + + Security-Aware Stub Resolver: An entity acting in the role of a stub + resolver (defined in section 5.3.1 of [RFC1034]) that has enough + of an understanding the DNS security extensions defined in this + document set to provide additional services not available from a + security-oblivious stub resolver. Security-aware stub resolvers + may be either "validating" or "non-validating", depending on + whether the stub resolver attempts to verify DNSSEC signatures on + its own or trusts a friendly security-aware name server to do so. + See also validating stub resolver, non-validating stub resolver. + + + + + +Arends, et al. Standards Track [Page 5] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Security-Oblivious <anything>: An <anything> that is not + "security-aware". + + Signed Zone: A zone whose RRsets are signed and that contains + properly constructed DNSKEY, Resource Record Signature (RRSIG), + Next Secure (NSEC), and (optionally) DS records. + + Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A + validating security-aware resolver uses this public key or hash as + a starting point for building the authentication chain to a signed + DNS response. In general, a validating resolver will have to + obtain the initial values of its trust anchors via some secure or + trusted means outside the DNS protocol. Presence of a trust + anchor also implies that the resolver should expect the zone to + which the trust anchor points to be signed. + + Unsigned Zone: A zone that is not signed. + + Validating Security-Aware Stub Resolver: A security-aware resolver + that sends queries in recursive mode but that performs signature + validation on its own rather than just blindly trusting an + upstream security-aware recursive name server. See also + security-aware stub resolver, non-validating security-aware stub + resolver. + + Validating Stub Resolver: A less tedious term for a validating + security-aware stub resolver. + + Zone Apex: Term used to describe the name at the child's side of a + zone cut. See also delegation point. + + Zone Signing Key (ZSK): An authentication key that corresponds to a + private key used to sign a zone. Typically, a zone signing key + will be part of the same DNSKEY RRset as the key signing key whose + corresponding private key signs this DNSKEY RRset, but the zone + signing key is used for a slightly different purpose and may + differ from the key signing key in other ways, such as validity + lifetime. Designating an authentication key as a zone signing key + is purely an operational issue; DNSSEC validation does not + distinguish between zone signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. See also key + signing key. + + + + + + + + +Arends, et al. Standards Track [Page 6] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require changes to the DNS protocol. DNSSEC adds + four new resource record types: Resource Record Signature (RRSIG), + DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure + (NSEC). It also adds two new message header bits: Checking Disabled + (CD) and Authenticated Data (AD). In order to support the larger DNS + message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support + for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a + security-aware resolver can indicate in its queries that it wishes to + receive DNSSEC RRs in response messages. + + These services protect against most of the threats to the Domain Name + System described in [RFC3833]. Please see Section 12 for a + discussion of the limitations of these extensions. + +3.1. Data Origin Authentication and Data Integrity + + DNSSEC provides authentication by associating cryptographically + generated digital signatures with DNS RRsets. These digital + signatures are stored in a new resource record, the RRSIG record. + Typically, there will be a single private key that signs a zone's + data, but multiple keys are possible. For example, there may be keys + for each of several different digital signature algorithms. If a + security-aware resolver reliably learns a zone's public key, it can + authenticate that zone's signed data. An important DNSSEC concept is + that the key that signs a zone's data is associated with the zone + itself and not with the zone's authoritative name servers. (Public + keys for DNS transaction authentication mechanisms may also appear in + zones, as described in [RFC2931], but DNSSEC itself is concerned with + object security of DNS data, not channel security of DNS + transactions. The keys associated with transaction security may be + stored in different RR types. See [RFC3755] for details.) + + A security-aware resolver can learn a zone's public key either by + having a trust anchor configured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the DNSKEY RR. Note that the private keys + used to sign zone data must be kept secure and should be stored + offline when practical. To discover a public key reliably via DNS + resolution, the target key itself has to be signed by either a + configured authentication key or another key that has been + + + +Arends, et al. Standards Track [Page 7] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + authenticated previously. Security-aware resolvers authenticate zone + information by forming an authentication chain from a newly learned + public key back to a previously known authentication public key, + which in turn either has been configured into the resolver or must + have been learned and verified previously. Therefore, the resolver + must be configured with at least one trust anchor. + + If the configured trust anchor is a zone signing key, then it will + authenticate the associated zone; if the configured key is a key + signing key, it will authenticate a zone signing key. If the + configured trust anchor is the hash of a key rather than the key + itself, the resolver may have to obtain the key via a DNS query. To + help security-aware resolvers establish this authentication chain, + security-aware name servers attempt to send the signature(s) needed + to authenticate a zone's public key(s) in the DNS reply message along + with the public key itself, provided that there is space available in + the message. + + The Delegation Signer (DS) RR type simplifies some of the + administrative tasks involved in signing delegations across + organizational boundaries. The DS RRset resides at a delegation + point in a parent zone and indicates the public key(s) corresponding + to the private key(s) used to self-sign the DNSKEY RRset at the + delegated child zone's apex. The administrator of the child zone, in + turn, uses the private key(s) corresponding to one or more of the + public keys in this DNSKEY RRset to sign the child zone's data. The + typical authentication chain is therefore + DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more + DS->DNSKEY subchains. DNSSEC permits more complex authentication + chains, such as additional layers of DNSKEY RRs signing other DNSKEY + RRs within a zone. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + on configured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more configured public keys (or hashes of public keys) other than + the root public key, may not provide configured knowledge of the root + public key, or may prevent the resolver from using particular public + keys for arbitrary reasons, even if those public keys are properly + signed with verifiable signatures. DNSSEC provides mechanisms by + which a security-aware resolver can determine whether an RRset's + signature is "valid" within the meaning of DNSSEC. In the final + analysis, however, authenticating both DNS keys and data is a matter + of local policy, which may extend or even override the protocol + extensions defined in this document set. See Section 5 for further + discussion. + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +3.2. Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + requires the use of another new resource record type, the NSEC + record. The NSEC record allows a security-aware resolver to + authenticate a negative reply for either name or type non-existence + with the same mechanisms used to authenticate other DNS replies. Use + of NSEC records requires a canonical representation and ordering for + domain names in zones. Chains of NSEC records explicitly describe + the gaps, or "empty space", between domain names in a zone and list + the types of RRsets present at existing names. Each NSEC record is + signed and authenticated using the mechanisms described in Section + 3.1. + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 12 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + ([RFC2136], [RFC3007]). Message authentication schemes described in + [RFC2845] and [RFC2931] address security operations that pertain to + these transactions. + +5. Scope of the DNSSEC Document Set and Last Hop Issues + + The specification in this document set defines the behavior for zone + signers and security-aware name servers and resolvers in such a way + that the validating entities can unambiguously determine the state of + the data. + + A validating resolver can determine the following 4 states: + + Secure: The validating resolver has a trust anchor, has a chain of + trust, and is able to verify all the signatures in the response. + + + +Arends, et al. Standards Track [Page 9] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Insecure: The validating resolver has a trust anchor, a chain of + trust, and, at some delegation point, signed proof of the + non-existence of a DS record. This indicates that subsequent + branches in the tree are provably insecure. A validating resolver + may have a local policy to mark parts of the domain space as + insecure. + + Bogus: The validating resolver has a trust anchor and a secure + delegation indicating that subsidiary data is signed, but the + response fails to validate for some reason: missing signatures, + expired signatures, signatures with unsupported algorithms, data + missing that the relevant NSEC RR says should be present, and so + forth. + + Indeterminate: There is no trust anchor that would indicate that a + specific portion of the tree is secure. This is the default + operation mode. + + This specification only defines how security-aware name servers can + signal non-validating stub resolvers that data was found to be bogus + (using RCODE=2, "Server Failure"; see [RFC4035]). + + There is a mechanism for security-aware name servers to signal + security-aware stub resolvers that data was found to be secure (using + the AD bit; see [RFC4035]). + + This specification does not define a format for communicating why + responses were found to be bogus or marked as insecure. The current + signaling mechanism does not distinguish between indeterminate and + insecure states. + + A method for signaling advanced error codes and policy between a + security-aware stub resolver and security-aware recursive nameservers + is a topic for future work, as is the interface between a security- + aware resolver and the applications that use it. Note, however, that + the lack of the specification of such communication does not prohibit + deployment of signed zones or the deployment of security aware + recursive name servers that prohibit propagation of bogus data to the + applications. + +6. Resolver Considerations + + A security-aware resolver has to be able to perform cryptographic + functions necessary to verify digital signatures using at least the + mandatory-to-implement algorithm(s). Security-aware resolvers must + also be capable of forming an authentication chain from a newly + learned zone back to an authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + + + +Arends, et al. Standards Track [Page 10] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + obtain necessary DNSKEY, DS, and RRSIG records. A security-aware + resolver should be configured with at least one trust anchor as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + authoritative name servers by a recursive name server or by any sort + of intermediary device that acts as a proxy for DNS, and if the + recursive name server or intermediary device is not security-aware, + the security-aware resolver may not be capable of operating in a + secure mode. For example, if a security-aware resolver's packets are + routed through a network address translation (NAT) device that + includes a DNS proxy that is not security-aware, the security-aware + resolver may find it difficult or impossible to obtain or validate + signed DNS data. The security-aware resolver may have a particularly + difficult time obtaining DS RRs in such a case, as DS RRs do not + follow the usual DNS rules for ownership of RRs at zone cuts. Note + that this problem is not specific to NATs: any security-oblivious DNS + software of any kind between the security-aware resolver and the + authoritative name servers will interfere with DNSSEC. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature. However, it should also allow for the possibility that + the security-aware resolver's own clock is wrong. Thus, a + security-aware resolver that is part of a security-aware recursive + name server will have to pay careful attention to the DNSSEC + "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid + blocking valid signatures from getting through to other + security-aware resolvers that are clients of this recursive name + server. See [RFC4035] for how a secure recursive server handles + queries with the CD bit set. + +7. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers that use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a security-aware iterative resolver. + + Even a security-oblivious stub resolver may benefit from DNSSEC if + the recursive name servers it uses are security-aware, but for the + stub resolver to place any real reliance on DNSSEC services, the stub + resolver must trust both the recursive name servers in question and + the communication channels between itself and those name servers. + The first of these issues is a local policy issue: in essence, a + security-oblivious stub resolver has no choice but to place itself at + the mercy of the recursive name servers that it uses, as it does not + perform DNSSEC validity checks on its own. The second issue requires + some kind of channel security mechanism; proper use of DNS + transaction authentication mechanisms such as SIG(0) ([RFC2931]) or + TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec. + Particular implementations may have other choices available, such as + operating system specific interprocess communication mechanisms. + Confidentiality is not needed for this channel, but data integrity + and message authentication are. + + A security-aware stub resolver that does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the Authenticated Data (AD) bit in the message + header of the response messages it receives. The stub resolver can + use this flag bit as a hint to find out whether the recursive name + server was able to validate signatures for all of the data in the + Answer and Authority sections of the response. + + There is one more step that a security-aware stub resolver can take + if, for whatever reason, it is not able to establish a useful trust + relationship with the recursive name servers that it uses: it can + perform its own signature validation by setting the Checking Disabled + (CD) bit in its query messages. A validating stub resolver is thus + able to treat the DNSSEC signatures as trust relationships between + the zone administrators and the stub resolver itself. + +8. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (RRSIG, + DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be + generated by a signing process prior to serving the zone. The RRSIG + records that accompany zone data have defined inception and + expiration times that establish a validity period for the signatures + and the zone data the signatures cover. + + + + + +Arends, et al. Standards Track [Page 12] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +8.1. TTL Values vs. RRSIG Validity Period + + It is important to note the distinction between a RRset's TTL value + and the signature validity period specified by the RRSIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later + than the end of the time period specified by the TTL fields of those + RRsets, regardless of whether the resolver is security-aware. + + The inception and expiration fields in the RRSIG RR ([RFC4034]), on + the other hand, specify the time period during which the signature + can be used to validate the covered RRset. The signatures associated + with signed zone data are only valid for the time period specified by + these fields in the RRSIG RRs in question. TTL values cannot extend + the validity period of signed RRsets in a resolver's cache, but the + resolver may use the time remaining before expiration of the + signature validity period of a signed RRset as an upper bound for the + TTL of the signed RRset and its associated RRSIG RR in the resolver's + cache. + +8.2. New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency that did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + RRSIG RR. The signature validity period of an RRSIG RR is an + interval during which the signature for one particular signed RRset + can be considered valid, and the signatures of different RRsets in a + zone may expire at different times. Re-signing one or more RRsets in + a zone will change one or more RRSIG RRs, which will in turn require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, + re-signing any RRset in a zone may also trigger DNS NOTIFY messages + and zone transfer operations. + +9. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries + from resolvers that have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. Because inclusion of these DNSSEC RRs could easily + cause UDP message truncation and fallback to TCP, a security-aware + name server must also support the EDNS "sender's UDP payload" + mechanism. + + + + + +Arends, et al. Standards Track [Page 13] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + If possible, the private half of each DNSSEC key pair should be kept + offline, but this will not be possible for a zone for which DNS + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + it is updated, so the private key corresponding to the zone signing + key will have to be kept online. This is an example of a situation + in which the ability to separate the zone's DNSKEY RRset into zone + signing key(s) and key signing key(s) may be useful, as the key + signing key(s) in such a case can still be kept offline and may have + a longer useful lifetime than the zone signing key(s). + + By itself, DNSSEC is not enough to protect the integrity of an entire + zone during zone transfer operations, as even a signed zone contains + some unsigned, nonauthoritative data if the zone has any children. + Therefore, zone maintenance operations will require some additional + mechanisms (most likely some form of channel security, such as TSIG, + SIG(0), or IPsec). + +10. DNS Security Document Family + + The DNSSEC document set can be partitioned into several main groups, + under the larger umbrella of the DNS base protocol documents. + + The "DNSSEC protocol document set" refers to the three documents that + form the core of the DNS security extensions: + + 1. DNS Security Introduction and Requirements (this document) + + 2. Resource Records for DNS Security Extensions [RFC4034] + + 3. Protocol Modifications for the DNS Security Extensions [RFC4035] + + Additionally, any document that would add to or change the core DNS + Security extensions would fall into this category. This includes any + future work on the communication between security-aware stub + resolvers and upstream security-aware recursive name servers. + + The "Digital Signature Algorithm Specification" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each document in this set deals with a specific + digital signature algorithm. Please see the appendix on "DNSSEC + Algorithm and Digest Types" in [RFC4034] for a list of the algorithms + that were defined when this core specification was written. + + The "Transaction Authentication Protocol" document set refers to the + group of documents that deal with DNS message authentication, + including secret key establishment and verification. Although not + + + +Arends, et al. Standards Track [Page 14] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted because of its relationship to DNSSEC. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses but may be used to support them. Documents that fall + in this category include those describing the use of DNS in the + storage and distribution of certificates ([RFC2538]). + +11. IANA Considerations + + This overview document introduces no new IANA considerations. Please + see [RFC4034] for a complete review of the IANA considerations + introduced by DNSSEC. + +12. Security Considerations + + This document introduces DNS security extensions and describes the + document set that contains the new security records and DNS protocol + modifications. The extensions provide data origin authentication and + data integrity using digital signatures over resource record sets. + This section discusses the limitations of these extensions. + + In order for a security-aware resolver to validate a DNS response, + all zones along the path from the trusted starting point to the zone + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + security-aware, as defined in this document set. A security-aware + resolver cannot verify responses originating from an unsigned zone, + from a zone not served by a security-aware name server, or for any + DNS data that the resolver is only able to obtain through a recursive + name server that is not security-aware. If there is a break in the + authentication chain such that a security-aware resolver cannot + obtain and validate the authentication keys it needs, then the + security-aware resolver cannot validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism such as TSIG ([RFC2845]) or + SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC + per se. + + A non-validating security-aware stub resolver, by definition, does + not perform DNSSEC signature validation on its own and thus is + vulnerable both to attacks on (and by) the security-aware recursive + name servers that perform these checks on its behalf and to attacks + on its communication with those security-aware recursive name + + + +Arends, et al. Standards Track [Page 15] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + servers. Non-validating security-aware stub resolvers should use + some form of channel security to defend against the latter threat. + The only known defense against the former threat would be for the + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, as an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with RRSIG RRs in response messages or by constructing + needlessly complex signature chains. An attacker may also be able to + consume resources in a security-aware name server that supports DNS + dynamic update, by sending a stream of update messages that force the + security-aware name server to re-sign some RRsets in the zone more + frequently than would otherwise be necessary. + + Due to a deliberate design choice, DNSSEC does not provide + confidentiality. + + DNSSEC introduces the ability for a hostile party to enumerate all + the names in a zone by following the NSEC chain. NSEC RRs assert + which names do not exist in a zone by linking from existing name to + existing name along a canonical ordering of all the names within a + zone. Thus, an attacker can query these NSEC RRs in sequence to + obtain all the names in a zone. Although this is not an attack on + the DNS itself, it could allow an attacker to map network hosts or + other resources by enumerating the contents of a zone. + + DNSSEC introduces significant additional complexity to the DNS and + thus introduces many new opportunities for implementation bugs and + misconfigured zones. In particular, enabling DNSSEC signature + validation in a resolver may cause entire legitimate zones to become + effectively unreachable due to DNSSEC configuration errors or bugs. + + DNSSEC does not protect against tampering with unsigned zone data. + Non-authoritative data at zone cuts (glue and NS RRs in the parent + zone) are not signed. This does not pose a problem when validating + the authentication chain, but it does mean that the non-authoritative + data itself is vulnerable to tampering during zone transfer + operations. Thus, while DNSSEC can provide data origin + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be + used to protect zone transfer operations. + + + +Arends, et al. Standards Track [Page 16] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + Please see [RFC4034] and [RFC4035] for additional security + considerations. + +13. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group. Although explicitly listing + everyone who has contributed during the decade in which DNSSEC has + been under development would be impossible, the editors would + particularly like to thank the following people for their + contributions to and comments on this document set: Jaap Akkerhuis, + Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, + David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald + Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, + Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip + Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, + Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon + Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, + Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, + Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ + Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob + Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, + Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, + Brian Wellington, and Suzanne Woolf. + + No doubt the above list is incomplete. We apologize to anyone we + left out. + +14. References + +14.1. Normative References + + [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. + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + + + + +Arends, et al. Standards Track [Page 17] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for 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. + +14.2. Informative References + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates + in the Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [RFC3007] Wellington, B., "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. + + [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4033 DNS Security Introduction and Requirements March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 21] + diff --git a/contrib/bind9/doc/rfc/rfc4034.txt b/contrib/bind9/doc/rfc/rfc4034.txt new file mode 100644 index 0000000..6a12c6b --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4034.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4034 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + Resource Records for the DNS Security Extensions + +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 (2005). + +Abstract + + This document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . 3 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4 + 2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4 + 2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4 + 2.1.2. The Protocol Field . . . . . . . . . . . . . . 5 + 2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5 + 2.1.4. The Public Key Field . . . . . . . . . . . . . 5 + 2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5 + 2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5 + 2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6 + 3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7 + 3.1.1. The Type Covered Field . . . . . . . . . . . . 7 + 3.1.2. The Algorithm Number Field . . . . . . . . . . 8 + 3.1.3. The Labels Field . . . . . . . . . . . . . . . 8 + 3.1.4. Original TTL Field . . . . . . . . . . . . . . 8 + 3.1.5. Signature Expiration and Inception Fields. . . 9 + 3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9 + 3.1.7. The Signer's Name Field. . . . . . . . . . . . 9 + 3.1.8. The Signature Field. . . . . . . . . . . . . . 9 + 3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10 + 3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12 + 4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13 + 4.1.1. The Next Domain Name Field . . . . . . . . . . 13 + 4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13 + 4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14 + 4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14 + 4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15 + 5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16 + 5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16 + 5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16 + 5.1.3. The Digest Type Field. . . . . . . . . . . . . 17 + 5.1.4. The Digest Field . . . . . . . . . . . . . . . 17 + 5.2. Processing of DS RRs When Validating Responses . . . . 17 + 5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17 + 5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18 + 6. Canonical Form and Order of Resource Records . . . . . . . . 18 + 6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18 + 6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19 + 6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20 + 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20 + 8. Security Considerations. . . . . . . . . . . . . . . . . . . 21 + + + +Arends, et al. Standards Track [Page 2] + +RFC 4034 DNSSEC Resource Records March 2005 + + + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . 23 + A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24 + A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24 + A.1.1. Private Algorithm Types. . . . . . . . . . . . 25 + A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25 + B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25 + B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29 + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNS Public Key (DNSKEY), Resource Record Signature + (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This + document defines the purpose of each resource record (RR), the RR's + RDATA format, and its presentation format (ASCII representation). + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC, which + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definition of common + terms; the reader is assumed to be familiar with this document. + [RFC4033] also contains a list of other documents updated by and + obsoleted by this document set. + + [RFC4035] defines the DNSSEC protocol operations. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them, particularly [RFC2181] and [RFC2308]. + + This document defines the DNSSEC resource records. All numeric DNS + type codes given in this document are decimal integers. + +1.2. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4034 DNSSEC Resource Records March 2005 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [RFC4035]: A zone signs its authoritative RRsets by + using a private key and stores the corresponding public key in a + DNSKEY RR. A resolver can then use the public key to validate + signatures covering the RRsets in the zone, and thus to authenticate + them. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys and MUST NOT be used to store certificates or public keys + that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1. DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.1.1. The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's + owner name MUST be the name of a zone. If bit 7 has value 0, then + the DNSKEY record holds some other type of DNS public key and MUST + NOT be used to verify RRSIGs that cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a + key intended for use as a secure entry point. This flag is only + + + +Arends, et al. Standards Track [Page 4] + +RFC 4034 DNSSEC Resource Records March 2005 + + + intended to be a hint to zone signing or debugging software as to the + intended use of this DNSKEY record; validators MUST NOT alter their + behavior during the signature validation process in any way based on + the setting of this bit. This also means that a DNSKEY RR with the + SEP bit set would also need the Zone Key flag set in order to be able + to generate signatures legally. A DNSKEY RR with the SEP set and the + Zone Key flag not set MUST NOT be used to verify RRSIGs that cover + RRsets. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR and MUST be ignored upon receipt. + +2.1.2. The Protocol Field + + The Protocol Field MUST have value 3, and the DNSKEY RR MUST be + treated as invalid during signature verification if it is found to be + some value other than 3. + +2.1.3. The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4. The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and is described in + separate documents. + +2.1.5. Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2. The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer. + Given the currently defined flags, the possible values are: 0, 256, + and 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + + +Arends, et al. Standards Track [Page 5] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Public Key field MUST be represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [RFC3548]. + +2.3. DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + +3. The RRSIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Digital signatures are stored in + RRSIG resource records and are used in the DNSSEC authentication + process described in [RFC4035]. A validator can use these RRSIG RRs + to authenticate RRsets from the zone. The RRSIG RR MUST only be used + to carry verification material (digital signatures) used to secure + DNS operations. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + validator can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034], which stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a signed + zone. + + + + +Arends, et al. Standards Track [Page 6] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR MUST match the TTL value of the RRset it + covers. This is an exception to the [RFC2181] rules for TTL values + of individual RRs within a RRset: individual RRSIG RRs with the same + owner name will have different TTL values if the RRsets they cover + have different TTL values. + +3.1. RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.1.1. The Type Covered Field + + The Type Covered field identifies the type of the RRset that is + covered by this RRSIG record. + + + + + + + +Arends, et al. Standards Track [Page 7] + +RFC 4034 DNSSEC Resource Records March 2005 + + +3.1.2. The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3. The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that a validator + uses it to determine whether the answer was synthesized from a + wildcard. If so, it can be used to determine what owner name was + used in generating the signature. + + To validate a signature, the validator needs the original owner name + that was used to create the signature. If the original owner name + contains a wildcard label ("*"), the owner name may have been + expanded by the server during the response process, in which case the + validator will have to reconstruct the original owner name in order + to validate the signature. [RFC4035] describes how to use the Labels + field to reconstruct the original owner name. + + The value of the Labels field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Labels field MUST be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when the signature is generated or verified. + +3.1.4. Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a validator requires the original TTL. [RFC4035] + describes how to use the Original TTL field value to reconstruct the + original TTL. + + + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4034 DNSSEC Resource Records March 2005 + + +3.1.5. Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + The Signature Expiration and Inception field values specify a date + and time in the form of a 32-bit unsigned number of seconds elapsed + since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network + byte order. The longest interval that can be expressed by this + format without wrapping is approximately 136 years. An RRSIG RR can + have an Expiration field value that is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic", as defined in [RFC1982]. As a direct + consequence, the values contained in these fields cannot refer to + dates more than 68 years in either the past or the future. + +3.1.6. The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature, in network byte order. Appendix B explains + how to calculate Key Tag values. + +3.1.7. The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR that a validator is supposed to use to validate this signature. + The Signer's Name field MUST contain the name of the zone of the + covered RRset. A sender MUST NOT use DNS name compression on the + Signer's Name field when transmitting a RRSIG RR. + +3.1.8. The Signature Field + + The Signature field contains the cryptographic signature that covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. The format of this field depends on the algorithm in + use, and these formats are described in separate companion documents. + +3.1.8.1. Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6), and the set RR(1),...RR(n) is signed as follows: + + + +Arends, et al. Standards Track [Page 9] + +RFC 4034 DNSSEC Resource Records March 2005 + + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | type | class | TTL | RDATA length | RDATA + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + canonical form; and + + The RRset MUST be sorted in canonical order. + + See Sections 6.2 and 6.3 for details on canonical form and ordering + of RRsets. + +3.2. The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field is represented as an RR type mnemonic. When + the mnemonic is not known, the TYPE representation as described in + [RFC3597], Section 5, MUST be used. + + The Algorithm field value MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic, as specified in Appendix + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented either as an unsigned decimal integer indicating seconds + since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in + UTC, where: + + YYYY is the year (0001-9999, but see Section 3.1.5); + MM is the month number (01-12); + DD is the day of the month (01-31); + HH is the hour, in 24 hour notation (00-23); + mm is the minute (00-59); and + SS is the second (00-59). + + Note that it is always possible to distinguish between these two + formats because the YYYYMMDDHHmmSS format will always be exactly 14 + digits, while the decimal representation of a 32-bit unsigned integer + can never be longer than 10 digits. + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. See + Section 2.2. + +3.3. RRSIG RR Example + + The following RRSIG RR stores the signature for the A RRset of + host.example.com: + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4034 DNSSEC Resource Records March 2005 + + + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicates that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate that this signature + can be authenticated using an example.com zone DNSKEY RR whose + algorithm is 5 and whose key tag is 2642. + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the next owner + name (in the canonical ordering of the zone) that contains + authoritative data or a delegation point NS RRset, and the set of RR + types present at the NSEC RR's owner name [RFC3845]. The complete + set of NSEC RRs in a zone indicates which authoritative RRsets exist + in a zone and also form a chain of authoritative owner names in the + zone. This information is used to provide authenticated denial of + existence for DNS data, as described in [RFC4035]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034], + which stated that if a CNAME is present for a name, it is the only + type allowed at that name. An RRSIG (see Section 3) and NSEC MUST + exist for the same name as does a CNAME resource record in a signed + zone. + + See [RFC4035] for discussion of how a zone signer determines + precisely which NSEC RRs it has to include in a zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching ([RFC2308]). + + + + + + + + + + + + +Arends, et al. Standards Track [Page 12] + +RFC 4034 DNSSEC Resource Records March 2005 + + +4.1. NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1.1. The Next Domain Name Field + + The Next Domain field contains the next owner name (in the canonical + ordering of the zone) that has authoritative data or contains a + delegation point NS RRset; see Section 6.1 for an explanation of + canonical ordering. The value of the Next Domain Name field in the + last NSEC record in the zone is the name of the zone apex (the owner + name of the zone's SOA RR). This indicates that the owner name of + the NSEC RR is the last name in the canonical ordering of the zone. + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets for which the given zone is not authoritative + (such as glue records) MUST NOT be listed in the Next Domain Name + unless at least one authoritative RRset exists at the same owner + name. + +4.1.2. The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types that exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + + +Arends, et al. Standards Track [Page 13] + +RFC 4034 DNSSEC Resource Records March 2005 + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, and bit 2 to RR type 258. If a bit is + set, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is clear, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + + Bits representing pseudo-types MUST be clear, as they do not appear + in zone data. If encountered, they MUST be ignored upon being read. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpreted as zero octets. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + A zone MUST NOT include an NSEC RR for any domain name that only + holds glue records. + +4.1.3. Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for the purposes of generating NSEC RRs. Wildcard owner + names appear in the Next Domain Name field without any wildcard + expansion. [RFC4035] describes the impact of wildcards on + authenticated denial of existence. + +4.2. The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + described in [RFC3597], Section 5, MUST be used. + + + + + +Arends, et al. Standards Track [Page 14] + +RFC 4034 DNSSEC Resource Records March 2005 + + +4.3. NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC, + and TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the validator can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or to + prove that there is no AAAA record associated with alfa.example.com. + Authenticated denial of existence is discussed in [RFC4035]. + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [RFC4035]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (parental) side of a delegation, and is authoritative + data in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + + + +Arends, et al. Standards Track [Page 15] + +RFC 4034 DNSSEC Resource Records March 2005 + + + "example.com" zone (the child zone). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing but introduces special response + processing requirements for the DS RR; these are described in + [RFC4035]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1. DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet + Algorithm field, a 1 octet Digest Type field, and a Digest field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +5.1.1. The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record, in network byte order. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2. The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the + algorithm number types. + + + + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4034 DNSSEC Resource Records March 2005 + + +5.1.3. The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4. The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of this writing, the only defined + digest algorithm is SHA-1, which produces a 20 octet digest. + +5.2. Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC + zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be + used in the validation process. + +5.3. The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + + + + + +Arends, et al. Standards Track [Page 17] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4. DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required in order to construct and verify RRSIG + RRs. + +6.1. Canonical DNS Name Order + + For the purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and uppercase + US-ASCII letters are treated as if they were lowercase US-ASCII + letters. + + + + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4034 DNSSEC Resource Records March 2005 + + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + by names ending "z.example". The names within each level are sorted + in the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + +6.2. Canonical RR Form + + For the purposes of DNS security, the canonical form of an RR is the + wire format of the RR where: + + 1. every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + + 2. all uppercase US-ASCII letters in the owner name of the RR are + replaced by the corresponding lowercase US-ASCII letters; + + 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in + the DNS names contained within the RDATA are replaced by the + corresponding lowercase US-ASCII letters; + + 4. if the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + + 5. the RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4034 DNSSEC Resource Records March 2005 + + +6.3. Canonical RR Ordering within an RRset + + For the purposes of DNS security, RRs with the same owner name, + class, and type are sorted by treating the RDATA portion of the + canonical form of each RR as a left-justified unsigned octet sequence + in which the absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs when + putting the RRset in canonical form, it MUST treat this as a protocol + error. If the implementation chooses to handle this protocol error + in the spirit of the robustness principle (being liberal in what it + accepts), it MUST remove all but one of the duplicate RR(s) for the + purposes of calculating the canonical form of the RRset. + +7. IANA Considerations + + This document introduces no new IANA considerations, as all of the + protocol parameters used in this document have already been assigned + by previous specifications. However, since the evolution of DNSSEC + has been long and somewhat convoluted, this section attempts to + describe the current state of the IANA registries and other protocol + parameters that are (or once were) related to DNSSEC. + + Please refer to [RFC4035] for additional IANA considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, + and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. + [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use + of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction + security protocol described in [RFC2931] and to the transaction + KEY Resource Record described in [RFC2930]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] + altered this registry to include flags for each entry regarding + its use with the DNS security extensions. Each algorithm entry + could refer to an algorithm that can be used for zone signing, + transaction security (see [RFC2931]), or both. Values 6-251 are + available for assignment by IETF standards action ([RFC3755]). + See Appendix A for a full listing of the DNS Security Algorithm + Numbers entries at the time of this writing and their status for + use in DNSSEC. + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4034 DNSSEC Resource Records March 2005 + + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] reassigned all values other than 3 + to reserved and closed this IANA registry. The registry remains + closed, and all KEY and DNSKEY records are required to have a + Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains assignments for bit 7 (the ZONE bit) + and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). + As stated in [RFC3755], bits 0-6 and 8-14 are available for + assignment by IETF Standards Action. + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [RFC4033] and [RFC4035] for + additional security considerations related to the use of these + records. + + The DS record points to a DNSKEY RR by using a cryptographic digest, + the key algorithm type, and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing a matching DNSKEY depends on the type of + digest algorithm in use. The only currently defined digest algorithm + is SHA-1, and the working group believes that constructing a public + key that would match the algorithm, key tag, and SHA-1 digest given + in a DS record would be a sufficiently difficult problem that such an + attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation that uses only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. Please see + Appendix B for further details. + + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The table of algorithms in Appendix A and the key tag calculation + algorithms in Appendix B include the RSA/MD5 algorithm for + completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as + explained in [RFC3110]. + +9. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. + +10. References + +10.1. Normative References + + [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. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2536, March 1999. + + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, May 2001. + + + + + +Arends, et al. Standards Track [Page 22] + +RFC 4034 DNSSEC Resource Records March 2005 + + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 3548, July 2003. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name + System KEY (DNSKEY) Resource Record (RR) Secure Entry + Point (SEP) Flag", RFC 3757, April 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, 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. + +10.2. Informative References + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain + Name System (DNS)", RFC 2537, March 1999. + + [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) + RDATA Format", RFC 3845, August 2004. + + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant them. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1. DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the + security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs, as described in [RFC2931]. + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED + 2 Diffie-Hellman [DH] n [RFC2539] - + 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + + + + + + + + + +Arends, et al. Standards Track [Page 24] + +RFC 4034 DNSSEC Resource Records March 2005 + + +A.1.1. Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use, and the remainder of the public key + area is determined by that algorithm. Entities should only use + domain names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO OID) of + that length. The OID indicates the private algorithm in use, and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2. DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but + it does not uniquely identify a DNSKEY record. Implementations MUST + NOT assume that the key tag uniquely identifies a DNSKEY RR. + + + + + +Arends, et al. Standards Track [Page 25] + +RFC 4034 DNSSEC Resource Records March 2005 + + + The key tag is the same for all DNSKEY algorithm types except + algorithm 1 (please see Appendix B.1 for the definition of the key + tag for algorithm 1). The key tag algorithm is the sum of the wire + format of the DNSKEY RDATA broken into 2 octet groups. First, the + RDATA (in wire format) is treated as a series of 2 octet groups. + These groups are then added together, ignoring any carry bits. + + A reference implementation of the key tag algorithm is as an ANSI C + function is given below, with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones-complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + + +Arends, et al. Standards Track [Page 26] + +RFC 4034 DNSSEC Resource Records March 2005 + + +B.1. Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently from the + key tag for all other algorithms, for historical reasons. For a + DNSKEY RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4034 DNSSEC Resource Records March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 29] + diff --git a/contrib/bind9/doc/rfc/rfc4035.txt b/contrib/bind9/doc/rfc/rfc4035.txt new file mode 100644 index 0000000..b701cd2 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4035.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4035 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + Protocol Modifications for the DNS Security Extensions + +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 (2005). + +Abstract + + This document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications that + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + defines the concept of a signed zone, along with the requirements for + serving and resolving by using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . . 4 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5 + 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5 + 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6 + 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7 + 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7 + 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8 + 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9 + 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10 + 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11 + 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11 + 3.1.4. Including DS RRs in a Response . . . . . . . . . 14 + 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15 + 3.1.6. The AD and CD Bits in an Authoritative Response. 16 + 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17 + 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18 + 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19 + 4.2. Signature Verification Support . . . . . . . . . . . . . 19 + 4.3. Determining Security Status of Data . . . . . . . . . . 20 + 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21 + 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21 + 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22 + 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22 + 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23 + 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23 + 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24 + 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24 + 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 + 5.1. Special Considerations for Islands of Security . . . . . 26 + 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26 + 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28 + 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28 + 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29 + 5.3.3. Checking the Signature . . . . . . . . . . . . . 31 + 5.3.4. Authenticating a Wildcard Expanded RRset + Positive Response. . . . . . . . . . . . . . . . 32 + + + +Arends, et al. Standards Track [Page 2] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32 + 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33 + 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 9.2. Informative References . . . . . . . . . . . . . . . . . 35 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41 + B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41 + B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43 + B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44 + B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44 + B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45 + B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46 + B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47 + B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49 + C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49 + C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49 + C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50 + C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50 + C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50 + C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51 + C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51 + C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51 + C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications that add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document + defines the concept of a signed zone and lists the requirements for + zone signing. Section 3 describes the modifications to authoritative + name server behavior necessary for handling signed zones. Section 4 + describes the behavior of entities that include security-aware + resolver functions. Finally, Section 5 defines how to use DNSSEC RRs + to authenticate a response. + + + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC that + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definitions of + common terms; the reader is assumed to be familiar with this + document. [RFC4033] also contains a list of other documents updated + by and obsoleted by this document set. + + [RFC4034] defines the DNSSEC resource records. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them; particularly, [RFC2181] and [RFC2308]. + + This document defines the DNSSEC protocol operations. + +1.2. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), + Next Secure (NSEC), and (optionally) Delegation Signer (DS) records + according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, + respectively. A zone that does not include these records according + to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as does a CNAME RR. + + DNSSEC specifies the placement of two new RR types, NSEC and DS, + which can be placed at the parental side of a zone cut (that is, at a + delegation point). This is an exception to the general prohibition + against putting data in the parent zone at a zone cut. Section 2.6 + describes this change. + + + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +2.1. Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR + containing the corresponding public key. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 + of [RFC4034]). Public keys associated with other DNS operations MAY + be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT + be used to verify RRSIGs. + + If the zone administrator intends a signed zone to be usable other + than as an island of security, the zone apex MUST contain at least + one DNSKEY RR to act as a secure entry point into the zone. This + secure entry point could then be used as the target of a secure + delegation via a corresponding DS RR in the parent zone (see + [RFC4034]). + +2.2. Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets the following requirements: + + o The RRSIG owner name is equal to the RRset owner name. + + o The RRSIG class is equal to the RRset class. + + o The RRSIG Type Covered field is equal to the RRset type. + + o The RRSIG Original TTL field is equal to the TTL of the RRset. + + o The RRSIG RR's TTL is equal to the TTL of the RRset. + + o The RRSIG Labels field is equal to the number of labels in the + RRset owner name, not counting the null root label and not + counting the leftmost label if it is a wildcard. + + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset. + + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + The process for constructing the RRSIG RR for a given RRset is + described in [RFC4034]. An RRset MAY have multiple RRSIG RRs + associated with it. Note that as RRSIG RRs are closely tied to the + RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS + + + +Arends, et al. Standards Track [Page 5] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RR types, do not form RRsets. In particular, the TTL values among + RRSIG RRs with a common owner name do not follow the RRset rules + described in [RFC2181]. + + An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would + add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated + with delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset + located at the delegating parent (if any). + +2.3. Including NSEC RRs in a Zone + + Each owner name in the zone that has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + format of NSEC RRs and the process for constructing the NSEC RR for a + given name is described in [RFC4034]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not + the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + + + +Arends, et al. Standards Track [Page 6] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part + visible only during the zone signing process, as NSEC RRsets are + authoritative data and are therefore signed. Thus, any owner name + that has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + +2.4. Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR that is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. DS RRs that fail to meet these + conditions are not useful for validation, but because the DS RR and + its corresponding DNSKEY RR are in different zones, and because the + DNS is only loosely consistent, temporary mismatches can occur. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (that is, the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5. Changes to the CNAME Resource Record + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed ([RFC3007]). + Other types MUST NOT be present at that name. + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + + + +Arends, et al. Standards Track [Page 7] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + +2.6. DNSSEC RR Types Appearing at Zone Cuts + + DNSSEC introduced two new RR types that are unusual in that they can + appear at the parental side of a zone cut. At the parental side of a + zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at + the owner name. A DS RR could also be present if the zone being + delegated is signed and seeks to have a chain of authentication to + the parent zone. This is an exception to the original DNS + specification ([RFC1034]), which states that only NS RRsets could + appear at the parental side of a zone cut. + + This specification updates the original DNS specification to allow + NSEC and DS RR types at the parent side of a zone cut. These RRsets + are authoritative for the parent when they appear at the parent side + of a zone cut. + +2.7. Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 ([RFC2671]) + message size extension, MUST support a message size of at least 1220 + octets, and SHOULD support a message size of 4000 octets. As IPv6 + packets can only be fragmented by the source host, a security aware + name server SHOULD take steps to ensure that UDP datagrams it + transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 + MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], + and [RFC3226] for further discussion of packet size and fragmentation + issues. + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server that receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit clear MUST + treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and + MUST NOT perform any of the additional processing described below. + Because the DS RR type has the peculiar property of only existing in + the parent zone at delegation points, DS RRs always require some + special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive explicit queries for + security RR types that match the content of more than one zone that + it serves (for example, NSEC and RRSIG RRs above and below a + delegation point where the server is authoritative for both zones) + should behave self-consistently. As long as the response is always + consistent for each query to the name server, the name server MAY + return one of the following: + + o The above-delegation RRsets. + o The below-delegation RRsets. + o Both above and below-delegation RRsets. + o Empty answer section (no records). + o Some other response. + o An error. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Sections 3.1.6, + 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. + + A security aware name server that synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1. Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT + pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name + server for a signed zone MUST include additional RRSIG, NSEC, and DS + RRs, according to the following rules: + + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1. + + + + + + + +Arends, et al. Standards Track [Page 9] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3. + + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + These rules only apply to responses where the semantics convey + information about the presence or absence of resource records. That + is, these rules are not intended to rule out responses such as RCODE + 4 ("Not Implemented") or RCODE 5 ("Refused"). + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1. Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server SHOULD attempt to send RRSIG RRs that a + security-aware resolver can use to authenticate the RRsets in the + response. A name server SHOULD make every attempt to keep the RRset + and its associated RRSIG(s) together in a response. Inclusion of + RRSIG RRs in a response is subject to the following rules: + + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may have to be included. If space does not permit inclusion + of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may have to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + associated RRSIG RRs, the name server MAY retain the RRset while + dropping the RRSIG RRs. If this happens, the name server MUST NOT + set the TC bit solely because these RRSIG RRs didn't fit. + + + + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.2. Including DNSKEY RRs in a Response + + When responding to a query that has the DO bit set and that requests + the SOA or NS RRs at the apex of a signed zone, a security-aware + authoritative name server for that zone MAY return the zone apex + DNSKEY RRset in the Additional section. In this situation, the + DNSKEY RRset and associated RRSIG RRs have lower priority than does + any other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3. Including NSEC RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server for a signed zone MUST include NSEC RRs in + each of the following cases: + + No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> + but does not contain any RRsets that exactly match <SNAME, SCLASS, + STYPE>. + + Name Error: The zone does not contain any RRsets that match <SNAME, + SCLASS> either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS> but does contain an RRset that matches + <SNAME, SCLASS, STYPE> via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match <SNAME, SCLASS> and does contain one or more RRsets that + match <SNAME, SCLASS> via wildcard name expansion, but does not + contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard + name expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for <SNAME, SCLASS, STYPE> was + not present in the zone and that the response that the name server is + returning is correct given the data in the zone. + + + + + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.3.1. Including NSEC RRs: No Data Response + + If the zone contains RRsets matching <SNAME, SCLASS> but contains no + RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST + include the NSEC RR for <SNAME, SCLASS> along with its associated + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove that the + requested RR type does not exist. + +3.1.3.2. Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching <SNAME, SCLASS> + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + + o An NSEC RR proving that there is no exact match for <SNAME, + SCLASS>. + + o An NSEC RR proving that the zone contains no RRsets that would + match <SNAME, SCLASS> via wildcard name expansion. + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + that is not the owner name for any RRset but that is the parent name + of one or more RRsets). + +3.1.3.3. Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets that exactly match <SNAME, + SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> + via wildcard name expansion, the name server MUST include the + + + +Arends, et al. Standards Track [Page 12] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section and MUST include in the Authority + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for <SNAME, SCLASS>. If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + +3.1.3.4. Including NSEC RRs: Wildcard No Data Response + + This case is a combination of the previous cases. The zone does not + contain an exact match for <SNAME, SCLASS>, and although the zone + does contain RRsets that match <SNAME, SCLASS> via wildcard + expansion, none of those RRsets matches STYPE. The name server MUST + include the following NSEC RRs in the Authority section, along with + their associated RRSIG RRs: + + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name that matched <SNAME, SCLASS> via wildcard + expansion. + + o An NSEC RR proving that there are no RRsets in the zone that would + have been a closer match for <SNAME, SCLASS>. + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5. Finding the Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server has to locate an NSEC RR + that proves that no RRsets matching a particular SNAME exist. + Locating such an NSEC RR within an authoritative zone is relatively + simple, at least in concept. The following discussion assumes that + the name server is authoritative for the zone that would have held + the non-existent RRsets matching SNAME. The algorithm below is + written for clarity, not for efficiency. + + To find the NSEC that proves that no RRsets matching name N exist in + the zone Z that would have held them, construct a sequence, S, + consisting of the owner names of every RRset in Z, sorted into + + + +Arends, et al. Standards Track [Page 13] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + canonical order ([RFC4034]), with no duplicate names. Find the name + M that would have immediately preceded N in S if any RRsets with + owner name N had existed. M is the owner name of the NSEC RR that + proves that no RRsets exist with owner name N. + + The algorithm for finding the NSEC RR that proves that a given name + is not covered by any applicable wildcard is similar but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + precisely the same as the algorithm for finding the NSEC RR that + proves that RRsets with any other owner name do not exist. The part + that's missing is a method of determining the name of the non- + existent applicable wildcard. In practice, this is easy, because the + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4. Including DS RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server returning a referral includes DNSSEC data + along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR that proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1. Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, as the name server for the + child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + + +Arends, et al. Standards Track [Page 14] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + + o The name server has received a query for the DS RRset at a zone + cut. + + o The name server is authoritative for the child zone. + + o The name server is not authoritative for the parent zone. + + o The name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5. Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails to meet any of the signing + requirements described in Section 2. The primary objective of a zone + transfer is to ensure that all authoritative name servers have + identical copies of the zone. An authoritative name server that + + + +Arends, et al. Standards Track [Page 15] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + chooses to perform its own zone validation MUST NOT selectively + reject some RRs and accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + of the zone in which the RRset is authoritative data. In the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut and + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, as the NSEC RR in the child zone's apex will always indicate + the presence of the child zone's SOA RR whereas the parental NSEC RR + at the zone cut will never indicate the presence of an SOA RR. As + with any other authoritative RRs, NSEC RRs MUST be included in zone + transfers of the zone in which they are authoritative data. The + parental NSEC RR at a zone cut MUST be included in zone transfers of + the parent zone, and the NSEC at the zone apex of the child zone MUST + be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut and + are authoritative in whichever zone contains the authoritative RRset + for which the RRSIG RR provides the signature. That is, the RRSIG RR + for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, and the RRSIG for any RRset in the + child zone's apex will be authoritative in the child zone. Parental + and child RRSIG RRs at a zone cut will never be identical to each + other, as the Signer's Name field of an RRSIG RR in the child zone's + apex will indicate a DNSKEY RR in the child zone's apex whereas the + same field of a parental RRSIG RR at the zone cut will indicate a + DNSKEY RR in the parent zone's apex. As with any other authoritative + RRs, RRSIG RRs MUST be included in zone transfers of the zone in + which they are authoritative data. + +3.1.6. The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + A security-aware name server does not perform signature validation + for authoritative data during query processing, even when the CD bit + is clear. A security-aware name server SHOULD clear the CD bit when + composing an authoritative response. + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation. However, the name + server MUST NOT do so unless the name server obtained the + authoritative zone via secure means (such as a secure zone transfer + mechanism) and MUST NOT do so unless this behavior has been + configured explicitly. + + A security-aware name server that supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2. Recursive Name Servers + + As explained in [RFC4033], a security-aware recursive name server is + an entity that acts in both the security-aware name server and + security-aware resolver roles. This section uses the terms "name + server side" and "resolver side" to refer to the code within a + security-aware recursive name server that implements the + security-aware name server role and the code that implements the + security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching that would apply to any security-aware resolver. + +3.2.1. The DO Bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2. The CD Bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the state of the CD bit to the resolver side along with the rest + + + +Arends, et al. Standards Track [Page 17] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + of an initiating query, so that the resolver side will know whether + it is required to verify the response data it returns to the name + server side. If the CD bit is set, it indicates that the originating + resolver is willing to perform whatever authentication its local + policy requires. Thus, the resolver side of the recursive name + server need not perform authentication on the RRsets in the response. + When the CD bit is set, the recursive name server SHOULD, if + possible, return the requested data to the originating resolver, even + if the recursive name server's local authentication policy would + reject the records in question. That is, by setting the CD bit, the + originating resolver has indicated that it takes responsibility for + performing its own authentication, and the recursive name server + should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query that matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the state of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + The intent of the above rule is to provide the raw data to clients + that are capable of performing their own signature verification + checks while protecting clients that depend on the resolver side of a + security-aware recursive name server to perform such checks. Several + of the possible reasons why signature validation might fail involve + conditions that may not apply equally to the recursive name server + and the client that invoked it. For example, the recursive name + server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security that the recursive name + server does not share. In such cases, "protecting" a client that is + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3. The AD Bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backward compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RRs demonstrably could have been synthesized from an authentic DNAME + RR that is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3. Example DNSSEC Responses + + See Appendix B for example response packets. + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1. EDNS Support + + A security-aware resolver MUST include an EDNS ([RFC2671]) OPT + pseudo-RR with the DO ([RFC3225]) bit set when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR + to advertise the message size that it is willing to accept. A + security-aware resolver's IP layer MUST handle fragmented UDP packets + correctly regardless of whether any such fragmented packets were + received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and + [RFC3226] for discussion of these requirements. + +4.2. Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5 and SHOULD apply them to every + received response, except when: + + o the security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + + o the response is the result of a query generated directly via some + form of application interface that instructed the security-aware + resolver not to perform validation for this query; or + + o validation for this query has been disabled by local policy. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security-aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware that the answers received may not be sufficient to + validate the original response. For example, a zone update may have + changed (or deleted) the desired information between the original and + follow-up queries. + + When attempting to retrieve missing NSEC RRs that reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name. If no NS RRset is present at that name, the + resolver then strips off the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +4.3. Determining Security Status of Data + + A security-aware resolver MUST be able to determine whether it should + expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed and is subject to + signature validation, as described above. + + Insecure: An RRset for which the resolver knows that it has no chain + of signed DNSKEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Bogus: An RRset for which the resolver believes that it ought to be + able to establish a chain of trust but for which it is unable to + do so, either due to signatures that for some reason fail to + validate or due to missing data that the relevant DNSSEC RRs + indicate should be present. This case may indicate an attack but + may also indicate a configuration error or some form of data + corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether the RRset should be signed, as the resolver is + not able to obtain the necessary DNSSEC RRs. This can occur when + the security-aware resolver is not able to contact security-aware + name servers for the relevant zones. + +4.4. Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + least one trusted public key or DS RR and SHOULD be capable of being + configured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a configured trust anchor, the resolver SHOULD have some + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also cover key material that is updated in a + secure manner. This secure manner could be through physical media, a + key exchange protocol, or some other out-of-band means. + +4.5. Response Caching + + A security-aware resolver SHOULD cache each response as a single + atomic entry containing the entire answer, including the named RRset + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double <QNAME,QCLASS>. + + The reason for these recommendations is that, between the initial + query and the expiration of the data from the cache, the + authoritative data might have been changed (for example, via dynamic + update). + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + There are two situations for which this is relevant: + + 1. By using the RRSIG record, it is possible to deduce that an + answer was synthesized from a wildcard. A security-aware + recursive name server could store this wildcard data and use it + to generate positive responses to queries other than the name for + which the original answer was first received. + + 2. NSEC RRs received to prove the non-existence of a name could be + reused by a security-aware resolver to prove the non-existence of + any name in the name range it spans. + + In theory, a resolver could use wildcards or NSEC RRs to generate + positive and negative responses (respectively) until the TTL or + signatures on the records in question expire. However, it seems + prudent for resolvers to avoid blocking new authoritative data or + synthesizing new data on their own. Resolvers that follow this + recommendation will have a more consistent view of the namespace. + +4.6. Handling of the CD and AD Bits + + A security-aware resolver MAY set a query's CD bit in order to + indicate that the resolver takes responsibility for performing + whatever authentication its local policy requires on the RRsets in + the response. See Section 3.2 for the effect this bit has on the + behavior of security-aware recursive name servers. + + A security-aware resolver MUST clear the AD bit when composing query + messages to protect against buggy name servers that blindly copy + header bits that they do not understand from the query message to the + response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained by using a secure channel + or the resolver was specifically configured to regard the message + header bits without using a secure channel. + +4.7. Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + + + +Arends, et al. Standards Track [Page 22] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Conceptually, caching such data is similar to negative caching + ([RFC2308]), except that instead of caching a valid negative + response, the resolver is caching the fact that a particular answer + failed to validate. This document refers to a cache of data with + invalid signatures as a "BAD cache". + + Resolvers that implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier, + particularly the following: + + o Since RRsets that fail to validate do not have trustworthy TTLs, + the implementation MUST assign a TTL. This TTL SHOULD be small, + in order to mitigate the effect of caching the results of an + attack. + + o In order to prevent caching of a transient validation failure + (which might be the result of an attack), resolvers SHOULD track + queries that result in validation failures and SHOULD only answer + from the BAD cache after the number of times that responses to + queries for that particular <QNAME, QTYPE, QCLASS> have failed to + validate exceeds a threshold value. + + Resolvers MUST NOT return RRsets from the BAD cache unless the + resolver is not required to validate the signatures of the RRsets in + question under the rules given in Section 4.2 of this document. See + Section 3.2.2 for discussion of how the responses returned by a + security-aware recursive name server interact with a BAD cache. + +4.8. Synthesized CNAMEs + + A validating security-aware resolver MUST treat the signature of a + valid signed DNAME RR as also covering unsigned CNAME RRs that could + have been synthesized from the DNAME RR, as described in [RFC2672], + at least to the extent of not rejecting a response message solely + because it contains such CNAME RRs. The resolver MAY retain such + CNAME RRs in its cache or in the answers it hands back, but is not + required to do so. + +4.9. Stub Resolvers + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. + + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +4.9.1. Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application that + invoked it, but is not required to do so. A non-validating stub + resolver that seeks to do this will need to set the DO bit in order + to receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, + because otherwise it will not receive the DNSSEC RRs it needs to + perform signature validation. + +4.9.2. Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless it is requested by the application + layer, as by definition, a non-validating stub resolver depends on + the security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + because otherwise the security-aware recursive name server will + answer the query using the name server's local policy, which may + prevent the stub resolver from receiving data that would be + acceptable to the stub resolver's local policy. + +4.9.3. Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + that sent the response claims to have cryptographically verified the + data in the Answer and Authority sections of the response message. + Note, however, that the responses received by a security-aware stub + resolver are heavily dependent on the local policy of the + security-aware recursive name server. Therefore, there may be little + practical value in checking the status of the AD bit, except perhaps + as a debugging aid. In any case, a security-aware stub resolver MUST + NOT place any reliance on signature validation allegedly performed on + its behalf, except when the security-aware stub resolver obtained the + data in question from a trusted security-aware recursive name server + via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, as, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + +Arends, et al. Standards Track [Page 24] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5. Authenticating DNS Responses + + To use DNSSEC RRs for authentication, a security-aware resolver + requires configured knowledge of at least one authenticated DNSKEY or + DS RR. The process for obtaining and authenticating this initial + trust anchor is achieved via some external mechanism. For example, a + resolver could use some off-line authenticated exchange to obtain a + zone's DNSKEY RR or to obtain a DS RR that identifies and + authenticates a zone's DNSKEY RR. The remainder of this section + assumes that the resolver has somehow obtained an initial set of + trust anchors. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset by using an initial key, + the resolver MUST: + + 1. verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA + bit 7) set; and + + 2. verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset by using an + initial DNSKEY RR, delegations from that zone can be authenticated by + using DS RRs. This allows a resolver to start from an initial key + and use DS RRsets to proceed recursively down the DNS tree, obtaining + other apex DNSKEY RRsets. If the resolver were configured with a + root DNSKEY RR, and if every delegation had a DS RR associated with + it, then the resolver could obtain and validate any apex DNSKEY + RRset. The process of using DS RRs to authenticate referrals is + described in Section 5.2. + + Section 5.3 shows how the resolver can use DNSKEY RRs in the apex + DNSKEY RRset and RRSIG RRs from the zone to authenticate any other + RRsets in the zone once the resolver has authenticated a zone's apex + DNSKEY RRset. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + lacks the appropriate DNSSEC RRs, whether due to configuration issues + such as an upstream security-oblivious recursive name server that + + + +Arends, et al. Standards Track [Page 25] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + accidentally interferes with DNSSEC RRs or due to a deliberate attack + in which an adversary forges a response, strips DNSSEC RRs from a + response, or modifies a query so that DNSSEC RRs appear not to be + requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1. Special Considerations for Islands of Security + + Islands of security (see [RFC4033]) are signed zones for which it is + not possible to construct an authentication chain to the zone from + its parent. Validating signatures within an island of security + requires that the validator have some other means of obtaining an + initial authenticated zone key for the island. If a validator cannot + obtain such a key, it SHOULD switch to operating as if the zones in + the island of security are unsigned. + + All the normal processes for validating responses apply to islands of + security. The only difference between normal validation and + validation within an island of security is in how the validator + obtains a trust anchor for the authentication chain. + +5.2. Authenticating Referrals + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset and contains a cryptographic digest of the + child zone's DNSKEY RR. Use of a strong cryptographic digest + algorithm ensures that it is computationally infeasible for an + adversary to generate a DNSKEY RR that matches the digest. Thus, + authenticating the digest allows a resolver to authenticate the + matching DNSKEY RR. The resolver can then use this child DNSKEY RR + to authenticate the entire child apex DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3). + + + + + +Arends, et al. Standards Track [Page 26] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset, and, when the DNSKEY RR's owner name and RDATA are hashed + using the digest algorithm specified in the DS RR's Digest Type + field, the resulting digest value matches the Digest field of the + DS RR. + + o The matching DNSKEY RR in the child zone has the Zone Flag bit + set, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator cannot authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + Note that, for a signed delegation, there are two NSEC RRs associated + with the delegated name. One NSEC RR resides in the parent zone and + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished because the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3. Authenticating an RRset with an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The validator then constructs the + canonical form of the signed data by appending the RRSIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, the validator uses the public key and + signature to authenticate the signed data. Sections 5.3.1, 5.3.2, + and 5.3.3 describe each step in detail. + +5.3.1. Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + + o The RRSIG RR and the RRset MUST have the same owner name and the + same class. + + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset. + + o The RRSIG RR's Type Covered field MUST equal the RRset's type. + + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field. + + o The validator's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field. + + o The validator's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field. + + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset. + + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set. + + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the validator cannot predetermine which DNSKEY + RR to use to authenticate the signature, and it MUST try each + matching DNSKEY RR until either the signature is validated or the + validator has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + validator authenticates the DNSKEY RR before using it to validate + signatures. The matching DNSKEY RR is considered to be authentic if: + + o the apex DNSKEY RRset containing the DNSKEY RR is considered + authentic; or + + o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a trust anchor. + +5.3.2. Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + Section 5.3.1, the validator has to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The validator should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | type | class | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + + + +Arends, et al. Standards Track [Page 29] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + RRset. + + The canonical forms for names and RRsets are defined in [RFC4034]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRsets are present at the parent zone. The second NSEC RRset resides + at the child zone and identifies which RRsets are present at the apex + in the child zone. The parent NSEC RRset and child NSEC RRset can + always be distinguished as only a child NSEC RR will indicate that an + SOA RRset exists at the name. When reconstructing the original NSEC + RRset for the delegation from the parent zone, the NSEC RRs MUST NOT + be combined with NSEC RRs from the child zone. When reconstructing + the original NSEC RRset for the apex of the child zone, the NSEC RRs + MUST NOT be combined with NSEC RRs from the parent zone. + + Note that each of the two NSEC RRsets at a delegation point has a + corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + + + + + + + + +Arends, et al. Standards Track [Page 30] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5.3.3. Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] + provides a list of algorithm types and provides pointers to the + documents that define each algorithm's use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the validator can only + determine which DNSKEY RR is correct by trying each matching public + key until the validator either succeeds in validating the signature + or runs out of keys to try. + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also has to test these RRSIG + RRs and how to resolve conflicts if these RRSIG RRs lead to differing + results. + + If the resolver accepts the RRset as authentic, the validator MUST + set the TTL of the RRSIG RR and each RR in the authenticated RRset to + a value no greater than the minimum of: + + o the RRset's TTL as received in the response; + + o the RRSIG RR's TTL as received in the response; + + o the value in the RRSIG RR's Original TTL field; and + + o the difference of the RRSIG RR's Signature Expiration time and the + current time. + + + + + +Arends, et al. Standards Track [Page 31] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5.3.4. Authenticating a Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the validator has verified the signature, as described in + Section 5.3, it must take additional steps to verify the non- + existence of an exact match or closer wildcard match for the query. + Section 5.4 discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4. Authenticated Denial of Existence + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Denial of existence is determined by the following rules: + + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [RFC4034], then no RRsets with the requested name exist + in the zone. However, it is possible that a wildcard could be + used to match the requested RR owner name and type, so proving + that the requested RRset does not exist also requires proving that + no possible wildcard RRset exists that could have been used to + generate a positive response. + + In addition, security-aware resolvers MUST authenticate the NSEC + RRsets that comprise the non-existence proof as described in Section + 5.3. + + To prove the non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + + + +Arends, et al. Standards Track [Page 32] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify the non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a validated NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a validator MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5. Resolver Behavior When Signatures Do Not Validate + + If for whatever reason none of the RRSIGs can be validated, the + response SHOULD be considered BAD. If the validation was being done + to service a recursive query, the name server MUST return RCODE 2 to + the originating client. However, it MUST return the full response if + and only if the original query had the CD bit set. Also see Section + 4.7 on caching responses that do not validate. + +5.6. Authentication Example + + Appendix C shows an example of the authentication process. + +6. IANA Considerations + + [RFC4034] contains a review of the IANA considerations introduced by + DNSSEC. The following are additional IANA considerations discussed + in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655], and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [RFC4033] for terminology and general security + considerations related to DNSSEC; see [RFC4034] for considerations + specific to the DNSSEC resource record types. + + + + +Arends, et al. Standards Track [Page 33] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection that DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Sections 3.2.2 and 4.9 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, as + recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will have to pay close attention to the + behavior of the applications that use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. + +9. References + +9.1. Normative References + + [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. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + + +Arends, et al. Standards Track [Page 34] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [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 DNS Security Extensions", RFC + 4034, March 2005. + +9.2. Informative References + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 35] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Standards Track [Page 36] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Standards Track [Page 37] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Standards Track [Page 38] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Standards Track [Page 39] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Standards Track [Page 40] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key that should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry, "*.w.example". Note that the + name "*.w.example" is used in constructing NSEC chains, and that the + RRSIG covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1. Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + + + +Arends, et al. Standards Track [Page 41] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + + + +Arends, et al. Standards Track [Page 42] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.2. Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + +Arends, et al. Standards Track [Page 43] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.3. No Data Error + + A "no data" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + +B.4. Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + ;; Header: QR DO RCODE=0 + ;; + + + +Arends, et al. Standards Track [Page 44] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + +B.5. Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + + +Arends, et al. Standards Track [Page 45] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + +B.6. Wildcard Expansion + + A successful query that was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + + + +Arends, et al. Standards Track [Page 46] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + +B.7. Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + + + +Arends, et al. Standards Track [Page 47] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + +B.8. DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + + + +Arends, et al. Standards Track [Page 48] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1. Authenticating an Answer + + The query in Appendix B.1 returned an MX RRset for "x.w.example.com". + The corresponding RRSIG indicates that the MX RRset was signed by an + "example" DNSKEY with algorithm 5 and key tag 38519. The resolver + needs the corresponding DNSKEY RR in order to authenticate this + answer. The discussion below describes how a resolver might obtain + this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600, and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates that the answer + was not the result of wildcard expansion. The "x.w.example.com" MX + RRset is placed in canonical form, and, assuming the current time + falls between the signature inception and expiration dates, the + signature is authenticated. + +C.1.1. Authenticating the Example DNSKEY RR + + This example shows the logical authentication process that starts + from the a configured root DNSKEY (or DS RR) and moves down the tree + to authenticate the desired "example" DNSKEY RR. Note that the + logical order is presented for clarity. An implementation may choose + to construct the authentication as referrals are received or to + construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with a configured DNSKEY RR for the + root zone (or a configured DS RR for the root zone). The resolver + checks whether this configured DNSKEY RR is present in the root + DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root + DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY + RRset, and whether the signature lifetime is valid. If all these + + + +Arends, et al. Standards Track [Page 49] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + conditions are met, all keys in the DNSKEY RRset are considered + authenticated. The resolver then uses one (or more) of the root + DNSKEY RRs to authenticate the "example" DS RRset. Note that the + resolver may have to query the root zone to obtain the root DNSKEY + RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. + + Finally, the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This + DNSKEY is used to authenticate the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. + +C.2. Name Error + + The query in Appendix B.2 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3. No Data Error + + The query in Appendix B.3 returned an NSEC RR that proves that the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4. Referral to Signed Zone + + The query in Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks whether + + + +Arends, et al. Standards Track [Page 50] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + the signature lifetime is valid. If all these conditions are met, + all keys in the "a.example" DNSKEY RRset are considered + authenticated. + +C.5. Referral to Unsigned Zone + + The query in Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + "example" to "b.example", and the NSEC RR is authenticated in a + manner identical to that of the MX RRset discussed above. + +C.6. Wildcard Expansion + + The query in Appendix B.6 returned an answer that was produced as a + result of wildcard expansion. The answer section contains a wildcard + RRset expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The RRSIG indicates that the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG labels field value of 2 indicates that the answer + is the result of wildcard expansion, as the "a.z.w.example" name + contains 4 labels. The name "a.z.w.w.example" is replaced by + "*.w.example", the MX RRset is placed in canonical form, and, + assuming that the current time falls between the signature inception + and expiration dates, the signature is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query, and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7. Wildcard No Data Error + + The query in Appendix B.7 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8. DS Child Zone No Data Error + + The query in Appendix B.8 returned NSEC RRs that shows the requested + was answered by a child server ("example" server). The NSEC RR + indicates the presence of an SOA RR, showing that the answer is from + the child . Queries for the "example" DS RRset should be sent to the + parent servers ("root" servers). + + + + + + +Arends, et al. Standards Track [Page 51] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 52] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 53] + diff --git a/contrib/bind9/doc/rfc/rfc4074.txt b/contrib/bind9/doc/rfc/rfc4074.txt new file mode 100644 index 0000000..d9252b3 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4074.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group Y. Morishita +Request for Comments: 4074 JPRS +Category: Informational T. Jinmei + Toshiba + May 2005 + + + Common Misbehavior Against DNS Queries for IPv6 Addresses + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + There is some known misbehavior of DNS authoritative servers when + they are queried for AAAA resource records. Such behavior can block + IPv4 communication that should actually be available, cause a + significant delay in name resolution, or even make a denial of + service attack. This memo describes details of known cases and + discusses their effects. + +1. Introduction + + Many existing DNS clients (resolvers) that support IPv6 first search + for AAAA Resource Records (RRs) of a target host name, and then for A + RRs of the same name. This fallback mechanism is based on the DNS + specifications, which if not obeyed by authoritative servers, can + produce unpleasant results. In some cases, for example, a web + browser fails to connect to a web server it could otherwise reach. + In the following sections, this memo describes some typical cases of + such misbehavior and its (bad) effects. + + Note that the misbehavior is not specific to AAAA RRs. In fact, all + known examples also apply to the cases of queries for MX, NS, and SOA + RRs. The authors believe this can be generalized for all types of + queries other than those for A RRs. In this memo, however, we + concentrate on the case for AAAA queries, since the problem is + particularly severe for resolvers that support IPv6, which thus + affects many end users. Resolvers at end users normally send A + and/or AAAA queries only, so the problem for the other cases is + relatively minor. + + + +Morishita & Jinmei Informational [Page 1] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +2. Network Model + + In this memo, we assume a typical network model of name resolution + environment using DNS. It consists of three components: stub + resolvers, caching servers, and authoritative servers. A stub + resolver issues a recursive query to a caching server, which then + handles the entire name resolution procedure recursively. The + caching server caches the result of the query and sends the result to + the stub resolver. The authoritative servers respond to queries for + names for which they have the authority, normally in a non-recursive + manner. + +3. Expected Behavior + + Suppose that an authoritative server has an A RR but has no AAAA RR + for a host name. Then, the server should return a response to a + query for an AAAA RR of the name with the response code (RCODE) being + 0 (indicating no error) and with an empty answer section (see + Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that + there is at least one RR of a different type than AAAA for the + queried name, and the stub resolver can then look for A RRs. + + This way, the caching server can cache the fact that the queried name + has no AAAA RR (but may have other types of RRs), and thus improve + the response time to further queries for an AAAA RR of the name. + +4. Problematic Behaviors + + There are some known cases at authoritative servers that do not + conform to the expected behavior. This section describes those + problematic cases. + +4.1. Ignore Queries for AAAA + + Some authoritative servers seem to ignore queries for an AAAA RR, + causing a delay at the stub resolver to fall back to a query for an A + RR. This behavior may cause a fatal timeout at the resolver or at + the application that calls the resolver. Even if the resolver + eventually falls back, the result can be an unacceptable delay for + the application user, especially with interactive applications like + web browsing. + +4.2. Return "Name Error" + + This type of server returns a response with RCODE 3 ("Name Error") to + a query for an AAAA RR, indicating that it does not have any RRs of + any type for the queried name. + + + + +Morishita & Jinmei Informational [Page 2] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + + With this response, the stub resolver may immediately give up and + never fall back. Even if the resolver retries with a query for an A + RR, the negative response for the name has been cached in the caching + server, and the caching server will simply return the negative + response. As a result, the stub resolver considers this to be a + fatal error in name resolution. + + Several examples of this behavior are known to the authors. As of + this writing, all have been fixed. + +4.3. Return Other Erroneous Codes + + Other authoritative servers return a response with erroneous response + codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not + Implemented"), indicating that the servers do not support the + requested type of query. + + These cases are less harmful than the previous one; if the stub + resolver falls back to querying for an A RR, the caching server will + process the query correctly and return an appropriate response. + + However, these can still cause a serious effect. There was an + authoritative server implementation that returned RCODE 2 ("Server + failure") to queries for AAAA RRs. One widely deployed mail server + implementation with a certain type of resolver library interpreted + this result as an indication of retry and did not fall back to + queries for A RRs, causing message delivery failure. + + If the caching server receives a response with these response codes, + it does not cache the fact that the queried name has no AAAA RR, + resulting in redundant queries for AAAA RRs in the future. The + behavior will waste network bandwidth and increase the load of the + authoritative server. + + Using RCODE 1 ("Format error") would cause a similar effect, though + the authors have not seen such implementations yet. + +4.4. Return a Broken Response + + Another type of authoritative servers returns broken responses to + AAAA queries. Returning a response whose RR type is AAAA with the + length of the RDATA being 4 bytes is a known behavior of this + category. The 4-byte data looks like the IPv4 address of the queried + host name. + + + + + + + +Morishita & Jinmei Informational [Page 3] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + + That is, the RR in the answer section would be described as follows: + + www.bad.example. 600 IN AAAA 192.0.2.1 + + which is, of course, bogus (or at least meaningless). + + A widely deployed caching server implementation transparently returns + the broken response (and caches it) to the stub resolver. Another + known server implementation parses the response by itself, and sends + a separate response with RCODE 2 ("Server failure"). + + In either case, the broken response does not affect queries for an A + RR of the same name. If the stub resolver falls back to A queries, + it will get an appropriate response. + + The latter case, however, causes the same bad effect as that + described in the previous section: redundant queries for AAAA RRs. + +4.5. Make Lame Delegation + + Some authoritative servers respond to AAAA queries in a way that + causes lame delegation. In this case, the parent zone specifies that + the authoritative server should have the authority of a zone, but the + server should not return an authoritative response for AAAA queries + within the zone (i.e., the AA bit in the response is not set). On + the other hand, the authoritative server returns an authoritative + response for A queries. + + When a caching server asks the server for AAAA RRs in the zone, it + recognizes the delegation is lame, and returns a response with RCODE + 2 ("Server failure") to the stub resolver. + + Furthermore, some caching servers record the authoritative server as + lame for the zone and will not use it for a certain period of time. + With this type of caching server, even if the stub resolver falls + back to querying for an A RR, the caching server will simply return a + response with RCODE 2, since all the servers are known to be "lame." + + There is also an implementation that relaxes the behavior a little + bit. It tries to avoid using the lame server, but continues to try + it as a last resort. With this type of caching server, the stub + resolver will get a correct response if it falls back after Server + failure. However, this still causes redundant AAAA queries, as + explained in the previous sections. + + + + + + + +Morishita & Jinmei Informational [Page 4] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +5. Security Considerations + + The CERT/CC pointed out that the response with RCODE 3 ("Name + Error"), described in Section 4.2, can be used for a denial of + service attack [2]. The same argument applies to the case of "lame + delegation", described in Section 4.5, with a certain type of caching + server. + +6. Acknowledgements + + Erik Nordmark encouraged the authors to publish this document as an + RFC. Akira Kato and Paul Vixie reviewed a preliminary version of + this document. Pekka Savola carefully reviewed a previous version + and provided detailed comments. Bill Fenner, Scott Hollenbeck, + Thomas Narten, and Alex Zinin reviewed and helped improve the + document at the last stage for publication. + +7. Informative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from + AAAA queries could cause denial-of-service conditions", + March 2003, <http://www.kb.cert.org/vuls/id/714121>. + +Authors' Addresses + + MORISHITA Orange Yasuhiro + Research and Development Department, Japan Registry Services Co.,Ltd. + Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda + Chiyoda-ku, Tokyo 101-0065 + Japan + + EMail: yasuhiro@jprs.co.jp + + + JINMEI Tatuya + Corporate Research & Development Center, Toshiba Corporation + 1 Komukai Toshiba-cho, Saiwai-ku + Kawasaki-shi, Kanagawa 212-8582 + Japan + + EMail: jinmei@isl.rdc.toshiba.co.jp + + + + + + + +Morishita & Jinmei Informational [Page 5] + +RFC 4074 Common Misbehavior Against DNS Queries May 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Morishita & Jinmei Informational [Page 6] + diff --git a/contrib/bind9/doc/rfc/rfc4159.txt b/contrib/bind9/doc/rfc/rfc4159.txt new file mode 100644 index 0000000..1ab4bd1 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc4159.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group G. Huston +Request for Comments: 4159 APNIC +BCP: 109 August 2005 +Category: Best Current Practice + + + Deprecation of "ip6.int" + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document advises of the deprecation of the use of "ip6.int" for + Standards Conformant IPv6 implementations. + +1. IPv6 Standards Action + + In August 2001 the IETF published [RFC3152], which advised that the + use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses + to DNS names was deprecated. The document noted that the use of + "ip6.int" would be phased out in an orderly fashion. + + As of 1 September 2005, the IETF advises the community that the DNS + domain "ip6.int" should no longer be used to perform reverse mapping + of IPv6 addresses to domain names, and that the domain "ip6.arpa" + should be used henceforth, in accordance with the IANA Considerations + described in [RFC3596]. The domain "ip6.int" is deprecated, and its + use in IPv6 implementations that conform to the IPv6 Internet + Standards is discontinued. + + The Regional Internet Registries (RIRs) are advised that maintenance + of delegation of entries in "ip6.int" is no longer required as part + of infrastructure services in support of Internet Standards + Conformant IPv6 implementations as of 1 September 2005. The RIRs are + requested to work with their communities to adopt a schedule + regarding the cessation of support of registration services for the + "ip6.int" domain. + + + + + + +Huston Best Current Practice [Page 1] + +RFC 4159 ip6.int August 2005 + + +2. IANA Considerations + + IANA is advised that the "ip6.int" domain for reverse mapping of IPv6 + addresses to domain names is no longer part of Internet Standards + Conformant support of IPv6 as of 1 September 2005. + +3. Security Considerations + + While DNS spoofing of address to name mapping has been exploited in + IPv4, removal of the "ip6.int" zone from the standard IPv6 + specification creates no new threats to the security of the internet. + +4. Acknowledgements + + The document was prepared with the assistance of Kurt Lindqvist, + Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian + Haberman, and Bill Manning. + +5. Normative References + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October + 2003. + +Author's Address + + Geoff Huston + APNIC + + EMail: gih@apnic.net + + + + + + + + + + + + + + + + + + +Huston Best Current Practice [Page 2] + +RFC 4159 ip6.int August 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Huston Best Current Practice [Page 3] + |
