From 56484c0f8572cb07124d89c939c986e69e4ca2d5 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 3 Nov 2003 01:07:13 +0000 Subject: [PATCH] new draft --- ....txt => draft-ietf-dnsext-dhcid-rr-07.txt} | 122 +- ...t => draft-ietf-dnsext-dns-threats-04.txt} | 348 +- .../draft-ietf-dnsext-dnssec-intro-05.txt | 1288 ------- .../draft-ietf-dnsext-dnssec-intro-07.txt | 1400 ++++++++ .../draft-ietf-dnsext-dnssec-protocol-02.txt | 2632 -------------- .../draft-ietf-dnsext-dnssec-protocol-03.txt | 3080 +++++++++++++++++ .../draft-ietf-dnsext-dnssec-records-03.txt | 1848 ---------- .../draft-ietf-dnsext-dnssec-records-05.txt | 2016 +++++++++++ ...ietf-dnsext-keyrr-key-signing-flag-11.txt} | 335 +- 9 files changed, 6925 insertions(+), 6144 deletions(-) rename doc/draft/{draft-ietf-dnsext-dhcid-rr-06.txt => draft-ietf-dnsext-dhcid-rr-07.txt} (82%) rename doc/draft/{draft-ietf-dnsext-dns-threats-03.txt => draft-ietf-dnsext-dns-threats-04.txt} (83%) delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-protocol-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-records-03.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-records-05.txt rename doc/draft/{draft-ietf-dnsext-keyrr-key-signing-flag-10.txt => draft-ietf-dnsext-keyrr-key-signing-flag-11.txt} (54%) diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-06.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt similarity index 82% rename from doc/draft/draft-ietf-dnsext-dhcid-rr-06.txt rename to doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt index 93fd0214e8..4634cfdf53 100644 --- a/doc/draft/draft-ietf-dnsext-dhcid-rr-06.txt +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt @@ -2,14 +2,14 @@ DNSEXT Working Group M. Stapp Internet-Draft Cisco Systems, Inc. -Expires: May 2, 2003 T. Lemon +Expires: April 23, 2004 T. Lemon A. Gustafsson Nominum, Inc. - November 1, 2002 + October 24, 2003 A DNS RR for Encoding DHCP Information (DHCID RR) - + Status of this Memo @@ -32,11 +32,11 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 2, 2003. + This Internet-Draft will expire on April 23, 2004. Copyright Notice - Copyright (C) The Internet Society (2002). All Rights Reserved. + Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract @@ -52,9 +52,9 @@ Abstract -Stapp, et. al. Expires May 2, 2003 [Page 1] +Stapp, et. al. Expires April 23, 2004 [Page 1] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 Table of Contents @@ -75,6 +75,7 @@ Table of Contents 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 @@ -107,10 +108,9 @@ Table of Contents - -Stapp, et. al. Expires May 2, 2003 [Page 2] +Stapp, et. al. Expires April 23, 2004 [Page 2] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 1. Terminology @@ -121,9 +121,9 @@ Internet-Draft The DHCID RR November 2002 2. Introduction - A set of procedures to allow DHCP[3] clients and servers to - automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in - "Resolution of DNS Name Conflicts"[1]. + A set of procedures to allow DHCP[7] clients and servers to + automatically update the DNS (RFC 1034[3], RFC 1035[4]) is proposed + in "Resolution of DNS Name Conflicts"[1]. Conflicts can arise if multiple DHCP clients wish to use the same DNS name. To resolve such conflicts, "Resolution of DNS Name @@ -135,7 +135,7 @@ Internet-Draft The DHCID RR November 2002 RR. In order to avoid exposing potentially sensitive identifying - information, the data stored is the result of a one-way MD5[6] hash + information, the data stored is the result of a one-way MD5[5] hash computation. The hash includes information from the DHCP client's REQUEST message as well as the domain name itself, so that the data stored in the DHCID RR will be dependent on both the client @@ -164,9 +164,9 @@ Internet-Draft The DHCID RR November 2002 -Stapp, et. al. Expires May 2, 2003 [Page 3] +Stapp, et. al. Expires April 23, 2004 [Page 3] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 3.1 DHCID RDATA format @@ -190,7 +190,7 @@ Internet-Draft The DHCID RR November 2002 In DNS master files, the RDATA is represented as a single block in base 64 encoding identical to that used for representing binary data - in RFC2535[7]. The data may be divided up into any number of white + in RFC 2535[8]. The data may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to form the complete RDATA. These substrings can span lines using the standard parentheses. @@ -220,9 +220,9 @@ Internet-Draft The DHCID RR November 2002 -Stapp, et. al. Expires May 2, 2003 [Page 4] +Stapp, et. al. Expires April 23, 2004 [Page 4] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 3.4 Computation of the RDATA @@ -240,7 +240,7 @@ Internet-Draft The DHCID RR November 2002 data = MD5(< identifier > < FQDN >) The FQDN is represented in the buffer in unambiguous canonical form - as described in RFC2535[7], section 8.1. The type code and the + as described in RFC 2535[8], section 8.1. The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. @@ -276,9 +276,9 @@ Internet-Draft The DHCID RR November 2002 -Stapp, et. al. Expires May 2, 2003 [Page 5] +Stapp, et. al. Expires April 23, 2004 [Page 5] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 3.5 Examples @@ -332,9 +332,9 @@ Internet-Draft The DHCID RR November 2002 that the client desires to use to compute a client identity hash, -Stapp, et. al. Expires May 2, 2003 [Page 6] +Stapp, et. al. Expires April 23, 2004 [Page 6] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 and then compare that hash to the data in any DHCID RRs on the name @@ -360,7 +360,7 @@ Internet-Draft The DHCID RR November 2002 Administrators should be wary of permitting unsecured DNS updates to zones which are exposed to the global Internet. Both DHCP clients and servers SHOULD use some form of update authentication (e.g., - TSIG[10]) when performing DNS updates. + TSIG[11]) when performing DNS updates. 7. IANA Considerations @@ -376,77 +376,77 @@ Internet-Draft The DHCID RR November 2002 tentatively assigned after the specification for the associated type code, published as an Internet Draft, has received expert review by a designated expert. The final assignment of DHCID RR type codes is - through Standards Action, as defined in RFC2434[11]. + through Standards Action, as defined in RFC 2434[6]. 8. Acknowledgements Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and Ralph Droms for their review and suggestions. -References +Normative References - [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP + [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients -Stapp, et. al. Expires May 2, 2003 [Page 7] +Stapp, et. al. Expires April 23, 2004 [Page 7] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 - Clients (draft-ietf-dhc-dns-resolution-*)", March 2001. + (draft-ietf-dhc-dns-resolution-*)", November 2002. - [2] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. - [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + [3] Mockapetris, P., "Domain names - Concepts and Facilities", RFC + 1034, Nov 1987. + + [4] Mockapetris, P., "Domain names - Implementation and + Specification", RFC 1035, Nov 1987. + + [5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April + 1992. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", RFC 2434, October 1998. + +Informative References + + [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar 1997. - [4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC - 1034, Nov 1987. - - [5] Mockapetris, P., "Domain names - Implementation and - Specification", RFC 1035, Nov 1987. - - [6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, - April 1992. - - [7] Eastlake, D., "Domain Name System Security Extensions", RFC + [8] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. - [8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, Mar 1997. - [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. + [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (draft-ietf-dhc-dhcpv6-*.txt)", November 2002. - [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. - [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", RFC 2434, October 1998. - Authors' Addresses Mark Stapp Cisco Systems, Inc. - 250 Apollo Dr. - Chelmsford, MA 01824 + 1414 Massachusetts Ave. + Boxborough, MA 01719 USA - Phone: 978.244.8498 + Phone: 978.936.1535 EMail: mjs@cisco.com - - -Stapp, et. al. Expires May 2, 2003 [Page 8] +Stapp, et. al. Expires April 23, 2004 [Page 8] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 Ted Lemon @@ -500,14 +500,14 @@ Internet-Draft The DHCID RR November 2002 -Stapp, et. al. Expires May 2, 2003 [Page 9] +Stapp, et. al. Expires April 23, 2004 [Page 9] -Internet-Draft The DHCID RR November 2002 +Internet-Draft The DHCID RR October 2003 Full Copyright Statement - Copyright (C) The Internet Society (2002). All Rights Reserved. + Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it @@ -556,5 +556,5 @@ Acknowledgement -Stapp, et. al. Expires May 2, 2003 [Page 10] +Stapp, et. al. Expires April 23, 2004 [Page 10] diff --git a/doc/draft/draft-ietf-dnsext-dns-threats-03.txt b/doc/draft/draft-ietf-dnsext-dns-threats-04.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-dns-threats-03.txt rename to doc/draft/draft-ietf-dnsext-dns-threats-04.txt index 7b52283b4e..8a47edaf7b 100644 --- a/doc/draft/draft-ietf-dnsext-dns-threats-03.txt +++ b/doc/draft/draft-ietf-dnsext-dns-threats-04.txt @@ -5,10 +5,10 @@ Network Working Group D. Atkins -draft-ietf-dnsext-dns-threats-03.txt IHTFP Consulting +draft-ietf-dnsext-dns-threats-04.txt IHTFP Consulting R. Austein Grunchweather Associates - June 2003 + October 2003 Threat Analysis Of The Domain Name System @@ -55,9 +55,9 @@ Abstract -Atkins & Austein Expires 29 December 2003 [Page 1] +Atkins & Austein Expires 30 April 2004 [Page 1] -draft-ietf-dnsext-dns-threats-03.txt June 2003 +draft-ietf-dnsext-dns-threats-04.txt October 2003 1. Introduction @@ -77,9 +77,6 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 - While some participants in the meeting were interested in authentication of DNS clients and servers as a basis for access control, this work was also ruled out of scope for DNSSEC per se. - DNS Transaction Signatures (TSIG) were eventually developed as a - separate mechanism to address threats of unauthorized access to - DNS's zone transfer and dynamic update mechanisms. - Backwards compatibility and co-existence with "insecure DNS" was listed as an explicit requirement. @@ -108,17 +105,17 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 it, that is nevertheless what this note attempts to do. Better late than never. - - - -Atkins & Austein Expires 29 December 2003 [Page 2] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - This note assumes that the reader is familiar with both the DNS and with DNSSEC, and does not attempt to provide a tutorial on either. + + + +Atkins & Austein Expires 30 April 2004 [Page 2] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + For purposes of discussion, this note uses the term "DNSSEC" to refer to the core hierarchical public key and signature mechanism specified in the DNSSEC documents, and refers to TKEY and TSIG as separate @@ -164,17 +161,17 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 relationships between all the parties that might be involved in resolving any particular query. For heavily used name servers (such as the servers for the root zone), this cost would almost certainly - - - -Atkins & Austein Expires 29 December 2003 [Page 3] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - be prohibitively high. Even more important, however, is that the underlying trust model in such a design would be wrong, since at best it would only provide a hop-by-hop integrity check on DNS messages + + + +Atkins & Austein Expires 30 April 2004 [Page 3] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + and would not provide any sort of end-to-end integrity check between the producer of DNS data (the zone administrator) and the consumer of DNS data (the application that triggered the query). @@ -203,16 +200,18 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 2.2. ID Guessing and Query Prediction - Since the ID field in the DNS header is only a 16-bit field and the - server UDP port associated with DNS is a well-known value, there are - only 2**32 possible combinations of ID and client UDP port for a - given client and server. This is not a particularly large range, and - is not proof against a brute force search; furthermore, in practice - both the client UDP port and the ID can often be predicted from - previous traffic, and it is not uncommon for the client port to be a - known fixed value as well (due to firewalls or other restrictions), - thus frequently reducing the search space to a range smaller than - 2**16. + Since DNS is for the most part used over UDP/IP, it is relatively + easy for an attacker to generate packets which will match the + transport protocol parameters. The ID field in the DNS header is + only a 16-bit field and the server UDP port associated with DNS is a + well-known value, so there are only 2**32 possible combinations of ID + and client UDP port for a given client and server. This is not a + particularly large range, and is not proof against a brute force + search; furthermore, in practice both the client UDP port and the ID + can often be predicted from previous traffic, and it is not uncommon + for the client port to be a known fixed value as well (due to + firewalls or other restrictions), thus frequently reducing the search + space to a range smaller than 2**16. By itself, ID guessing is not enough to allow an attacker to inject bogus data, but combined with knowledge (or guesses) about QNAMEs and @@ -220,15 +219,15 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 resolver only weakly defended against injection of bogus responses. Since this attack relies on predicting a resolver's behavior, it's - - - -Atkins & Austein Expires 29 December 2003 [Page 4] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - most likely to be successful when the victim is in a known state, + + + +Atkins & Austein Expires 30 April 2004 [Page 4] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + whether because the victim rebooted recently, or because the victim's behavior has been influenced by some other action by the attacker, or because the victim is responding (in a predictable way) to some third @@ -276,16 +275,15 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 - Attacker injects response, whether via packet interception, query guessing, or by being a legitimate name server that's involved at some point in the process of answering the query that the victim - - - -Atkins & Austein Expires 29 December 2003 [Page 5] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - issued. + + +Atkins & Austein Expires 30 April 2004 [Page 5] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + - Attacker's response includes one or more RRs with DNS names in their RDATA; depending on which particular form this attack takes, the object may be to inject false data associated with those names @@ -307,8 +305,10 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 This class of attack is particularly insidious given that it's quite easy for an attacker to provoke a victim into querying for a particular name of the attacker's choosing, for example, by embedding - a link to a 1x1-pixel "web bug" in a piece of Text/HTML mail to the - victim. + a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail + to the victim. If the victim's mail reading program attempts to + follow such a link, the result will be a DNS query for a name chosen + by the attacker. DNSSEC should provide a good defense against most (all?) variations on this class of attack. By checking signatures, a resolver can @@ -335,9 +335,9 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 -Atkins & Austein Expires 29 December 2003 [Page 6] +Atkins & Austein Expires 30 April 2004 [Page 6] -draft-ietf-dnsext-dns-threats-03.txt June 2003 +draft-ietf-dnsext-dns-threats-04.txt October 2003 resolvers, and use trusted servers to perform all of their DNS @@ -356,17 +356,31 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 matter what brand of middle boxes a particular hotel chain might have installed when adding network drops in every guest room...). - From the protocol standpoint, the only difference between this sort - of betrayal and a packet interception attack is that in this case the - client has voluntarily sent its request to the attacker. The defense - against this is the same as with a packet interception attack: the - resolver must either check DNSSEC signatures itself or use TSIG (or - equivalent) to authenticate the server that it has chosen to trust. - Note that use of TSIG does not by itself guarantee that a name server - is at all trustworthy: all TSIG can do is help a resolver protect its - communication with a name server that it has already decided to trust - for other reasons. Protecting a resolver's communication with a - server that's giving out bogus answers is not particularly useful. + While the obvious solution to this problem would be for the client to + chose a more trustworthy server, in practice this may not be an + option for the client. In many network environments a client machine + has only a limited set of recursive name server from which to chose, + and none of them may be particularly trustworthy. In extreme cases, + port filtering or other forms of packet interception may prevent the + client host from being able to run an iterative resolver even if the + owner of the client machine is willing and able to do so. Thus, + while the initial source of this problem is not a DNS protocol attack + per se, this sort of betrayal is a threat to DNS clients, and simply + switching to a different recursive name server is not an adequate + defense. + + Viewed strictly from the DNS protocol standpoint, the only difference + between this sort of betrayal and a packet interception attack is + that in this case the client has voluntarily sent its request to the + attacker. The defense against this is the same as with a packet + interception attack: the resolver must either check DNSSEC signatures + itself or use TSIG (or equivalent) to authenticate the server that it + has chosen to trust. Note that use of TSIG does not by itself + guarantee that a name server is at all trustworthy: all TSIG can do + is help a resolver protect its communication with a name server that + it has already decided to trust for other reasons. Protecting a + resolver's communication with a server that's giving out bogus + answers is not particularly useful. Also note that if the stub resolver does not trust the name server that is doing work on its behalf and wants to check the DNSSEC @@ -375,6 +389,13 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 (usually the public key for the root zone, but in some cases knowledge of additional keys may also be appropriate). + + +Atkins & Austein Expires 30 April 2004 [Page 7] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + It is difficult to escape the conclusion that a properly paranoid resolver must always perform its own signature checking, and that this rule even applies to stub resolvers. @@ -389,13 +410,6 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 some cases can also increase the number of messages needed to answer a query. TSIG (and similar mechanisms) have equivalent problems. - - -Atkins & Austein Expires 29 December 2003 [Page 7] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - DNS servers are also at risk of being used as denial of service amplifiers, since DNS response packets tend to be significantly longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help @@ -430,6 +444,14 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 Much discussion has taken place over whether and how to provide data integrity and data origin authentication for "wildcard" DNS names. Conceptually, RRs with wildcard names are patterns for synthesizing + + + +Atkins & Austein Expires 30 April 2004 [Page 8] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + RRs on the fly according to the matching rules described in section 4.3.2 of RFC 1034. While the rules that control the behavior of wildcard names have a few quirks that can make them a trap for the @@ -444,14 +466,6 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 - We need to prove the non-existance of any RRs which, if they existed, would make the wildcard RR irrelevant according to the - - - -Atkins & Austein Expires 29 December 2003 [Page 8] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - synthesis rules the way in which wildcards are used (that is, we need to prove that the synthesis rule is applicable). @@ -486,6 +500,14 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 delays that DNSSEC will impose into account, but that's a separate topic for another document....) + + + +Atkins & Austein Expires 30 April 2004 [Page 9] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + - Like DNS itself, DNSSEC's trust model is almost totally hierarchical. While DNSSEC does allow resolvers to have special additional knowledge of public keys beyond those for the root, in @@ -500,14 +522,6 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 come close to adequately specifying how the root key rolls over, or even how it's configured in the first place. - - - -Atkins & Austein Expires 29 December 2003 [Page 9] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - - DNSSEC creates a requirement of loose time synchronization between the resolver and the host creating the DNSSEC signatures. Prior to DNSSEC, all time-related actions in DNS could be performed by a @@ -541,6 +555,15 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 This section lists a few subjects not covered above which probably need additional study, additional mechanisms, or both. + + + + +Atkins & Austein Expires 30 April 2004 [Page 10] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + 4.1. Interactions With Other Protocols The above discussion has concentrated exclusively on attacks within @@ -556,14 +579,6 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 authenticate the updating client to the server. While TSIG does not scale very well (it requires manual configuration of shared keys between the DNS name server and each TSIG client), it works well in a - - - -Atkins & Austein Expires 29 December 2003 [Page 10] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - limited or closed environment such as a DHCP server updating a local DNS name server. @@ -597,6 +612,14 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 access. For example, Alice may need to be able to add new nodes to the zone or change existing nodes, but not remove them; Bob may need to be able to remove zones but not add them; Carol may need to be + + + +Atkins & Austein Expires 30 April 2004 [Page 11] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + able to add, remove, or modify nodes, but only A records. Scaling properties of the key management problem here are a @@ -612,14 +635,6 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 DNSSEC does not provide object security, because zones include unsigned NS RRs and glue at delegation points. Use of TSIG to protect zone transfer (AXFR or IXFR) operations provides "channel - - - -Atkins & Austein Expires 29 December 2003 [Page 11] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - security", but still does not provide object security for complete zones, so the trust relationships involved in zone transfer are still very much a hop-by-hop matter of name server operators trusting other @@ -650,6 +665,17 @@ IANA Considerations None. + + + + + + +Atkins & Austein Expires 30 April 2004 [Page 12] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + Acknowledgments This note is based both previous published works by others and on a @@ -669,13 +695,6 @@ Normative References [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987. - - -Atkins & Austein Expires 29 December 2003 [Page 12] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - [HOST-REQUIREMENTS] Braden, R., Editor, "Requirements for Internet Hosts - Application and Support", RFC 1123, October 1989. @@ -685,9 +704,6 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 [NCACHE] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" RFC 2308, March 1998. - [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. @@ -701,14 +717,23 @@ draft-ietf-dnsext-dns-threats-03.txt June 2003 [SECURE-UPDATE] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update" RFC 3007, November 2000. - [SIGNING-AUTHORITY] Wellington, B., "Domain Name System Security - (DNSSEC) Signing Authority" RFC 3008, November 2000. - - [DNSSEC-ZONE-STATUS] Lewis, E., "DNS Security Extension Clarification - on Zone Status" RFC 3090, March 2001. + [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. Informative References + [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture + Board, "Guidelines for Writing RFC Text on Security + + + +Atkins & Austein Expires 30 April 2004 [Page 13] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + + Considerations", RFC 3552, July 2003. + [Bellovin95] Bellovin, S., "Using the Domain Name System for System Break-Ins", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. @@ -723,20 +748,6 @@ Informative References [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. - - - - -Atkins & Austein Expires 29 December 2003 [Page 13] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - - [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture - Board, "Guidelines for Writing RFC Text on Security - Considerations", work in progress (draft-iab-sec-cons-03.txt), - January 2003. - Author's addresses: Derek Atkins @@ -752,6 +763,36 @@ Author's addresses: Email: sra@hactrn.net +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + + + +Atkins & Austein Expires 30 April 2004 [Page 14] + +draft-ietf-dnsext-dns-threats-04.txt October 2003 + + + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. @@ -780,14 +821,6 @@ Full Copyright Statement HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Atkins & Austein Expires 29 December 2003 [Page 14] - -draft-ietf-dnsext-dns-threats-03.txt June 2003 - - Acknowledgement Funding for the RFC Editor function is currently provided by the @@ -806,37 +839,4 @@ Acknowledgement - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Atkins & Austein Expires 29 December 2003 [Page 15] +Atkins & Austein Expires 30 April 2004 [Page 15] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt deleted file mode 100644 index 7eee7845d3..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt +++ /dev/null @@ -1,1288 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 15, 2003 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - February 14, 2003 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-05 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 15, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -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 - - - -Arends, et al. Expires August 15, 2003 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - - services that the DNS security extensions do and do not provide. - Last, this document describes the interrelationships between the - group of documents that collectively describe DNSSEC. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 6 - 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 6 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 7 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 9 - 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 10 - 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 11 - 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 7.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 12 - 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 12 - 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 13 - 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 14 - 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 14 - 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 14 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 - Normative References . . . . . . . . . . . . . . . . . . . . . 20 - Informative References . . . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 2] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and its two companion documents ([13] and - [14]) update, clarify, and refine the security extensions originally - defined in RFC 2535 [3]. These security extensions consist of a set - of new resource record types and modifications to the existing DNS - protocol [2]. The new records and protocol modifications are not - fully described in this document, but are described in a family of - documents outlined in Section 9. Section 3 and Section 4 describe - the capabilities and limitations of the security extensions in - greater detail. Section 5, Section 6, Section 7, and Section 8 - discuss the effect that these security extensions will have on - resolvers, stub resolvers, zones and name servers. - - This document and its two companions update and obsolete RFCs 2535, - 3008, 3090, 3225, 3226, and 3445, as well as several works in - progress: "Redefinition of the AD bit", "Delegation Signer Resource - Record", and "DNSSEC Opt-In". See [18] for more details on these - documents. - - 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 protection against - other types of attack, nor do they provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 3] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -2. Definitions of Important DNSSEC Terms - - authentication chain: In the DNSSEC model, a KEY RR signs a DS RR, - which hashes one RR in another KEY RRset, which in turn signs - another DS RR, which hashes one RR in yet another KEY RRset, and - so forth, finally ending, if all goes well, with a KEY RR which - signs whatever DNS data the end user was looking for in the first - place. This alternating succession of KEY RRsets and DS RRs forms - a chain of signed data, with each link in the chain vouching for - the next. If a signature somewhere in this chain has been - generated by an authentication key known to a security-aware - resolver, then the resolver can attempt to verify and authenticate - the signed chain of KEY and DS RRs from that point down to the - target data. - - authentication key: A public key which a security-aware resolver - trusts and can therefore use to verify data. A security-aware - resolver can discover trusted authentication keys in three ways. - First, the resolver is generally preconfigured to know about at - least one key which it should trust. Second, the resolver may be - able to discover both a new key and an associated DS RR which - contains a valid hash of the new key and which has been signed by - a key which the resolver trusts. Third, the resolver may be able - to determine that a new key has been signed by another key which - the resolver trusts. Note that the resolver must always be guided - by local policy when deciding whether to trust a new key, even if - the local policy is simply to trust any new key for which the - resolver is able verify the signature. - - key signing key: An authentication key which is used to sign one or - more other authentication keys. Typically, a key signing key will - sign a zone signing key, which in turn will sign other zone data. - Local policy may require the zone signing key to 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 itself does not distinguish - between key signing keys and other DNSSEC authentication keys. - Key signing keys are discussed in more detail in [12]. - - security-aware name server: An entity acting in the role of a name - server (defined in section 2.4 of [1]) which understands the DNS - security extensions defined in this document set. In particular, - a security-aware name server is an entity which receives DNS - queries, sends DNS responses, supports the EDNS0 [4] message size - extension and the DO bit [8], and supports the RR types and - message header bits defined in this document set. - - - - -Arends, et al. Expires August 15, 2003 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - - security-aware recursive name server: An entity which acts in both - the security-aware name server and security-aware resolver roles. - A more cumbersome equivalent phrase would be "a security-aware - name server which offers recursive service". - - security-aware resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [1]) which understands the DNS security - extensions defined in this document set. In particular, a - security-aware resolver is an entity which sends DNS queries, - receives DNS responses, supports the EDNS0 [4] message size - extension and the DO bit [8], 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 - resolver (defined in section 2.4 of [1]) which has at least a - minimal understanding the DNS security extensions defined in this - document set, but which 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 security-aware - stub resolver is an entity which sends DNS queries, receives DNS - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will - provide these services on behalf of the security-aware stub - resolver. Note that the distinction between security-aware - resolvers and security-aware stub resolvers is different from the - distinction between iterative-mode and recursive-mode resolvers in - the base DNS specification: a particular security-aware resolver - may operate exclusively in recursive mode, but still performs its - own DNSSEC signature validity checks, while a security-aware stub - resolver does not, by definition. - - security-oblivious: The opposite of "security-aware". - - signed zone: A zone whose RRsets are signed and which contains - properly constructed KEY, SIG, NXT and (optionally) DS records. - - unsigned zone: The opposite of a "signed zone". - - zone signing key: An authentication key which is used to sign a zone. - See key signing key, above. Typically a zone signing key will be - part of the same KEY RRset as the key signing key which signs it, - but is used for a slightly different purpose and may differ from - the key signing key in other ways, such as validity lifetime. - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 5] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -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 minor changes to the DNS protocol. DNSSEC - adds four new resource record types (SIG, KEY, DS and NXT) and two - new message header bits (CD and AD). In order to support the larger - DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also - requires EDNS0 support [4]. Finally, DNSSEC requires support for the - DO bit [8], 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 [11]. - -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 SIG 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 [7], but DNSSEC itself is concerned with - object security of DNS data, not channel security of DNS - transactions). - - A security-aware resolver can learn a zone's public key either by - having the key preconfigured into the resolver or by normal DNS - resolution. To allow the latter, public keys are stored in a new - type of resource record, the KEY RR. Note that the private keys used - to sign zone data must be kept secure, and should be stored offline - when practical to do so. To discover a public key reliably via DNS - resolution, the target key itself needs to be signed by either a - preconfigured authentication key or another key that has been - 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 must have been preconfigured into the resolver - or must have been learned and verified previously. Therefore, the - - - -Arends, et al. Expires August 15, 2003 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - - resolver must be configured with at least one public key: if the - preconfigured key is a zone signing key, then it will authenticate - the associated zone; if the preconfigured key is a key signing key, - it will authenticate a zone signing key. 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 in the DNS reply message along with the public key - itself, provided there is space available in the message. - - The authentication chain specified in the original DNS security - extensions proceeded from signed KEY record to signed KEY record, as - necessary, and finally to the queried RRset. The current - specification adds a new Delegation Signer (DS) RR type to simplify - 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 key or keys used - by the delegated child zone to self-sign the KEY RRset at the child - zone's apex. The child zone, in turn, uses one or more of the keys - in this KEY RRset to sign its zone data. The authentication chain is - therefore KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS- - >KEY subchains. - - This authentication chain is normally constructed from the root of - the DNS hierarchy down to the leaf zones, and is normally based on - preconfigured knowledge of the public key for the root. Local - policy, however, may also allow a security-aware resolver to trust - one or more preconfigured keys other than the root key, or may not - provide preconfigured knowledge of the root key, or may even prevent - the resolver from trusting particular keys for arbitrary reasons even - if those 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, - but authentication and trust, in the final analysis, are matters of - local policy, which may extend or even override the protocol - extensions defined in this document set. - -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 NXT record. - The NXT record allows a security-aware resolver to authenticate a - negative reply for either name or type non-existence via the same - mechanisms used to authenticate other DNS replies. Use of NXT - records require a canonical representation and ordering for domain - names in zones. Chains of NXT records explicitly describe the gaps, - or "empty space", between domain names in a zone, as well as listing - - - -Arends, et al. Expires August 15, 2003 [Page 7] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - - the types of RRsets present at existing names. Each NXT record is - signed and authenticated using the mechanisms described in Section - 3.1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 8] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -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 11 for details. - - The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above extend no protection to - operations such as zone transfers and dynamic update [16]. Message - authentication schemes described in [5] and [7] address security - operations that pertain to these transactions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 9] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -5. Resolver Considerations - - A security-aware resolver needs to be able to perform necessary - cryptographic functions to verify digital signatures using at least - the mandatory-to-implement algorithms. Security-aware resolvers must - also be capable of forming a authentication chain from a newly - learned zone back to a authentication key, as described above. This - process might require additional queries to intermediate DNS zones to - obtain necessary KEY, DS and SIG records. A security-aware resolver - should be configured with at least one authentication key 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 device which acts as a proxy for DNS, and if the recursive name - server or proxy is not security-aware, the security-aware resolver - may not be able to operate in a secure mode. For example, if a - security-aware resolver's packets are routed through a network - address translation device that includes a DNS proxy which is not - security-aware the security-aware resolver may find it difficult or - impossible to obtain or validate signed DNS data. - - 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, but should also allow for the possibility that the - security-aware resolver's own clock is wrong. Thus, a security-aware - resolver which is part of a security-aware recursive name server will - need to pay careful attention to the DNSSEC "checking disabled" (CD) - bit [13] in order to avoid blocking valid signatures from getting - through to other security-aware resolvers which are clients of this - recursive name server and which are capable of performing their own - DNSSEC validity checks. - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 10] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -6. 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 which 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 - 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 full security-aware resolver. - - Even an unaugmented stub resolver may get some 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 stub - resolver has no real choice but to place itself at the mercy of the - recursive name servers that it uses, since 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) or TSIG would suffice, as - would appropriate use of IPsec, and 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. - - {{AD bit currently ratholed, update this when its fate is settled}} - - There is one more step which 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 which it uses: it can - perform its own signature validation, by setting the Checking - Disabled (CD) bit in its query messages. Upon taking this step, the - resolver is no longer really a stub resolver at all anymore (in the - terminology used in this document set, anyway), and is now a - security-aware resolver with somewhat limited functionality. - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 11] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -7. Zone Considerations - - There are several differences between signed and unsigned zones. A - signed zone will contain additional security-related records (SIG, - KEY, DS and NXT records). SIG and NXT records may be generated by a - signing process prior to serving the zone. The SIG records that - accompany zone data have defined inception and expiration times, - which establish a validity period for the signatures and the zone - data the signatures cover. - -7.1 TTL values vs. SIG validity period - - It is important to note the distinction between an RRset's TTL value - and the signature validity period specified by the SIG 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 or not the resolver is security-aware. - - The inception and expiration fields in the SIG RR [13], on the other - hand, specify the time period during which the signature can be used - to validate the RRset that it covers. The signatures associated with - signed zone data are only valid for the time period specified by - these fields in the SIG 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 SIG RR in the resolver's - cache. - -7.2 New Temporal Dependency Issues for Zones - - Information in a signed zone has a temporal dependency which 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 - SIG RR. The signature validity period of a SIG RR is a 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 SIG RRs, which in turn will 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 transfers operations. - - - - - - -Arends, et al. Expires August 15, 2003 [Page 12] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -8. Name Server Considerations - - A security-aware name server should include the appropriate DNSSEC - records (SIG, KEY, DS and NXT) in all responses to queries from - resolvers which have signaled their willingness to receive such - records via use of the DO bit in the EDNS header, subject to message - size limitations. For this reason a security-aware name server must - support the EDNS mechanism size extension, since otherwise inclusion - of DNSSEC RRs could easily cause UDP message truncation and fallback - to TCP. - - 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 - updated, so the private half of the zone signing key will have to be - kept online. This is an example of a situation where the ability to - separate the zone's KEY RRset into zone signing key(s) and key - signing key(s) may be useful, since the key singing key(s) in such a - case can still be kept offline. - - DNSSEC, by itself, is not enough to protect the integrity of an - entire zone during zone transfer operations, since even a signed zone - contains some unsigned data, so zone maintenance operations will - require some additional mechanisms (most likely some form of channel - security, such as TSIG, SIG(0), or IPsec). - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 13] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -9. DNS Security Document Family - - The DNSSEC set of documents can be partitioned into five main groups - as depicted in Figure 1. All these documents are in turn under the - larger umbrella of the DNS base protocol documents described in [18]. - -9.1 DNS Security Document Roadmap - - --------------------------------------------------------------------- - - - +----------------------------------+ - | Base DNS Protocol Documents | - | [RFC1035, RFC2181, et sequentia] | - +----------------------------------+ - | - | - +-----------+ +----------+ - | DNSSEC | | New | - | Protocol |--------->| Security | - | Documents | | Uses | - +-----------+ +----------+ - | - | - +---------------- - - - - - - -+ - | . - | . - +------------------+ . - | Digital | +------------------+ - | Signature | | Transaction | - | Algorithm | | Authentication | - | Implementations | | Implementations | - +------------------+ +------------------+ - - Figure 1: DNSSEC Document Roadmap - - --------------------------------------------------------------------- - - -9.2 Categories of DNS Security Documents - - The "DNSSEC protocol document set" refers to the three documents - which form the core of the DNS security extensions: - - 1. DNS Security Introduction and Requirements (this document) - - 2. Resource Records for DNS Security Extensions [13] - - - - -Arends, et al. Expires August 15, 2003 [Page 14] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - - 3. Protocol Modifications for the DNS Security Extensions [14] - - The "Digital Signature Algorithm Implementations" 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 of these documents deals with a specific digital - signature algorithm. - - The "Transaction Authentication Implementations" document set refers - to the group of documents that deal with DNS message authentication, - including secret key establishment and verification. While not - strictly part of the DNSSEC specification as defined in this set of - documents, this group is noted to show 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 the use of DNS in the storage and - distribution of certificates [15] and individual user public keys - (PGP, e-mail, and so forth) [17]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -10. IANA Considerations - - This document introduces no new IANA considerations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 16] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -11. Security Considerations - - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. This document discusses the capabilities and - limitations of these extensions. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets. - - In order for a security-aware resolver to validate a DNS response, - all of the intermediate zones must be signed, and all of the - intermediate name servers 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 which the resolver is - only able to obtain through a recursive name server which 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, but transaction security is not - part of DNSSEC per se. - - A 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 - which perform these checks on its behalf and also to attacks on its - communication with those security-aware recursive name servers. - 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 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, since 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 SIG 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 which supports DNS - - - -Arends, et al. Expires August 15, 2003 [Page 17] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - - 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. - - DNSSEC add the ability for a hostile party to enumerate all the names - in a zone by following the NXT chain. NXT 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 NXT RRs in sequence to obtain all the names - in a zone. While not an attack on the DNS itself, this could allow - an attacker to map network hosts or other resources by enumerating - the contents of a zone. - - DNSSEC does not provide confidentiality, due to a deliberate design - choice. - - 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. Thus, while DNSSEC can provide data origin - authentication and data integrity for RRsets, it cannot do so for - zones, and other mechanisms must be used to protect zone transfer - operations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 18] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -12. Acknowledgements - - This document was created from the input and ideas of several members - of the DNS Extensions Working Group. The authors would like to - acknowledge (in alphabetical order) the following people for their - contributions and comments on this document: - - Derek Atkins - Donald Eastlake - Miek Gieben - Olafur Gudmundsson - Olaf Kolkman - Ed Lewis - Ted Lindgreen - Bill Manning - Brian Wellington - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 19] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -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] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [4] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [5] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [6] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC - 2930, September 2000. - - [7] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, - December 2001. - - [9] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name - System", draft-ietf-dnsext-dns-threats-02 (work in progress), - February 2002. - - [12] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK) - Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in - progress), December 2002. - - [13] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource - Records for DNS Security Extensions", draft-ietf-dnsext-dnssec- - records-02 (work in progress), November 2002. - - [14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol - Modifications for the DNS Security Extensions", draft-ietf- - dnsext-dnssec-protocol-00 (work in progress), October 2002. - - - -Arends, et al. Expires August 15, 2003 [Page 20] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -Informative References - - [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", RFC 2538, March 1999. - - [16] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [17] Schlyter, J., "Storing application public keys in the DNS", - draft-schlyter-appkey-02 (work in progress), February 2002. - - [18] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext- - dnssec-roadmap-06 (work in progress), November 2001. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Software Consortium - 40 Gavin Circle - Reading, MA 01867 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 21] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.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. Expires August 15, 2003 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements February 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 15, 2003 [Page 23] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt new file mode 100644 index 0000000000..47dcc8fddf --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt @@ -0,0 +1,1400 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: April 26, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + October 27, 2003 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-07 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 26, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Domain Name System Security Extensions (DNSSEC) adds 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. + + + +Arends, et al. Expires April 26, 2004 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 + 3. Services Provided by DNS Security . . . . . . . . . . . . . . 7 + 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 7 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 8 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 10 + 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 12 + 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 7.1 TTL values vs. RRSIG validity period . . . . . . . . . . . . . 13 + 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13 + 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 + 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15 + 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 15 + 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 15 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + Normative References . . . . . . . . . . . . . . . . . . . . . 21 + Informative References . . . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . 24 + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents + ([I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the + security extensions defined in RFC 2535 [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 9. Section 3 and Section 4 describe the + capabilities and limitations of the security extensions in greater + detail. Section 5, Section 6, Section 7, and Section 8 discuss the + effect that these security extensions will have on resolvers, stub + resolvers, zones and name servers. + + This document and its two companions update and obsolete RFCs 2535 + [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445 + [RFC3445], as well as several works in progress: "Redefinition of the + AD bit" [I-D.ietf-dnsext-ad-is-secure], "Legacy Resolver + Compatibility for Delegation Signer" + [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation Signer + Resource Record" [I-D.ietf-dnsext-delegation-signer]. + + 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. + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +2. Definitions of Important DNSSEC Terms + + authentication chain: an alternating succession of DNSKEY RRsets and + DS RRs forms a chain of signed data, with each link in the chain + vouching for the next. A DNSKEY RR is used to check 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 which + signs the desired DNS data. For example, the root DNSKEY can be + used to authenticated the DS RR for "example." The "example." DS + RR contains a hash that matches some "example." DNSKEY and this + DNSKEY signs the "example." DNSKEY RRset. Keys in the "example." + DNSKEY RRset sign data records such as "www.example." as well as + DS RRs for delegations such as "subzone.example." + + authentication key: A public key which 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 preconfigured to know + about at least one public key. This preconfigured data is either + the public key itself, or a hash of the key as found in the DS RR. + Second, the resolver may use an authenticated public key to verify + a DS RR and its associated DNSKEY RR. Third, the resolver may be + able to determine that a new key has been signed by another key + which the resolver has verified. Note that the resolver must + always be guided by local policy when deciding whether to + authenticate a new key, even if the local policy is simply to + authenticate any new key for which the resolver is able verify the + signature. + + 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 with the island's key in its + delegating parent zone (see [I-D.ietf-dnsext-dnssec-records]). An + island of security is served by a security-aware nameserver and + may provide authentication chains to any delegated child zones. + Responses from an island of security or its descendents can only + be validated if its zone key can be obtained by some trusted means + out of band from the DNS protocol. + + key signing key: An authentication key which is used to sign one or + more other authentication keys. Typically, a key signing key will + sign a zone signing key, which in turn will sign other zone data. + Local policy may require the zone signing key to be changed + frequently, while the key signing key may have a longer validity + + + +Arends, et al. Expires April 26, 2004 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + 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. Key signing keys are discussed in more + detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. + + security-aware name server: An entity acting in the role of a name + server (defined in section 2.4 of [RFC1034]) which understands the + DNS security extensions defined in this document set. In + particular, a security-aware name server is an entity which + 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 which acts in both + the security-aware name server and security-aware resolver roles. + A more cumbersome equivalent phrase would be "a security-aware + name server which offers recursive service". + + security-aware resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity which 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 + resolver (defined in section 2.4 of [RFC1034]) which has at least + a minimal understanding the DNS security extensions defined in + this document set, but which 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 security-aware + stub resolver is an entity which sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. Note that the distinction between security-aware + resolvers and security-aware stub resolvers is different from the + distinction between iterative-mode and recursive-mode resolvers in + the base DNS specification: a particular security-aware resolver + may operate exclusively in recursive mode, but still perform its + own DNSSEC signature validity checks, while a security-aware stub + resolver does not, by definition. + + + + +Arends, et al. Expires April 26, 2004 [Page 5] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + security-oblivious (server or resolver): The opposite of + "security-aware". + + signed zone: A zone whose RRsets are signed and which contains + properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS + records. + + unsigned zone: The opposite of a "signed zone". + + zone signing key: An authentication key which is used to sign a zone. + See key signing key, above. Typically a zone signing key will be + part of the same DNSKEY RRset as the key signing key which signs + it, but is used for a slightly different purpose and may differ + from the key signing key in other ways, such as validity lifetime. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +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 (RRSIG, DNSKEY, DS and NSEC) and two + new message header bits (CD and 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 DO 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 [I-D.ietf-dnsext-dns-threats]. + +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). + + A security-aware resolver can learn a zone's public key either by + having the key preconfigured 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 do so. To discover a public key reliably + via DNS resolution, the target key itself needs to be signed by + either a preconfigured authentication key or another key that has + been 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 must have been preconfigured into the + + + +Arends, et al. Expires April 26, 2004 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + resolver or must have been learned and verified previously. + Therefore, the resolver must be configured with at least one public + key or hash of a public key: if the preconfigured key is a zone + signing key, then it will authenticate the associated zone; if the + preconfigured key is a key signing key, it will authenticate a zone + signing key. If the resolver has been preconfigured with the hash of + a key rather than the key itself, the resolver may need 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 in the DNS + reply message along with the public key itself, provided 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 key or keys used by the + delegated child zone to self-sign the DNSKEY RRset at the child + zone's apex. The child zone, in turn, uses one or more of the keys + in this DNSKEY RRset to sign its zone data. The authentication chain + is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or + more DS->DNSKEY subchains. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + on preconfigured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more preconfigured keys (or key hashes) other than the root key, + or may not provide preconfigured knowledge of the root key, or may + prevent the resolver from using particular keys for arbitrary reasons + even if those 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. + +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 + via the same mechanisms used to authenticate other DNS replies. Use + of NSEC records require a canonical representation and ordering for + domain names in zones. Chains of NSEC records explicitly describe + + + +Arends, et al. Expires April 26, 2004 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + the gaps, or "empty space", between domain names in a zone, as well + as listing the types of RRsets present at existing names. Each NSEC + record is signed and authenticated using the mechanisms described in + Section 3.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +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 11 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above extend no protection to + operations such as zone transfers and dynamic update [RFC3007]. + Message authentication schemes described in [RFC2845] and [RFC2931] + address security operations that pertain to these transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +5. Resolver Considerations + + A security-aware resolver needs to be able to perform cryptographic + functions necessary to verify digital signatures using at least the + mandatory-to-implement algorithms. 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 + obtain necessary DNSKEY, DS and RRSIG records. A security-aware + resolver should be configured with at least one authentication key or + a key's DS RR hash 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 device which acts as a proxy for DNS, and if the recursive name + server or proxy is not security-aware, the security-aware resolver + may not be able to operate in a secure mode. For example, if a + security-aware resolver's packets are routed through a network + address translation device that includes a DNS proxy which is not + security-aware, the security-aware resolver may find it difficult or + impossible to obtain or validate signed DNS data. + + 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, but should also allow for the possibility that the + security-aware resolver's own clock is wrong. Thus, a security-aware + resolver which is part of a security-aware recursive name server will + need to pay careful attention to the DNSSEC "checking disabled" (CD) + bit [I-D.ietf-dnsext-dnssec-records] in order to avoid blocking valid + signatures from getting through to other security-aware resolvers + which are clients of this recursive name server and which are capable + of performing their own DNSSEC validity checks. See + [I-D.ietf-dnsext-dnssec-protocol] for how a secure recursive server + handles queries with the CD bit set. + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +6. 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 which 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 + 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 full security-aware resolver. + + Even an unaugmented stub resolver may get some 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 stub + resolver has no real choice but to place itself at the mercy of the + recursive name servers that it uses, since 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) or TSIG would suffice, as + would appropriate use of IPsec, and 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 which does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the 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 which 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 which it uses: it can + perform its own signature validation, by setting the Checking + Disabled (CD) bit in its query messages. Upon taking this step, the + resolver is no longer really a stub resolver at all anymore (in the + terminology used in this document set, anyway), and is now a + security-aware resolver with somewhat limited functionality. + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +7. 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, which establish a validity period for the + signatures and the zone data the signatures cover. + +7.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 or not the resolver is security-aware. + + The inception and expiration fields in the RRSIG RR + [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time + period during which the signature can be used to validate the RRset + that it covers. 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. + +7.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which 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 in turn will 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 transfers operations. + + + + + + +Arends, et al. Expires April 26, 2004 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +8. 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 which have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. For this reason a security-aware name server must + support the EDNS mechanism size extension, since otherwise inclusion + of DNSSEC RRs could easily cause UDP message truncation and fallback + to TCP. + + 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 + updated, so the private half of the zone signing key will have to be + kept online. This is an example of a situation where the ability to + separate the zone's DNSKEY RRset into zone signing key(s) and key + signing key(s) may be useful, since the key singing key(s) in such a + case can still be kept offline. + + DNSSEC, by itself, is not enough to protect the integrity of an + entire zone during zone transfer operations, since even a signed zone + contains some unsigned data if the zone has any children, so zone + maintenance operations will require some additional mechanisms (most + likely some form of channel security, such as TSIG, SIG(0), or + IPsec). + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +9. DNS Security Document Family + + The DNSSEC set of documents can be partitioned into five main groups + as depicted in Figure 1. All of these documents are in turn under + the larger umbrella of the DNS base protocol documents. + +9.1 DNS Security Document Roadmap + + +----------------------------------+ + | Base DNS Protocol Documents | + | [RFC1035, RFC2181, et sequentia] | + +----------------------------------+ + | + | + +-----------+ +----------+ + | DNSSEC | | New | + | Protocol |--------->| Security | + | Documents | | Uses | + +-----------+ +----------+ + | + | + +---------------- - - - - - - -+ + | . + | . + +------------------+ . + | Digital | +------------------+ + | Signature | | Transaction | + | Algorithm | | Authentication | + | Implementations | | Implementations | + +------------------+ +------------------+ + + +9.2 Categories of DNS Security Documents + + The "DNSSEC protocol document set" refers to the three documents + which form the core of the DNS security extensions: + + 1. DNS Security Introduction and Requirements (this document) + + 2. Resource Records for DNS Security Extensions + [I-D.ietf-dnsext-dnssec-records] + + 3. Protocol Modifications for the DNS Security Extensions + [I-D.ietf-dnsext-dnssec-protocol] + + The "Digital Signature Algorithm Implementations" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + + + +Arends, et al. Expires April 26, 2004 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + record format. Each of these documents deals with a specific digital + signature algorithm. + + The "Transaction Authentication Implementations" document set refers + to the group of documents that deal with DNS message authentication, + including secret key establishment and verification. While not + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted to show 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 the use of DNS in the storage and + distribution of certificates [RFC2538]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +10. IANA Considerations + + This overview document introduces no new IANA considerations. Please + see [I-D.ietf-dnsext-dnssec-records] for a complete review of the + IANA considerations introduced by DNSSEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +11. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. This document discusses the capabilities and + limitations of these extensions. The extensions provide data origin + authentication and data integrity using digital signatures over + resource record sets. + + In order for a security-aware resolver to validate a DNS response, + all of the intermediate zones must be signed, and all of the + intermediate name servers 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 which the resolver is + only able to obtain through a recursive name server which 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, but transaction security is not + part of DNSSEC per se. + + A 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 + which perform these checks on its behalf and also to attacks on its + communication with those security-aware recursive name servers. + 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 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, since 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 which supports DNS + + + +Arends, et al. Expires April 26, 2004 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + 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. + + 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. While not an attack on the DNS + itself, this could allow an attacker to map network hosts or other + resources by enumerating the contents of a zone. There are non-DNS + protocol means of limiting this attack such as limiting the number of + NSEC queries from a single host, use of intrusion detection tools, + etc. + + DNSSEC does not provide confidentiality, due to a deliberate design + choice. + + 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. Thus, while DNSSEC can provide data origin + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms must be used to protect zone transfer + operations. + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +12. Acknowledgements + + This document was created from the input and ideas of several members + of the DNS Extensions Working Group. The editors would like to + acknowledge (in alphabetical order) the following people for their + contributions and comments on this document: Derek Atkins, Donald + Eastlake, Miek Gieben, Olafur Gudmundsson, Olaf Kolkman, Ed Lewis, + Ted Lindgreen, Bill Manning, and Brian Wellington. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +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, 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. + + [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. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-05 (work in progress), + October 2003. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in + progress), October 2003. + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +Informative References + + [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in + the Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2931] Eastlake, 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. + + [I-D.ietf-dnsext-dns-threats] + Atkins, D. and R. Austein, "Threat Analysis Of The Domain + Name System", draft-ietf-dnsext-dns-threats-04 (work in + progress), October 2003. + + [I-D.ietf-dnsext-ad-is-secure] + Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD + bit", draft-ietf-dnsext-ad-is-secure-06 (work in + progress), June 2002. + + [I-D.ietf-dnsext-delegation-signer] + Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15 (work in progress), + June 2003. + + [I-D.ietf-dnsext-dnssec-2535typecode-change] + Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 + (work in progress), October 2003. + + [I-D.ietf-dnsext-keyrr-key-signing-flag] + Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", + draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in + progress), October 2003. + + + + + +Arends, et al. Expires April 26, 2004 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.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. Expires April 26, 2004 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires April 26, 2004 [Page 24] + +Internet-Draft DNSSEC Introduction and Requirements October 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 25] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-02.txt deleted file mode 100644 index ebd84258cf..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-02.txt +++ /dev/null @@ -1,2632 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: March 30, 2004 M. Larson - VeriSign - R. Austein - ISC - D. Massey - USC/ISI - S. Rose - NIST - September 30, 2003 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-02 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 30, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document is part of a family of documents which describes the - DNS Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of new resource records and protocol modifications which - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - - - -Arends, et al. Expires March 30, 2004 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - defines the concept of a signed zone, along with the requirements for - serving and resolving 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. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 - 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 9 - 3.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 10 - 3.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 10 - 3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not - Present . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches . . . 11 - 3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches . . . . . 11 - 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 12 - 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 12 - 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 13 - 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 14 - 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 15 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 21 - 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 22 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 24 - 5.1 Special Considerations for Islands of Security . . . . . . . 25 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 25 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 26 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 27 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 29 - 5.3.4 Authenticating A Wildcard Expanded RRset Positive - - - -Arends, et al. Expires March 30, 2004 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - Response . . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 30 - 5.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 5.5.1 Example of Re-Constructing the Original Owner Name . . . . . 31 - 5.5.2 Examples of Authenticating a Response . . . . . . . . . . . 32 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 34 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 - Normative References . . . . . . . . . . . . . . . . . . . . 36 - Informative References . . . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 - A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 39 - B. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 - Intellectual Property and Copyright Statements . . . . . . . 46 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which 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 to handle signed zones. Section 4 describes - the behavior of entities which include security-aware resolver - functions. Finally, Section 5 defines how to use DNSSEC RRs to - authenticate a response. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034] and RFC1035 [RFC1035]. - - This document is part of a family of documents which define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC - resource records can be found in [I-D.ietf-dnsext-dnssec-records]. - -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 RFC 2119. [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - - - - -Arends, et al. Expires March 30, 2004 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -2. Zone Signing - - DNSSEC is built around the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. Any zone which does not include these - records according to the rules in this section MUST be considered - unsigned for the purposes of the DNS security extensions. - - DNSSEC requires a change to the definition of the CNAME resource - record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs - to appear at the same owner name as a CNAME RR. - - Section 2.6 shows a sample signed zone. - -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, there SHOULD be a corresponding zone DNSKEY RR - stored in the zone. A zone key DNSKEY RR has the Zone Key bit of the - flags RDATA field set to one -- see Section 2.1.1 of - [I-D.ietf-dnsext-dnssec-records]. Public keys associated with other - DNS operations MAY be stored in DNSKEY RRs that are not marked as - zone keys. - - If the zone is delegated and does not wish to act as an island of - security, the zone MUST have at least one DNSKEY RR at the apex to - act as a secure entry point into the zone. This DNSKEY would then be - used to generate a DS RR at the delegating parent (see - [I-D.ietf-dnsext-dnssec-records]). This DNSKEY RR SHOULD be either a - zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro] - for definition). The DNSKEY RRset at the zone apex MUST be signed by - at least one zone signing or DNSKEY signing private key. - - DNSKEY RRs MUST NOT appear at delegation points. - -2.2 Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone (which excludes both NS - RRsets at delegation points and glue RRsets), there MUST be at least - one RRSIG record that meets all of 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; - - - - -Arends, et al. Expires March 30, 2004 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - 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 wildcard label if the owner name is a wildcard; - - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset; and - - 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 [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. - - An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR - would add no value and would create an infinite loop in the signing - process. - - The NS RRset which appears at the zone apex name MUST be signed, but - the NS RRsets which appear at delegation points (that is, the NS - RRsets in the parent zone which delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated with - delegations MUST NOT be signed. - - The difference between the set of owner names which require RRSIG - records and the set of owner names which 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 - 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 - only visible during the zone signing process, because NSEC RRsets are - authoritative data, and are therefore signed, thus any owner name - which has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - -2.3 Including NSEC RRs in a Zone - - Each owner name in the zone MUST have an NSEC resource record, except - for the owner names of any glue address RRsets. The process for - - - -Arends, et al. Expires March 30, 2004 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - constructing the NSEC RR for a given name is described in - [I-D.ietf-dnsext-dnssec-records]. - - 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. - -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 key used by the child zone to sign its apex DNSKEY - RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT - appear at non-delegation points nor at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR which is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. - - 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. 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 co-exist with a CNAME record, but a signed zone - 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 co-exist with NSEC and RRSIG - RRs. - -2.6 Example of a Secure Zone - - Appendix B shows a complete example of a small signed zone. - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -3. Serving - - This section describes the behavior of a security-aware authoritative - name server. A security-aware authoritative 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 [RFC3226]. Since functions specific to security-aware - recursive name servers included components of both resolving and - serving, issues specific to security-aware recursive name servers are - described in Section 4. - - Upon receiving a relevant query which has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set to one, 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 which can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1; - - o NSEC RRs which can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.3; - - o Either DS RRs or an NSEC RR proving that no DS RRs exist MUST be - included in referrals automatically according to the rules in - Section 3.4. - - DNSSEC does not change the DNS zone transfer protocol. Zone transfer - requirements are reviewed in Section 3.6. - - A security-aware name server which receives a DNS query which does - not include the EDNS OPT pseudo-RR or which has the DO bit set to - zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other - RRset, and MUST NOT perform any of the additional processing - described above. Since 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.5. - -3.1 Including RRSIG RRs in a Response - - When a query has the DO bit set to one, the authoritative name server - SHOULD attempt to send RRSIG RRs which can be used to authenticate - the RRsets in the 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 - - - -Arends, et al. Expires March 30, 2004 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - which may need 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 need 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 these RRSIG RRs, the name - server MUST NOT set the TC bit solely because these RRSIG RRs - didn't fit. - - -3.2 Including DNSKEY RRs In a Response - - When a query has the DO bit set to one and 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 DNSKEY RRset with the same name - in the Additional section. In this situation, the DNSKEY RR set and - associated RRSIG RRs have lower priority than any other information - that would be placed in the additional section. The name server - should include the DNSKEY RRset if and only if there is enough space - in the response for both the DNSKEY RRset and 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. - -3.3 Including NSEC RRs In a Response - - When a query has the DO bit set to one, security-aware authoritative - name servers for a signed zone MUST include NSEC RRs in each of the - following cases: - - Case 1: The QNAME has RRsets associated with it in the zone, but the - requested RR type does not exist. - - Case 2: The QNAME, QTYPE, QCLASS tuple does not exist, and no - wildcard can be expanded to answer the query. - - Case 3: The QNAME (or search name) does not exist, but a wildcard can - be expanded to positively answer the query. - - Note that, in each case, a set of NSEC RRs is included to provide - authenticated denial of existence. - - - - -Arends, et al. Expires March 30, 2004 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -3.3.1 Case 1: QNAME is Associated with RRsets, but RR Type Not Present - - If there are RR types associated with a given QNAME, but the - requested RR type is not present at the name, then the name server - MUST include the NSEC RR associated with the query name and any RRSIG - RRs associated with the NSEC RR in the Authority section (see Section - 3.1). If space does not permit inclusion of the NSEC RR or its - associated RRSIG RRs, the name server MUST set the TC bit. - - Note that, since the query name exists, no wildcard expansion applies - to this query, and a single NSEC RR suffices to prove the requested - RR type does not exist. - -3.3.2 Case 2: QNAME Does Not Exist, and No Wildcard Matches - - If the query name does not exist in the zone, and no wildcard - expansion matches both the query name and the query type, 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 was no exact match for the name; and - - o An NSEC RR combination proving that there was no wildcard which - would have matched the query. See [I-D.ietf-dnsext-wcard-clarify] - for further information on NSEC coverage. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1). - - Appendix A provides an algorithm which computes the appropriate NSEC - RRs to prove that no wildcard matches a given query name. - -3.3.3 Case 3: QNAME Does Not Exist, but Wildcard Matches - - If the query name does not exist, but a wildcard expansion can be - used to return a positive match to the query, the name server MUST - include the wildcard-expanded answer and the corresponding - wildcard-expanded RRSIG RRs in the Answer section. The Authority - section of the response MUST include the following NSEC RRs along - with their corresponding RRSIG RRs: - - o An NSEC RR which proves that there were no exact matches for the - QNAME and QTYPE; and - - o An NSEC RR combination which proves that there are no closer - wildcard entries which could have been expanded to match the - query. See [I-D.ietf-dnsext-wcard-clarify] for further - information on NSEC coverage. - - - -Arends, et al. Expires March 30, 2004 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1). - - Appendix A provides an algorithm which computes the appropriate NSEC - RRs to prove that no closer wildcard matches the query name. - -3.4 Including DS RRs In a Response - - When a query has the DO bit set to one, and a DS RR exists at the - query name, an authoritative security-aware name server returning a - referral for the delegation MUST include both the NS RRset and also - the DS RRset and its associated RRSIG RR(s). The name server MUST - place the NS RRset before the DS RRset and its associated RRSIG RRs. - - When a query has the DO bit set to one, and no DS RR exists at the - query name, an authoritative security-aware name server returning a - referral for the delegation MUST include both the NS RRset and also - the NSEC RR and associated RRSIG RR(s) which proves that the DS RRset - does not exist. The name server MUST place the NS RRset before the - NSEC RRset and its associated RRSIG RR(s). - - Including these DS 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. - - Security-aware name servers also include NSEC RRs in a referral - response when no DS RR is present; in this case, the NSEC RR proves - that no DS RR exists for the delegation. Section 3.4 discusses - referrals in more detail. - -3.5 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. In other words, the DS record for - the delegation of "example.com" is only stored in the "com" zone. - This introduces novel name server behavior, since the name server for - the child zone is authoritative for the name by the normal DNS rules - but the child zone does not contain the DS RR. An authoritative name - server's response to a DS query depends on whether the name server is - authoritative for the parent zone, the child zone, or both, as - described below. - - If a name server is authoritative for the parent zone, and receives a - query for the DS record at the delegated name, then the name server - MUST return the DS RRset from the parent zone. This rule applies - regardless of whether or not the name server is also authoritative - for the child zone. - - - -Arends, et al. Expires March 30, 2004 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - If the name server is authoritative for the child zone, is not - authoritative for the parent zone, and receives a query for the DS - record at the delegated name, there is no obvious response, because - the child zone is not authoritative for the DS record at the child - zone's apex, and the authoritative DS RR is only stored at the - parent. - - If the name server allows recursion, and the RD bit is set in the - query, the name server MAY perform recursion to find the DS record - for the delegated name from the parent zone, and MAY return the DS - record from its cache. In this case, the AA bit MUST NOT be set in - the response. - - If the name server does not perform recursion to find the DS RR, the - name server MUST reply with: - - RCODE: NOERROR - AA bit: set - Answer Section: Empty - Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)] - - In other words, a name server which is authoritative for the child - zone but not for the parent zone answers as if the DS record does not - exist. Note that security-aware resolvers will query the parent zone - at delegation points, and thus will not be affected by this behavior. - - For example, suppose that "example.com" is a delegation point, and a - name server receives a query for the "example.com" DS RRset. - - o If the name server is authoritative for "com", the name server - MUST reply with the "example.com" DS RRset from the "com" zone. - - o If the name server is authoritative for "example.com", is not - authoritative for "com", and the RD bit is set to one in the - query, the name server MAY perform recursion to find the - "example.com" DS record. If the name server does not use - recursion to obtain the DS RR, the name server MUST reply as - though the DS RR did not exist: - - RCODE: NOERROR - AA bit: set - Answer Section: Empty - Authority Section: SOA [+ RRSIG(SOA) + NSEC + RRSIG(NSEC)] - - -3.6 Responding to Queries for Type AXFR or IXFR - - DNSSEC does not change the DNS zone transfer process. A signed zone - - - -Arends, et al. Expires March 30, 2004 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these - records have no special meaning with respect to a zone transfer - operation, and these RRs are treated as any other resource record - type. - - 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 meets 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 which chooses to perform - its own zone validation MUST NOT selectively reject some RRs and - accept others. - - Note that the DS RR appears only in the 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 "example.com" zone (the child zone). As with any - other authoritative RRset, the "example.com" DS RR MUST be included - the "com" zone transfer. - - Note that authoritative NSEC RRs appear in both the parent and child - zones at a delegated name, and that the NSEC RRs for the delegated - name in the parent and child zones are never identical to each other. - As with any other authoritative RRset, the parental NSEC RR at a - delegated name MUST be included zone transfers of the parent zone, - while the NSEC at the zone apex of the child zone MUST be included in - zone transfers of the child zone. - -3.7 Setting the AD and CD Bits in a Response - - Editors' note: This section seems a little lost here. Perhaps we - should rearrange the section ordering slightly, or provide a - pointer to this subsection at the beginning of Section 3. - - 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 set in query messages by the resolver, and MUST be - copied into the response by the name server. If the CD bit is set to - one, it indicates that the resolver is willing to perform whatever - authentication its local policy requires, and thus that the name - server need not perform authentication on the RRsets in the response. - - Regardless of the setting of the CD bit, the name server MAY choose - whether or not to perform authentication according to its own local - name server policy, and the name server MAY use the CD bit as input - - - -Arends, et al. Expires March 30, 2004 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - to its own local policy. However, if the resolver has set the CD - bit, a name server SHOULD, if possible, return the requested data to - the resolver even if the name server's local authentication policy - would reject the records in question. That is, by setting the CD - bit, the resolver has taken responsibility for performing its own - authentication, and the name server should not interfere in this - case. - - The AD bit is set by name servers, and indicates the data in the - response has been authenticated by the name server, according to the - local name server policy. The AD bit MUST NOT be set on a response - unless all of the RRsets in the Answer and Authority sections have - met the name server's local authentication policy. A resolver MUST - NOT trust the AD bit unless it communicates with the name server over - a secure transport mechanism and is explicitly configured to trust - the name server's policy. - -3.8 Example DNSSEC Responses - - Editors' note: these examples probably ought to move to an - appendix and probably ought to use the "real" signed example zone - that's already in an appendix. - - The examples in this section use the following example zone to - demonstrate the formation of replies by an authoritative name server. - The zone has two name servers, a single child, and a wildcard MX RR. - The zone is completely signed and has a full NSEC chain. - - example.com. SOA (...) - RRSIG SOA ... - NS a.example.com. - NS b.example.com. - RRSIG NS ... - MX 10 a.example.com - RRSIG MX ... - DNSKEY ... - RRSIG DNSKEY ... - NSEC *.example.com. - * MX 10 a.example.com. - RRSIG MX ... - NSEC a.example.com. - a A 10.10.10.1 - RRSIG A ... - NSEC b.example.com. - b A 10.10.10.2 - RRSIG A ... - NSEC c.example.com. - c CNAME a.example.com. - - - -Arends, et al. Expires March 30, 2004 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - RRSIG CNAME - NSEC sub.example.com. - sub NS ns.sub.example.com. - RRSIG NS - DS ... - RRSIG DS - NSEC *.example.com. - ns.sub A 10.10.10.3 - sub-nosig NS ns.sub-nosig.example.com. - NSEC example.com. - ns.sub-nosig A 10.10.10.4 - - A query to the authoritative name server for this zone for - QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce: - - Flags: QR=1, AA=1, RCODE=0 (NOERROR) - EDNS: DO=1, size=4000 - QUERY: - c.example.com. IN A - ANSWER: - c.example.com. IN A a.example.com - IN RRSIG CNAME - a.example.com. IN A 10.10.10.1 - IN RRSIG A - AUTHORITY: - example.com. IN NS a.example.com. - IN NS b.example.com. - IN RRSIG NS ... - ADDITIONAL: - a.example.com. IN A 10.10.10.1 - IN RRSIG A ... - b.example.com. IN A 10.10.10.2 - IN RRSIG A ... - - A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would - results in a referral to a signed zone. The resolver can determine - that "sub.example.com" is signed because of the presence of the DS RR - with the hash of the "sub.example.com" zone key. - - Flags: QR=1, AA=1, RCODE=0 (NOERROR) - EDNS: DO=1, size=4000 - QUERY: - www.sub.example.com. IN A - ANSWER: - ;; empty - AUTHORITY: - sub.example.com. IN NS ns.sub.example.com. - IN DS ... - - - -Arends, et al. Expires March 30, 2004 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - IN RRSIG DS ... - ADDITIONAL: - ns.sub.example.com. IN A 10.10.10.3 - - A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A - would result in a referral to an unsigned zone. The resolver knows - not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS - bit in the NSEC RR bitmap in the referral is not set. Even if DNSSEC - RRs are present in responses from "sub-nosig.example.com" name - servers, the resolver will not be able to construct a authentication - chain, since there is a break between "sub-nosig.example.com" and its - delegating parent zone. - - Flags: QR=1, AA=1, RCODE=0 (NOERROR) - EDNS: DO=1, size=4000 - QUERY: - www.sub-nosig.example.com. IN A - ANSWER: - ;; empty - AUTHORITY: - sub-nosig.example.com. IN NS ns.sub-nosig.example.com. - IN NSEC ;; (DS bit not set) - IN RRSIG NSEC ... - ADDITIONAL: - ns.sub-nosig.example.com. IN A 10.10.10.4 - - A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name - error, because the name does not exist and is not covered by wildcard - expansion. Therefore, the name server must present proof that the - name does not exist, and that no wildcard expansion is present which - could have been used to answer the query. - - Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN) - EDNS: DO=1, size=4000 - QUERY: - f.example.com. IN A - ANSWER: - ;; empty - AUTHORITY: - example.com. IN SOA ... - IN RRSIG SOA ... - c.example.com. IN NSEC sub.example.com. ... - IN RRSIG NSEC ... - *.example.com. IN NSEC a.example.com. ... - IN RRSIG NSEC ... - ADDITIONAL: - example.com. IN DNSKEY ... - IN RRSIG DNSKEY ... - - - -Arends, et al. Expires March 30, 2004 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX - RR synthesized via wildcard expansion. The name server must prove - that no exact match exists. - - Flags: QR=1, AA=1, RCODE=0 (NOERROR) - EDNS: DO=1, size=4000 - QUERY: - f.example.com. IN MX - ANSWER: - f.example.com. IN MX 10 a.example.com. - IN RRSIG MX ... - AUTHORITY: - example.com. IN NS a.example.com. - IN NS b.example.com. - IN RRSIG NS ... - c.example.com. IN NSEC sub.example.com. - IN RRSIG NSEC ... - ADDITIONAL: - a.example.com. IN A 10.10.10.1 - IN RRSIG A ... - b.example.com. IN A 10.10.10.2 - IN RRSIG A ... - - If these responses came from a recursive name server which had all of - the necessary RRsets in its cache instead of from an authoritative - server, the only differences would be the TTLs and the header flags. - The AA bit would not be set, and the AD bit would be set if (and only - if) all the RRsets in a response passed the security policy checks of - the recursive name server. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -4. Resolving - - This section describes the behavior of entities which 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 a - separate subsection. - - A security-aware resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set to one 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 - advertise the supported message size using the "sender's UDP payload - size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST - handle fragmented UDP packets correctly regardless of whether any - such fragmented packets were received via IPv4 or IPv6. Please see - [RFC3226] for discussion of these requirements. - - A security-aware resolver MUST support the signature verification - mechanisms described in Section 5, and MUST 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 which instructed the security-aware - resolver not to perform validation for this query; or - - o Validation for this query has been disabled by local policy. - - A security-aware resolver's support for signature verification MUST - include support for verification of wildcard owner names. - - A security-aware resolver MUST attempt to retrieve missing DS, - DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these - RRs in order to perform signature verification. - - A security-aware resolver MUST attempt to retrieve missing a NSEC RR - which the resolver needs to authenticate a NODATA response. In - general it is not possible for a resolver to retrieve missing NSEC - RRs, since the resolver will have no way of knowing the owner name of - the missing NSEC RR, but in the specific case of a NODATA response, - the resolver does know the name of the missing NSEC RR, and must - therefore attempt to retrieve it. - - - -Arends, et al. Expires March 30, 2004 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - A security-aware resolver MUST be able to determine whether or not it - should expect a particular RRset to be signed. More precisely, a - security-aware resolver must be able to distinguish between three - cases: - - 1. An RRset for which the resolver is able to build a chain of - signed DNSKEY and DS RRs from a trusted starting point to the - RRset. In this case, the RRset should be signed, and is subject - to signature validation as described above. - - 2. 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. - - 3. An RRset for which the resolver is not able to determine whether - or not the RRset should be signed, because 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. - - A security-aware resolver MUST be capable of being preconfigured with - at least one trusted public key, and MUST be capable of being - preconfigured with multiple trusted public keys or DS RRs. Since a - security-aware resolver will not be able to validate signatures - without such a preconfigured trusted key, the resolver SHOULD have - some reasonably robust mechanism for obtaining such keys when it - boots. - - A security-aware resolver SHOULD cache each response as a single - atomic entry, indexed by the triple , with the - 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. - - A security-aware resolver SHOULD NOT cache data with invalid - signatures under normal circumstances. However, a security-aware - resolver SHOULD take steps to rate limit the number of identical - queries it generates, which may require the resolver to retain some - data about recently generated queries. Conceptually, this is similar - to negative caching [RFC2308], but since the resolver has no way of - obtaining the appropriate caching TTL from received data in this - case, the TTL will have to be set by the implementation. This - document refers data retained as part of such a rate limiting - mechanism as the "BAD cache". - - - - -Arends, et al. Expires March 30, 2004 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -4.1 Recursive Name Servers - - As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware - recursive name server is an entity which 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 which - implements the security-aware name server role and the code which - implements the security-aware resolver role, respectively. - - A security-aware recursive name server MUST NOT attempt to answer a - query by piecing together cached data it received in response to - previous queries that requested different QNAMEs, QTYPEs, or - QCLASSes. A security-aware recursive name server MUST NOT use NSEC - RRs from one negative response to synthesize a response for a - different query. A security-aware recursive name server MUST NOT use - a previous wildcard expansion to generate a response to a different - query. - - The name server side of a security-aware recursive name server MUST - pass the sense of the CD bit to the resolver side along with the rest - of an initiating query, so that the resolver side will know whether - whether or not it is required to verify the response data it returns - to the name server side. - - 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 but - MUST NOT strip any DNSSEC RRs that the initiating query explicitly - requested. - - The resolver side MUST follow the usual rules for caching and - negative caching which would apply to any security-aware resolver. - - If the name server side receives a query which matches an entry in - the resolver side's BAD cache, the name server side's response - depends on the setting 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 SHOULD - return RCODE 2 (server failure). - - 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 or Authority sections of the response to be - authentic, and SHOULD set the AD bit if and only if the name server - considers all RRsets in the Answer section and any relevant negative - - - -Arends, et al. Expires March 30, 2004 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - response RRs in the Authority section to be authentic. How the name - server side of a security-aware recursive name server determines - whether an RRset is authentic depends on the origin of the RRset. If - the RRset came from the resolver side of the recursive name server - (the normal case), recursive name server MUST follow the procedure - described in Section 5. If the RRset came from a zone for which the - name server side of the recursive name server is authoritative, local - policy MAY consider the RRset to be authentic without further - verification simply because the RRset came from an authoritative - zone, but the name server SHOULD NOT do so unless the it 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. - -4.2 Stub resolvers - - A security-aware stub resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set to one when sending queries. - - A security-aware stub resolver MUST support a message size of at - least 1220 octets, SHOULD support a message size of 4000 octets, and - MUST advertise the supported message size using the "sender's UDP - payload size" field in the EDNS OPT pseudo-RR. A security-aware stub - resolver MUST handle fragmented UDP packets correctly regardless of - whether any such fragmented packets were received via IPv4 or IPv6. - Please see [RFC3226] for discussion of these requirements. - - 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. A security-aware stub resolver MAY include the - DNSSEC RRs returned by a security-aware recursive name server as part - of the data that it the stub resolver hands back to the application - which invoked it but is not required to do so. - - A security-aware stub resolver SHOULD NOT set the CD bit when sending - queries, since, by definition, a security-aware stub resolver does - not validate signatures and thus depends on the security-aware - recursive name server to perform validation on its behalf. - - A 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 which 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, so as a practical matter there - may be little practical value to checking the status of the AD bit - - - -Arends, et al. Expires March 30, 2004 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -5. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires preconfigured knowledge of at least one - authenticated DNSKEY or DS RR. The process for obtaining and - authenticating this initial DNSKEY or DS RR 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 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 authenticated DNSKEY RRs. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset using an initial key, - the resolver MUST: - - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR has the Zone Key Flag - (DNSKEY RDATA bit 7) set to one. - - 2. Verify that there is some RRSIG RR which 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 using an - initial DNSKEY RR, delegations from that zone can be authenticated - 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 preconfigured 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. - - Once the resolver has authenticated a zone's apex DNSKEY RRset, - 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. 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, 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 which that lacks - the appropriate DNSSEC RRs, whether due to configuration issues such - as a security-oblivious recursive name server which accidentally - - - -Arends, et al. Expires March 30, 2004 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - interfere 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 [I-D.ietf-dnsext-dnssec-intro]) 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 the validator to have some other means of - obtaining a trusted zone key. If a validator cannot obtain such a - key, it will have to choose whether to accept the unvalidated - responses or not based on local policy. - - 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 trusted starting point 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. A strong cryptographic digest algorithm - ensures that an adversary can not easily 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); - - 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 - - - -Arends, et al. Expires March 30, 2004 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - RRset which, when hashed using the digest algorithm specified in - the DS RR's Digest Type field, results in a digest value which - matches the Digest field of the DS RR; and - - o The matching DNSKEY RR in the child zone has the Zone Flag bit set - to one, 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.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 resolver authenticates an NSEC RRset which 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 which 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 resolver can not authenticate RRsets in or below the - child zone. - - 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, since 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. - -5.3 Authenticating an RRset Using an RRSIG RR - - A resolver can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The resolver first checks the RRSIG - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The resolver 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, resolver uses the public key and signature - to authenticate the signed data. Section 5.3.1, Section 5.3.2, and - Section 5.3.3 describe each step in detail. - - - - -Arends, et al. Expires March 30, 2004 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -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 resolver'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 resolver'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 to one. - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the resolver can not predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until the resolver has either validated the signature or - has run out of matching keys to try. - - Note that this authentication process is only meaningful if the - resolver 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 DS RR or DNSKEY RR which the resolver has - been preconfigured to believe to be authentic. - - - - -Arends, et al. Expires March 30, 2004 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -5.3.2 Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - Section 5.3.1, the resolver needs 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 resolver 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 | class | type | 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 - - 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 = RRset's fully qualified domain name in - canonical form - - if rrsig_labels = fqdn_labels, - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the leftmost rrsig_label labels of the - fqdn - - - -Arends, et al. Expires March 30, 2004 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - if rrsig_labels > fqdn - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - RRset. - - Section 5.5.1 gives an example of original name calculation. The - canonical forms for names and RRsets are defined in - [I-D.ietf-dnsext-dnssec-records]. - - 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 - RRset 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 since only the child NSEC RRs will - specify 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, and 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 also 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 which contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - -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 resolver 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 to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key to used generate the signature is contained in the Public Key - field of the matching DNSKEY RR(s) (found in Section 5.3.1). - [I-D.ietf-dnsext-dnssec-records] 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 - - - -Arends, et al. Expires March 30, 2004 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - conditions in Section 5.3.1. In this case, the resolver can only - determine which DNSKEY RR by trying each matching key until the - resolver 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 RRSIG RR, the local resolver - security policy determines whether the resolver also needs to test - these RRSIG RRs, and determines how to resolve conflicts if these - RRSIG RRs lead to differing results. - - If the resolver accepts the RRset as authentic, the resolver 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; and - - o The value in the RRSIG RR's Original TTL field. - - -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's fully qualified domain name is - greater than the Labels field in the covering RRSIG RDATA, then the - RRset and its covering RRSIG RR were created as a result of wildcard - expansion. Once the resolver has verified the signature as described - in Section 5.3, the resolver 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.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. - - - - -Arends, et al. Expires March 30, 2004 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - Security-aware resolvers MUST first authenticate NSEC RRsets - according to the standard RRset authentication rules described in - Section 5.3, then apply the NSEC RRsets as follows: - - 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. Since the existence of the authenticated - NSEC RR proves that the owner name exists in the zone, wildcard - expansion could not have been used to match the requested RR owner - name and type. - - o If the requested RR name would appear after an authenticated NSEC - RR 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 [I-D.ietf-dnsext-dnssec-records], then no exact match - for the requested RR name exists 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 exists which - could have been used to generate a positive response. - - To prove 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 - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to 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 - 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 verified NSEC RR proves the existance of both itself and its - corresponding RRSIG RR, a verifier MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5 Examples - - Editors' note: perhaps all of this should move to an appendix? - - -5.5.1 Example of Re-Constructing the Original Owner Name - - Suppose that a security-aware resolver receives a response containing - an answer RRset with an owner name of is "www.a.b.c.example.com". - This fully qualified domain name has 6 labels: "www", "a", "b", "c", - - - -Arends, et al. Expires March 30, 2004 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - "example", and "com". What name the resolver should use when - reconstructing the original signed data depends on the value of the - RRSIG RR's Labels field. - - If the value of the RRSIG RR's Labels field is 6, then the RRSIG RR's - Labels field matches the number of labels in the owner name, and the - resolver should assume that this RRset is not the result of wildcard - expansion. The resolver should therefore use "www.a.b.c.example.com" - as the owner name when reconstructing the original signed data for - the signature check. - - If the value of the RRSIG RR's Labels field is less than 6, then the - RRSIG RR's Labels count is less than the number of labels in the - RRset's owner name, and the resolver should assume that this RRset is - the result of wildcard expansion. The resolver should therefore - reconstruct the original owner name by replacing the labels which - appear to be the result of wildcard expansion with a single "*." - label. For example, if the RRSIG RR's Labels field is 3, the - resolver should reconstruct the original owner name by prepending - "*." to the last 3 labels of the owner name of the answer RRset. - Thus, the resolver should use "*.c.example.com" as the owner name - when reconstructing the original signed data. - - If the value of the RRSIG RR's Labels field is greater than 6, then - this RRSIG RR cannot possibly be valid for the answer RRset, and - there is no point in attempting to validate the signature. - -5.5.2 Examples of Authenticating a Response - - Editors' note: Eventually this will be an example of the - authentication process for "www.example.com", starting from an - initial root key. - - Editors' note: Eventually this will be an example of the - authentication process for non-existent "www.a.b.c.example.com", - starting from an initial root key. - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -6. IANA Considerations - - [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA - considerations introduced by DNSSEC. The 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 [I-D.ietf-dnsext-ad-is-secure] - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - - DNSSEC introduces a number of denial of service issues. These issues - will also be addressed in a future version of these security - considerations. - - Please see [I-D.ietf-dnsext-dnssec-intro] for general security - considerations related to DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -8. Acknowledgements - - This document was created from the input and ideas of several members - of the DNS Extensions Working Group and working group mailing list. - The co-authors of this draft would like to express their thanks for - the comments and suggestions received during the revision of these - security extension specifications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -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. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, 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. - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-06 (work in progress), - September 2003. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-04 (work in progress), - September 2003. - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -Informative References - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [I-D.ietf-dnsext-delegation-signer] - Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15 (work in progress), - June 2003. - - [I-D.ietf-dnsext-wcard-clarify] - Halley, B. and E. Lewis, "Clarifying the Role of Wild Card - Domains in the Domain Name System", - draft-ietf-dnsext-wcard-clarify-01 (work in progress), - August 2003. - - [I-D.ietf-dnsext-ad-is-secure] - Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD - bit", draft-ietf-dnsext-ad-is-secure-06 (work in - progress), June 2002. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Rob Austein - Internet Software Consortium - 40 Gavin Circle - Reading, MA 01867 - USA - - EMail: sra@isc.org - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.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. Expires March 30, 2004 [Page 38] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -Appendix A. Algorithm For Handling Wildcard Expansion - - For zone (Z) and a name (N) that may occur in Z, the following - algorithm finds all wildcard RRsets that match N or returns an NSEC - RRset that proves no wildcard expansion matches N. The algorithm was - written for clarity, not efficiency: - - 0. INPUT: a name (N) and a zone (Z). - INIT: NSEC_SET = NULL - - 1. Construct S = sequence of all names in Z, sorted - into canonical order. - - 2. If N exists in S - There is an exact match for N. - Return all RRsets associated with N - Else - Add the name that would immediately - precede N in S to NSEC_SET. - EndIf - - 3. Replace the leftmost label of N with * - - 4. If N exists in S and answers the query - There is a positive wildcard match for N. - Return all RRsets associated with N - Else - Add the NSEC for name that would immediately - precede N in S to NSEC_SET. - Return the NSEC_SET. - EndIf - - 5. Remove the leading * from N. - - 6. If N exists in S - There is a name that terminates the wildcard search. - Add the NSEC for N to NSEC_SET and return NSEC_SET. - Else - Add the NSEC for name that would immediately - precede N in S to NSEC_SET. - Return the NSEC_SET. - EndIf - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -Appendix B. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.ns1.example. ( - 1064876255 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 1 1 3600 20031029215736 ( - 20030929215736 4638 example. - Bo6PBV6UOrnCzptCZg0lTQQqsZ4qqIn16vbA - KQobYD2wNxs5hxNYlvNRlNPB0nfSD9o2daBE - v0Q/Q5mEanr2R28a62PHwkHNwHUx/spGWAGJ - h5u28d5wMNQQvMsFgB+kSSnNEcL1Z7uLjRal - ahgGvtiSMzzSS7n65xfxc1X78Nw= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 1 1 3600 20031029215736 ( - 20030929215736 4638 example. - WeJdApmzK+GIrOQKYmkABF5POWu5SDU6opwd - wOjWrVFGRNhFHe1Z/KZwT1Ii5YjH2X9dTRRh - YG3U/wcqvWLJ1882FoUZakwmtzGFotdONcs3 - DzhFMxTawVlBb+MLsPj8J2GuZiR28eTyPB6i - TYq3Ed0R9VStJwtiKmoXqubFAr0= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 1 1 3600 20031029215736 ( - 20030929215736 4638 example. - eBXNS2Vi/MhqX76VCIlpbK4yq9UWzvYcSBV9 - Cx0t6rl9CWOpdFVzV/lL0wyVYQjZXBlZ1gpo - djLXl0QTEE+9MrRO3c8j7NyVsOEJQdnWdEAW - BL8f+F3fwayjj5dIsq1NngF8neGXROao1bJM - 5gmIc/F6gzUL3/KyJA8zPF2fUVA= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC - 3600 RRSIG NSEC 1 1 3600 20031029215736 ( - 20030929215736 4638 example. - t3VabTtmQ3uEgohzbuHKk2bFEDqYWa3hgTi2 - D1Sv+eN+IkV1xExBvsvuE6Oovf+QlDqV7sU/ - XP2kRzob5V9N40xQCZMBFx2GgAim8px788EX - ZuS7u0fKeHfaP/2sSTktGnpK77Mx4fM6RK8x - DBRONckIWXn2chGDeicQuEHjhfQ= ) - 3600 DNSKEY 256 3 1 ( - AQPbGuRKgswzNd2Qb7ck1Tdai9FFbapP3mUO - G80mSowM5s9aMao+JOeFl/4f33cs2hWHznn3 - LZ5EuIlA/lvvG+f5h46OvCR+CFXHmqEPyMmd - kiCdJmHcvRuMIzekHM2DSDcG7i1lZG/jXvaG - - - -Arends, et al. Expires March 30, 2004 [Page 40] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - mK5G3NeHjqssh1AujDaqHFf5IRIeQQ== - ) - 3600 DNSKEY 257 3 1 ( - AQPGkQLwyHHfD8nkDxZSbErTBHLYdOKkVIoq - SJkBnpfABtFdiJBgZYcjCNExAFjlc/olW42g - TJYBRjs1INw3I08/h43L595Iq8fyhEyBoGOR - +6db+Q3oQ9G2EKpfMEPDLU6f7gYrHpzDHIjO - rsSftzmRYHou70oVQ7aBjd9ePPCOVw== - ) - 3600 RRSIG DNSKEY 1 1 3600 20031029215736 ( - 20030929215736 4638 example. - GMZI2r4bwFYpKIs0Dv//4aWg5HhpzMBkm5Vk - 4KFg4hEkOabYgWoBJdZdjRBTrjwkrtiPH9KF - kJKlzFfeeELbFEfhgZ3SujDqNQmGfoZ1i7a2 - lH47jc1JOeos75e9QK8fUFjIxOF8fkZNO9Fx - lOyOxNDJPATE3Wm+AX0SmQSJ3XY= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 23677 1 1 ( - F248F32298280A061736C93FB078A51C17CC - C291 ) - 3600 RRSIG DS 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - k6fA3VfeR5UHu9L/+4y8HJrUubVHBdyFzMaa - 8EpDYqw3vYEVsrL5YvXwoqrSZsSAxdIrUXoB - SzjbKFOq6HRxXjuLsJ2TLT90p6mg9ZHL57jH - FfmrNPuq58QwRWvwuOyaExJWEdxMIEIbvETz - YJs3G/9tNte9i25YtAuLHbD2UqY= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - tQbGVL6yxb2vBQ5ItcQ1XQyxNxz3+zHTTkgs - T/WSk9YXr+swug7h+Wq20RPXfsEl7lVMi/By - d60s6Q7lEibGucIQCLLx0Xe68zQOmWx7fmU6 - iSDTQgc7TOsG/blDba7MiRENTeI6iynyZHw9 - gURpK8RlfEPb7O98rrYLWZbzg3o= ) - 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 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - UCegsbGngHOwgyxevtBrCSsV6Jv6OxGWApvY - RsbwL2XZBFc4saU6Zujiz8i2urkVLSlFM2MM - OHuEMN5E+cjGDjqfaI8O5eILapsGRqHUPM9t - 5wCOb9BqANn03UUFUhAnKBkv3fHFM5hg+IZQ - vVNUzslGEBlQ0SJZkWJcCtRDo5c= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 1 2 3600 20031029215736 ( - - - -Arends, et al. Expires March 30, 2004 [Page 41] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - 20030929215736 4638 example. - CP6bRkIyQ3FnhsBWO63uQN1QtJse8mWNRTf2 - jXqR33dekEfKNhlQtw0yzepa7lX75uyQTAlP - NBBK73Zlim5g1bw3ulLl0vXnTpQRSK80SJw9 - uPPTYBDq68jMKn1a3RvGnR5MynQR33UY2vGT - 6IAiGfqY/zYFXWSIsmJr0875PQ0= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - VnpRe+HGt+mCalDopO4wtHtRvs9CKdjr3FoG - zv8BPFvC1FdDJAjxpAgJs6Ihx+174Hl+jlZU - Z3HOd0MBwch0XH1UDcU0/opQRquW+oYwV3E4 - esgKhsy9EUj3NtoW/GQ/1dJEbuUZah4/IPGH - KI0DhRWJC/iKs6J963WLNdPnwKk= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - A7MtS+oATUFf6t3nj/0GL7lBbt86ozzkbbJM - J3tLwFkGebf1XV+MnpPeSzeRXm4QeqohDvVZ - U5SluyOHT397x4WQPwHCRXojos1lQnWhPUji - qjKaXLVRHv4x2O2fzWu0OE65GJkL6zAnFqCL - SpV8hBOC+EAcLjnuAi5DJJlONmc= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - lGZ+rJ1vtIEtLjXKG4Iruipq6KoXrre89QHZ - dBgSPcomROrsSElhUBFLcl2+KMCnKCqtEJZ7 - YPOTK07WCwFU6Rek+xD+OuuJrQRWTbiCmFMX - N9ZMk87lkIWHAXMk1YM3f1/FUytbb8RI8RfH - u2x/e3zoBQdHAId3LCOO9jYDzCc= ) - 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 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - u/uV4xcu7KSVV+3Vtg8O0qTGlGHeFKU1vBQJ - x1QKLtolw/ZstzqIuRBI5fuF4JYxSwMoaI7b - JBFyZ3KkCCK88r1VjZTkicNvFG7RO3G2faxb - MualMbGfhcexJzRcoZsIXSb3+qtbAr4aKF7c - fdZ587NLR1Ns2GraGTztUDMSK/A= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - bsz0NVY6tQ0kmIpKOR3QHNEradwR39uNikey - jQIr7TMOvNVDX6tVBNoDuKxUy6zHR5CS6oBs - nN5OPPKEjTdOGWUfHavSZgZGT7b8xfL++Ahi - - - -Arends, et al. Expires March 30, 2004 [Page 42] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - Cgeg0ofB6Ext7KfeMkTrxP/8BsDMJm8R8Ome - I2mIq/WvuXTr2XKcJDbxYIdSyss= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - mCzjw1wydcnYx0d7kbPbJTXVw+FnksdLnTmq - DrIdy269MeGL4AGJSV8g8Gt0Zbq3hGo6+/Tz - S9VIp4QZtKgRZ1nlI0XQOlkASOLPjvo7hHRr - PPiFqGyznqy9+QHdIalqTO4BOrfS3f5bIgJW - IGUMRh8nFi+wnG09+OH46IlkB9s= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - FS6W/8Na26DIs1DYB1Xhhxc1GyRlzj5XkG/3 - pY6H6PQGc/nP6CVM1eHEkmvYAG8kWfk9ZdDZ - 64cOb2tisSH1o7WMLg7hWUS5nnXyxyyj5/Gs - n3CpVCDptq9JnQe+jjH0empKdbTYoeVIX8h/ - 2aw1RkmYb4LbuhP0uwN/lZqQVik= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - MHxP6z3ozpA9AICDnEW0T06o2GlIOtj0+oGm - TC4nqveQj2QSKOEUNXgVaUkBTT9F/FIVy9q+ - FAAe4SXnBcVpIvTVN2NhU4Jm9976hU8HTEfi - EMlnhmn4vJ1qZ+DI1WgWK+iKSU/N6ShdN/Fi - G7zd/X4PmuWIIYG+5IAzmtB2UJs= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - tXBqjlbdFl70S+dzovir86EQBHavroozeo4f - Spsc9BlorSdTTSwbf7lh+GRIS0hCtaJxMFog - 0XhGhO6sn1Yai3s7NeV6viQpy8gPfJ0wfr9Y - H1nYv76o6oXX2KlGTJrd4J7f7Hxz2DsOWVoK - w1LXOATBvP/kCRgmq4KdFNwTiBc= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 1 3 3600 20031029215736 ( - 20030929215736 4638 example. - p/BQOuDk4Wg3pZreH6kmxws0A1hNYIkJTTlP - rHoI9T/HMfA50p/qnXQHxgYh1IDnsxjeswaE - LL7B/q0QxmaT1/0wNbZTn58/rqDSpV43Qxjl - QHK0fDgp6al4VNxvK+uIJIHO525jCH146BEC - +tqUhrmtTxtItfpV/8Q7i6+B2bY= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 1 3 3600 20031029215736 ( - 20030929215736 4638 example. - c2/unp4ewGHNJIOVKiw9O/aA+PfXJ5Thwjt4 - EyleUaXFp01H5RkDVxMVicJEHcfslqfzF8XP - M9pPTwU7DPAFrxXo71pMez/EqA3pnhxnUcEi - - - -Arends, et al. Expires March 30, 2004 [Page 43] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - lVextpfIxIZam0Oj5Q+nCLJJs95Q3I8E5J29 - IgHVoBYahu8hE0DycgzLredhC5A= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 1 4 3600 20031029215736 ( - 20030929215736 4638 example. - nwe5rxko6mbV2f0edTn0/H1CbDd8T4ZHg2Wg - Os3Lh5Rz092PVbAnbzCp4Y95MdPPwMUd3cKk - h7tvjBJgPPBhAWufdv2uVcq2lnINs1+LsJH7 - CtJobsu9LxcORCkcYEKG1bc4fInPPnuUnlXD - JYEmK1UOpYTDRx+lKLRI5tLzKmc= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 1 4 3600 20031029215736 ( - 20030929215736 4638 example. - UjlRFPbR2LzHtiP+CDGsJnaSo0iyooOkZ2By - vyqOGHg+0OudJ4/+VYC/8C0dJNRUzAAm17GG - ox272n3P0BHERCeegWAFCjYCARhZwkfpq8sQ - ynkJRjpFlkxgdSFiHDZOAQz/s0a9ZaFDKP27 - rKbS4qvhL+dfOnPBPNI099W7EAw= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - irvnPlRadiUTTM3feA/mNNKnxRIRY7vZ0r3d - foc+IgbvYJeHi8UYThPrinjF2SPcwQ29g+6h - aFA8ne9ZpRwL1lEQ6U3OTGLKd1OtGCTizEmN - fgmPU/wIUuNaR7AG4i6FekWhciHbrjfRF/NN - zJKlxAUeVRQ2ufYCoSY7wa6cIV4= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - NL6VSnSkuPX41EgJChuPiVF9JzIsJ/p7pQ61 - DG8oWhtZjTP1uYWdwHPMM3EDxQykJBwJShE9 - 5Mg7myUpRFAuLHZJZ35227AZ6+eo0UoikJSA - opuXW50OLYARZTy4lRqSUU41B5Km1vvYaIoq - hjNlRggyhvEmSNw4kvl5w99jqKg= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - wkkCfIYfNeQ2YK0fL/bceo9oONGfZNkp/MnQ - yllq11xEoelJbWjqlS7RbfUViOVbrxJbV+8j - AYnLEC3/YGdoDUeVBPk2hqfGB8vMZfsu/d1Y - bhcMej6fIoXj/q4HIXNSD9UcP0CNtLR6n7Bq - ndtF5V/pM6xI0tiE51KudVttsJI= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 1 2 3600 20031029215736 ( - 20030929215736 4638 example. - fi2La99VLlZhIPUgGd/Fd6MH8wJZ6ziSPW34 - k214lDIQQBlu0X4V0z4DcZ/PDBeqvKOORmEI - AhZLwELtWv5XSAmALYUr3Rrtp/H066R4EpAu - - - -Arends, et al. Expires March 30, 2004 [Page 44] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - YrS4pZ8/QFM+HnPUcofSK3IzLBucXsnDSYr0 - fQ5nfoBQ++eHo+IEohbqrwnE60E= ) - - 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 which 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires March 30, 2004 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications September 2003 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires March 30, 2004 [Page 47] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt new file mode 100644 index 0000000000..0673d91b8c --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt @@ -0,0 +1,3080 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: April 26, 2004 M. Larson + VeriSign + R. Austein + ISC + D. Massey + USC/ISI + S. Rose + NIST + October 27, 2003 + + + Protocol Modifications for the DNS Security Extensions + draft-ietf-dnsext-dnssec-protocol-03 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 26, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document is part of a family of documents which describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + + + +Arends, et al. Expires April 26, 2004 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + defines the concept of a signed zone, along with the requirements for + serving and resolving 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6 + 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6 + 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 8 + 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 + 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 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 . . . . . . . . . . . . . 10 + 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 11 + 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13 + 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 14 + 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 15 + 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 16 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 18 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 21 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 23 + 5.1 Special Considerations for Islands of Security . . . . . . . 24 + 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 24 + 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 25 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 26 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 27 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 28 + 5.3.4 Authenticating A Wildcard Expanded RRset Positive + + + +Arends, et al. Expires April 26, 2004 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + Response . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 29 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 32 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 + Normative References . . . . . . . . . . . . . . . . . . . . 34 + Informative References . . . . . . . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 35 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 37 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . 43 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 44 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 45 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 46 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 47 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 47 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 48 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 49 + C. Authentication Examples . . . . . . . . . . . . . . . . . . 51 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 51 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 51 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 52 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 52 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 52 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 52 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 53 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 53 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 53 + Intellectual Property and Copyright Statements . . . . . . . 54 + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 3] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications which 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 to handle signed zones. Section 4 describes + the behavior of entities which include security-aware resolver + functions. Finally, Section 5 defines how to use DNSSEC RRs to + authenticate a response. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034] and RFC1035 [RFC1035]. + + This document is part of a family of documents which define DNSSEC. + An introduction to DNSSEC and definition of common terms can be found + in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC + resource records can be found in [I-D.ietf-dnsext-dnssec-records]. + +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 RFC 2119. [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Open Technical Issues + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + + + + +Arends, et al. Expires April 26, 2004 [Page 4] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +1.3.3 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +2. Zone Signing + + DNSSEC is built around the concept of signed zones. A signed zone + includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to + the rules specified in Section 2.1, Section 2.2, Section 2.3 and + Section 2.4, respectively. Any zone which does not include these + records according to the rules in this section MUST be considered + unsigned for the purposes of the DNS security extensions. + + DNSSEC requires a change to the definition of the CNAME resource + record. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs + to appear at the same owner name as a CNAME RR. + + Section 2.6 shows a sample signed zone. + +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, there SHOULD be a corresponding zone DNSKEY RR + stored in the zone. A zone key DNSKEY RR has the Zone Key bit of the + flags RDATA field set to one -- see Section 2.1.1 of + [I-D.ietf-dnsext-dnssec-records]. Public keys associated with other + DNS operations MAY be stored in DNSKEY RRs that are not marked as + zone keys. + + If the zone is delegated and does not wish to act as an island of + security, the zone MUST have at least one DNSKEY RR at the apex to + act as a secure entry point into the zone. This DNSKEY would then be + used to generate a DS RR at the delegating parent (see + [I-D.ietf-dnsext-dnssec-records]). This DNSKEY RR SHOULD be either a + zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro] + for definition). + + DNSKEY RRs MUST NOT appear at delegation points. + +2.2 Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone (which excludes both NS + RRsets at delegation points and glue RRsets), there MUST be at least + one RRSIG record that meets all of 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; + + + +Arends, et al. Expires April 26, 2004 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + 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 wildcard label if the owner name is a wildcard; + + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset; and + + 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 [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have + multiple RRSIG RRs associated with it. + + An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR + would add no value and would create an infinite loop in the signing + process. + + The NS RRset which appears at the zone apex name MUST be signed, but + the NS RRsets which appear at delegation points (that is, the NS + RRsets in the parent zone which 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 generated using at least one + DNSKEY of each algorithm in the parent zone's DS RRset and each + additional algorithm, if any, in the apex DNSKEY RRset. The apex + DNSKEY RRset itself MUST be signed by each algorithm appearing in the + DS RRset. + + The difference between the set of owner names which require RRSIG + records and the set of owner names which 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 + 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 + only visible during the zone signing process, because NSEC RRsets are + authoritative data, and are therefore signed, thus any owner name + which has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + + + +Arends, et al. Expires April 26, 2004 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +2.3 Including NSEC RRs in a Zone + + Each owner name in the zone MUST have an NSEC resource record, except + for the owner names of any glue address RRsets. The process for + constructing the NSEC RR for a given name is described in + [I-D.ietf-dnsext-dnssec-records]. + + 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. + +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 key used by the child zone to sign its apex DNSKEY + RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT + appear at non-delegation points nor at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR which is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. + + The TTL of a DS RRset SHOULD match the TTL of the corresponding NS + 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. 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 + 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 Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + + + +Arends, et al. Expires April 26, 2004 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +3. Serving + + This section describes the behavior of entities which include + security-aware name 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 as a + security-aware recursive name server does. 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. + + The terms "SNAME", "SCLASS", and "STYPE" in the following discussion + 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 [RFC3226]. + + A security-aware name server which receives a DNS query which does + not include the EDNS OPT pseudo-RR or which has the DO bit set to + zero 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. Since 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. + + 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 Section 3.1.6, + Section 3.2.2, Section 3.2.3, Section 4, and Section 4.2 for details + on the behavior of these bits. + +3.1 Authoritative Name Servers + + Upon receiving a relevant query which has the EDNS [RFC2671] OPT + pseudo-RR DO bit [RFC3225] set to one, 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 which can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1; + + o NSEC RRs which 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; + + + +Arends, et al. Expires April 26, 2004 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + 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. + + 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 which has the DO bit set to one, a + security-aware authoritative name server SHOULD attempt to send RRSIG + RRs which a security-aware resolver can use to authenticate the + RRsets in the 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 + which may need 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 need 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 these RRSIG RRs, the name + server MUST NOT set the TC bit solely because these RRSIG RRs + didn't fit. + + +3.1.2 Including DNSKEY RRs In a Response + + When responding to a query which has the DO bit set to one and which + 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 + 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). + + + +Arends, et al. Expires April 26, 2004 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +3.1.3 Including NSEC RRs In a Response + + When responding to a query which has the DO bit set to one, 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 which exactly match , but does not contain any RRsets which exactly match + . + + Name Error: The zone does not contain any RRsets which match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets which exactly + match but does contain an RRset which matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets which exactly + match , does contain one or more RRsets which + matches via wildcard name expansion, but does not + contain any RRsets which match 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 was + not present in the zone and that the response which the name server + is returning is correct given the data which are in the zone. + +3.1.3.1 Including NSEC RRs: No Data Response + + If the zone contains RRsets matching but contains no + RRset matching , then the name server MUST + include the NSEC RR for 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 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 + 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: + + + +Arends, et al. Expires April 26, 2004 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + o An NSEC RR proving that there is no exact match for ; and + + o An NSEC RR proving that the zone contains no RRsets which would + match via wildcard name expansion. + + In some cases a single NSEC RR may prove both of these points, in + which case 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). + +3.1.3.3 Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets which exactly match but does contain an RRset which matches via wildcard name expansion, the name server MUST include the + 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 . If space does + not permit inclusion of these 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 , and while the zone does + contain RRsets which match via wildcard name + expansion, none of those RRsets match 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 which matched via wildcard + expansion; and + + o An NSEC RR proving that there are no RRsets in the zone which + would have been a closer match for . + + In some cases a single NSEC RR may prove both of these points, in + which case 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). + + + + +Arends, et al. Expires April 26, 2004 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +3.1.3.5 Finding The Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server needs to locate an NSEC RR + which proves that a particular SNAME does not 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 which would have held the + nonexistent SNAME. The algorithm below is written for clarity, not + efficiency. + + To find the NSEC which proves that name N does not exist in the zone + Z which would have held it, construct sequence S consisting of every + name in Z, sorted into canonical order. Find the name M which would + have immediately preceded N in S if N had existed. M is the owner + name of the NSEC RR which proves that N does not exist. + + The algorithm for finding the NSEC RR which 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 the applicable wildcard name does not exist is precisely + the same as the algorithm for finding the NSEC RR which proves that + any other name does not exist: the part that's missing is how to + determine the name of the nonexistent 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 which has the DO bit set to one, 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) along + with the NS RRset. The name server MUST place the NS RRset before + the DS RRset and its associated RRSIG RR(s). + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR which 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. + + + +Arends, et al. Expires April 26, 2004 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + 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, since 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. + + A security-aware resolver will send queries to the parent zone when + looking for a DS RRset at a delegation point, and thus will never + trigger the corresponding special processing in a security-aware name + server. The rest of this section describes how a security-aware + recursive name server processes a misdirected DS query. + + The need for special processing by a security-aware name server only + arises when: + + 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; and + + 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 of 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 + + + +Arends, et al. Expires April 26, 2004 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + records have no special meaning with respect to a zone transfer + operation, and these RRs are treated as any other resource record + type. + + 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 meets 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 which 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, since the NSEC RR in the child zone's apex will always + indicate the presence of the child zone's SOA RR while 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 zone transfers of + the parent zone, while 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, while the RRSIG for any RRset in + the child zone's apex will be authoritative in the child zone. 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 to be used in communication between + security-aware resolvers and security-aware recursive name servers. + This bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + + + +Arends, et al. Expires April 26, 2004 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + Since a security-aware name server does not perform signature + validation for authoritative data during query processing even when + the CD bit is set to zero, a security-aware name server SHOULD ignore + the setting of the CD bit when composing an authoritative response. + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer or + 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, but 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 which 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 [I-D.ietf-dnsext-dnssec-intro], a security-aware + recursive name server is an entity which 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 which + implements the security-aware name server role and the code which + implements the security-aware resolver role, respectively. + + A security-aware recursive name server MUST NOT attempt to answer a + query by piecing together cached data it received in response to + previous queries that requested different QNAMEs, QTYPEs, or + QCLASSes. A security-aware recursive name server MUST NOT use NSEC + RRs from one negative response to synthesize a response for a + different query. A security-aware recursive name server MUST NOT use + a previous wildcard expansion to generate a response to a different + query. + + The resolver side MUST follow the usual rules for caching and + negative caching which 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 but + MUST NOT strip any DNSSEC RRs that the initiating query explicitly + + + +Arends, et al. Expires April 26, 2004 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + 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. This is a useful but somewhat + dangerous capability that requires careful handling by security-aware + recursive name servers. + + A security-aware recursive name server MUST disregard the CD bit and + perform normal signature validation unless: + + o the name server side received that query via a secure channel; or + + o the recursive name server's local policy dictates that the + recursive name server honor the CD bit even when received via an + insecure channel. + + Discussion of cases in which the CD bit is set to one in the rest of + this section assumes that one or both of the above conditions applies + to the query being processed. If neither condition applies, the + recursive name server MUST process the query as if the CD bit were + set to zero. Note, however, that the name server side MUST always + copy the setting of the CD bit from a query to the corresponding + response, regardless of whether or not the recursive name server + trusts the setting of the CD bit. + + The name server side of a security-aware recursive name server MUST + pass the sense of the CD bit to the resolver side along with the rest + of an initiating query, so that the resolver side will know whether + or not it is required to verify the response data it returns to the + name server side. If the CD bit is set to one, 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 to one 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.1) and the + name server side receives a query which matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the sense of the CD bit in the original query. If the CD bit is set, + + + +Arends, et al. Expires April 26, 2004 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + 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). + +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 or Authority sections of the response to be + authentic, and 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. + +3.3 Example DNSSEC Responses + + See Appendix B for example response packets. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +4. Resolving + + This section describes the behavior of entities which 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. + + A security-aware resolver MUST include an EDNS [RFC2671] OPT + pseudo-RR with the DO [RFC3225] bit set to one 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 + advertise the supported message size using the "sender's UDP payload + size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST + handle fragmented UDP packets correctly regardless of whether any + such fragmented packets were received via IPv4 or IPv6. Please see + [RFC3226] for discussion of these requirements. + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5, and MUST 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 which instructed the security-aware + resolver not to perform validation for this query; or + + o Validation for this query has been disabled by local policy. + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + A security-aware resolver MUST attempt to retrieve missing DS, + DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these + RRs in order to perform signature verification. + + A security-aware resolver MUST attempt to retrieve a missing NSEC RR + which the resolver needs to authenticate a NODATA response. In + general it is not possible for a resolver to retrieve missing NSEC + RRs, since the resolver will have no way of knowing the owner name of + the missing NSEC RR, but in the specific case of a NODATA response, + the resolver does know the name of the missing NSEC RR, and must + therefore attempt to retrieve it. + + + +Arends, et al. Expires April 26, 2004 [Page 19] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + When attempting to retrieve missing NSEC or DS RRs which 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. + + A security-aware resolver MUST be able to determine whether or not it + should expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between three + cases: + + 1. An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted starting point to the + RRset. In this case, the RRset should be signed, and is subject + to signature validation as described above. + + 2. 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. + + 3. An RRset for which the resolver is not able to determine whether + or not the RRset should be signed, because 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. + + A security-aware resolver MUST be capable of being preconfigured with + at least one trusted public key, and MUST be capable of being + preconfigured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a preconfigured trusted key, the resolver SHOULD have + some reasonably robust mechanism for obtaining such keys when it + boots. + + A security-aware resolver SHOULD cache each response as a single + atomic entry, indexed by the triple , with the + 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. + + A security-aware resolver MAY set the CD bit in a query to one 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. + + + + +Arends, et al. Expires April 26, 2004 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + A security-aware resolver MUST zero the AD bit when composing query + messages. + +4.1 Rate Limiting + + A security-aware resolver SHOULD NOT cache data with invalid + signatures under normal circumstances. However, a security-aware + resolver SHOULD take steps to rate limit the number of identical + queries that it generates if signature validation of the responses + fails repeatedly. + + Conceptually, this is similar in some respects to negative caching + [RFC2308], but since the resolver has no way of obtaining an + appropriate caching TTL from received data in this case, the TTL will + have to be set by the implementation. This document refers to the + data retained as part of such a rate limiting mechanism as the "BAD + cache". + + A security-aware resolver MAY chose to retain RRsets for which + signature validation has failed in its BAD cache, but MUST NOT return + such RRsets from its BAD cache unless both of the following + conditions are met: + + o The resolver has recently generated enough queries identical to + this one that the resolver is suppressing queries for this ; and + + o The resolver is not required to validate the signatures of the + RRsets in question under the rules given in Section 4 of this + document. + + The intent of the above rule is to provide the raw data to clients + which are capable of performing their own signature verification + checks while protecting clients which depend on this resolver to + perform such checks. Several of the possible reasons why signature + validation might fail involve conditions which may not apply equally + to this resolver and the client which invoked it: for example, this + resolver's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security which this resolver does + not share. In such cases, "protecting" a client which is capable of + performing its own signature validation from ever seeing the "bad" + data does not help the client. + +4.2 Stub resolvers + + A security-aware stub resolver MUST include an EDNS [RFC2671] OPT + pseudo-RR with the DO [RFC3225] bit set to one when sending queries. + + + + +Arends, et al. Expires April 26, 2004 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + A security-aware stub resolver MUST support a message size of at + least 1220 octets, SHOULD support a message size of 4000 octets, and + MUST advertise the supported message size using the "sender's UDP + payload size" field in the EDNS OPT pseudo-RR. A security-aware stub + resolver MUST handle fragmented UDP packets correctly regardless of + whether any such fragmented packets were received via IPv4 or IPv6. + Please see [RFC3226] for discussion of these requirements. + + 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. A security-aware stub resolver MAY include the + DNSSEC RRs returned by a security-aware recursive name server as part + of the data that it the stub resolver hands back to the application + which invoked it but is not required to do so. + + A security-aware stub resolver SHOULD NOT set the CD bit when sending + queries, since, by definition, a security-aware stub resolver does + not validate signatures and thus depends on the security-aware + recursive name server to perform validation on its behalf. + + A 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 which 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, so as a practical matter there + may be little practical value to 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. + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +5. Authenticating DNS Responses + + In order to use DNSSEC RRs for authentication, a security-aware + resolver requires preconfigured knowledge of at least one + authenticated DNSKEY or DS RR. The process for obtaining and + authenticating this initial DNSKEY or DS RR 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 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 authenticated DNSKEY RRs. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset using an initial key, + the resolver MUST: + + 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and verify that the DNSKEY RR has the Zone Key Flag + (DNSKEY RDATA bit 7) set to one. + + 2. Verify that there is some RRSIG RR which 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 using an + initial DNSKEY RR, delegations from that zone can be authenticated + 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 preconfigured 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. + + Once the resolver has authenticated a zone's apex DNSKEY RRset, + 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. 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, 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 which that lacks + the appropriate DNSSEC RRs, whether due to configuration issues such + as a security-oblivious recursive name server which accidentally + + + +Arends, et al. Expires April 26, 2004 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + interfere 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 [I-D.ietf-dnsext-dnssec-intro]) 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 the validator to have some other means of + obtaining an initial authenticated zone key for the island. If a + validator cannot obtain such a key, it will have to choose whether to + accept the unvalidated responses or not based on local policy. + + 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 starting point 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. A strong cryptographic digest algorithm + ensures that an adversary can not easily 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); + + 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 + + + +Arends, et al. Expires April 26, 2004 [Page 24] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + RRset which, when hashed using the digest algorithm specified in + the DS RR's Digest Type field, results in a digest value which + matches the Digest field of the DS RR; and + + o The matching DNSKEY RR in the child zone has the Zone Flag bit set + to one, 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 resolver authenticates an NSEC RRset which 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 which 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 resolver can not authenticate RRsets in or below the + child zone. + + 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, since 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. + +5.3 Authenticating an RRset Using an RRSIG RR + + A resolver can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The resolver first checks the RRSIG + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The resolver 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, resolver uses the public key and signature + to authenticate the signed data. Section 5.3.1, Section 5.3.2, and + Section 5.3.3 describe each step in detail. + + + + +Arends, et al. Expires April 26, 2004 [Page 25] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +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 resolver'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 resolver'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 to one. + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the resolver can not predetermine which DNSKEY + RR to use to authenticate the signature, MUST try each matching + DNSKEY RR until the resolver has either validated the signature or + has run out of matching keys to try. + + Note that this authentication process is only meaningful if the + resolver 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 DS RR or DNSKEY RR which the resolver has + been preconfigured to believe to be authentic. + + + + +Arends, et al. Expires April 26, 2004 [Page 26] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +5.3.2 Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + Section 5.3.1, the resolver needs 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 resolver 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 | class | type | 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 + + 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 = RRset's fully qualified domain name in + canonical form + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the leftmost rrsig_label labels of the + fqdn + + + +Arends, et al. Expires April 26, 2004 [Page 27] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + if rrsig_labels > fqdn + 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 + [I-D.ietf-dnsext-dnssec-records]. + + 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 + RRset 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 since only the child NSEC RRs will + specify 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, and 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 also 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 which contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + +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 resolver 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 to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key to used generate the signature is contained in the Public Key + field of the matching DNSKEY RR(s) (found in Section 5.3.1). + [I-D.ietf-dnsext-dnssec-records] 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 resolver can only + + + +Arends, et al. Expires April 26, 2004 [Page 28] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + determine which DNSKEY RR by trying each matching key until the + resolver 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 RRSIG RR, the local resolver + security policy determines whether the resolver also needs to test + these RRSIG RRs, and determines how to resolve conflicts if these + RRSIG RRs lead to differing results. + + If the resolver accepts the RRset as authentic, the resolver 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; and + + o The value in the RRSIG RR's Original TTL field. + + +5.3.4 Authenticating A Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's fully qualified domain name is + greater than the Labels field in the covering RRSIG RDATA, then the + RRset and its covering RRSIG RR were created as a result of wildcard + expansion. Once the resolver has verified the signature as described + in Section 5.3, the resolver 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. + + Security-aware resolvers MUST first authenticate NSEC RRsets + + + +Arends, et al. Expires April 26, 2004 [Page 29] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + according to the standard RRset authentication rules described in + Section 5.3, then apply the NSEC RRsets as follows: + + 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. Since the existence of the authenticated + NSEC RR proves that the owner name exists in the zone, wildcard + expansion could not have been used to match the requested RR owner + name and type. + + o If the requested RR name would appear after an authenticated NSEC + RR 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 [I-D.ietf-dnsext-dnssec-records], then no exact match + for the requested RR name exists 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 exists which + could have been used to generate a positive response. + + To prove 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 + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to 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 + 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 verified NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a verifier MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + + Authentication examples are given in Section Appendix C. + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 30] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +6. IANA Considerations + + [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA + considerations introduced by DNSSEC. The 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 [I-D.ietf-dnsext-ad-is-secure] + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 31] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +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 [I-D.ietf-dnsext-dnssec-intro] for terminology and general + security considerations related to DNSSEC. + + 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 which 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 Section 3.2.2 and Section 4.2 for further discussion. + + DNSSEC introduces a number of denial of service issues. These issues + will also be addressed in a future version of these security + considerations. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +8. Acknowledgements + + This document was created from the input and ideas of several 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 33] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +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. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, 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. + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-07 (work in progress), + October 2003. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-05 (work in progress), + October 2003. + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 34] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +Informative References + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [I-D.ietf-dnsext-delegation-signer] + Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15 (work in progress), + June 2003. + + [I-D.ietf-dnsext-wcard-clarify] + Halley, B. and E. Lewis, "Clarifying the Role of Wild Card + Domains in the Domain Name System", + draft-ietf-dnsext-wcard-clarify-02 (work in progress), + September 2003. + + [I-D.ietf-dnsext-ad-is-secure] + Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD + bit", draft-ietf-dnsext-ad-is-secure-06 (work in + progress), June 2002. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 35] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.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. Expires April 26, 2004 [Page 36] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.ns1.example. ( + 1065745538 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb + 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v + BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff + pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX + LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw + ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ + exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ + dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF + BYpCn/jKFJ7lYnYYGLAUofh/+mo= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + CSB4g+vSxyrfsfycsZwAx2hKhwK/x7GAIY0p + MLBgAA/USiiMben0II4aYf5lybs0NINnFDju + 2Kc78M8t9zBGeJcZCZEs9mKiXhW8WJanvIjg + BwJgWXwAnVnq20TXlsHiuwuhmtrb76/Avl4i + lnX6XA3eeDlQlOTuPe0B91MCuow= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG + krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1 + IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By + yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2 + 2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= ) + 3600 DNSKEY 256 3 1 ( + AQPdhnap0Oj2jUq74g+vel5cukdH+wpzjiH8 + ZOQSOHrw+s3TmbhyqXbZ/j5Uu9p65ARoevvG + yv459dxxZCKZ4wftXe5BUkJvZVf8HnhYW5R+ + kQduVeqGVlkBarL5haKX28Pxvs8tV7CyY/Rd + + + +Arends, et al. Expires April 26, 2004 [Page 37] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + cfnJlZyJcfwY0ETo4P2gntVMERZuJQ== + ) + 3600 DNSKEY 257 3 1 ( + AQOwRqeRkdYUD6UCyJXTaErj0UYLHxOHlhDb + qik1k/j2PJFOZ7GZhc95HnYco611O5VRQ6WQ + pK0dL9eiwcc+gSS2L6V9pWxCfDnEPWFC6eVm + jRZAdAU6gsyNSZCT7rF1lAXdmWcwkaIdNaDL + oNqpieIQd2t+rd/oF8/++DRtzF0toQ== + ) + 3600 RRSIG DNSKEY 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + EtFrBqs8i80Ath+xOtjPHcepV/cjATf2E1fo + +fhSggjw2vAXDY4Sygk2tKZ9Tvhahmw1rRC3 + CnApLvsjQ9qmnYAvkZdMILw9gPx1rBaq9d7H + nt7mPc/LFrO4G9JS6JNwBCnjwcxro8kNYLo6 + 97FCO3y4T7y9Hb80OvCZ36cNdps= ) + 3600 RRSIG DNSKEY 1 1 3600 20031108232541 ( + 20031009232541 23853 example. + VseD0IGDKqJXiZMJnRNuq89ibF5g8VGPmMJS + h/hS8+nu5vLiyEObJcVxfanslAlBQSGHmJsM + AvXpeJUrT/zOyZ8vfy/igMhd25rnSxAD6uhl + 4ohJiiPtFvHgLEvT0QZHizrP4wMvpXvfwn03 + 1/VEFzXZ0rULlTdWjoNzSMIYBwg= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 42939 1 1 ( + 4BA08982E5739A60E02B69409B0927F9524E + 3494 ) + 3600 RRSIG DS 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/ + gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp + zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H + YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c + iHQEOrm7yXIHwnrre1iuzMZn1jY= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + mhov2WXDa2Swk/7/VQoI36e5OKvd/0CmMWdi + +3k/+i7mo9omz854ZBFMLaQzFvaS7Cn//I/H + 7tYSY/fScUrs/UfB7le0DzdocsoaMYtexSS1 + KA7ofbPdYpBHngIGbO5EHaGrqbKGY61fIQ/g + /WvT0KXnoX+v31Oq3VstBoWmizo= ) + 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 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + + + +Arends, et al. Expires April 26, 2004 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a + 0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn + KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n + 3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F + UU/kYIPkm9qpSE3wtELJEq2cNsU= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + jDn/zgIqY5ucajWNW333u+KfxORI55wvnZDs + pCHZQ9ISjWNT7467wUcfJKBaG+alNlCOJExg + z8yUS5NwySlrFtGL/CBCxmrSVioKMMetg7gP + Qb6x5A53OhsQAGT6azS9bdBM2RFbqBkeZkXA + 8mJ/QOldXdH5iPpmZb2Pn47x7V4= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1 + ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC + uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG + qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv + 8gB4wQFPYoozOQYTprwGtIHR2k8= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + W3fFJqdRtmpz9QikpK+v5rL+Y5iNpx5H7X7c + 1yPMlcaS0nhowHGjCPnNbCP28Ktv9I5eqhO1 + N/A75FLTOe9L5Qzetb/C3/ME8D46apKLBEv5 + 0GWsJqTsijj4dAjup60yeLPXTWxIdO6RNdfe + Qd56t0fY79/kd25RzRCFGs2qHXs= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th + 0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM + RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps + TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f + BFydo6dXwQ4WK8OUC6sMCM+OHEg= ) + 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 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58 + +ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF + cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE + HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s + + + +Arends, et al. Expires April 26, 2004 [Page 39] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + Oett68JnQVQq2l/DhWsJSjuIFBQ= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO + KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L + zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a + ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk + o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ + tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4 + mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9 + +huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas + 8Ic8f9zHwZmCUc0wnxX6x+422PM= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + kkYPMaBn4zJM/iQAOO9i81X57MMCQnzk+pch + 6tWUFF/D1ZFZf8QY2MzwDA5Bv/1DluWVbo3x + WjzyUV7fn77k9QKLQseUSXGnpyL2HR1hGfBV + 6ZHAqJc99t5+5vjyiflLtOpA0+Ri46SlQGZf + IZ4X2Ksgn+hpIu77NRQMdmh59M8= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD + b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd + agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/ + +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20 + FxfIqrcIL24dO4Ytdz2ifqvJmuM= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9 + 7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL + 4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH + yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx + vOHmndDhRTDwVCg179qlrEIsOgE= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 1 3 3600 20031108232541 ( + 20031009232541 5742 example. + i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d + NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5 + UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r + uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp + + + +Arends, et al. Expires April 26, 2004 [Page 40] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + IKZXg2219TD4UqJuRATLhxZj2fU= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 1 3 3600 20031108232541 ( + 20031009232541 5742 example. + VTRE+Bu91QK7dBiMshr04tE/I5HCvSrjqDv+ + b4tlUqUqkv4MoxfoceUwavMkdLm9Pi/aYUrS + m6XVGBDAjpDmjivlMKNkME8c0f7oQ3E1CtHS + pPLjTcB9WfxEOzjJJGK5BDDT6A56P4eibLiw + +bNx4OGknGvVqhg9pu5qEWi814s= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 1 4 3600 20031108232541 ( + 20031009232541 5742 example. + yDPXa5Osa4r1AF0AjKWOo87kGNDlnVPmCbIi + MPvBpzJ91d5TFtEZWYJpYv+eGWZCJhK7SsnL + Zbbjthkn7YmX1tReDQhn8aCQ6DyrIU6wZpj5 + ywBx0z3HGcqoYmv+AiFtcYVPxG0elsrakIwG + /e+CPi2yE2c9M+NnwMxhpEFVGRs= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 1 4 3600 20031108232541 ( + 20031009232541 5742 example. + cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj + R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb + w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P + sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa + 66FPTb3/hhrHYkMneBO2Yvfvpj8= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp + Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v + ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd + +N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4 + aI16ggg9/UEWRbvn+7tp2UfMYSw= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + vteMgDuG1ekaSmWlXlwVRoqTXjvZ8kGWCAku + 6Rd3t/wPeVmn3YSbC8+szYRgP8n0HvYzmVYj + qPyC1HCFoqIJIaNLkDEyCSHuhBwpVhyKGJdM + EbJ1P8Yk3w5Szjap6wn7QxcLnr8Df3xUMXnB + AAwDzum3fUKzVM274T9O8ggeXgE= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43 + YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27 + ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+ + AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0 + + + +Arends, et al. Expires April 26, 2004 [Page 41] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + GxlD/3EneV4+IIIv0hekxzpR8Qs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + cKkFJS6Em56M0XCjMma4zFzy5ylHh2ma62oe + yHrqkMYS+QVUuJ8yfAoXoFbok/kDLN3rsCKK + ICJl1dFA3fvJnMejg0JVabQHShO2W1LmWegr + dh251WZQVtJHDRY8/ltYB+GHUuFpZ1CF4m+c + 6EPqS1uLrFpRg3k4BV5y6146nZ8= ) + + 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 which 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 42] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +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 1 3 3600 20031108232541 ( + 20031009232541 5742 example. + i65kcyRnXBHd3ynSNTVKpd71DS85EjGDTi7d + NQR+E4/qtXVaU78hmG4BhyFMVbvyPNpj83z5 + UqpB0baVoSVTSqGMSLxi1T38H8gqPgaYd+4r + uEEXZj5I+s8Cq/1RHXi0yqISqeUGAqMHqryp + IKZXg2219TD4UqJuRATLhxZj2fU= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw + ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ + exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ + dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF + BYpCn/jKFJ7lYnYYGLAUofh/+mo= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + ZW+++XV6FyceT4UtcfbVwcsx3u5tRfFLfAHp + Ji11YMdORJKIJS0uVfu+UuAbe/FImnBmQq4v + ShjQXbLeN9BKLvde4dlMphHSKhp24913/KFd + +N0DMDWGZ/wPoACnqrpn1gDKWdT0l+gkF3y4 + aI16ggg9/UEWRbvn+7tp2UfMYSw= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43 + + + +Arends, et al. Expires April 26, 2004 [Page 43] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27 + ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+ + AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0 + GxlD/3EneV4+IIIv0hekxzpR8Qs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + dJTb+VNXApV4lPaEwlyZxOS17eofL95DJe58 + +ija8iaROK9a9D7bAI7lIKJ/4hSfBN8lIjhF + cpVeuGXCxldaSTOhAU5bg2GZJfxS4onfvBTE + HBf19SZAT9rHBeNJISau8EwDaNBHBweiaC/s + Oett68JnQVQq2l/DhWsJSjuIFBQ= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + VGTTFv2DZ+KN+tm7dzAP1vWGZTLdYn9v/yuQ + tu9rQYAwVWoGq7iiADgLlY0cjR58GCKCGfn4 + mXMyM9mDljOj3VmHxUjRNMgUo+AoIi8Jysr9 + +huB5dgYRKFukcCpxKb1SmXNmSLfdS75gCas + 8Ic8f9zHwZmCUc0wnxX6x+422PM= ) + + +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.ns1.example. ( + 1065745538 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb + 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v + BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff + + + +Arends, et al. Expires April 26, 2004 [Page 44] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX + LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th + 0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM + RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps + TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f + BFydo6dXwQ4WK8OUC6sMCM+OHEg= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG + krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1 + IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By + yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2 + 2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= ) + + ;; Additional + ;; (empty) + + +B.3 No Data Error + + A "NODATA" 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.ns1.example. ( + 1065745538 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb + 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v + + + +Arends, et al. Expires April 26, 2004 [Page 45] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff + pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX + LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + M8q/t6bDqPktgMyfa2LjkEDZiGloFp+I8LaO + KBQt96RzZ9xiXOA/7wE5ZrBrgzfl1eotLn0L + zbOwCwpZf7XoVm/IYCOlIEPj6kJHYvIIzp3a + ZBn7uDx1kInt7qc2AmTpPiWCPtSD5KTBwdLk + o3hJ8fow/NDw5Lsb6RQOSQ5Qxuo= ) + + ;; 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 + ;; + ;; 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 42939 1 1 ( + 4BA08982E5739A60E02B69409B0927F9524E + 3494 ) + a.example. 3600 RRSIG DS 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + Dp6ySNq7SgIfndS4N5wFynmqXXf+WQ7RTAW/ + gC4RPDljbV8WnjZp5P7ip9zsHO9A7hEW8LPp + zEMMzUPfucrSnZ/Jmc60BYIkzkt493QPfz1H + YFRaJ6VyZoF38oN0s/H+a97c+HxAt4TElW+c + iHQEOrm7yXIHwnrre1iuzMZn1jY= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + + + +Arends, et al. Expires April 26, 2004 [Page 46] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +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 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + csgLA1XphdEtY9WiwZOHjcOvGiBShTobK+th + 0xDnKv7ZUxcMRi/g88Z99It+FV/Qufcf5zmM + RxEVOjD1e7an1X/dxD389/6Qzo6NAtSu85ps + TDKZscoaPBr/wYv6PG73F5yfm1hh31nhnD8f + BFydo6dXwQ4WK8OUC6sMCM+OHEg= ) + + ;; 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 which 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 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + Uht2mND0Kzc4hnM4Pq4zM+fjiGTEcCzx+wSD + b2flOHxLQPv75mXfnH1tZv7iwrzQmcyucWsd + + + +Arends, et al. Expires April 26, 2004 [Page 47] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/ + +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20 + FxfIqrcIL24dO4Ytdz2ifqvJmuM= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + KBhJYJ0vFNyMJrt07gvHN9WAOijhXbcikUNw + ZEJxkL+UCv/GFJi1ABGMDowschPkpHIgDEOQ + exaLWGGUrOA5xMHYONWZpkL4rQ3URAKF46VJ + dMg0UTdw3pTD7Lvs8t6Dim46dj9h/QQEgNLF + BYpCn/jKFJ7lYnYYGLAUofh/+mo= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 1 4 3600 20031108232541 ( + 20031009232541 5742 example. + cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj + R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb + w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P + sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa + 66FPTb3/hhrHYkMneBO2Yvfvpj8= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a + 0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn + KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n + 3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F + UU/kYIPkm9qpSE3wtELJEq2cNsU= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + LcSkeCXOOcYClsS9GYJoG/yGeuyaUJrNICK1 + ONN4PEzGWJ7kcF+C4N972x05bPX+wsWszBbC + uP/RqMyNenc8Is25te6hZ8MU7Z0zBDtKeTTG + qz4ir4NZfqvB6moHjcVu6Pwb5KkSb8nAobCv + 8gB4wQFPYoozOQYTprwGtIHR2k8= ) + + +B.7 Wildcard No Data Error + + A "NODATA" 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. + + + + +Arends, et al. Expires April 26, 2004 [Page 48] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.ns1.example. ( + 1065745538 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb + 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v + BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff + pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX + LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 1 4 3600 20031108232541 ( + 20031009232541 5742 example. + cn4aj3I/EQDa+vysa08xMQSnTz8YGtLLzqAj + R8gy8Yqa4uSm7J17NydsWqgJkhlVxD3oBtnb + w/6tDzx45IHcbnVm6UDrc3DVby21AivrsZ8P + sm5Escp1X+qBLGSNAg2K6dlX/i2vut6g3vDa + 66FPTb3/hhrHYkMneBO2Yvfvpj8= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 1 2 3600 20031108232541 ( + 20031009232541 5742 example. + fsk9iik9+gpte3I4tffoXyca5jfuYnLLy7/9 + 7LAVd4KKj9zqSB8f3QD1mjditUK9PGTTtlPL + 4mq8F3T8PIt0pfgV8mPl6GP+bR+iVQEEE1YH + yzR21az4Od5KBYYdsPjZzJnOhzCtgyleAoOx + vOHmndDhRTDwVCg179qlrEIsOgE= ) + + ;; Additional + ;; (empty) + + +B.8 DS Child Zone No Data Error + + A "NODATA" response for a QTYPE=DS query which was mistakenly sent to + a name server for the child zone. + + + +Arends, et al. Expires April 26, 2004 [Page 49] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.ns1.example. ( + 1065745538 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb + 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v + BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff + pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX + LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 1 1 3600 20031108232541 ( + 20031009232541 5742 example. + 10XG3f8uExTPfof30CoonvXSMeqrhrkcN9YG + krhJD4xeVKarTkQMt0dFe66Bbuy961Bv9go1 + IEp0R+sV3B5ldqSKBrcIRsh4QFqQp6IPZ+By + yxyYV25L68I1dkM1JoV7IMFsfcTDPjyl3wv2 + 2LAQ2lyqLBpow5BRR4sAgjZ7Yaw= ) + + ;; Additional + ;; (empty) + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 50] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +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 section Appendix B.1 returned an MX RRset for + "x.w.example.com". The corresponding RRSIG indicates the MX RRset was + signed by an "example" DNSKEY with algorithm 1 and key tag 5742. 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 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 preconfigured root DNSKEY (or DS RR) and moves down the + tree to authenticate the desired "example" DNSKEY RR. Note the + logical order is presented for clarity and an implementation may + choose to construct the authentication as referrals are received or + may choose 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 an preconfigured DNSKEY RR for the + root zone (or a preconfigured DS RR for the root zone). The resolver + checks this preconfigured DNSKEY RR is present in the root DNSKEY + RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset), + this DNSKEY RR has signed the root DNSKEY RRset and the signature + lifetime is valid. If all these 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 the resolver may need to query the root zone to obtain + the root DNSKEY RRset and/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 + + + +Arends, et al. Expires April 26, 2004 [Page 51] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + matching "example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "example" DNSKEY RRset and the signature lifetime + is valid. If all 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 1 and has a key tag of 5742. This DNSKEY + is used to authenticated the RRSIG included in the response. If + multiple "example" DNSKEY RRs have algorithm 1 and key tag of 5742, + then each DNSKEY RR is tried and the answer is authenticated if + either DNSKEY RR validates the signature as described above. + +C.2 Name Error + + The query in section Appendix B.2 returned NSEC RRs that prove 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 section Appendix B.3 returned an NSEC RR that proves 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 section 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 this DNSKEY + RR has signed the "a.example" DNSKEY RRset and 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 section 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 + + + +Arends, et al. Expires April 26, 2004 [Page 52] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + identical to that of the MX RRset discussed above. + +C.6 Wildcard Expansion + + The query in section Appendix B.6 returned an answer that was + produced as a result of wildcard expansion. The RRset expanded as + the similar to The corresponding RRSIG indicates the MX RRset was + signed by an "example" DNSKEY with algorithm 1 and key tag 5742. 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 2 indicates the answer the result of + wildcard expansion since 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 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 section Appendix B.7 returned NSEC RRs that prove 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 section 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 the answer is + from the child . Queries for the "example" DS RRset should be sent + to the parent servers ("root" servers). + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 53] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires April 26, 2004 [Page 54] + +Internet-Draft DNSSEC Protocol Modifications October 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 55] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt deleted file mode 100644 index 23475b80c0..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt +++ /dev/null @@ -1,1848 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 26, 2003 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - February 25, 2003 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-03 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 26, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describes 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 - - - -Arends, et al. Expires August 26, 2003 [Page 1] - -Internet-Draft DNSSEC Resource Records February 2003 - - - KEY, DS, SIG, and NXT resource records. The purpose and format of - each resource record is described in detail and an example of each - resource record is given. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. The KEY Resource Record . . . . . . . . . . . . . . . . . . 6 - 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . . 6 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.5 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . . 7 - 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . . 7 - 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . . 7 - 3. The SIG Resource Record . . . . . . . . . . . . . . . . . . 9 - 3.1 SIG RDATA Wire Format . . . . . . . . . . . . . . . . . . . 9 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 - 3.2 The SIG RR Presentation Format . . . . . . . . . . . . . . . 12 - 3.3 SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13 - 4. The NXT Resource Record . . . . . . . . . . . . . . . . . . 15 - 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 - 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15 - 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16 - 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . . 16 - 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 18 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19 - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19 - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19 - 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . . 19 - - - -Arends, et al. Expires August 26, 2003 [Page 2] - -Internet-Draft DNSSEC Resource Records February 2003 - - - 5.3 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20 - 6. Canonical Form and Order of Resource Records . . . . . . . . 21 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 24 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 - Normative References . . . . . . . . . . . . . . . . . . . . 26 - Informative References . . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 29 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 29 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 30 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 31 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 32 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 3] - -Internet-Draft DNSSEC Resource Records February 2003 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: KEY, SIG, NXT, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - ASCII representation. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [1] and RFC1035 [2]. - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication the Domain Name System (DNS). An - introduction to DNSSEC and definition of common terms can be found in - [10]. A description of DNS protocol modifications can be found in - [11]. This document defines the DNSSEC resource records. - -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 RFC 2119 [5]. - -1.3 Editors Notes - -1.3.1 Open Technical Issues - - The NXT section (Section 4) may be updated in the next version if - DNSSEC-Opt-In [13] becomes part of DNSSEC. - - The cryptographic algorithm types (Appendix A) requires input from - the working group. The DSA algorithm was moved to OPTIONAL. This - had strong consensus in workshops and various discussions and a - separate internet draft solely to move DSA from MANDATORY to OPTIONAL - seemed excessive. This draft solicits input on that proposed change. - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - - - -Arends, et al. Expires August 26, 2003 [Page 4] - -Internet-Draft DNSSEC Resource Records February 2003 - - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 5] - -Internet-Draft DNSSEC Resource Records February 2003 - - -2. The KEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in KEY - resource records and are used in the DNSSEC authentication process - described in [11]. In a typical example, a zone signs its - authoritative RRsets using a private key and stores the corresponding - public key in a KEY RR. A resolver can then use these signatures to - authenticate RRsets from the zone. - - The KEY RR may also be used to store public keys associated with - other DNS operations such as TKEY [15]. In all cases, the KEY RR - plays a special role in secure DNS resolution and DNS message - processing. The KEY RR is not intended as a record for storing - arbitrary public keys. The KEY RR MUST NOT be used to store - certificates or public keys that do not directly relate to the DNS - infrastructure. Examples of certificates and public keys that MUST - NOT be stored in the KEY RR include X.509 certificates, IPSEC public - keys, and SSH public keys. - - The Type value for the KEY RR type is 25. - - The KEY RR is class independent. - - There are no special TTL requirements on the KEY record. - -2.1 KEY RDATA Wire Format - - The RDATA for a KEY 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 KEY record holds a DNS zone key and the KEY's owner name - MUST be the name of a zone. If bit 7 has value 0, then the KEY - record holds some other type of DNS public key, such as a public key - - - -Arends, et al. Expires August 26, 2003 [Page 6] - -Internet-Draft DNSSEC Resource Records February 2003 - - - used by TKEY. - - Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of - the KEY RR, and MUST be ignored upon reception. - - Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this - by allocating bit 15 as the KSK bit. - -2.1.2 The Protocol Field - - The Protocol Field MUST have value 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. - -2.1.5 Notes on KEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with an earlier version of the KEY record. - -2.2 The KEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field is represented as an unsigned decimal integer with a - value of either 0 or 256. - - The Protocol Field is represented as an unsigned decimal integer with - a value of 3. - - The Algorithm field is represented either as an unsigned decimal - integer or as an algorithm mnemonic as specified in Appendix A.1. - - 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 [3] Section 5.2. - -2.3 KEY RR Example - - The following KEY RR stores a DNS zone key for example.com. - - - - -Arends, et al. Expires August 26, 2003 [Page 7] - -Internet-Draft DNSSEC Resource Records February 2003 - - - example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl - +BBZH4b/0PY1kxkmvHjcZc8nokfzj31 - GajIQKY+5CptLr3buXA10hWqTkF7H6R - foRqXQeogmMHfpftf6zMv1LyBUgia7z - a6ZEzOJBOztyvhjL742iU/TpPSEDhm2 - SNKLijfUppn1UaNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (KEY). 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 [8]. The remaining text is a - base 64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 8] - -Internet-Draft DNSSEC Resource Records February 2003 - - -3. The SIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Signatures are stored in SIG resource - records and are used in the DNSSEC authentication process described - in [11]. In a typical example, a zone signs its authoritative RRsets - using a private key and stores the corresponding signatures in SIG - RRs. A resolver can then use these SIG RRs to authenticate RRsets - from the zone. - - A SIG record contains the signature for an RRset with a particular - name, class, and type. The SIG RR specifies a validity interval for - the signature and uses the Algorithm, the Signer's Name, and the Key - Tag to identify the public key (KEY RR) that can be used to verify - the signature. - - The SIG RR may cover a transaction instead of an RRset. In this - case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear - in any zone, and its use and processing are outside the scope of this - document. Please see [7] for further details. - - The Type value for the SIG RR type is 24. - - The SIG RR MUST have the same class as the RRset it covers. - - The SIG RR TTL value SHOULD match the TTL value of the RRset it - covers. - -3.1 SIG RDATA Wire Format - - The RDATA for a SIG 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 | / - - - -Arends, et al. Expires August 26, 2003 [Page 9] - -Internet-Draft DNSSEC Resource Records February 2003 - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the type of the RRset which is - covered by this SIG record. - - If Type Covered field has a value of 0, the record is referred to as - a transaction signature; please see [7] for further details. - -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 SIG - RR owner name. It is included to handle signatures associated with - wildcard owner names. - - To validate a signature, the validator requires the original owner - name that was used when the signature was created. 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 need to reconstruct the original owner name - in order to validate the signature. [11] describes how to use the - Labels field to reconstruct the original owner name. - - The value of the Label field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - present). The value of the Label field MUST be less than or equal to - the number of labels in the SIG owner name. For example, - "www.example.com." has a Label field value of 3, and "*.example.com." - has a Label field value of 2. Root (".") has a Label field value of - 0. - - Note that, although the wildcard label is not included in the count - stored in the Label field of the SIG RR, the wildcard label is part - of the RRset's owner name when generating or verifying the signature. - - - -Arends, et al. Expires August 26, 2003 [Page 10] - -Internet-Draft DNSSEC Resource Records February 2003 - - -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 resolver requires the original TTL. [11] describes how - to use the Original TTL field value to reconstruct the original TTL. - - The Original TTL value MUST be greater than or equal to the TTL value - of the SIG record itself. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The SIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - Signature Expiration and Inception field values are in POSIX.1 time - format, 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 which can be expressed by this format without - wrapping is approximately 136 years. A SIG RR can have an Expiration - field value which 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 [4]. 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 KEY RR that - validates this signature. The process of calculating the Key Tag - value is given in Appendix B. - -3.1.7 The Signer's Name Field - - The Signer's Name field value identifies the owner name of the KEY RR - used to authenticate this signature. The Signer's Name field MUST - contain the name of the zone of the covered RRset, unless the Type - Covered field value is 0. A sender MUST NOT use DNS name compression - on the Signer's Name field when transmitting a SIG RR. A receiver - which receives a SIG RR containing a compressed Signer's Name field - SHOULD decompress the field value. - - - -Arends, et al. Expires August 26, 2003 [Page 11] - -Internet-Draft DNSSEC Resource Records February 2003 - - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature which covers - the SIG RDATA (excluding the Signature field) and the RRset specified - by the SIG owner name, SIG class, and SIG Type Covered field. - -3.1.8.1 Signature Calculation - - A signature covers the SIG RDATA (excluding the Signature Field) and - covers the RRset specified by the SIG owner name, SIG class, and SIG - Type Covered field. The RRset is in canonical form (see Section 6) - and the set RR(1),...RR(n) is signed as follows: - - signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - SIG_RDATA is the wire format of the SIG RDATA fields with - the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | class | type | 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 SIG RR; - - Each RR MUST have the same class as the SIG RR; - - Each RR in the RRset MUST have the RR type listed in the - SIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the SIG - 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. - - -3.2 The SIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field value is represented either as an unsigned - - - -Arends, et al. Expires August 26, 2003 [Page 12] - -Internet-Draft DNSSEC Resource Records February 2003 - - - decimal integer or as the mnemonic for the covered RR type. - - The Algorithm field value is represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Labels field value is represented as an unsigned decimal integer. - - The Original TTL field value is represented as an unsigned decimal - integer. - - The Signature Inception Time and Expiration Time field values are - represented in the form YYYYMMDDHHmmSS in UTC, where: - - YYYY is the year (0000-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 hours notation (00-23); - - mm is the minute (00-59); - - SS is the second (00-59). - - The Key Tag field is represented as an unsigned decimal integer. - - The Signer's Name field value is represented as a fully qualified - domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding see [3] Section 5.2. - -3.3 SIG RR Example - - The following a SIG RR stores the signature for the A RRset of - host.example.com: - - host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - - - -Arends, et al. Expires August 26, 2003 [Page 13] - -Internet-Draft DNSSEC Resource Records February 2003 - - - The first four fields specify the owner name, TTL, Class, and RR type - (SIG). 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 SIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - 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 SIG RR owner name, class, and Type Covered - indicate that this SIG 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 this signature can be - authenticated using an example.com zone KEY RR whose algorithm is 5 - and key tag is 2642. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 14] - -Internet-Draft DNSSEC Resource Records February 2003 - - -4. The NXT Resource Record - - The NXT resource record lists two separate things: the owner name of - the next authoritative RRset in the canonical ordering of the zone, - and the set of RR types present at the NXT RR's owner name. The - complete set of NXT RRs in a zone both indicate 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 [11]. - - The type value for the NXT RR is 30. - - The NXT RR is class independent. - -4.1 NXT RDATA Wire Format - - The RDATA of the NXT 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 Map / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next - authoritative RRset in the canonical ordering of the zone; see - Section 6.1 for an explanation of canonical ordering. The value of - the Next Domain Name field in the last NXT record in the zone is the - name of the zone apex (the owner name name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NXT RR. A receiver which receives an NXT - RR containing a compressed Next Domain Name field SHOULD decompress - the field value. - - Owner names of non-authoritative RRsets (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 Map Field - - The Type Bit Map field identifies the RRset types which exist at the - NXT RR's owner name. - - - -Arends, et al. Expires August 26, 2003 [Page 15] - -Internet-Draft DNSSEC Resource Records February 2003 - - - Each bit in the Type Bit Map field corresponds to an RR type. Bit 1 - corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), - and so forth. If a bit is set to 1, it indicates that an RRset of - that type is present for the NXT's owner name. If a bit is set to 0, - it indicates that no RRset of that type present for the NXT's owner - name. - - Bit 1 MUST NOT indicate glue address records. - - Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can - never appear in zone data. - - Trailing zero octets MUST be omitted. The length of the Type Bit Map - field varies, and is determined by the type code with the largest - numerical value among the set of RR types present at the NXT RR's - owner name. Trailing zero octets not specified MUST be interpreted - as zero octets. - - The above Type Bit Map format MUST NOT be used when an RR type code - with numerical value greater than 127 is present. - - Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A - value of 0 in bit 0 denotes the format described above, therefore bit - 0 MUST have a value of 0. The format and meaning of a Type Bit Map - with a value of 1 in bit 0 is undefined. - -4.1.3 Inclusion of Wildcard Names in NXT 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 purposes of generating NXT RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - [11] describes the impact of wildcards on authenticated denial of - existence. - -4.2 The NXT 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 Map field is represented either as a sequence of RR type - mnemonics or as a sequence of unsigned decimal integers denoting the - RR type codes. - -4.3 NXT RR Example - - The following NXT RR identifies the RRsets associated with - - - -Arends, et al. Expires August 26, 2003 [Page 16] - -Internet-Draft DNSSEC Resource Records February 2003 - - - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT - - The first four text fields specify the name, TTL, Class, and RR type - (NXT). The entry host.example.com. is the next authoritative name - after alfa.example.com. (in canonical order). The A, MX, SIG and - NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated - with the name alfa.example.com. - - Note the NXT record can be used for authenticated denial of - existence. If the example NXT record were authenticated, it could be - used to prove that beta.example.com. does not exist, or could be - used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - [11] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 17] - -Internet-Draft DNSSEC Resource Records February 2003 - - -5. The DS Resource Record - - The DS Resource Record refers to a KEY RR and is used in the DNS KEY - authentication process. A DS RR refers to a KEY RR by storing the - key tag, algorithm number, and a digest of KEY RR. Note that while - the digest should be sufficient to identify the 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 KEY RR to which the DS record points. The key - authentication process is described in [11]. - - The DS RR and its corresponding KEY 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 - "example.com" zone (the child zone). The corresponding KEY 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 [11]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - There are no special TTL requirements on the DS resource record. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet - Algorithm field, a one 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 KEY RR referred to by the - DS record. The KEY RR MUST be a zone key. The KEY RR Flags MUST - have Flags bit 7 set to value 1. - - - -Arends, et al. Expires August 26, 2003 [Page 18] - -Internet-Draft DNSSEC Resource Records February 2003 - - - The Key Tag used by the DS RR is identical to the Key Tag used by the - SIG RR and Appendix B describes how to compute a Key Tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the KEY RR referred - to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by the SIG RR and KEY RR. Appendix A.1 lists the - algorithm number types. - -5.1.3 The Digest Type Field - - The DS RR refers to a KEY RR by including a digest of that KEY RR. - The Digest Type field identifies the algorithm used to construct the - digest and Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record refers to a KEY RR by including a digest of that KEY - RR. The Digest field holds the digest. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the KEY RR (abbreviated below as "key - RR name") with the KEY RDATA, and then applying the digest algorithm. - - digest = digest_algorithm( KEY RR name | KEY RDATA); - - "|" denotes concatenation - - KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key. - - - The size of the digest may vary depending on the digest algorithm and - KEY RR size. Currently, the defined digest algorithm is SHA-1, which - produces a 20 octet digest. - -5.2 The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field is represented as an unsigned decimal integer. - - The Algorithm field is represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field is represented as an unsigned decimal integer. - - - -Arends, et al. Expires August 26, 2003 [Page 19] - -Internet-Draft DNSSEC Resource Records February 2003 - - - The Digest is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.3 DS RR Example - - The following example shows a KEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN KEY 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." KEY RR, and value 5 denotes the algorithm used - by this "dskey.example.com." KEY RR. The value 1 is the algorithm - used to construct the digest, and the rest of the RDATA text is the - digest in hexadecimal. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 20] - -Internet-Draft DNSSEC Resource Records February 2003 - - -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 NXT name chain. A canonical RR form and ordering - within an RRset are required to construct and verify SIG RRs. - -6.1 Canonical DNS Name Order - - For 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 upper case - US-ASCII letters are treated as if they were lower case US-ASCII - letters. - - 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 - 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 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 - - - -Arends, et al. Expires August 26, 2003 [Page 21] - -Internet-Draft DNSSEC Resource Records February 2003 - - - 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, or A6, all uppercase US-ASCII letters in the DNS - names within the RDATA of the RR 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 - authoritative zone containing the RR or the Original TTL field of - the covering SIG RR. - - Editors' Note: the above definition sacrifices readability for an - attempt at precision. Please send better text! - -6.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with same owner name, same class, - and same type are sorted by sorting the canonical forms of the RRs - while treating the RDATA portion of the canonical form of each RR as - a left justified unsigned octet sequence. The absence of an octet - sorts before the zero octet. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 22] - -Internet-Draft DNSSEC Resource Records February 2003 - - -7. IANA Considerations - - This document introduces one new IANA consideration. RFC 2535 [14] - created an IANA registry for DNS Security Algorithm Numbers. This - document re-assigns DNS Security Algorithm Number 252 to be - "reserved". This value is no longer available for assignment by - IANA. - - This document clarifies the use of existing DNS resource records. - For completeness, the IANA considerations from the previous documents - which defined these resource records are summarized below. No IANA - changes are made by this document other than the one change described - in the first paragraph of this section. - - [14] updated the IANA registry for DNS Resource Record Types, and - assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs, - respectively. [9] assigned DNS Resource Record Type 43 to DS. - - [14] created an IANA registry for DNSSEC Resource Record Algorithm - Numbers. Values to 1-4, and 252-255 were assigned by [14]. Value 5 - was assigned by [8]. Value 252 is re-assigned by this document, as - noted above. - - [9] created an IANA registry for DNSSEC DS Digest Types, and assigned - value 0 to reserved and value 1 to SHA-1. - - [14] created an IANA Registry for KEY Protocol Values, but [16] re- - assigned all assigned values other than 3 to reserved and closed this - IANA registry. The registry remains closed, and all KEY records are - required to have Protocol Octet value of 3. - - The Flag bits in the KEY RR are not assigned by IANA, and there is no - IANA registry for these flags. All changes to the meaning of the KEY - RR Flag bits require a standards action. - - The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT - RR can only be assigned by a standards action. - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 23] - -Internet-Draft DNSSEC Resource Records February 2003 - - -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. The use of these records is specified in a - separate document, and security considerations related to the use - these resource records are discussed in that document. - - The DS record points to a KEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing KEY RR, but it is theoretically possible for an - attacker to generate a KEY that matches all the DS fields. The - probability of constructing such a matching KEY 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 which 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 KEY resource records efficiently, - but it does not uniquely identify a single KEY resource record. It - is possible for two distinct KEY RRs to have the same owner name, the - same algorithm type, and the same key tag. An implementation which - used only the key tag to select a KEY RR might select the wrong - public key in some circumstances. Implementations MUST NOT assume - the key tag is unique public key identifier; this is clearly stated - in Appendix B. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 24] - -Internet-Draft DNSSEC Resource Records February 2003 - - -9. Acknowledgments - - This document was created from the input and ideas of several members - of the DNS Extensions Working Group and working group mailing list. - The co-authors of this draft would like to express their thanks for - the comments and suggestions received during the revision of these - security extension specifications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 25] - -Internet-Draft DNSSEC Resource Records February 2003 - - -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] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail - Extensions) Part One: Mechanisms for Specifying and Describing - the Format of Internet Message Bodies", RFC 1521, September - 1993. - - [4] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [7] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - - [9] Gudmundsson, O., "Delegation Signer Resource Record", draft- - ietf-dnsext-delegation-signer-12 (work in progress), December - 2002. - - [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "DNS Security Introduction and Requirements", draft-ietf- - dnsext-dnssec-intro-05 (work in progress), February 2003. - - [11] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-protocol-00 (work in progress), - Februari 2003. - - [12] Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf- - dnsext-unknown-rrs-04 (work in progress), September 2002. - - [13] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft- - ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003. - - - - - -Arends, et al. Expires August 26, 2003 [Page 26] - -Internet-Draft DNSSEC Resource Records February 2003 - - -Informative References - - [14] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC - 2930, September 2000. - - [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Software Consortium - 40 Gavin Circle - Reading, MA 01867 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - -Arends, et al. Expires August 26, 2003 [Page 27] - -Internet-Draft DNSSEC Resource Records February 2003 - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 28] - -Internet-Draft DNSSEC Resource Records February 2003 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The KEY, SIG, 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. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - An "Algorithm Number" field in the KEY, SIG, and DS resource record - types identifies the cryptographic algorithm used by the resource - record. Algorithm specific formats are described in separate - documents. The following table lists the currently defined algorithm - types and provides references to their supporting documents: - - VALUE Algorithm RFC STATUS - 0 Reserved - - - 1 RSA/MD5 RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman RFC 2539 OPTIONAL - 3 DSA RFC 2536 OPTIONAL - 4 elliptic curve TBA OPTIONAL - 5 RSA/SHA1 RFC 3110 MANDATORY - 6-251 available for assignment - - 252 reserved - - 253 private see below OPTIONAL - 254 private see below OPTIONAL - 255 reserved - - - - -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 KEY RR - and the signature area in the SIG RR begin with a wire encoded domain - name. Only local domain name compression is permitted. 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. - - - - -Arends, et al. Expires August 26, 2003 [Page 29] - -Internet-Draft DNSSEC Resource Records February 2003 - - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the KEY RR - and the signature area in the SIG 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 30] - -Internet-Draft DNSSEC Resource Records February 2003 - - -Appendix B. Key Tag Calculation - - The Key Tag field in the SIG 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 KEY record. Both the SIG and DS resource records have - corresponding KEY records. The Key Tag field in the SIG and DS - records can be used to help select the corresponding KEY RR - efficiently when more than one candidate KEY 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 KEY 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 KEY record. Implementations MUST NOT assume - that the key tag uniquely identifies a KEY RR. - - The key tag is the same for all KEY algorithm types except algorithm - 1 (please see Appendix B.1 for the definition of the key tag for - algorithm 1). For all algorithms other than algorithm 1, the key tag - is defined to be the output which would be generated by running the - ANSI C function shown below with the RDATA portion of the KEY RR 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 below 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 KEY RR. The code is written for - clarity, not efficiency. - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 31] - -Internet-Draft DNSSEC Resource Records February 2003 - - - /* - * 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 KEY 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; - } - - -B.1 Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently than the - key tag for all other algorithms, for historical reasons. For a KEY - 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. Expires August 26, 2003 [Page 32] - -Internet-Draft DNSSEC Resource Records February 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 26, 2003 [Page 33] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-05.txt new file mode 100644 index 0000000000..c726d7ff1f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-05.txt @@ -0,0 +1,2016 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: April 26, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + October 27, 2003 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-05 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 26, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes 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 + + + +Arends, et al. Expires April 26, 2004 [Page 1] + +Internet-Draft DNSSEC Resource Records October 2003 + + + 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6 + 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7 + 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7 + 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9 + 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 + 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 12 + 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15 + 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 + 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 16 + 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 16 + 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 16 + 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 19 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19 + + + +Arends, et al. Expires April 26, 2004 [Page 2] + +Internet-Draft DNSSEC Resource Records October 2003 + + + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19 + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2 Processing of DS RRs When Validating Responses . . . . . . . 19 + 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 20 + 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Canonical Form and Order of Resource Records . . . . . . . . 21 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 + Normative References . . . . . . . . . . . . . . . . . . . . 27 + Informative References . . . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 31 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 31 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 31 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 32 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 33 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 34 + Intellectual Property and Copyright Statements . . . . . . . 35 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 3] + +Internet-Draft DNSSEC Resource Records October 2003 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + ASCII representation. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs + that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 + [RFC2308]. + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication and data integrity to the Domain Name + System (DNS). An introduction to DNSSEC and definition of common + terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description + of DNS protocol modifications can be found in + [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC + resource records. + +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 RFC 2119 [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Open Technical Issues + + The cryptographic algorithm types (Appendix A) requires input from + the working group. The DSA algorithm was moved to OPTIONAL. This + had strong consensus in workshops and various discussions and a + separate Internet-Draft solely to move DSA from MANDATORY to OPTIONAL + seemed excessive. This draft solicits input on that proposed change. + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + + +Arends, et al. Expires April 26, 2004 [Page 4] + +Internet-Draft DNSSEC Resource Records October 2003 + + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + +1.3.3 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 5] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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 [I-D.ietf-dnsext-dnssec-protocol]. For example, a zone + signs its authoritative RRsets using a private key and stores the + corresponding public key in a DNSKEY RR. A resolver can then use + these signatures to authenticate RRsets from the zone. + + 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, such as a + public key used by TKEY. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1, + then the DNSKEY record holds a key intended for use as a secure entry + + + +Arends, et al. Expires April 26, 2004 [Page 6] + +Internet-Draft DNSSEC Resource Records October 2003 + + + point. This flag is only intended to be to a hint to zone signing or + debugging software as to the intended use of this DNSKEY record; + security-aware resolvers MUST NOT alter their behavior during the + signature validation process in any way based on the setting of this + bit. + + 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 reception. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3 and MUST be treated as invalid + during signature verification if 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 itself. + +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 + with a value of 0, 256, or 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. + + 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 [RFC1521] Section 5.2. + + + + + +Arends, et al. Expires April 26, 2004 [Page 7] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 8] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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 [I-D.ietf-dnsext-dnssec-protocol]. A + security-aware resolver 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 + resolver can use to verify the signature. + + 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 SHOULD match the TTL value of the RRset + it covers. + +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 / + / / + + + +Arends, et al. Expires April 26, 2004 [Page 9] + +Internet-Draft DNSSEC Resource Records October 2003 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset which is + covered by this RRSIG record. + +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 from it a + verifier can determine if 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 need to reconstruct the original owner name in order + to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] + describes how to use the Labels field to reconstruct the original + owner name. + + The value of the Label field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Label field MUST be less than or equal to + the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Label field value of 3, and "*.example.com." + has a Label field value of 2. Root (".") has a Label field value of + 0. + + Note that, although the wildcard label is not included in the count + stored in the Label field of the RRSIG RR, the wildcard label is part + of the RRset's owner name when generating or verifying the signature. + + + + + +Arends, et al. Expires April 26, 2004 [Page 10] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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 resolver requires the original TTL. + [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original + TTL field value to reconstruct the original TTL. + +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. + + Signature Expiration and Inception field values are in POSIX.1 time + format: 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 which can be expressed by this format without + wrapping is approximately 136 years. An RRSIG RR can have an + Expiration field value which 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. 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 which a security-aware resolver should 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. A receiver + which receives an RRSIG RR containing a compressed Signer's Name + field SHOULD decompress the field value. + + + + + +Arends, et al. Expires April 26, 2004 [Page 11] + +Internet-Draft DNSSEC Resource Records October 2003 + + +3.1.8 The Signature Field + + The Signature field contains the cryptographic signature which covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. + +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 field. The RRset is in canonical form + (see Section 6) and the set RR(1),...RR(n) is signed as follows: + + 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 | class | type | 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. + + +3.2 The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + + + +Arends, et al. Expires April 26, 2004 [Page 12] + +Internet-Draft DNSSEC Resource Records October 2003 + + + The Type Covered field value MUST be represented either as an + unsigned decimal integer or as the mnemonic for the covered RR type. + + 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. + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Inception Time and Expiration Time field values MUST be + represented in the form YYYYMMDDHHmmSS in UTC, where: + + YYYY is the year (0000-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 hours notation (00-23); + + mm is the minute (00-59); + + SS is the second (00-59). + + 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. For a + definition of Base64 encoding see [RFC1521] Section 5.2. + +3.3 RRSIG RR Example + + The following an 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= ) + + + +Arends, et al. Expires April 26, 2004 [Page 13] + +Internet-Draft DNSSEC Resource Records October 2003 + + + 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 + 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 + indicate 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 this signature can be + authenticated using an example.com zone DNSKEY RR whose algorithm is + 5 and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 14] + +Internet-Draft DNSSEC Resource Records October 2003 + + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the owner name of + the next authoritative RRset in the canonical ordering of the zone, + and the set of RR types present at the NSEC RR's owner name. The + complete set of NSEC RRs in a zone both indicate 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 + [I-D.ietf-dnsext-dnssec-protocol]. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR has no special TTL requirements. + +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 Map / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next + authoritative RRset in the canonical ordering of the zone; 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). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. A receiver which receives an + NSEC RR containing a compressed Next Domain Name field SHOULD + decompress the field value. + + Owner names of RRsets not authoritative for the given zone (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. + + + + + +Arends, et al. Expires April 26, 2004 [Page 15] + +Internet-Draft DNSSEC Resource Records October 2003 + + +4.1.2 The Type Bit Map Field + + The Type Bit Map field identifies the RRset types which exist at the + NSEC RR's owner name. + + Each bit in the Type Bit Map field corresponds to an RR type. Bit 1 + corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), + and so forth. If a bit is set to 1, it indicates that an RRset of + that type is present for the NSEC RR's owner name. If a bit is set to + 0, it indicates that no RRset of that type present for the NSEC RR's + owner name. + + A zone MUST NOT generate an NSEC RR for any domain name that only + holds glue records. + + Bits representing pseudo-RR types MUST be set to 0, since they do not + appear in zone data. If encountered, they must be ignored upon + reading. + + Trailing zero octets MUST be omitted. The length of the Type Bit Map + field varies, and is determined by the type code with the largest + numerical value 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 above Type Bit Map format MUST NOT be used when an RR type code + with numerical value greater than 127 is present. + + Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A + value of 0 in bit 0 denotes the format described above, therefore bit + 0 MUST have a value of 0. The format and meaning of a Type Bit Map + with a value of 1 in bit 0 is undefined. + +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 purposes of generating NSEC RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [I-D.ietf-dnsext-dnssec-protocol] 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. + + + + +Arends, et al. Expires April 26, 2004 [Page 16] + +Internet-Draft DNSSEC Resource Records October 2003 + + + The Type Bit Map field is represented either as a sequence of RR type + mnemonics or as a sequence of unsigned decimal integers denoting the + RR type codes. + +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 + + 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 and NSEC + mnemonics indicate there are A, MX, RRSIG and NSEC RRsets associated + with the name alfa.example.com. + + Assuming that the resolver can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or could + be used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + [I-D.ietf-dnsext-dnssec-protocol]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 17] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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 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 + [I-D.ietf-dnsext-dnssec-protocol]. + + 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 + "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 + [I-D.ietf-dnsext-dnssec-protocol]. + + 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 one + octet Algorithm field, a one 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 / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 18] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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. + + 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. + +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 field holds the digest. + + 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. Currently, 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 + + + +Arends, et al. Expires April 26, 2004 [Page 19] + +Internet-Draft DNSSEC Resource Records October 2003 + + + have Flags bit 7 set to value 1. If the key tag does not indicate a + DNSSEC zone key, the DS RR (and 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. + + 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. + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 20] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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 to construct and verify RRSIG RRs. + +6.1 Canonical DNS Name Order + + For 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 upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + 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 + 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 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 + + + +Arends, et al. Expires April 26, 2004 [Page 21] + +Internet-Draft DNSSEC Resource Records October 2003 + + + 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. + + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with the same owner name, class, + and type are sorted by RDATA: first by RDATA length, shortest to + longest, then by the canonical form of the RDATA itself in the case + of length equality, treating the RDATA portion of the canonical form + of each RR as a left justified unsigned octet sequence. The absence + of an octet sorts before a zero octet. + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 22] + +Internet-Draft DNSSEC Resource Records October 2003 + + +7. IANA Considerations + + This document introduces no new IANA considerations, because 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 which are (or once were) related to DNSSEC. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. + [I-D.ietf-dnsext-delegation-signer] assigned DNS Resource Record + Type 43 to DS. [I-D.ietf-dnsext-dnssec-2535typecode-change] + assigned types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, + respectively. [I-D.ietf-dnsext-dnssec-2535typecode-change] 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]. + + SIG(0) 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. + [I-D.ietf-dnsext-dnssec-2535typecode-change] renamed this registry + to "SIG(0) Algorithm Numbers" to indicate that this registry is + now used only by the "SIG(0)" transaction security protocol + described in [RFC2931]. + + DNS Security Algorithm Numbers: + [I-D.ietf-dnsext-dnssec-2535typecode-change] created a new "DNS + Security Algorithm Numbers" registry, assigned initial values to + algorithms 2 (Diffie-Hellman), 3 (DSA/SHA-1), 5 (RSA/SHA-1), 253 + (private algorithms - domain name) and 254 (private algorithms - + OID), and reserved values 0, 1, and 255. As stated in + [I-D.ietf-dnsext-dnssec-2535typecode-change], value 4 and values + 6-252 are available for assignment by IETF Standards Action. + + [I-D.ietf-dnsext-delegation-signer] 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] re-assigned all assigned 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 Protocol Octet value of 3. + + + + + + +Arends, et al. Expires April 26, 2004 [Page 23] + +Internet-Draft DNSSEC Resource Records October 2003 + + + Flag bits in the KEY and DNSKEY RRs: The Flag bits in the KEY and + DNSKEY RRs are not assigned by IANA, and there is no IANA registry + for these flags. All changes to the meaning of the Flag bits in + the KEY and DNSKEY RRs require a standards action. + + Bit zero of Type Bit Map in NSEC RRs: The meaning of a value of 1 in + bit zero of the Type Bit Map of an NSEC RR can only be assigned by + a standards action. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 24] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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. The use of these records is specified in a + separate document, and security considerations related to the use + these resource records are discussed in that document. + + The DS record points to a DNSKEY RR 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 such 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 which 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 which used only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 25] + +Internet-Draft DNSSEC Resource Records October 2003 + + +9. Acknowledgments + + This document was created from the input and ideas of several 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 26] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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. + + [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1521, September 1993. + + [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. + + [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. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [I-D.ietf-dnsext-delegation-signer] + Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15 (work in progress), + June 2003. + + + +Arends, et al. Expires April 26, 2004 [Page 27] + +Internet-Draft DNSSEC Resource Records October 2003 + + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-07 (work in progress), + October 2003. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in + progress), October 2003. + + [I-D.ietf-dnsext-keyrr-key-signing-flag] + Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", + draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in + progress), October 2003. + + [I-D.ietf-dnsext-dnssec-2535typecode-change] + Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 + (work in progress), October 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 28] + +Internet-Draft DNSSEC Resource Records October 2003 + + +Informative References + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + + + + +Arends, et al. Expires April 26, 2004 [Page 29] + +Internet-Draft DNSSEC Resource Records October 2003 + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 30] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + An "Algorithm Number" field in the DNSKEY, RRSIG, and DS resource + record types identifies the cryptographic algorithm used by the + resource record. Algorithm specific formats are described in + separate documents. The following table lists the currently defined + algorithm types and provides references to their supporting + documents: + + VALUE Algorithm [mnemonic] RFC STATUS + 0 Reserved - - + 1 RSA/MD5 [RSA/MD5] RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman [DH] RFC 2539 OPTIONAL + 3 DSA [DSA] RFC 2536 OPTIONAL + 4 elliptic curve [ECC] TBA OPTIONAL + 5 RSA/SHA1 [RSA/SHA1] RFC 3110 MANDATORY + 6-251 available for assignment - + 252 reserved - + 253 private [PRIVATE_DNS] see below OPTIONAL + 254 private [PRIVATE_OID] see below OPTIONAL + 255 reserved - - + + +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. + + + + +Arends, et al. Expires April 26, 2004 [Page 31] + +Internet-Draft DNSSEC Resource Records October 2003 + + + 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 - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 32] + +Internet-Draft DNSSEC Resource Records October 2003 + + +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. + + 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. + + + +Arends, et al. Expires April 26, 2004 [Page 33] + +Internet-Draft DNSSEC Resource Records October 2003 + + + */ + + 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; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than 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. Expires April 26, 2004 [Page 34] + +Internet-Draft DNSSEC Resource Records October 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property 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; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication 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 implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires April 26, 2004 [Page 35] + +Internet-Draft DNSSEC Resource Records October 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires April 26, 2004 [Page 36] + diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-10.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt similarity index 54% rename from doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-10.txt rename to doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt index a62903071e..2dabfb888f 100644 --- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-10.txt +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt @@ -1,19 +1,16 @@ - - - DNS Extensions O. Kolkman Internet-Draft RIPE NCC -Expires: March 28, 2004 J. Schlyter +Expires: March 1, 2004 J. Schlyter E. Lewis ARIN - September 28, 2003 + September 2003 - KEY RR Secure Entry Point Flag - draft-ietf-dnsext-keyrr-key-signing-flag-10 + DNSKEY RR Secure Entry Point Flag + draft-ietf-dnsext-keyrr-key-signing-flag-11 Status of this Memo @@ -35,7 +32,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 28, 2004. + This Internet-Draft will expire on March 1, 2004. Copyright Notice @@ -43,39 +40,40 @@ Copyright Notice Abstract - With the Delegation Signer (DS) resource record the concept of a key - acting as a secure entry point has been introduced. During - key-exchanges with the parent there is a need to differentiate secure - entry point keys from other keys in the KEY resource record (RR) set. - A flag bit in the KEY RR is defined to indicate that KEY is to be - used as a secure entry point. The flag bit is intended to assist in - operational procedures to correctly generate DS resource records, or - to indicate what keys are intended for static configuration. The flag - bit is not to be used in the DNS verification protocol. This document + With the Delegation Signer (DS) resource record the concept of a + public key acting as a secure entry point has been introduced. During + exchanges of public keys with the parent there is a need to + differentiate secure entry point keys from other public keys in the + DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is + defined to indicate that DNSKEY is to be used as a secure entry + point. 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 -Kolkman, et al. Expires March 28, 2004 [Page 1] +Kolkman, et al. Expires March 1, 2004 [Page 1] -Internet-Draft KEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 - updates RFC 2535 and RFC 3445. + be used in the DNS verification protocol. This document updates RFC + 2535 and RFC 3445. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4 - 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 4 - 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 4 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Internationalization Considerations . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 - Normative References . . . . . . . . . . . . . . . . . . . . . . 6 - Informative References . . . . . . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . 7 + Informative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . . . 8 + Intellectual Property and Copyright Statements . . . . . . . . . 9 @@ -110,10 +108,9 @@ Table of Contents - -Kolkman, et al. Expires March 28, 2004 [Page 2] +Kolkman, et al. Expires March 1, 2004 [Page 2] -Internet-Draft KEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 1. Introduction @@ -121,57 +118,86 @@ Internet-Draft KEY RR Secure Entry Point Flag September 2003 "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 zone keys - that are (to be) pointed to by parental DS RRs and other keys in the - zone. We refer to these keys as Secure Entry Point (SEP) keys. A - SEP key is either used to generate a DS RR or is distributed to - resolvers that use the key as the root of a trusted subtree[3]. + [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) keys in each - zone has been prevalent. One key is used to sign just the zone's KEY - resource record (RR) set and is the key referenced by a DS RR at the - parent or configured statically in a resolver. Another key is used to - sign the rest of the zone's data sets. The former key 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, - but there will be multiples of each at times. + 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 zone keys into KSK's and ZSK's is - not mandatory in any definition of DNSSEC, not even with the + 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. - There is a need to differentiate between a KSK and a ZSK by the zone - administrator. This need is driven by knowing which keys are to be - sent for DS RRs, which keys are to be distributed to resolvers, and - which keys are fed to the signer application at the appropriate time. + 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 the flow between signer and (parental) key-collector and in the - flow between the signer and the resolver configuration it is - important to be able to differentiate the SEP keys from the other - keys in a KEY RR set. The SEP flag is to be of no interest to the - flow between the verifier and the authoritative data store. + 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. + + + + +Kolkman, et al. Expires March 1, 2004 [Page 3] + +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 + + + 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 is made by the signer, a key could be - both a KSK and a ZSK. 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 a KSK flag bit - and a ZSK flag bit, setting on needing just one bit.) + 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 RFC2119 [1]. - - -Kolkman, et al. Expires March 28, 2004 [Page 3] - -Internet-Draft KEY RR Secure Entry Point Flag September 2003 - - 2. The Secure Entry Point (SEP) Flag @@ -187,17 +213,24 @@ Internet-Draft KEY RR Secure Entry Point Flag September 2003 / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - KEY RR Format + DNSKEY RR Format - The SEP bit (TBD) in the flags field is assigned to be the secure - entry point flag. If the 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. This document assigns the - 15'th bit [4] as the SEP bit. This way operators can recognize the - secure entry point key by the even or odd-ness of the decimal - representation of the flag field. + + + +Kolkman, et al. Expires March 1, 2004 [Page 4] + +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 + + + This document assigns the 15'th bit [4] in the flags field as the + secure entry point (SEP) bit. If the 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 @@ -209,25 +242,18 @@ Internet-Draft KEY RR Secure Entry Point Flag September 2003 4. Operational Guidelines - The SEP bit is set by the key-generator and MAY be used by the zone - signer to decide whether the key 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. + 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 KEY RR. As the SEP bit is within the - data that is used to compute the 'key tag field' in the SIG RR, + 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. - - - -Kolkman, et al. Expires March 28, 2004 [Page 4] - -Internet-Draft KEY RR Secure Entry Point Flag September 2003 - - 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. @@ -235,21 +261,29 @@ Internet-Draft KEY RR Secure Entry Point Flag September 2003 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 KEY - RR set, such keys might be pending retirement or not yet in use. + 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 key to be used as - trusted root, administrators can choose to ignore the fact that a KEY - has its SEP bit set or not when configuring a trusted root for their - resolvers. + 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 flag a key roll over can be automated. The parent can use - an existing trust relation to verify key sets in which a new key with - the SEP flag appears. + + +Kolkman, et al. Expires March 1, 2004 [Page 5] + +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 + + + 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 @@ -260,32 +294,27 @@ Internet-Draft KEY RR Secure Entry Point Flag September 2003 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 key exchanges, we think - the following consideration is in place. + 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 key exchange - where a key set, containing two keys with the SEP flag set, is sent - to the parent. The parent verifies the key set with the existing - trust relation and creates the new DS RR from the key that the - current DS 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. + 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. 6. IANA Considerations - - - -Kolkman, et al. Expires March 28, 2004 [Page 5] - -Internet-Draft KEY RR Secure Entry Point Flag September 2003 - - - IANA considerations: The flag bits in the KEY RR are assigned by - IETF consensus. There is no action on IANA. + IANA considerations: The flag bits in the DNSKEY RR are assigned by + IETF consensus. This document assigns the 15th bit in the DNSKEY RR + as the Secure Entry Point (SEP) bit. [Final text pending + clarification of the DNSKEY flag registry] 7. Internationalization Considerations @@ -296,9 +325,17 @@ Internet-Draft KEY RR Secure Entry Point Flag September 2003 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, Miek Gieben, Olafur Gudmundsson, Daniel - Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler have - contributed ideas and provided feedback. + 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. + + + + +Kolkman, et al. Expires March 1, 2004 [Page 6] + +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 + This document saw the light during a workshop on DNSSEC operations hosted by USC/ISI in August 2002. @@ -327,19 +364,6 @@ Informative References Story", ISBN 0151002177 (50th anniversary edition), April 1996. - - - - - - - - -Kolkman, et al. Expires March 28, 2004 [Page 6] - -Internet-Draft KEY RR Secure Entry Point Flag September 2003 - - Authors' Addresses Olaf M. Kolkman @@ -361,6 +385,14 @@ Authors' Addresses EMail: jakob@schlyter.se + + + +Kolkman, et al. Expires March 1, 2004 [Page 7] + +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 + + Edward P. Lewis ARIN 3635 Concorde Parkway Suite 200 @@ -391,9 +423,30 @@ Authors' Addresses -Kolkman, et al. Expires March 28, 2004 [Page 7] + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires March 1, 2004 [Page 8] -Internet-Draft KEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 Intellectual Property Statement @@ -447,9 +500,9 @@ Full Copyright Statement -Kolkman, et al. Expires March 28, 2004 [Page 8] +Kolkman, et al. Expires March 1, 2004 [Page 9] -Internet-Draft KEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -503,5 +556,5 @@ Acknowledgment -Kolkman, et al. Expires March 28, 2004 [Page 9] +Kolkman, et al. Expires March 1, 2004 [Page 10]