From 18fff72430f9fd8413b5d76c22c70cd3fb5ab6af Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 18 Dec 2003 21:01:57 +0000 Subject: [PATCH] new draft --- ... => draft-ietf-dnsext-dnssec-intro-08.txt} | 351 ++-- ... draft-ietf-dnsext-dnssec-protocol-04.txt} | 1593 +++++++++-------- ...> draft-ietf-dnsext-dnssec-records-06.txt} | 599 ++++--- ...ietf-dnsext-keyrr-key-signing-flag-12.txt} | 66 +- ...s-26.txt => draft-ietf-dnsext-mdns-27.txt} | 492 ++--- 5 files changed, 1664 insertions(+), 1437 deletions(-) rename doc/draft/{draft-ietf-dnsext-dnssec-intro-07.txt => draft-ietf-dnsext-dnssec-intro-08.txt} (83%) rename doc/draft/{draft-ietf-dnsext-dnssec-protocol-03.txt => draft-ietf-dnsext-dnssec-protocol-04.txt} (68%) rename doc/draft/{draft-ietf-dnsext-dnssec-records-05.txt => draft-ietf-dnsext-dnssec-records-06.txt} (80%) rename doc/draft/{draft-ietf-dnsext-keyrr-key-signing-flag-11.txt => draft-ietf-dnsext-keyrr-key-signing-flag-12.txt} (89%) rename doc/draft/{draft-ietf-dnsext-mdns-26.txt => draft-ietf-dnsext-mdns-27.txt} (85%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt rename to doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt index 47dcc8fddf..41070d556d 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-07.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: April 26, 2004 R. Austein +Expires: June 16, 2004 R. Austein ISC M. Larson VeriSign @@ -10,11 +10,11 @@ Expires: April 26, 2004 R. Austein USC/ISI S. Rose NIST - October 27, 2003 + December 17, 2003 DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-07 + draft-ietf-dnsext-dnssec-intro-08 Status of this Memo @@ -36,7 +36,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 April 26, 2004. + This Internet-Draft will expire on June 16, 2004. Copyright Notice @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires April 26, 2004 [Page 1] +Arends, et al. Expires June 16, 2004 [Page 1] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 Last, this document describes the interrelationships between the @@ -83,7 +83,7 @@ Table of Contents Normative References . . . . . . . . . . . . . . . . . . . . . 21 Informative References . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . 24 + Intellectual Property and Copyright Statements . . . . . . . . 25 @@ -108,9 +108,9 @@ Table of Contents -Arends, et al. Expires April 26, 2004 [Page 2] +Arends, et al. Expires June 16, 2004 [Page 2] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 1. Introduction @@ -136,7 +136,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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]. + Resource Record" [I-D.ietf-dnsext-delegation-signer]. This document + set also updates, but does not obsolete, RFCs 1034 [RFC1034], 1035 + [RFC1035], 2136 [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 + [RFC3597]. The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key @@ -161,18 +164,21 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 - - - -Arends, et al. Expires April 26, 2004 [Page 3] +Arends, et al. Expires June 16, 2004 [Page 3] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 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 + This section defines a number of terms used in this document set. + Since this is intended to be useful as a reference while reading the + rest of the document set, first-time readers may wish to skim this + section quickly, read the rest of this document, then come back to + this section. + + authentication chain: an alternating sequence 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 @@ -183,9 +189,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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." + DNSKEY signs the "example." DNSKEY RRset. Private key + counterparts 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 @@ -202,35 +209,42 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 authenticate any new key for which the resolver is able verify the signature. + delegation point: Term used to describe the name at the parental side + of a zone cut. That is, the delegation point for "foo.example" + would be the foo.example node in the "example" zone (as opposed to + the zone apex of the "foo.example" zone). + 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. + parent. That is, there is no DS RR with the island's public key + + + +Arends, et al. Expires June 16, 2004 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements December 2003 + + + 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]. + detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone + signing key. security-aware name server: An entity acting in the role of a name server (defined in section 2.4 of [RFC1034]) which understands the @@ -259,6 +273,14 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 5] + +Internet-Draft DNSSEC Introduction and Requirements December 2003 + + 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 @@ -273,14 +295,6 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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". @@ -295,6 +309,7 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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. + See also: key signing key. @@ -317,24 +332,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 - - - - - - - - - - - - - - - -Arends, et al. Expires April 26, 2004 [Page 6] +Arends, et al. Expires June 16, 2004 [Page 6] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 3. Services Provided by DNS Security @@ -388,9 +388,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 7] +Arends, et al. Expires June 16, 2004 [Page 7] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 resolver or must have been learned and verified previously. @@ -444,9 +444,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 8] +Arends, et al. Expires June 16, 2004 [Page 8] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 the gaps, or "empty space", between domain names in a zone, as well @@ -500,9 +500,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 9] +Arends, et al. Expires June 16, 2004 [Page 9] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 4. Services Not Provided by DNS Security @@ -556,9 +556,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 10] +Arends, et al. Expires June 16, 2004 [Page 10] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 5. Resolver Considerations @@ -596,12 +596,11 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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. + bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid + blocking valid signatures from getting through to other + security-aware resolvers which are clients of this recursive name + server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure + recursive server handles queries with the CD bit set. @@ -612,9 +611,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 11] + +Arends, et al. Expires June 16, 2004 [Page 11] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 6. Stub Resolver Considerations @@ -633,16 +633,17 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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. + The first of these issues is a local policy issue: in essence, a + security-oblivious 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 @@ -667,10 +668,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 - -Arends, et al. Expires April 26, 2004 [Page 12] +Arends, et al. Expires June 16, 2004 [Page 12] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 7. Zone Considerations @@ -724,9 +724,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 13] +Arends, et al. Expires June 16, 2004 [Page 13] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 8. Name Server Considerations @@ -747,7 +747,7 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 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 + signing key(s) may be useful, since the key signing key(s) in such a case can still be kept offline. DNSSEC, by itself, is not enough to protect the integrity of an @@ -780,9 +780,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 14] +Arends, et al. Expires June 16, 2004 [Page 14] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 9. DNS Security Document Family @@ -836,9 +836,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 15] +Arends, et al. Expires June 16, 2004 [Page 15] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 record format. Each of these documents deals with a specific digital @@ -892,9 +892,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 16] +Arends, et al. Expires June 16, 2004 [Page 16] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 10. IANA Considerations @@ -948,9 +948,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 17] +Arends, et al. Expires June 16, 2004 [Page 17] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 11. Security Considerations @@ -1004,9 +1004,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 -Arends, et al. Expires April 26, 2004 [Page 18] +Arends, et al. Expires June 16, 2004 [Page 18] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 dynamic update, by sending a stream of update messages that force the @@ -1025,6 +1025,10 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 NSEC queries from a single host, use of intrusion detection tools, etc. + DNSSEC introduces significant additional complexity to the DNS, and + thus introduces many new opportunities for implementation bugs and + misconfigured zones. + DNSSEC does not provide confidentiality, due to a deliberate design choice. @@ -1035,6 +1039,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 zones, and other mechanisms must be used to protect zone transfer operations. + Please see [I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations. @@ -1053,26 +1060,31 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 - - - - - - - -Arends, et al. Expires April 26, 2004 [Page 19] +Arends, et al. Expires June 16, 2004 [Page 19] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 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. + This document was created from the input and ideas of the members of + the DNS Extensions Working Group. While explicitly listing everyone + who has contributed during the decade during which DNSSEC has been + under development would be an impossible task, the editors would + particularly like to thank the following people for their + contributions to and comments on this document set: Mark Andrews, + Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, + Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael + Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip + Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf + Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted + Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, + Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik + Rozendaal, Jakob Schlyter, Mike StJohns, Sam Weiler, and Brian + Wellington. + + No doubt the above is an incomplete list. We apologize to anyone we + left out. @@ -1104,21 +1116,9 @@ Internet-Draft DNSSEC Introduction and Requirements October 2003 - - - - - - - - - - - - -Arends, et al. Expires April 26, 2004 [Page 20] +Arends, et al. Expires June 16, 2004 [Page 20] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 Normative References @@ -1172,13 +1172,23 @@ Normative References -Arends, et al. Expires April 26, 2004 [Page 21] +Arends, et al. Expires June 16, 2004 [Page 21] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 Informative References + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. @@ -1198,6 +1208,9 @@ Informative References [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001. + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + [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 @@ -1213,6 +1226,13 @@ Informative References draft-ietf-dnsext-delegation-signer-15 (work in progress), June 2003. + + +Arends, et al. Expires June 16, 2004 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements December 2003 + + [I-D.ietf-dnsext-dnssec-2535typecode-change] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 @@ -1225,14 +1245,6 @@ Informative References progress), October 2003. - - - -Arends, et al. Expires April 26, 2004 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements October 2003 - - Authors' Addresses Roy Arends @@ -1271,6 +1283,12 @@ Authors' Addresses EMail: masseyd@isi.edu + +Arends, et al. Expires June 16, 2004 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements December 2003 + + Scott Rose National Institute for Standards and Technology 100 Bureau Drive @@ -1284,9 +1302,47 @@ Authors' Addresses -Arends, et al. Expires April 26, 2004 [Page 23] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires June 16, 2004 [Page 24] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 Intellectual Property Statement @@ -1340,9 +1396,9 @@ Full Copyright Statement -Arends, et al. Expires April 26, 2004 [Page 24] +Arends, et al. Expires June 16, 2004 [Page 25] -Internet-Draft DNSSEC Introduction and Requirements October 2003 +Internet-Draft DNSSEC Introduction and Requirements December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -1396,5 +1452,6 @@ Acknowledgement -Arends, et al. Expires April 26, 2004 [Page 25] +Arends, et al. Expires June 16, 2004 [Page 26] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-04.txt similarity index 68% rename from doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt rename to doc/draft/draft-ietf-dnsext-dnssec-protocol-04.txt index 0673d91b8c..24f94a7efc 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-03.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-04.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: April 26, 2004 M. Larson +Expires: June 16, 2004 M. Larson VeriSign R. Austein ISC @@ -10,11 +10,11 @@ Expires: April 26, 2004 M. Larson USC/ISI S. Rose NIST - October 27, 2003 + December 17, 2003 Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-03 + draft-ietf-dnsext-dnssec-protocol-04 Status of this Memo @@ -36,7 +36,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 April 26, 2004. + This Internet-Draft will expire on June 16, 2004. Copyright Notice @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires April 26, 2004 [Page 1] +Arends, et al. Expires June 16, 2004 [Page 1] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 defines the concept of a signed zone, along with the requirements for @@ -77,96 +77,96 @@ Table of Contents 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.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 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 + 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10 + 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11 + 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11 + 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12 + 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14 + 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16 + 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17 + 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20 + 4.3 Determining Security Status of Data . . . . . . . . . . . . 21 + 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 21 + 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 21 + 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22 + 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 22 + 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 23 + 4.8.1 ENDS Support . . . . . . . . . . . . . . . . . . . . . . . . 23 + 4.8.2 Handling of the CD and AD Bits . . . . . . . . . . . . . . . 23 + + + +Arends, et al. Expires June 16, 2004 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25 + 5.1 Special Considerations for Islands of Security . . . . . . . 26 + 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26 + 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 27 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 28 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 29 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30 5.3.4 Authenticating A Wildcard Expanded RRset Positive + Response . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 31 + 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 32 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 34 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 + Normative References . . . . . . . . . . . . . . . . . . . . 36 + Informative References . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 39 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . 45 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 47 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 48 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 49 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 49 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 50 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 51 + C. Authentication Examples . . . . . . . . . . . . . . . . . . 53 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 53 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 53 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 54 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 54 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 54 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 54 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 55 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 55 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 55 + Intellectual Property and Copyright Statements . . . . . . . 56 -Arends, et al. Expires April 26, 2004 [Page 2] + + + + + + + + + + +Arends, et al. Expires June 16, 2004 [Page 3] -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 +Internet-Draft DNSSEC Protocol Modifications December 2003 1. Introduction @@ -220,9 +220,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 4] +Arends, et al. Expires June 16, 2004 [Page 4] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 1.3.3 Typos and Minor Corrections @@ -276,9 +276,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 5] +Arends, et al. Expires June 16, 2004 [Page 5] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 2. Zone Signing @@ -294,8 +294,6 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 @@ -330,15 +328,15 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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; + + +Arends, et al. Expires June 16, 2004 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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 @@ -385,21 +383,26 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + + Each owner name in the zone which has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + process for constructing the NSEC RR for a given name is described in [I-D.ietf-dnsext-dnssec-records]. + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRsets at any particular owner name. That is, the signing process + MUST NOT create (or RRSIG) RRs for owner names nodes which were not + the owner name of any RRset before the zone was signed. + 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. @@ -409,9 +412,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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. + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS + RRsets MUST NOT appear at 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 @@ -438,15 +441,68 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 this conflict, this specification modifies the definition of the CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + + + +Arends, et al. Expires June 16, 2004 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires June 16, 2004 [Page 9] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 3. Serving @@ -481,7 +537,7 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details on the behavior of these bits. 3.1 Authoritative Name Servers @@ -500,9 +556,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 9] +Arends, et al. Expires June 16, 2004 [Page 10] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST @@ -556,9 +612,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 10] +Arends, et al. Expires June 16, 2004 [Page 11] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 3.1.3 Including NSEC RRs In a Response @@ -612,9 +668,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 11] +Arends, et al. Expires June 16, 2004 [Page 12] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 o An NSEC RR proving that there is no exact 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. + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + If space does not permit inclusion of these NSEC and RRSIG RRs, the name server MUST set the TC bit (see Section 3.1.1). - - - -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 @@ -708,6 +777,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 security-aware authoritative name server returning a referral includes DNSSEC data along with the NS RRset. + + + +Arends, et al. Expires June 16, 2004 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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 @@ -721,14 +798,6 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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). @@ -764,6 +833,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + return either the DS RRset or an error response according to the normal processing rules. @@ -777,14 +854,6 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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. @@ -820,6 +889,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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 @@ -833,14 +910,6 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 @@ -869,15 +938,6 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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. @@ -885,18 +945,18 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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 @@ -941,18 +1001,18 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + + If the resolver side implements a BAD cache (see Section 4.7) 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). @@ -1000,13 +1060,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 - - - - -Arends, et al. Expires April 26, 2004 [Page 18] +Arends, et al. Expires June 16, 2004 [Page 19] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 4. Resolving @@ -1018,6 +1074,8 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 specific to security-aware recursive name servers are described in Section 3.2. +4.1 EDNS Support + A security-aware resolver MUST include an EDNS [RFC2671] OPT pseudo-RR with the DO [RFC3225] bit set to one when sending queries. @@ -1029,6 +1087,8 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 such fragmented packets were received via IPv4 or IPv6. Please see [RFC3226] for discussion of these requirements. +4.2 Signature Verification Support + A security-aware resolver MUST support the signature verification mechanisms described in Section 5, and MUST apply them to every received response except when: @@ -1053,30 +1113,33 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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. +4.3 Determining Security Status of Data + 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 + signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed, and is subject to signature validation as described above. @@ -1093,38 +1156,45 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 security-aware resolver is not able to contact security-aware name servers for the relevant zones. + +4.4 Preconfigured Public Keys + A security-aware resolver MUST be capable of being preconfigured with - at least one trusted public key, and MUST be capable of being + at least one trusted public key, and SHOULD 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. +4.5 Response Caching + + + + +Arends, et al. Expires June 16, 2004 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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. +4.6 Handling of the CD and AD bits + 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 +4.7 Rate Limiting A security-aware resolver SHOULD NOT cache data with invalid signatures under normal circumstances. However, a security-aware @@ -1155,6 +1225,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications December 2003 + + 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 @@ -1164,19 +1242,13 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 performing its own signature validation from ever seeing the "bad" data does not help the client. -4.2 Stub resolvers +4.8 Stub resolvers + +4.8.1 ENDS Support 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 @@ -1192,10 +1264,13 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 of the data that it the stub resolver hands back to the application which invoked it but is not required to do so. +4.8.2 Handling of the CD and AD Bits + 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. + queries unless requested by the application layer, 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 @@ -1206,6 +1281,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 June 16, 2004 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications December 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 @@ -1228,9 +1311,38 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 22] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires June 16, 2004 [Page 24] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 5. Authenticating DNS Responses @@ -1284,9 +1396,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 23] +Arends, et al. Expires June 16, 2004 [Page 25] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 interfere with DNSSEC RRs or due to a deliberate attack in which an @@ -1340,9 +1452,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 24] +Arends, et al. Expires June 16, 2004 [Page 26] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 RRset which, when hashed using the digest algorithm specified in @@ -1396,9 +1508,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 25] +Arends, et al. Expires June 16, 2004 [Page 27] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 5.3.1 Checking the RRSIG RR Validity @@ -1435,7 +1547,7 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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. + has run out of matching public keys to try. Note that this authentication process is only meaningful if the resolver authenticates the DNSKEY RR before using it to validate @@ -1452,9 +1564,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 26] +Arends, et al. Expires June 16, 2004 [Page 28] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 5.3.2 Reconstructing the Signed Data @@ -1508,9 +1620,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 27] +Arends, et al. Expires June 16, 2004 [Page 29] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 if rrsig_labels > fqdn @@ -1551,10 +1663,10 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 authenticate the RRset. The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm to generate the signature. The signature itself is + algorithm used 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). + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types, and provides pointers to the documents that define each algorithm's use. @@ -1564,14 +1676,14 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 28] +Arends, et al. Expires June 16, 2004 [Page 30] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 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. + determine which DNSKEY RR by trying each matching public 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 @@ -1580,10 +1692,10 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 other RRSIG RRs also cover this RRset, 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 @@ -1598,13 +1710,13 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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 + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the 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. + 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). @@ -1620,9 +1732,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 29] +Arends, et al. Expires June 16, 2004 [Page 31] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 according to the standard RRset authentication rules described in @@ -1632,37 +1744,39 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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. + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. o If the requested RR name would appear after an authenticated NSEC - RR owner name and before the name listed in that NSEC RR's Next + RR's owner name and before the name listed in that NSEC RR's Next Domain Name field according to the canonical DNS name order - defined in [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 + defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with + the requested name exist in the zone. However, it is possible + that a wildcard could be used to match the requested RR owner name + and type, so proving that the requested RRset does not exist also + requires proving that no possible wildcard RRset exists 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. + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify 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. +5.5 Authentication Example + + Appendix C shows an example the authentication process. @@ -1674,11 +1788,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 - - -Arends, et al. Expires April 26, 2004 [Page 30] +Arends, et al. Expires June 16, 2004 [Page 32] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 6. IANA Considerations @@ -1732,9 +1844,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 31] +Arends, et al. Expires June 16, 2004 [Page 33] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 7. Security Considerations @@ -1742,18 +1854,27 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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. + security considerations related to DNSSEC; see + [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the + DNSSEC resource record types. 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. + channel. See Section 3.2.2 and Section 4.8 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. + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, + since recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will need to pay close attention to the + behavior of the applications which use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidently denying service to the clients it is + intended to support. @@ -1779,27 +1900,22 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 - - - - - - - - - -Arends, et al. Expires April 26, 2004 [Page 32] +Arends, et al. Expires June 16, 2004 [Page 34] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 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 + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and suggestions received during the revision of these security extension - specifications. + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. @@ -1840,13 +1956,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 - - - - -Arends, et al. Expires April 26, 2004 [Page 33] +Arends, et al. Expires June 16, 2004 [Page 35] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 Normative References @@ -1900,9 +2012,9 @@ Normative References -Arends, et al. Expires April 26, 2004 [Page 34] +Arends, et al. Expires June 16, 2004 [Page 36] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 Informative References @@ -1956,9 +2068,9 @@ Authors' Addresses -Arends, et al. Expires April 26, 2004 [Page 35] +Arends, et al. Expires June 16, 2004 [Page 37] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 Matt Larson @@ -2012,300 +2124,300 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 36] +Arends, et al. Expires June 16, 2004 [Page 38] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 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 + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 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 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) 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 RRSIG NS 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz + +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj + s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY + eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH + FTVyQbVkcaxQ6U2FbZtMbfo//go= ) 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 RRSIG MX 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18 + 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe + IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+ + M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q + 7wxkDWyzgasGiMNIKgYrm9vXz04= ) 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 + 3600 RRSIG NSEC 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT + vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX + TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g + Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 + 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) + 3600 DNSKEY 256 3 5 ( + AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH + UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV + fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv + BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO -Arends, et al. Expires April 26, 2004 [Page 37] +Arends, et al. Expires June 16, 2004 [Page 39] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - cfnJlZyJcfwY0ETo4P2gntVMERZuJQ== + 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q== ) - 3600 DNSKEY 257 3 1 ( - AQOwRqeRkdYUD6UCyJXTaErj0UYLHxOHlhDb - qik1k/j2PJFOZ7GZhc95HnYco611O5VRQ6WQ - pK0dL9eiwcc+gSS2L6V9pWxCfDnEPWFC6eVm - jRZAdAU6gsyNSZCT7rF1lAXdmWcwkaIdNaDL - oNqpieIQd2t+rd/oF8/++DRtzF0toQ== + 3600 DNSKEY 257 3 5 ( + AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U + Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv + klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE + 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT + nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ== ) - 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= ) + 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU + pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5 + YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc + tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG + PjJstq6fvRq8kX7TPJcljUmDFKM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( + 20031216201552 60717 example. + EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/ + C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK + L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY + J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34 + Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= ) 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 DS 48327 5 1 ( + DFEB5E00E71A4DED5CABBBD7F15F24871983 + CAB7 ) + 3600 RRSIG DS 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ + hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb + rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c + ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC + 0yfe2uolEkeegjesDZuF+fC61Eg= ) 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= ) + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb + RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1 + 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O + ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf + YgfAHJEJJj7K88QbKEK4/Je1hyk= ) 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. + 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. -Arends, et al. Expires April 26, 2004 [Page 38] +Arends, et al. Expires June 16, 2004 [Page 40] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - MtQkYPqpRfM5ntlRR/Wg7pdFt5fuf+ESoV+a - 0RTtEUW9Q5ac7uV3luTnOSmWFFjes1x9Anqn - KVeWcZJU/wRYqbUK2Q9s/kLb3cPMFavHal9n - 3gR5v5zNaTQxBrdFlxGNgX/aa9Bs3LfxK14F - UU/kYIPkm9qpSE3wtELJEq2cNsU= ) + hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 + jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c + Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk + OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A + sWifTxvcG5hv+A6TOd0O2xJYRik= ) 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 RRSIG HINFO 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C + hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2 + KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2 + Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92 + xo9NLoltg0GuwggZM240pRoTwO8= ) 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 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 + 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ + G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI + A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI + zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) 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= ) + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE + ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y + ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU + 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR + ovChG5Ih3TOa8Qnch4IJQVfSFNU= ) 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= ) + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs + VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW + VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN + k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX + GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) 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 + 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 + CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs + RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf + +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa -Arends, et al. Expires April 26, 2004 [Page 39] +Arends, et al. Expires June 16, 2004 [Page 41] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - Oett68JnQVQq2l/DhWsJSjuIFBQ= ) + WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) 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= ) + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ + sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 + eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA + s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj + I2A5W86mMEbSgEF/pZHX/wi5FJI= ) 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 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL + xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK + HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht + sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG + wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) 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= ) + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb + IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b + f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J + aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl + yCup5bk/Dr47eU2/6+lqrBTOV8Q= ) *.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 RRSIG MX 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg + OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns + Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA + n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK + 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) 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= ) + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr + f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 + 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK + /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW + ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) 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 + 3600 RRSIG MX 5 3 3600 20040115201552 ( + 20031216201552 41681 example. + g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW + ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m + 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY + MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv -Arends, et al. Expires April 26, 2004 [Page 40] +Arends, et al. Expires June 16, 2004 [Page 42] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - IKZXg2219TD4UqJuRATLhxZj2fU= ) + btznHMFDIbtuw/tAX7xXH2pDDHY= ) 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= ) + 3600 RRSIG NSEC 5 3 3600 20040115201552 ( + 20031216201552 41681 example. + zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia + CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA + EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA + aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT + 3lMXiX4KNWUhB87q/pT/5z+xrqY= ) 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 RRSIG MX 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD + v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE + unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK + Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk + Iykd5UmaTO5j4LlRnAvF8Z1m9/k= ) 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= ) + 3600 RRSIG NSEC 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 + VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj + Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq + AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J + viOQHZ6I4xoZQP5G7r98/PhlrLM= ) 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 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap + tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq + iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS + KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G + 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 1 2 3600 20031108232541 ( - 20031009232541 5742 example. - vteMgDuG1ekaSmWlXlwVRoqTXjvZ8kGWCAku - 6Rd3t/wPeVmn3YSbC8+szYRgP8n0HvYzmVYj - qPyC1HCFoqIJIaNLkDEyCSHuhBwpVhyKGJdM - EbJ1P8Yk3w5Szjap6wn7QxcLnr8Df3xUMXnB - AAwDzum3fUKzVM274T9O8ggeXgE= ) + 3600 RRSIG HINFO 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw + p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA + gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/ + pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp + EDXT07qFXtGntvBSpF9uQbEub6Y= ) 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 1 2 3600 20031108232541 ( - 20031009232541 5742 example. - LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43 - YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27 - ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+ - AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0 + 3600 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 + dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD + mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg + CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z -Arends, et al. Expires April 26, 2004 [Page 41] +Arends, et al. Expires June 16, 2004 [Page 43] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - GxlD/3EneV4+IIIv0hekxzpR8Qs= ) + D4ZubIon0XGe9fIjLnmb3pX/FUk= ) 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= ) + 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn + uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE + NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a + 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187 + sSNF3PAC0HPadh7SdHmXlFQtQ44= ) 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 @@ -2348,9 +2460,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 42] +Arends, et al. Expires June 16, 2004 [Page 44] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 Appendix B. Example Responses @@ -2369,66 +2481,66 @@ B.1 Answer ;; 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= ) + x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 ( + 20031216201552 41681 example. + g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW + ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m + 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY + MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv + btznHMFDIbtuw/tAX7xXH2pDDHY= ) ;; 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= ) + example. 3600 RRSIG NS 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz + +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj + s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY + eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH + FTVyQbVkcaxQ6U2FbZtMbfo//go= ) ;; 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 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap + tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq + iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS + KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G + 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 1 2 3600 20031108232541 ( - 20031009232541 5742 example. - LY9gLxiep4FO8uuiegMzc1zdE/O7ApxjiO43 + xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 -Arends, et al. Expires April 26, 2004 [Page 43] +Arends, et al. Expires June 16, 2004 [Page 45] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - YDBVfuf3z+IghfPRY9IhkAJss6zBxMxciC27 - ZmlPBrysWcKDfWF7fX+q0CDZ3ZbqdU32MuK+ - AcWaIFu9JcYUIwFRCKt/0LA0OrycwELStUB0 - GxlD/3EneV4+IIIv0hekxzpR8Qs= ) + dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD + mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg + CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z + D4ZubIon0XGe9fIjLnmb3pX/FUk= ) 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= ) + ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 + CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs + RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf + +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa + WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) 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= ) + ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL + xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK + HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht + sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG + wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) B.2 Name Error @@ -2445,44 +2557,44 @@ B.2 Name Error ;; (empty) ;; Authority - example. 3600 IN SOA ns1.example. bugs.ns1.example. ( - 1065745538 + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 3600 300 3600000 3600 ) - example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( - 20031009232541 5742 example. - 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb - 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v - BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff + example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj -Arends, et al. Expires April 26, 2004 [Page 44] +Arends, et al. Expires June 16, 2004 [Page 46] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX - LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) 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= ) + b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs + VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW + VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN + k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX + GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) 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= ) + example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT + vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX + TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g + Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 + 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) ;; Additional ;; (empty) @@ -2502,36 +2614,36 @@ B.3 No Data Error ;; (empty) ;; Authority - example. 3600 IN SOA ns1.example. bugs.ns1.example. ( - 1065745538 + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 3600 300 3600000 3600 ) - example. 3600 RRSIG SOA 1 1 3600 20031108232541 ( - 20031009232541 5742 example. - 0EhIo5SFK2xwM2CMh3P6FJUmpV5VFotM5pzb - 8f3cL3SyKfOswI2osc3VvbtiEDQHEcE4/b+v + example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 -Arends, et al. Expires April 26, 2004 [Page 45] +Arends, et al. Expires June 16, 2004 [Page 47] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - BNx99Wc4jm3llWlsDOxlIbtR/S44xeOVRpff - pLuMW4IZmdwGY/xh/WHOCV+bqVl+s9un0OcX - LQTbyhlNTWdVYxPLo2T2dNP8a+0= ) + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) 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= ) + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ + sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 + eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA + s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj + I2A5W86mMEbSgEF/pZHX/wi5FJI= ) ;; Additional ;; (empty) @@ -2554,16 +2666,16 @@ B.4 Referral to Signed Zone ;; 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= ) + a.example. 3600 DS 48327 5 1 ( + DFEB5E00E71A4DED5CABBBD7F15F24871983 + CAB7 ) + a.example. 3600 RRSIG DS 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ + hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb + rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c + ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC + 0yfe2uolEkeegjesDZuF+fC61Eg= ) ;; Additional ns1.a.example. 3600 IN A 192.0.2.5 @@ -2572,9 +2684,9 @@ B.4 Referral to Signed Zone -Arends, et al. Expires April 26, 2004 [Page 46] +Arends, et al. Expires June 16, 2004 [Page 48] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 B.5 Referral to Unsigned Zone @@ -2594,13 +2706,13 @@ B.5 Referral to Unsigned Zone 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= ) + b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs + VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW + VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN + k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX + GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) ;; Additional ns1.b.example. 3600 IN A 192.0.2.7 @@ -2621,58 +2733,58 @@ B.6 Wildcard Expansion ;; 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 + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg + OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns -Arends, et al. Expires April 26, 2004 [Page 47] +Arends, et al. Expires June 16, 2004 [Page 49] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 - agwalJcGa3A2+UL45fjYR6zDEsag4cdg1D0/ - +T7gIqOGWhYfiXbXuTOgUfyZRXqyGsHsAu20 - FxfIqrcIL24dO4Ytdz2ifqvJmuM= ) + Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA + n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK + 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) ;; 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= ) + example. 3600 RRSIG NS 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz + +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj + s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY + eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH + FTVyQbVkcaxQ6U2FbZtMbfo//go= ) 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= ) + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 + VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj + Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq + AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J + viOQHZ6I4xoZQP5G7r98/PhlrLM= ) ;; 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 RRSIG A 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 + jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c + Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk + OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A + sWifTxvcG5hv+A6TOd0O2xJYRik= ) 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= ) + ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 + 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ + G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI + A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI + zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) B.7 Wildcard No Data Error @@ -2684,9 +2796,9 @@ B.7 Wildcard No Data Error -Arends, et al. Expires April 26, 2004 [Page 48] +Arends, et al. Expires June 16, 2004 [Page 50] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 ;; Header: QR AA DO RCODE=0 @@ -2698,36 +2810,36 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 ;; (empty) ;; Authority - example. 3600 IN SOA ns1.example. bugs.ns1.example. ( - 1065745538 + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 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 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) 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= ) + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( + 20031216201552 41681 example. + sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 + VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj + Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq + AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J + viOQHZ6I4xoZQP5G7r98/PhlrLM= ) *.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= ) + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( + 20031216201552 41681 example. + OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr + f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 + 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK + /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW + ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) ;; Additional ;; (empty) @@ -2740,9 +2852,9 @@ B.8 DS Child Zone No Data Error -Arends, et al. Expires April 26, 2004 [Page 49] +Arends, et al. Expires June 16, 2004 [Page 51] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 ;; Header: QR AA DO RCODE=0 @@ -2754,28 +2866,28 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 ;; (empty) ;; Authority - example. 3600 IN SOA ns1.example. bugs.ns1.example. ( - 1065745538 + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1071609350 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 RRSIG SOA 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA + hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 + VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj + CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM + owLe/OV+Qqqic7ShV/S9l2YJF9I= ) 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= ) + example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( + 20031216201552 41681 example. + kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT + vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX + TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g + Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 + 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) ;; Additional ;; (empty) @@ -2796,9 +2908,9 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 -Arends, et al. Expires April 26, 2004 [Page 50] +Arends, et al. Expires June 16, 2004 [Page 52] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 Appendix C. Authentication Examples @@ -2810,10 +2922,10 @@ 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. + signed by an "example" DNSKEY with algorithm 5 and key tag 41681. + 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 @@ -2852,9 +2964,9 @@ C.1.1 Authenticating the example DNSKEY RR -Arends, et al. Expires April 26, 2004 [Page 51] +Arends, et al. Expires June 16, 2004 [Page 53] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 matching "example" DNSKEY is found, the resolver checks this DNSKEY @@ -2863,11 +2975,11 @@ Internet-Draft DNSSEC Protocol Modifications October 2003 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. + DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This + DNSKEY is used to authenticated the RRSIG included in the response. + If multiple "example" DNSKEY RRs have algorithm 5 and key tag of + 41681, 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 @@ -2908,9 +3020,9 @@ C.5 Referral to Unsigned Zone -Arends, et al. Expires April 26, 2004 [Page 52] +Arends, et al. Expires June 16, 2004 [Page 54] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 identical to that of the MX RRset discussed above. @@ -2920,15 +3032,15 @@ 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. + signed by an "example" DNSKEY with algorithm 5 and key tag 41681. + 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 @@ -2964,9 +3076,9 @@ C.8 DS Child Zone No Data Error -Arends, et al. Expires April 26, 2004 [Page 53] +Arends, et al. Expires June 16, 2004 [Page 55] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 Intellectual Property Statement @@ -3020,9 +3132,9 @@ Full Copyright Statement -Arends, et al. Expires April 26, 2004 [Page 54] +Arends, et al. Expires June 16, 2004 [Page 56] -Internet-Draft DNSSEC Protocol Modifications October 2003 +Internet-Draft DNSSEC Protocol Modifications December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -3076,5 +3188,6 @@ Acknowledgement -Arends, et al. Expires April 26, 2004 [Page 55] +Arends, et al. Expires June 16, 2004 [Page 57] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-06.txt similarity index 80% rename from doc/draft/draft-ietf-dnsext-dnssec-records-05.txt rename to doc/draft/draft-ietf-dnsext-dnssec-records-06.txt index c726d7ff1f..a4668b76e8 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-05.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-06.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: April 26, 2004 R. Austein +Expires: June 16, 2004 R. Austein ISC M. Larson VeriSign @@ -10,11 +10,11 @@ Expires: April 26, 2004 R. Austein USC/ISI S. Rose NIST - October 27, 2003 + December 17, 2003 Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-05 + draft-ietf-dnsext-dnssec-records-06 Status of this Memo @@ -36,7 +36,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 April 26, 2004. + This Internet-Draft will expire on June 16, 2004. Copyright Notice @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires April 26, 2004 [Page 1] +Arends, et al. Expires June 16, 2004 [Page 1] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 signature (RRSIG), and authenticated denial of existence (NSEC) @@ -90,51 +90,51 @@ Table of Contents 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.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 12 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 12 + 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13 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.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . . . . 16 + 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17 + 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17 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 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20 -Arends, et al. Expires April 26, 2004 [Page 2] +Arends, et al. Expires June 16, 2004 [Page 2] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 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 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20 + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20 + 5.2 Processing of DS RRs When Validating Responses . . . . . . . 20 + 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21 + 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Canonical Form and Order of Resource Records . . . . . . . . 22 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 26 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 + Normative References . . . . . . . . . . . . . . . . . . . . 28 + Informative References . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35 + Intellectual Property and Copyright Statements . . . . . . . 36 @@ -164,9 +164,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 3] +Arends, et al. Expires June 16, 2004 [Page 3] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 1. Introduction @@ -220,9 +220,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 4] +Arends, et al. Expires June 16, 2004 [Page 4] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 An example correction to dnssec-editors might be: Page X says @@ -276,9 +276,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 5] +Arends, et al. Expires June 16, 2004 [Page 5] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 2. The DNSKEY Resource Record @@ -332,9 +332,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 6] +Arends, et al. Expires June 16, 2004 [Page 6] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 point. This flag is only intended to be to a hint to zone signing or @@ -388,9 +388,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 7] +Arends, et al. Expires June 16, 2004 [Page 7] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 2.3 DNSKEY RR Example @@ -444,9 +444,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 8] +Arends, et al. Expires June 16, 2004 [Page 8] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 3. The RRSIG Resource Record @@ -466,6 +466,14 @@ Internet-Draft DNSSEC Resource Records October 2003 Key Tag to identify the DNSKEY RR containing the public key that a resolver can use to verify the signature. + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034] that stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a secure + zone. + The Type value for the RRSIG RR type is 46. The RRSIG RR is class independent. @@ -473,7 +481,10 @@ Internet-Draft DNSSEC Resource Records October 2003 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. + it covers. This is an exception to the [RFC2181] rules for TTL + values of individuals RRs within a RRset: individual RRSIG with the + same owner name will have different TTLs if the RRsets that they + cover have different TTLs. 3.1 RRSIG RDATA Wire Format @@ -486,6 +497,14 @@ Internet-Draft DNSSEC Resource Records October 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Arends, et al. Expires June 16, 2004 [Page 9] + +Internet-Draft DNSSEC Resource Records December 2003 + + | Type Covered | Algorithm | Labels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original TTL | @@ -497,14 +516,6 @@ Internet-Draft DNSSEC Resource Records October 2003 | Key Tag | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / / / - - - -Arends, et al. Expires April 26, 2004 [Page 9] - -Internet-Draft DNSSEC Resource Records October 2003 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Signature / @@ -542,6 +553,14 @@ Internet-Draft DNSSEC Resource Records October 2003 The value of the Label field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if + + + +Arends, et al. Expires June 16, 2004 [Page 10] + +Internet-Draft DNSSEC Resource Records December 2003 + + 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." @@ -552,15 +571,6 @@ Internet-Draft DNSSEC Resource Records October 2003 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 @@ -598,6 +608,15 @@ Internet-Draft DNSSEC Resource Records October 2003 validates this signature. Appendix B explains how to calculate Key Tag values. + + + + +Arends, et al. Expires June 16, 2004 [Page 11] + +Internet-Draft DNSSEC Resource Records December 2003 + + 3.1.7 The Signer's Name Field The Signer's Name field value identifies the owner name of the DNSKEY @@ -608,15 +627,6 @@ Internet-Draft DNSSEC Resource Records October 2003 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 @@ -655,6 +665,14 @@ Internet-Draft DNSSEC Resource Records October 2003 Each RR in the RRset MUST have the TTL listed in the RRSIG Original TTL Field; + + + +Arends, et al. Expires June 16, 2004 [Page 12] + +Internet-Draft DNSSEC Resource Records December 2003 + + Any DNS names in the RDATA field of each RR MUST be in canonical form; and @@ -665,14 +683,6 @@ Internet-Draft DNSSEC Resource Records October 2003 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. @@ -711,6 +721,14 @@ Internet-Draft DNSSEC Resource Records October 2003 3.3 RRSIG RR Example + + + +Arends, et al. Expires June 16, 2004 [Page 13] + +Internet-Draft DNSSEC Resource Records December 2003 + + The following an RRSIG RR stores the signature for the A RRset of host.example.com: @@ -722,13 +740,6 @@ Internet-Draft DNSSEC Resource Records October 2003 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. @@ -769,20 +780,9 @@ Internet-Draft DNSSEC Resource Records October 2003 - - - - - - - - - - - -Arends, et al. Expires April 26, 2004 [Page 14] +Arends, et al. Expires June 16, 2004 [Page 14] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 4. The NSEC Resource Record @@ -796,6 +796,13 @@ Internet-Draft DNSSEC Resource Records October 2003 denial of existence for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol]. + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034] that + stated that if a CNAME is present for a name, it is the only type + allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist + for the same name as a CNAME resource record in a secure zone. + The type value for the NSEC RR is 47. The NSEC RR is class independent. @@ -811,7 +818,7 @@ Internet-Draft DNSSEC Resource Records October 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Next Domain Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Map / + / Type Bit Maps / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -826,54 +833,73 @@ Internet-Draft DNSSEC Resource Records October 2003 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 + + + +Arends, et al. Expires June 16, 2004 [Page 15] + +Internet-Draft DNSSEC Resource Records December 2003 + + 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. +4.1.2 The Type Bit Maps Field - - - -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 + The Type Bit Maps 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. + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that has + at least one active RR type is encoded using a single octet window + number (from 0 to 255), a single octet bitmap length (from 1 to 32) + indicating the number of octets used for the window block's bitmap, + and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. 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 is present for the NSEC RR's owner name. + + Since bit 0 in window block 0 refers to the non-existent RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing pseudo-types MUST be set to 0, since they do not + appear in zone data. If encountered, they MUST be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpreted as zero octets. + + + +Arends, et al. Expires June 16, 2004 [Page 16] + +Internet-Draft DNSSEC Resource Records December 2003 + 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 ("*") @@ -889,17 +915,9 @@ Internet-Draft DNSSEC Resource Records October 2003 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. + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + as described in [RFC3597] (section 5) MUST be used. 4.3 NSEC RR Example @@ -907,13 +925,33 @@ Internet-Draft DNSSEC Resource Records October 2003 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 + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC - mnemonics indicate there are A, MX, RRSIG and NSEC RRsets associated - with the name alfa.example.com. + mnemonics indicate there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets + associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + + + +Arends, et al. Expires June 16, 2004 [Page 17] + +Internet-Draft DNSSEC Resource Records December 2003 + Assuming that the resolver can authenticate this NSEC record, it could be used to prove that beta.example.com does not exist, or could @@ -948,9 +986,27 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 17] + + + + + + + + + + + + + + + + + + +Arends, et al. Expires June 16, 2004 [Page 18] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 5. The DS Resource Record @@ -958,11 +1014,11 @@ Internet-Draft DNSSEC Resource Records October 2003 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 + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in [I-D.ietf-dnsext-dnssec-protocol]. The DS RR and its corresponding DNSKEY RR have the same owner name, @@ -1004,9 +1060,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 18] +Arends, et al. Expires June 16, 2004 [Page 19] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 5.1.1 The Key Tag Field @@ -1060,9 +1116,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 19] +Arends, et al. Expires June 16, 2004 [Page 20] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 have Flags bit 7 set to value 1. If the key tag does not indicate a @@ -1116,9 +1172,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 20] +Arends, et al. Expires June 16, 2004 [Page 21] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 6. Canonical Form and Order of Resource Records @@ -1172,9 +1228,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 21] +Arends, et al. Expires June 16, 2004 [Page 22] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 replaced by the corresponding lowercase US-ASCII letters; @@ -1203,6 +1259,15 @@ Internet-Draft DNSSEC Resource Records October 2003 of each RR as a left justified unsigned octet sequence. The absence of an octet sorts before a zero octet. + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs during + RRset canonicalization, the implementation MUST treat this as a + protocol error. If the implementation chooses to handle this + protocol error in the spirit of the robustness principle (being + liberal in what it accepts), the implementation MUST remove all but + one of the duplicate RR(s) for purposes of calculating the canonical + form of the RRset. @@ -1219,18 +1284,9 @@ Internet-Draft DNSSEC Resource Records October 2003 - - - - - - - - - -Arends, et al. Expires April 26, 2004 [Page 22] +Arends, et al. Expires June 16, 2004 [Page 23] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 7. IANA Considerations @@ -1252,22 +1308,17 @@ Internet-Draft DNSSEC Resource Records October 2003 (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 + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers, and assigned values 1-4 and 252-255. [RFC3110] assigned value 5. - [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-dnssec-2535typecode-change] altered this registry + to include flags for each entry regarding its use with the DNS + security extensions. Each algorithm entry could refer to an + algorithm that can be used for zone signing, transaction security + (see [RFC2931]) or both. Values 6-251 are available for assignment + by IETF standards action. See Appendix A for a full listing of the + DNS Security Algorithm Numbers entries at the time of writing and + their status of use in DNSSEC. [I-D.ietf-dnsext-delegation-signer] created an IANA registry for DNSSEC DS Digest Types, and assigned value 0 to reserved and value @@ -1279,21 +1330,21 @@ Internet-Draft DNSSEC Resource Records October 2003 registry remains closed, and all KEY and DNSKEY records are required to have Protocol Octet value of 3. + Flag bits in the KEY and DNSKEY RRs: + [I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains an assignment for bit 7 (the ZONE bit) + and a reservation for bit 15 for the Secure Entry Point flag (SEP + bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14 + are available for assignment by IETF Standards Action. - - -Arends, et al. Expires April 26, 2004 [Page 23] +Arends, et al. Expires June 16, 2004 [Page 24] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 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. @@ -1340,9 +1391,14 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 24] + + + + + +Arends, et al. Expires June 16, 2004 [Page 25] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 8. Security Considerations @@ -1351,9 +1407,9 @@ Internet-Draft DNSSEC Resource Records October 2003 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. + security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] + and Please see [I-D.ietf-dnsext-dnssec-protocol] additional security + considerations related to the use of these records. 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 @@ -1396,18 +1452,22 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 25] +Arends, et al. Expires June 16, 2004 [Page 26] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 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 + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and suggestions received during the revision of these security extension - specifications. + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. @@ -1448,13 +1508,9 @@ Internet-Draft DNSSEC Resource Records October 2003 - - - - -Arends, et al. Expires April 26, 2004 [Page 26] +Arends, et al. Expires June 16, 2004 [Page 27] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 Normative References @@ -1508,9 +1564,9 @@ Normative References -Arends, et al. Expires April 26, 2004 [Page 27] +Arends, et al. Expires June 16, 2004 [Page 28] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 [I-D.ietf-dnsext-dnssec-intro] @@ -1564,9 +1620,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 28] +Arends, et al. Expires June 16, 2004 [Page 29] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 Informative References @@ -1620,9 +1676,9 @@ Authors' Addresses -Arends, et al. Expires April 26, 2004 [Page 29] +Arends, et al. Expires June 16, 2004 [Page 30] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 Scott Rose @@ -1676,9 +1732,9 @@ Internet-Draft DNSSEC Resource Records October 2003 -Arends, et al. Expires April 26, 2004 [Page 30] +Arends, et al. Expires June 16, 2004 [Page 31] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 Appendix A. DNSSEC Algorithm and Digest Types @@ -1698,45 +1754,50 @@ Appendix A. DNSSEC Algorithm and Digest Types 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: + The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify + the security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. - 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 - - + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs as described in [RFC2931] + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman [DH] n RFC 2539 - + 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. 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 + + + +Arends, et al. Expires June 16, 2004 [Page 32] + +Internet-Draft DNSSEC Resource Records December 2003 + + 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 @@ -1783,14 +1844,9 @@ A.2 DNSSEC Digest Types - - - - - -Arends, et al. Expires April 26, 2004 [Page 32] +Arends, et al. Expires June 16, 2004 [Page 33] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 Appendix B. Key Tag Calculation @@ -1844,9 +1900,9 @@ Appendix B. Key Tag Calculation -Arends, et al. Expires April 26, 2004 [Page 33] +Arends, et al. Expires June 16, 2004 [Page 34] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 */ @@ -1900,9 +1956,9 @@ B.1 Key Tag for Algorithm 1 (RSA/MD5) -Arends, et al. Expires April 26, 2004 [Page 34] +Arends, et al. Expires June 16, 2004 [Page 35] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 Intellectual Property Statement @@ -1956,9 +2012,9 @@ Full Copyright Statement -Arends, et al. Expires April 26, 2004 [Page 35] +Arends, et al. Expires June 16, 2004 [Page 36] -Internet-Draft DNSSEC Resource Records October 2003 +Internet-Draft DNSSEC Resource Records December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -2012,5 +2068,6 @@ Acknowledgement -Arends, et al. Expires April 26, 2004 [Page 36] +Arends, et al. Expires June 16, 2004 [Page 37] + diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt similarity index 89% rename from doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt rename to doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt index 2dabfb888f..6bffb70423 100644 --- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-11.txt +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt @@ -1,16 +1,15 @@ - DNS Extensions O. Kolkman Internet-Draft RIPE NCC -Expires: March 1, 2004 J. Schlyter +Expires: June 17, 2004 J. Schlyter E. Lewis ARIN - September 2003 + December 18, 2003 DNSKEY RR Secure Entry Point Flag - draft-ietf-dnsext-keyrr-key-signing-flag-11 + draft-ietf-dnsext-keyrr-key-signing-flag-12 Status of this Memo @@ -32,7 +31,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 1, 2004. + This Internet-Draft will expire on June 17, 2004. Copyright Notice @@ -52,9 +51,9 @@ Abstract -Kolkman, et al. Expires March 1, 2004 [Page 1] +Kolkman, et al. Expires June 17, 2004 [Page 1] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 be used in the DNS verification protocol. This document updates RFC @@ -108,9 +107,9 @@ Table of Contents -Kolkman, et al. Expires March 1, 2004 [Page 2] +Kolkman, et al. Expires June 17, 2004 [Page 2] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 1. Introduction @@ -164,9 +163,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 -Kolkman, et al. Expires March 1, 2004 [Page 3] +Kolkman, et al. Expires June 17, 2004 [Page 3] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 An administrator has configured a DNSKEY as root for a trusted @@ -220,13 +219,13 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 -Kolkman, et al. Expires March 1, 2004 [Page 4] +Kolkman, et al. Expires June 17, 2004 [Page 4] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 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 + This document assigns the 15'th bit 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 @@ -276,9 +275,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 -Kolkman, et al. Expires March 1, 2004 [Page 5] +Kolkman, et al. Expires June 17, 2004 [Page 5] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 Using the SEP flag a key roll over can be automated. The parent can @@ -311,10 +310,10 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 6. IANA Considerations - 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] + The flag bits in the DNSKEY RR are assigned by IETF consensus and + registered in the DNSKEY Flags registry (created by [4]). This + document assigns the 15th bit in the DNSKEY RR as the Secure Entry + Point (SEP) bit. 7. Internationalization Considerations @@ -332,9 +331,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 -Kolkman, et al. Expires March 1, 2004 [Page 6] +Kolkman, et al. Expires June 17, 2004 [Page 6] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 This document saw the light during a workshop on DNSSEC operations @@ -351,8 +350,9 @@ Normative References [3] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001. - [4] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. + [4] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work + in progress), October 2003. Informative References @@ -387,10 +387,9 @@ Authors' Addresses - -Kolkman, et al. Expires March 1, 2004 [Page 7] +Kolkman, et al. Expires June 17, 2004 [Page 7] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 Edward P. Lewis @@ -444,9 +443,9 @@ Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 -Kolkman, et al. Expires March 1, 2004 [Page 8] +Kolkman, et al. Expires June 17, 2004 [Page 8] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 Intellectual Property Statement @@ -500,9 +499,9 @@ Full Copyright Statement -Kolkman, et al. Expires March 1, 2004 [Page 9] +Kolkman, et al. Expires June 17, 2004 [Page 9] -Internet-Draft DNSKEY RR Secure Entry Point Flag September 2003 +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -556,5 +555,6 @@ Acknowledgment -Kolkman, et al. Expires March 1, 2004 [Page 10] +Kolkman, et al. Expires June 17, 2004 [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-mdns-26.txt b/doc/draft/draft-ietf-dnsext-mdns-27.txt similarity index 85% rename from doc/draft/draft-ietf-dnsext-mdns-26.txt rename to doc/draft/draft-ietf-dnsext-mdns-27.txt index 2f5da9f156..1e78616558 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-26.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-27.txt @@ -3,8 +3,8 @@ DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -11 December 2003 + Microsoft +17 December 2003 Linklocal Multicast Name Resolution (LLMNR) @@ -57,26 +57,25 @@ Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 Table of Contents 1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 + 1.1 Requirements .................................... 3 1.2 Terminology ..................................... 4 2. Name resolution using LLMNR ........................... 4 2.1 Sender behavior ................................. 5 2.2 Responder behavior .............................. 6 2.3 Unicast queries ................................. 7 - 2.4 Addressing ...................................... 8 - 2.5 Off-link detection .............................. 8 - 2.6 Retransmissions ................................. 9 + 2.4 Off-link detection .............................. 8 + 2.5 Responder responsibility ........................ 9 + 2.6 Retransmissions ................................. 10 2.7 DNS TTL ......................................... 10 - 2.8 Use of the authority and additional sections .... 10 + 2.8 Use of the authority and additional sections .... 11 3. Usage model ........................................... 11 - 3.1 Responder responsibility ....................... 11 - 3.2 LLMNR configuration ............................. 12 + 3.1 LLMNR configuration ............................. 12 4. Conflict resolution ................................... 13 4.1 Considerations for multiple interfaces .......... 15 4.2 API issues ...................................... 16 @@ -111,13 +110,14 @@ Full Copyright Statement ..................................... 22 + Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 1. Introduction @@ -136,16 +136,14 @@ they respond with errors, as described in Section 2. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. -LLMNR queries are sent to and received on port TBD. Link-scope -multicast addresses are used to prevent propagation of LLMNR traffic -across routers, potentially flooding the network; for details, see -Section 2.4. LLMNR queries can also be sent to a unicast address, as -described in Section 2.3. +Link-scope multicast addresses are used to prevent propagation of LLMNR +traffic across routers, potentially flooding the network. LLMNR queries +can also be sent to a unicast address, as described in Section 2.3. Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a gateway, then the network is able to provide DNS server -configuration. Configuration issues are discussed in Section 3.2. +configuration. Configuration issues are discussed in Section 3.1. In the future, it may be desirable to consider use of multicast name resolution with multicast scopes beyond the link-scope. This could @@ -165,9 +163,11 @@ Service discovery in general, as well as discovery of DNS servers using LLMNR in particular, is outside of the scope of this document, as is name resolution over non-multicast capable media. +1.1. Requirements - - +In this document, several words are used to signify the requirements of +the specification. These words are often capitalized. The key words +"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD @@ -177,14 +177,9 @@ Esibov, Aboba & Thaler Standards Track [Page 3] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 -1.1. Requirements - -In this document, several words are used to signify the requirements of -the specification. These words are often capitalized. The key words -"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -193,9 +188,6 @@ interpreted as described in [RFC2119]. This document assumes familiarity with DNS terminology defined in [RFC1035]. Other terminology used in this document includes: -Owner A host is said to be the owner of a Resource Record (RR) if it - is configured to respond to an LLMNR query for that RR. - Routable address An address other than a Link-Local address. This includes globally routable addresses, as well as private addresses. @@ -208,14 +200,19 @@ Sender A host that sends an LLMNR query. 2. Name resolution using LLMNR LLMNR is a peer-to-peer name resolution protocol that is not intended as -a replacement for DNS. This document does not specify how names are -chosen or configured. This may occur via any mechanism, including -DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. +a replacement for DNS. LLMNR queries are sent to and received on port +TBD. IPv4 administratively scoped multicast usage is specified in +"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope +multicast address a given responder listens to, and to which a sender +sends queries, is TBD. The IPv6 link-scope multicast address a given +responder listens to, and to which a sender sends all queries, is TBD. Typically a host is configured as both an LLMNR sender and a responder. A host MAY be configured as a sender, but not a responder. However, a host configured as a responder MUST act as a sender to verify the -uniqueness of names as described in Section 4. +uniqueness of names as described in Section 4. This document does not +specify how names are chosen or configured. This may occur via any +mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. LLMNR usage MAY be configured manually or automatically on a per interface basis. By default, LLMNR responders SHOULD be enabled on all @@ -225,9 +222,12 @@ An LLMNR sender may send a request for any name. However, by default, LLMNR requests SHOULD be sent only when one of the following conditions are met: -[1] No manual or automatic DNS configuration has been performed. - If an interface has been configured with DNS server address(es), - then LLMNR SHOULD NOT be used as the primary name resolution +[1] No manual or automatic DNS configuration has been performed. If an + interface has been configured with DNS server address(es), then + LLMNR SHOULD NOT be used as the primary name resolution mechanism + on that interface, although it MAY be used as a name resolution + mechanism of last resort. + @@ -237,38 +237,30 @@ Esibov, Aboba & Thaler Standards Track [Page 4] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 - mechanism on that interface, although it MAY be used as a name - resolution mechanism of last resort. +[2] DNS servers do not respond. -[2] DNS servers do not respond. - -[3] DNS servers respond to a DNS query with RCODE=3 - (Authoritative Name Error) or RCODE=0, and an empty - answer section. +[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name + Error) or RCODE=0, and an empty answer section. A typical sequence of events for LLMNR usage is as follows: -[1] DNS servers are not configured or do not respond to a - DNS query, or respond with RCODE=3, or RCODE=0 and an - empty answer section. +[a] DNS servers are not configured or do not respond to a DNS query, or + respond with RCODE=3, or RCODE=0 and an empty answer section. -[2] An LLMNR sender sends an LLMNR query to the link-scope multicast - address(es) defined in Section 2.4, unless a unicast query is - indicated. A sender SHOULD send LLMNR queries for PTR RRs - via unicast, as specified in Section 2.3. +[b] An LLMNR sender sends an LLMNR query to the link-scope multicast + address(es) defined in Section 2, unless a unicast query is + indicated. A sender SHOULD send LLMNR queries for PTR RRs via + unicast, as specified in Section 2.3. -[3] A responder responds to this query only if it is authoritative - for the domain name in the query. A responder responds to a - multicast query by sending a unicast UDP response to the sender. - Unicast queries are responded to as indicated in Section 2.3. +[c] A responder responds to this query only if it is authoritative for + the domain name in the query. A responder responds to a multicast + query by sending a unicast UDP response to the sender. Unicast + queries are responded to as indicated in Section 2.3. -[4] Upon the reception of the response, the sender performs the checks - described in Section 2.5. If these conditions are met, then the - sender uses and caches the returned response. If not, then the - sender ignores the response and continues waiting for the response. +[d] Upon reception of the response, the sender processes it. Further details of sender and responder behavior are provided in the sections that follow. @@ -288,6 +280,14 @@ be sent. The sender MUST anticipate receiving no replies to some LLMNR queries, in the event that no responders are available within the link-scope or in the event no positive non-null responses exist for the transmitted +query. If no positive response is received, a resolver treats it as a +response that no records of the specified type and class exist for the +specified name (it is treated the same as a response with RCODE=0 and an +empty answer section). + +Since the responder may order the RRs in the response so as to indicate +preference, the sender SHOULD preserve ordering in the response to the +querying application. @@ -297,57 +297,57 @@ Esibov, Aboba & Thaler Standards Track [Page 5] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 -query. If no positive response is received, a resolver treats it as a -response that no records of the specified type and class exist for the -specified name (it is treated the same as a response with RCODE=0 and an -empty answer section). - 2.2. Responder behavior A response to an LLMNR query is composed in exactly the same manner and with the same packet format as a response to a DNS query as specified in -[RFC1035]. +[RFC1035]. The response MUST be sent to the sender via unicast. Upon configuring an IP address responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR -queries for these RRs. However, in general whether RRs are manually or +queries for these RRs. An SOA RR is synthesized only when a responder +has another RR as well; the SOA RR MUST NOT be the only RR that a +responder has. However, in general whether RRs are manually or automatically created is an implementation decision. -Responders MUST NOT respond using cached data, and the AA (Authoritative -Answer) bit MUST be set. The response MUST be sent to the sender via -unicast. If a responder receives a query with the header containing RD -set bit, the responder MUST ignore the RD bit. +In responding to queries: -A responder MUST listen on UDP port TBD on the link-scope multicast -address(es) defined in Section 2.4 and on UDP and TCP port TBD on the -unicast address(es) that could be set as the source address(es) when the -responder responds to the LLMNR query. +[a] Responders MUST NOT respond using cached data, and the AA + (Authoritative Answer) bit MUST be set. -Responders MUST NOT respond to LLMNR queries for names they are not -authoritative for. Responders SHOULD respond to LLMNR queries for names -and addresses they are authoritative for. This applies to both forward -and reverse lookups. +[b] If a responder receives a query with the header containing the RD + bit set, the responder MUST ignore the RD bit. -A response to an LLMNR query MUST have RCODE set to zero. Responses -with RCODE set to zero are referred to in this document as "positively -resolved". LLMNR responders may respond only to queries which they can -resolve positively. If a responder is authoritative for a name, it MAY -respond with RCODE=0 and an empty answer section, if the type of query -does not match a RR owned by the responder. +[c] Responders MUST listen on UDP port TBD on the link-scope multicast + address(es) defined in Section 2, and on UDP and TCP port TBD on + the unicast address(es) that could be set as the source address(es) + when the responder responds to the LLMNR query. -As an example, a host configured to respond to LLMNR queries for the -name "foo.example.com." is authoritative for the name -"foo.example.com.". On receiving an LLMNR query for an A RR with the -name "foo.example.com." the host authoritatively responds with A RR(s) -that contain IP address(es) in the RDATA of the resource record. If the -responder owns a AAAA RR, but no A RR, and an A RR query is received, -the responder would respond with RCODE=0 and an empty answer section. +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + +[e] A response to an LLMNR query MUST have RCODE set to zero. + Responses with RCODE set to zero are referred to in this document + as "positively resolved". + +[f] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups. + +[g] If a DNS server is running on a host that supports LLMNR, the DNS + server MUST respond to LLMNR queries only for the RRSets relating + to the host on which the server is running, but MUST NOT respond + for other records for which the server is authoritative. DNS + servers also MUST NOT send LLMNR queries in order to resolve DNS + queries. + +[h] If a responder is authoritative for a name, it MAY respond with + RCODE=0 and an empty answer section, if the type of query does not + match a RR that the responder has. -If a DNS server is running on a host that supports LLMNR, the DNS server -MUST respond to LLMNR queries only for the RRSets relating to the host @@ -357,19 +357,22 @@ Esibov, Aboba & Thaler Standards Track [Page 6] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 -on which the server is running, but MUST NOT respond for other records -for which the server is authoritative. DNS servers also MUST NOT send -LLMNR queries in order to resolve DNS queries they receive from DNS -clients. +As an example, a host configured to respond to LLMNR queries for the +name "foo.example.com." is authoritative for the name +"foo.example.com.". On receiving an LLMNR query for an A RR with the +name "foo.example.com." the host authoritatively responds with A RR(s) +that contain IP address(es) in the RDATA of the resource record. If the +responder has a AAAA RR, but no A RR, and an A RR query is received, the +responder would respond with RCODE=0 and an empty answer section. In conventional DNS terminology a DNS server authoritative for a zone is -authoritative for all the domain names under the zone root except for +authoritative for all the domain names under the zone appex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone -root. +appex. For example the host "foo.example.com." is not authoritative for the name "child.foo.example.com." unless the host is configured with @@ -398,16 +401,13 @@ lightweight hosts. Unicast queries SHOULD be sent when: - a. A sender repeats a query after it received a response - with the TC bit set to the previous LLMNR multicast query, or +[a] A sender repeats a query after it received a response with the TC + bit set to the previous LLMNR multicast query, or + +[b] The sender queries for a PTR RR of a fully formed IP address within + the "in-addr.arpa" or "ip6.arpa" zones. - b. The sender queries for a PTR RR of a fully formed IP address - within the "in-addr.arpa" or "ip6.arpa" zones. -If a TC (truncation) bit is set in the response, then the sender MAY use -the response if it contains all necessary information, or the sender MAY -discard the response and resend the query over TCP using the unicast -address of the responder. The RA (Recursion Available) bit in the @@ -417,25 +417,25 @@ Esibov, Aboba & Thaler Standards Track [Page 7] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 +If a TC (truncation) bit is set in the response, then the sender MAY use +the response if it contains all necessary information, or the sender MAY +discard the response and resend the query over TCP using the unicast +address of the responder. The RA (Recursion Available) bit in the header of the response MUST NOT be set. If the RA bit is set in the response header, the sender MUST ignore the RA bit. Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP unicast LLMNR queries MUST be sent using TCP, using the same connection -as the query. If the sender of a TCP query receives a response not -using TCP, the response MUST be silently discarded. +as the query. If the sender of a TCP query receives a response to that +query not using TCP, the response MUST be silently discarded. Unicast UDP queries MAY be responded to with a UDP response containing an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP. Senders MUST support sending TCP -queries, and Responders MUST support listening for TCP queries. The -Responder SHOULD set the TTL or Hop Limit settings on the TCP listen -socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop -Limit (IPv6) set to one (1). This prevents an incoming connection from -off-link since the Sender will not receive a SYN-ACK from the Responder. +queries, and Responders MUST support listening for TCP queries. If an ICMP "Time Exceeded" message is received in response to a unicast UDP query, or if TCP connection setup cannot be completed in order to @@ -449,15 +449,7 @@ guard against a potential Denial of Service (DoS) attack. If a match cannot be made, then the sender relies on the retransmission and timeout behavior described in Section 2.6. -2.4. Addressing - -IPv4 administratively scoped multicast usage is specified in -"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope -multicast address a given responder listens to, and to which a sender -sends queries, is TBD. The IPv6 link-scope multicast address a given -responder listens to, and to which a sender sends all queries, is TBD. - -2.5. Off-link detection +2.4. "Off link" detection For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local @@ -469,6 +461,14 @@ A sender MUST select a source address for LLMNR queries that is "on link". The destination address of an LLMNR query MUST be a link-scope multicast address or an "on link" unicast address. +A responder MUST select a source address for responses that is "on +link". The destination address of an LLMNR response MUST be an "on link" +unicast address. + +On receiving an LLMNR query, the responder MUST check whether it was +sent to a LLMNR multicast addresses defined in Section 2. If it was +sent to another multicast address, then the query MUST be silently + Esibov, Aboba & Thaler Standards Track [Page 8] @@ -477,22 +477,11 @@ Esibov, Aboba & Thaler Standards Track [Page 8] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 -A responder MUST select a source address for responses that is "on -link". The destination address of an LLMNR response MUST be an "on link" -unicast address. - -On receiving an LLMNR query, the responder MUST check whether it was -sent to a LLMNR multicast addresses defined in Section 2.4. If it was -sent to another multicast address, then the query MUST be silently discarded. -A sender SHOULD prefer RRs including reachable addresses where RRs -involving both reachable and unreachable addresses are returned in -response to a query. - In composing LLMNR queries, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). Even when LLMNR queries are sent to a link-scope multicast @@ -507,6 +496,12 @@ Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). This is done so as to prevent the use of LLMNR for denial of service attacks across the Internet. +Section 2.3 discusses use of TCP for LLMNR queries and responses. The +responder SHOULD set the TTL or Hop Limit settings on the TCP listen +socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop +Limit (IPv6) set to one (1). This prevents an incoming connection from +off-link since the sender will not receive a SYN-ACK from the responder. + Implementation note: In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL @@ -516,6 +511,39 @@ Implementation note: recvmsg(). [RFC2292] specifies similar options for setting and retrieving the IPv6 Hop Limit. +2.5. Responder responsibilities + +It is the responsibility of the responder to ensure that RRs returned in +LLMNR responses MUST only include values that are valid on the local +interface, such as IPv4 or IPv6 addresses valid on the local link or +names defended using the mechanism described in Section 4. In +particular: + +[a] If a link-scope IPv6 address is returned in a AAAA RR, that address + MUST be valid on the local link over which LLMNR is used. + +[b] If an IPv4 address is returned, it MUST be reachable through the + link over which LLMNR is used. + +[c] If a name is returned (for example in a CNAME, MX or SRV RR), the + name MUST be resolvable on the local link over which LLMNR is used. + + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 17 December 2003 + + +Routable addresses MUST be included first in the response, if available. +This encourages use of routable address(es) for establishment of new +connections. + 2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are @@ -528,18 +556,6 @@ responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 11 December 2003 - - Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, @@ -563,30 +579,14 @@ Recommended values are an initial RTO of 1 second, a minimum RTO of 2.7. DNS TTL The responder should use a pre-configured TTL value in the records -returned in the LLMNR query response. A default value of 0 is -recommended in highly dynamic environments (such as mobile ad-hoc -networks). In less dynamic environments, LLMNR traffic can be reduced -by setting the TTL to a higher value. +returned in the LLMNR query response. A default value of 30 seconds is +RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc +networks), the TTL value may need to be reduced. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value. -2.8. Use of the authority and additional sections -Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a -concept of delegation. In LLMNR, the NS resource record type may be -stored and queried for like any other type, but it has no special -delegation semantics as it does in the DNS. Responders MAY own NS -records associated with the names for which they are authoritative, but -they SHOULD NOT include these NS records in the authority sections of -responses. - -Responders SHOULD insert an SOA record into the authority section of a -negative response, to facilitate negative caching as specified in -[RFC2308]. The owner name of this SOA record MUST be equal to the query -name. - -Responders SHOULD NOT perform DNS additional section processing. @@ -597,9 +597,26 @@ Esibov, Aboba & Thaler Standards Track [Page 10] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 +2.8. Use of the authority and additional sections + +Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a +concept of delegation. In LLMNR, the NS resource record type may be +stored and queried for like any other type, but it has no special +delegation semantics as it does in the DNS. Responders MAY have NS +records associated with the names for which they are authoritative, but +they SHOULD NOT include these NS records in the authority sections of +responses. + +Responders SHOULD insert an SOA record into the authority section of a +negative response, to facilitate negative caching as specified in +[RFC2308]. The owner name of this SOA record MUST be equal to the query +name. + +Responders SHOULD NOT perform DNS additional section processing. + Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes such as negative caching. @@ -631,23 +648,6 @@ issues with failover, and recommends that resolvers try another server when they don't receive a response to a query. These policies are likely to avoid unnecessary LLMNR queries. -[RFC1536] Section 3 describes zero answer bugs, which if addressed will -also reduce unnecessary LLMNR queries. - -[RFC1536] Section 6 describes name error bugs and recommended searchlist -processing that will reduce unnecessary RCODE=3 (authoritative name) -errors, thereby also reducing unnecessary LLMNR queries. - -3.1. Responder responsibilities - -It is the responsibility of the responder to ensure that RRs returned in -LLMNR responses MUST only include values that are valid on the local -interface, such as IPv4 or IPv6 addresses valid on the local link or -names defended using the mechanism described in Section 4. In -particular: - -[1] If a link-scope IPv6 address is returned in a AAAA RR, that - address MUST be valid on the local link over which LLMNR is @@ -657,22 +657,17 @@ Esibov, Aboba & Thaler Standards Track [Page 11] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 - used. +[RFC1536] Section 3 describes zero answer bugs, which if addressed will +also reduce unnecessary LLMNR queries. -[2] If an IPv4 address is returned, it MUST be reachable through - the link over which LLMNR is used. +[RFC1536] Section 6 describes name error bugs and recommended searchlist +processing that will reduce unnecessary RCODE=3 (authoritative name) +errors, thereby also reducing unnecessary LLMNR queries. -[3] If a name is returned (for example in a CNAME, MX - or SRV RR), the name MUST be valid on the local interface. - -Routable addresses MUST be included first in the response, if available. -This encourages use of routable address(es) for establishment of new -connections. - -3.2. LLMNR configuration +3.1. LLMNR configuration Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a @@ -708,6 +703,11 @@ DHCPv4-based dynamic update, then the names of local IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no DNS server is authoritative for the names of local hosts, or the authoritative DNS server(s) do not support dynamic update, then LLMNR enables linklocal +name resolution over IPv4. + +Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to +configure LLMNR on an interface. The LLMNR Enable Option, described in +[LLMNREnable], can be used to explicitly enable or disable use of LLMNR @@ -717,14 +717,9 @@ Esibov, Aboba & Thaler Standards Track [Page 12] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 -name resolution over IPv4. - -Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to -configure LLMNR on an interface. The LLMNR Enable Option, described in -[LLMNREnable], can be used to explicitly enable or disable use of LLMNR on an interface. The LLMNR Enable Option does not determine whether or in which order DNS itself is used for name resolution. The order in which various name resolution mechanisms should be used can be specified @@ -747,7 +742,10 @@ LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents an unnecessary degradation in capabilities. As a result, it is recommended that hosts without a configured DNS server periodically attempt to obtain DNS configuration. -A default retry interval of one (1) minute is RECOMMENDED. +For example, where DHCP is used for DNS configuration, [RFC2131] +recommends a maximum retry interval of 64 seconds. In the absence of +other guidance, a default retry interval of one (1) minute is +RECOMMENDED. 4. Conflict resolution @@ -768,6 +766,8 @@ query and type of the query. For example it is expected that: - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in + the cluster) + - only a single host may respond to a query for an A or AAAA @@ -777,21 +777,20 @@ Esibov, Aboba & Thaler Standards Track [Page 13] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 - the cluster) - - only a single host may respond to a query for an A or AAAA type record for a name. Every responder that responds to an LLMNR query AND includes a UNIQUE record in the response: - 1. MUST verify that there is no other host within the scope of the - LLMNR query propagation that can return a resource record - for the same name, type and class. - 2. MUST NOT include a UNIQUE resource record in the - response without having verified its uniqueness. +[1] MUST verify that there is no other host within the scope of the + LLMNR query propagation that can return a resource record for the + same name, type and class. + +[2] MUST NOT include a UNIQUE resource record in the response without + having verified its uniqueness. Where a host is configured to issue LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache. @@ -810,7 +809,7 @@ UNIQUE. Uniqueness verification is carried out when the host: - is configured to respond to the LLMNR queries using additional UNIQUE resource records -When a host that owns a UNIQUE record receives an LLMNR query for that +When a host that has a UNIQUE record receives an LLMNR query for that record, the host MUST respond. After the client receives a response, it MUST check whether the response arrived on an interface different from the one on which the query was sent. If the response arrives on a @@ -828,6 +827,7 @@ uniqueness. When name conflicts are detected, they SHOULD be logged. To detect duplicate use of a name, an administrator can use a name resolution +utility which employs LLMNR and lists both responses and responders. @@ -837,10 +837,9 @@ Esibov, Aboba & Thaler Standards Track [Page 14] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 -utility which employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name. @@ -891,13 +890,14 @@ both interfaces. + Esibov, Aboba & Thaler Standards Track [Page 15] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 Host myhost cannot distinguish between the situation shown in Figure 2, @@ -957,7 +957,7 @@ Esibov, Aboba & Thaler Standards Track [Page 16] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 In order to address the security vulnerabilities, the following @@ -1017,7 +1017,7 @@ Esibov, Aboba & Thaler Standards Track [Page 17] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 be present on the same link. These threats are most serious in wireless @@ -1077,7 +1077,7 @@ Esibov, Aboba & Thaler Standards Track [Page 18] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 decreases reliance on it. @@ -1100,8 +1100,10 @@ hosts. This specification does not create any new name spaces for IANA administration. LLMNR requires allocation of a port TBD for both TCP and UDP. Assignment of the same port for both transports is requested. -LLMNR requires allocation of a link-scope multicast IPv4 address as well -as a link-scope multicast IPv6 address TBD. + +LLMNR requires allocation of a link-scope multicast IPv4 address TBD. +LLMNR also requires allocation of a link-scope multicast IPv6 address +TBD. 7. References @@ -1125,9 +1127,7 @@ as a link-scope multicast IPv6 address TBD. [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. + @@ -1137,9 +1137,13 @@ Esibov, Aboba & Thaler Standards Track [Page 19] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. @@ -1184,10 +1188,6 @@ INTERNET-DRAFT LLMNR 11 December 2003 [IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of IPv4 Link-Local Addresses", Internet draft (work in - progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October - 2003. - @@ -1197,9 +1197,13 @@ Esibov, Aboba & Thaler Standards Track [Page 20] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 + of IPv4 Link-Local Addresses", Internet draft (work in + progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October + 2003. + [POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open Group Technical Standard: Base Specifications, Issue 6, December @@ -1244,10 +1248,6 @@ Phone: +1 425 706 6605 EMail: bernarda@microsoft.com Dave Thaler -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - @@ -1257,9 +1257,13 @@ Esibov, Aboba & Thaler Standards Track [Page 21] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + Phone: +1 425 703 8835 EMail: dthaler@microsoft.com @@ -1304,10 +1308,6 @@ 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. - @@ -1317,9 +1317,13 @@ Esibov, Aboba & Thaler Standards Track [Page 22] -INTERNET-DRAFT LLMNR 11 December 2003 +INTERNET-DRAFT LLMNR 17 December 2003 +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. + Open Issues Open issues with this specification are tracked on the following web @@ -1329,7 +1333,7 @@ http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html Expiration Date -This memo is filed as , and expires +This memo is filed as , and expires June 22, 2004. @@ -1362,10 +1366,6 @@ June 22, 2004. - - - -