summaryrefslogtreecommitdiff
path: root/dist/bind/doc/draft
diff options
context:
space:
mode:
Diffstat (limited to 'dist/bind/doc/draft')
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt561
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt1457
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt3193
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt1849
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt639
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt335
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt1559
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt466
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt1344
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt1321
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt1969
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt391
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt485
-rw-r--r--dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt617
-rw-r--r--dist/bind/doc/draft/update10
15 files changed, 16193 insertions, 3 deletions
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
new file mode 100644
index 00000000000..09776618f2a
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt
@@ -0,0 +1,561 @@
+
+
+DNSEXT M. Stapp
+Internet-Draft Cisco Systems, Inc.
+Expires: January 14, 2005 T. Lemon
+ A. Gustafsson
+ Nominum, Inc.
+ July 16, 2004
+
+
+ A DNS RR for Encoding DHCP Information (DHCID RR)
+ <draft-ietf-dnsext-dhcid-rr-08.txt>
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 14, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ It is possible for multiple DHCP clients to attempt to update the
+ same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
+ the clients themselves perform the DNS updates, conflicts can arise.
+ To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
+ proposes storing client identifiers in the DNS to unambiguously
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 1]
+
+Internet-Draft The DHCID RR July 2004
+
+
+ associate domain names with the DHCP clients to which they refer.
+ This memo defines a distinct RR type for this purpose for use by DHCP
+ clients and servers, the "DHCID" RR.
+
+Table of Contents
+
+ 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4
+ 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4
+ 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4
+ 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4
+ 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6
+ 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8
+ 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
+ Intellectual Property and Copyright Statements . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 2]
+
+Internet-Draft The DHCID RR July 2004
+
+
+1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [2].
+
+2. Introduction
+
+ A set of procedures to allow DHCP [7] clients and servers to
+ automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
+ in "Resolution of DNS Name Conflicts" [1].
+
+ Conflicts can arise if multiple DHCP clients wish to use the same DNS
+ name. To resolve such conflicts, "Resolution of DNS Name Conflicts"
+ [1] proposes storing client identifiers in the DNS to unambiguously
+ associate domain names with the DHCP clients using them. In the
+ interest of clarity, it is preferable for this DHCP information to
+ use a distinct RR type. This memo defines a distinct RR for this
+ purpose for use by DHCP clients or servers, the "DHCID" RR.
+
+ In order to avoid exposing potentially sensitive identifying
+ information, the data stored is the result of a one-way MD5 [5] hash
+ computation. The hash includes information from the DHCP client's
+ REQUEST message as well as the domain name itself, so that the data
+ stored in the DHCID RR will be dependent on both the client
+ identification used in the DHCP protocol interaction and the domain
+ name. This means that the DHCID RDATA will vary if a single client
+ is associated over time with more than one name. This makes it
+ difficult to 'track' a client as it is associated with various domain
+ names.
+
+ The MD5 hash algorithm has been shown to be weaker than the SHA-1
+ algorithm; it could therefore be argued that SHA-1 is a better
+ choice. However, SHA-1 is significantly slower than MD5. A
+ successful attack of MD5's weakness does not reveal the original data
+ that was used to generate the signature, but rather provides a new
+ set of input data that will produce the same signature. Because we
+ are using the MD5 hash to conceal the original data, the fact that an
+ attacker could produce a different plaintext resulting in the same
+ MD5 output is not significant concern.
+
+3. The DHCID RR
+
+ The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
+ DHCID RR is only defined in the IN class. DHCID RRs cause no
+ additional section processing. The DHCID RR is not a singleton type.
+
+
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 3]
+
+Internet-Draft The DHCID RR July 2004
+
+
+3.1 DHCID RDATA format
+
+ The RDATA section of a DHCID RR in transmission contains RDLENGTH
+ bytes of binary data. The format of this data and its interpretation
+ by DHCP servers and clients are described below.
+
+ DNS software should consider the RDATA section to be opaque. DHCP
+ clients or servers use the DHCID RR to associate a DHCP client's
+ identity with a DNS name, so that multiple DHCP clients and servers
+ may deterministically perform dynamic DNS updates to the same zone.
+ From the updater's perspective, the DHCID resource record RDATA
+ consists of a 16-bit identifier type, in network byte order, followed
+ by one or more bytes representing the actual identifier:
+
+ < 16 bits > DHCP identifier used
+ < n bytes > MD5 digest
+
+
+3.2 DHCID Presentation Format
+
+ In DNS master files, the RDATA is represented as a single block in
+ base 64 encoding identical to that used for representing binary data
+ in RFC 2535 [8]. The data may be divided up into any number of white
+ space separated substrings, down to single base 64 digits, which are
+ concatenated to form the complete RDATA. These substrings can span
+ lines using the standard parentheses.
+
+3.3 The DHCID RR Type Codes
+
+ The DHCID RR Type Code specifies what data from the DHCP client's
+ request was used as input into the hash function. The type codes are
+ defined in a registry maintained by IANA, as specified in Section 7.
+ The initial list of assigned values for the type code is:
+
+ 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
+ 0x0001 = The data portion from a DHCPv4 client's Client Identifier
+ option [9].
+ 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
+ client's Client Identifier option [10] or the DUID field from a
+ DHCPv4 client's Client Identifier option [12]).
+
+ 0x0003 - 0xfffe = Available to be assigned by IANA.
+
+ 0xffff = RESERVED
+
+3.4 Computation of the RDATA
+
+ The DHCID RDATA is formed by concatenating the two type bytes with
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 4]
+
+Internet-Draft The DHCID RR July 2004
+
+
+ some variable-length identifying data.
+
+ < type > < data >
+
+ The RDATA for all type codes other than 0xffff, which is reserved for
+ future expansion, is formed by concatenating the two type bytes and a
+ 16-byte MD5 hash value. The input to the hash function is defined to
+ be:
+
+ data = MD5(< identifier > < FQDN >)
+
+ The FQDN is represented in the buffer in unambiguous canonical form
+ as described in RFC 2535 [8], section 8.1. The type code and the
+ identifier are related as specified in Section 3.3: the type code
+ describes the source of the identifier.
+
+ When the updater is using the client's link-layer address as the
+ identifier, the first two bytes of the DHCID RDATA MUST be zero. To
+ generate the rest of the resource record, the updater computes a
+ one-way hash using the MD5 algorithm across a buffer containing the
+ client's network hardware type, link-layer address, and the FQDN
+ data. Specifically, the first byte of the buffer contains the
+ network hardware type as it appeared in the DHCP 'htype' field of the
+ client's DHCPREQUEST message. All of the significant bytes of the
+ chaddr field in the client's DHCPREQUEST message follow, in the same
+ order in which the bytes appear in the DHCPREQUEST message. The
+ number of significant bytes in the 'chaddr' field is specified in the
+ 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified
+ above, follows.
+
+ When the updater is using the DHCPv4 Client Identifier option sent by
+ the client in its DHCPREQUEST message, the first two bytes of the
+ DHCID RR MUST be 0x0001, in network byte order. The rest of the
+ DHCID RR MUST contain the results of computing an MD5 hash across the
+ payload of the option, followed by the FQDN. The payload of the
+ option consists of the bytes of the option following the option code
+ and length.
+
+ When the updater is using the DHCPv6 DUID sent by the client in its
+ REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
+ in network byte order. The rest of the DHCID RR MUST contain the
+ results of computing an MD5 hash across the payload of the option,
+ followed by the FQDN. The payload of the option consists of the
+ bytes of the option following the option code and length.
+
+3.5 Examples
+
+
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 5]
+
+Internet-Draft The DHCID RR July 2004
+
+
+3.5.1 Example 1
+
+ A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
+ Ethernet MAC address 01:02:03:04:05:06 using domain name
+ "client.example.com" uses the client's link-layer address to identify
+ the client. The DHCID RDATA is composed by setting the two type
+ bytes to zero, and performing an MD5 hash computation across a buffer
+ containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
+ address, and the domain name (represented as specified in Section
+ 3.4).
+
+ client.example.com. A 10.0.0.1
+ client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
+
+
+3.5.2 Example 2
+
+ A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
+ included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
+ in its DHCP request. The server updates the name "chi.example.com"
+ on the client's behalf, and uses the DHCP client identifier option
+ data as input in forming a DHCID RR. The DHCID RDATA is formed by
+ setting the two type bytes to the value 0x0001, and performing an MD5
+ hash computation across a buffer containing the seven bytes from the
+ client-id option and the FQDN (represented as specified in Section
+ 3.4).
+
+ chi.example.com. A 10.0.12.99
+ chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
+
+
+4. Use of the DHCID RR
+
+ This RR MUST NOT be used for any purpose other than that detailed in
+ "Resolution of DNS Name Conflicts" [1]. Although this RR contains
+ data that is opaque to DNS servers, the data must be consistent
+ across all entities that update and interpret this record.
+ Therefore, new data formats may only be defined through actions of
+ the DHC Working Group, as a result of revising [1].
+
+5. Updater Behavior
+
+ The data in the DHCID RR allows updaters to determine whether more
+ than one DHCP client desires to use a particular FQDN. This allows
+ site administrators to establish policy about DNS updates. The DHCID
+ RR does not establish any policy itself.
+
+ Updaters use data from a DHCP client's request and the domain name
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 6]
+
+Internet-Draft The DHCID RR July 2004
+
+
+ that the client desires to use to compute a client identity hash, and
+ then compare that hash to the data in any DHCID RRs on the name that
+ they wish to associate with the client's IP address. If an updater
+ discovers DHCID RRs whose RDATA does not match the client identity
+ that they have computed, the updater SHOULD conclude that a different
+ client is currently associated with the name in question. The
+ updater SHOULD then proceed according to the site's administrative
+ policy. That policy might dictate that a different name be selected,
+ or it might permit the updater to continue.
+
+6. Security Considerations
+
+ The DHCID record as such does not introduce any new security problems
+ into the DNS. In order to avoid exposing private information about
+ DHCP clients to public scrutiny, a one-way hash is used to obscure
+ all client information. In order to make it difficult to 'track' a
+ client by examining the names associated with a particular hash
+ value, the FQDN is included in the hash computation. Thus, the RDATA
+ is dependent on both the DHCP client identification data and on each
+ FQDN associated with the client.
+
+ Administrators should be wary of permitting unsecured DNS updates to
+ zones which are exposed to the global Internet. Both DHCP clients
+ and servers SHOULD use some form of update authentication (e.g., TSIG
+ [11]) when performing DNS updates.
+
+7. IANA Considerations
+
+ IANA is requested to allocate an RR type number for the DHCID record
+ type.
+
+ This specification defines a new number-space for the 16-bit type
+ codes associated with the DHCID RR. IANA is requested to establish a
+ registry of the values for this number-space.
+
+ Three initial values are assigned in Section 3.3, and the value
+ 0xFFFF is reserved for future use. New DHCID RR type codes are
+ tentatively assigned after the specification for the associated type
+ code, published as an Internet Draft, has received expert review by a
+ designated expert. The final assignment of DHCID RR type codes is
+ through Standards Action, as defined in RFC 2434 [6].
+
+8. Acknowledgements
+
+ Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
+ Ralph Droms for their review and suggestions.
+
+
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 7]
+
+Internet-Draft The DHCID RR July 2004
+
+
+9. References
+
+9.1 Normative References
+
+ [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
+ DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Mockapetris, P., "Domain names - concepts and facilities", STD
+ 13, RFC 1034, November 1987.
+
+ [4] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+ 1992.
+
+ [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+9.2 Informative References
+
+ [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [8] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+ [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
+ Carney, "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 3315, July 2003.
+
+ [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+ 2845, May 2000.
+
+ [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
+ for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
+
+
+
+
+
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 8]
+
+Internet-Draft The DHCID RR July 2004
+
+
+Authors' Addresses
+
+ Mark Stapp
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ Phone: 978.936.1535
+ EMail: mjs@cisco.com
+
+
+ Ted Lemon
+ Nominum, Inc.
+ 950 Charter St.
+ Redwood City, CA 94063
+ USA
+
+ EMail: mellon@nominum.com
+
+
+ Andreas Gustafsson
+ Nominum, Inc.
+ 950 Charter St.
+ Redwood City, CA 94063
+ USA
+
+ EMail: gson@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 9]
+
+Internet-Draft The DHCID RR July 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 10]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
new file mode 100644
index 00000000000..0783e7b26e1
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt
@@ -0,0 +1,1457 @@
+
+
+DNS Extensions R. Arends
+Internet-Draft Telematica Instituut
+Expires: January 13, 2005 R. Austein
+ ISC
+ M. Larson
+ VeriSign
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ July 15, 2004
+
+
+ DNS Security Introduction and Requirements
+ draft-ietf-dnsext-dnssec-intro-11
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 13, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ The Domain Name System Security Extensions (DNSSEC) add data origin
+ authentication and data integrity to the Domain Name System. This
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 1]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ document introduces these extensions, and describes their
+ capabilities and limitations. This document also discusses the
+ services that the DNS security extensions do and do not provide.
+ Last, this document describes the interrelationships between the
+ group of documents that collectively describe DNSSEC.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
+ 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8
+ 3.1 Data Origin Authentication and Data Integrity . . . . . . 8
+ 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9
+ 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11
+ 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12
+ 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14
+ 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15
+ 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16
+ 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16
+ 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16
+ 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17
+ 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18
+ 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . 20
+ 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
+ 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
+ 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+ Intellectual Property and Copyright Statements . . . . . . . . 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 2]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+1. Introduction
+
+ This document introduces the Domain Name System Security Extensions
+ (DNSSEC). This document and its two companion documents
+ ([I-D.ietf-dnsext-dnssec-records] and
+ [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
+ security extensions defined in RFC 2535 [RFC2535] and its
+ predecessors. These security extensions consist of a set of new
+ resource record types and modifications to the existing DNS protocol
+ [RFC1035]. The new records and protocol modifications are not fully
+ described in this document, but are described in a family of
+ documents outlined in Section 10. Section 3 and Section 4 describe
+ the capabilities and limitations of the security extensions in
+ greater detail. Section 5 discusses the scope of the document set.
+ Section 6, Section 7, Section 8, and Section 9 discuss the effect
+ that these security extensions will have on resolvers, stub
+ resolvers, zones and name servers.
+
+ This document and its two companions update and obsolete RFCs 2535
+ [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
+ [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
+ [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but
+ does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
+ [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
+ of 3226 [RFC3226] (dealing with DNSSEC).
+
+ The DNS security extensions provide origin authentication and
+ integrity protection for DNS data, as well as a means of public key
+ distribution. These extensions do not provide confidentiality.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 3]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+2. Definitions of Important DNSSEC Terms
+
+ 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
+ RRsets forms a chain of signed data, with each link in the chain
+ vouching for the next. A DNSKEY RR is used to verify the
+ signature covering a DS RR and allows the DS RR to be
+ authenticated. The DS RR contains a hash of another DNSKEY RR and
+ this new DNSKEY RR is authenticated by matching the hash in the DS
+ RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset
+ and, in turn, some DNSKEY RR in this set may be used to
+ authenticate another DS RR and so forth until the chain finally
+ ends with a DNSKEY RR whose corresponding private key signs the
+ desired DNS data. For example, the root DNSKEY RRset can be used
+ to authenticate the DS RRset for "example." The "example." DS
+ RRset contains a hash that matches some "example." DNSKEY, and
+ this DNSKEY's corresponding private key signs the "example."
+ DNSKEY RRset. Private key counterparts of the "example." DNSKEY
+ RRset sign data records such as "www.example." as well as DS RRs
+ for delegations such as "subzone.example."
+
+ Authentication Key: A public key that a security-aware resolver has
+ verified and can therefore use to authenticate data. A
+ security-aware resolver can obtain authentication keys in three
+ ways. First, the resolver is generally configured to know about
+ at least one public key; this configured data is usually either
+ the public key itself or a hash of the public key as found in the
+ DS RR (see "trust anchor"). Second, the resolver may use an
+ authenticated public key to verify a DS RR and the DNSKEY RR to
+ which the DS RR refers. Third, the resolver may be able to
+ determine that a new public key has been signed by the private key
+ corresponding to another public key which the resolver has
+ verified. Note that the resolver must always be guided by local
+ policy when deciding whether to authenticate a new public key,
+ even if the local policy is simply to authenticate any new public
+ key for which the resolver is able verify the signature.
+
+ 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).
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 4]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ Island of Security: Term used to describe a signed, delegated zone
+ that does not have an authentication chain from its delegating
+ parent. That is, there is no DS RR containing a hash of a DNSKEY
+ RR for the island in its delegating parent zone (see
+ [I-D.ietf-dnsext-dnssec-records]). An island of security is
+ served by security-aware name servers and may provide
+ authentication chains to any delegated child zones. Responses
+ from an island of security or its descendents can only be
+ authenticated if its authentication keys can be authenticated by
+ some trusted means out of band from the DNS protocol.
+
+ Key Signing Key (KSK): An authentication key that corresponds to a
+ private key used to sign one or more other authentication keys for
+ a given zone. Typically, the private key corresponding to a key
+ signing key will sign a zone signing key, which in turn has a
+ corresponding private key which will sign other zone data. Local
+ policy may require the zone signing key to be changed frequently,
+ while the key signing key may have a longer validity period in
+ order to provide a more stable secure entry point into the zone.
+ Designating an authentication key as a key signing key is purely
+ an operational issue: DNSSEC validation does not distinguish
+ between key signing keys and other DNSSEC authentication keys, and
+ it is possible to use a single key as both a key signing key and a
+ zone signing key. Key signing keys are discussed in more detail
+ in [RFC3757]. Also see: zone signing key.
+
+ Non-Validating Security-Aware Stub Resolver: A security-aware stub
+ resolver which trusts one or more security-aware recursive name
+ servers to perform most of the tasks discussed in this document
+ set on its behalf. In particular, a non-validating security-aware
+ stub resolver is an entity which sends DNS queries, receives DNS
+ responses, and is capable of establishing an appropriately secured
+ channel to a security-aware recursive name server which will
+ provide these services on behalf of the security-aware stub
+ resolver. See also: security-aware stub resolver, validating
+ security-aware stub resolver.
+
+ Non-Validating Stub Resolver: A less tedious term for a
+ non-validating security-aware stub resolver.
+
+ Security-Aware Name Server: An entity acting in the role of a name
+ server (defined in section 2.4 of [RFC1034]) that understands the
+ DNS security extensions defined in this document set. In
+ particular, a security-aware name server is an entity which
+ receives DNS queries, sends DNS responses, supports the EDNS0
+ [RFC2671] message size extension and the DO bit [RFC3225], and
+ supports the RR types and message header bits defined in this
+ document set.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 5]
+
+
+ Security-Aware Recursive Name Server: An entity which acts in both
+ the security-aware name server and security-aware resolver roles.
+ A more cumbersome equivalent phrase would be "a security-aware
+ name server which offers recursive service".
+
+ Security-Aware Resolver: An entity acting in the role of a resolver
+ (defined in section 2.4 of [RFC1034]) which understands the DNS
+ security extensions defined in this document set. In particular,
+ a security-aware resolver is an entity which sends DNS queries,
+ receives DNS responses, supports the EDNS0 [RFC2671] message size
+ extension and the DO bit [RFC3225], and is capable of using the RR
+ types and message header bits defined in this document set to
+ provide DNSSEC services.
+
+ Security-Aware Stub Resolver: An entity acting in the role of a stub
+ resolver (defined in section 5.3.1 of [RFC1034]) which has enough
+ of an understanding the DNS security extensions defined in this
+ document set to provide additional services not available from a
+ security-oblivious stub resolver. Security-aware stub resolvers
+ may be either "validating" or "non-validating" depending on
+ whether the stub resolver attempts to verify DNSSEC signatures on
+ its own or trusts a friendly security-aware name server to do so.
+ See also: validating stub resolver, non-validating stub resolver.
+
+ Security-Oblivious <anything>: An <anything> that is not
+ "security-aware".
+
+ Signed Zone: A zone whose RRsets are signed and which contains
+ properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS
+ records.
+
+ Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A
+ validating security-aware resolver uses this public key or hash as
+ a starting point for building the authentication chain to a signed
+ DNS response. In general, a validating resolver will need to
+ obtain the initial values of its trust anchors via some secure or
+ trusted means outside the DNS protocol. Presence of a trust
+ anchor also implies that the resolver should expect the zone to
+ which the trust anchor points to be signed.
+
+ Unsigned Zone: A zone that is not signed.
+
+ Validating Security-Aware Stub Resolver: A security-aware resolver
+ that sends queries in recursive mode but which performs signature
+ validation on its own rather than just blindly trusting an
+ upstream security-aware recursive name server. See also:
+ security-aware stub resolver, non-validating security-aware stub
+ resolver.
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 6]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ Validating Stub Resolver: A less tedious term for a validating
+ security-aware stub resolver.
+
+ Zone Signing Key (ZSK): An authentication key that corresponds to a
+ private key used to sign a zone. Typically a zone signing key
+ will be part of the same DNSKEY RRset as the key signing key whose
+ corresponding private key signs this DNSKEY RRset, but the zone
+ signing key is used for a slightly different purpose, and may
+ differ from the key signing key in other ways, such as validity
+ lifetime. Designating an authentication key as a zone signing key
+ is purely an operational issue: DNSSEC validation does not
+ distinguish between zone signing keys and other DNSSEC
+ authentication keys, and it is possible to use a single key as
+ both a key signing key and a zone signing key. See also: key
+ signing key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 7]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+3. Services Provided by DNS Security
+
+ The Domain Name System (DNS) security extensions provide origin
+ authentication and integrity assurance services for DNS data,
+ including mechanisms for authenticated denial of existence of DNS
+ data. These mechanisms are described below.
+
+ These mechanisms require changes to the DNS protocol. DNSSEC adds
+ four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
+ new message header bits (CD and AD). In order to support the larger
+ DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
+ requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support
+ for the DO bit [RFC3225], so that a security-aware resolver can
+ indicate in its queries that it wishes to receive DNSSEC RRs in
+ response messages.
+
+ These services protect against most of the threats to the Domain Name
+ System described in [I-D.ietf-dnsext-dns-threats].
+
+3.1 Data Origin Authentication and Data Integrity
+
+ DNSSEC provides authentication by associating cryptographically
+ generated digital signatures with DNS RRsets. These digital
+ signatures are stored in a new resource record, the RRSIG record.
+ Typically, there will be a single private key that signs a zone's
+ data, but multiple keys are possible: for example, there may be keys
+ for each of several different digital signature algorithms. If a
+ security-aware resolver reliably learns a zone's public key, it can
+ authenticate that zone's signed data. An important DNSSEC concept is
+ that the key that signs a zone's data is associated with the zone
+ itself and not with the zone's authoritative name servers (public
+ keys for DNS transaction authentication mechanisms may also appear in
+ zones, as described in [RFC2931], but DNSSEC itself is concerned with
+ object security of DNS data, not channel security of DNS
+ transactions. The keys associated with transaction security may be
+ stored in different RR types. See [RFC3755] for details.).
+
+ A security-aware resolver can learn a zone's public key either by
+ having a trust anchor configured into the resolver or by normal DNS
+ resolution. To allow the latter, public keys are stored in a new
+ type of resource record, the DNSKEY RR. Note that the private keys
+ used to sign zone data must be kept secure, and should be stored
+ offline when practical to do so. To discover a public key reliably
+ via DNS resolution, the target key itself needs to be signed by
+ either a configured authentication key or another key that has been
+ authenticated previously. Security-aware resolvers authenticate zone
+ information by forming an authentication chain from a newly learned
+ public key back to a previously known authentication public key,
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 8]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ which in turn either has been configured into the resolver or must
+ have been learned and verified previously. Therefore, the resolver
+ must be configured with at least one trust anchor. If the configured
+ key is a zone signing key, then it will authenticate the associated
+ zone; if the configured key is a key signing key, it will
+ authenticate a zone signing key. If the resolver has been configured
+ with the hash of a key rather than the key itself, the resolver may
+ need to obtain the key via a DNS query. To help security-aware
+ resolvers establish this authentication chain, security-aware name
+ servers attempt to send the signature(s) needed to authenticate a
+ zone's public key(s) in the DNS reply message along with the public
+ key itself, provided there is space available in the message.
+
+ The Delegation Signer (DS) RR type simplifies some of the
+ administrative tasks involved in signing delegations across
+ organizational boundaries. The DS RRset resides at a delegation
+ point in a parent zone and indicates the public key(s) corresponding
+ to the private key(s) used to self-sign the DNSKEY RRset at the
+ delegated child zone's apex. The administrator of the child zone, in
+ turn, uses the private key(s) corresponding to one or more of the
+ public keys in this DNSKEY RRset to sign the child zone's data. The
+ typical authentication chain is therefore
+ DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
+ DS->DNSKEY subchains. DNSSEC permits more complex authentication
+ chains, such as additional layers of DNSKEY RRs signing other DNSKEY
+ RRs within a zone.
+
+ A security-aware resolver normally constructs this authentication
+ chain from the root of the DNS hierarchy down to the leaf zones based
+ on configured knowledge of the public key for the root. Local
+ policy, however, may also allow a security-aware resolver to use one
+ or more configured public keys (or hashes of public keys) other than
+ the root public key, or may not provide configured knowledge of the
+ root public key, or may prevent the resolver from using particular
+ public keys for arbitrary reasons even if those public keys are
+ properly signed with verifiable signatures. DNSSEC provides
+ mechanisms by which a security-aware resolver can determine whether
+ an RRset's signature is "valid" within the meaning of DNSSEC. In the
+ final analysis however, authenticating both DNS keys and data is a
+ matter of local policy, which may extend or even override the
+ protocol extensions defined in this document set. See Section 5 for
+ further discussion.
+
+3.2 Authenticating Name and Type Non-Existence
+
+ The security mechanism described in Section 3.1 only provides a way
+ to sign existing RRsets in a zone. The problem of providing negative
+ responses with the same level of authentication and integrity
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 9]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ requires the use of another new resource record type, the NSEC
+ record. The NSEC record allows a security-aware resolver to
+ authenticate a negative reply for either name or type non-existence
+ via the same mechanisms used to authenticate other DNS replies. Use
+ of NSEC records requires a canonical representation and ordering for
+ domain names in zones. Chains of NSEC records explicitly describe
+ the gaps, or "empty space", between domain names in a zone, as well
+ as listing the types of RRsets present at existing names. Each NSEC
+ record is signed and authenticated using the mechanisms described in
+ Section 3.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 10]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+4. Services Not Provided by DNS Security
+
+ DNS was originally designed with the assumptions that the DNS will
+ return the same answer to any given query regardless of who may have
+ issued the query, and that all data in the DNS is thus visible.
+ Accordingly, DNSSEC is not designed to provide confidentiality,
+ access control lists, or other means of differentiating between
+ inquirers.
+
+ DNSSEC provides no protection against denial of service attacks.
+ Security-aware resolvers and security-aware name servers are
+ vulnerable to an additional class of denial of service attacks based
+ on cryptographic operations. Please see Section 12 for details.
+
+ The DNS security extensions provide data and origin authentication
+ for DNS data. The mechanisms outlined above are not designed to
+ protect operations such as zone transfers and dynamic update
+ [RFC3007]. Message authentication schemes described in [RFC2845] and
+ [RFC2931] address security operations that pertain to these
+ transactions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 11]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+5. Scope of the DNSSEC Document Set and Last Hop Issues
+
+ The specification in this document set defines the behavior for zone
+ signers and security-aware name servers and resolvers in such a way
+ that the validating entities can unambiguously determine the state of
+ the data.
+
+ A validating resolver can determine these 4 states:
+
+ Secure: The validating resolver has a trust anchor, a chain of trust
+ and is able to verify all the signatures in the response.
+
+ Insecure: The validating resolver has a trust anchor, a chain of
+ trust, and, at some delegation point, signed proof of the
+ non-existence of a DS record. That indicates that subsequent
+ branches in the tree are provably insecure. A validating resolver
+ may have local policy to mark parts of the domain space as
+ insecure.
+
+ Bogus: The validating resolver has a trust anchor and there is a
+ secure delegation which is indicating that subsidiary data will be
+ signed, but the response fails to validate due to one or more
+ reasons: missing signatures, expired signatures, signatures with
+ unsupported algorithms, data missing which the relevant NSEC RR
+ says should be present, and so forth.
+
+ Indeterminate: There is no trust anchor which would indicate that a
+ specific portion of the tree is secure. This is the default
+ operation mode.
+
+ This specification only defines how security aware name servers can
+ signal non-validating stub resolvers that data was found to be bogus
+ (using RCODE=2, "Server Failure" -- see
+ [I-D.ietf-dnsext-dnssec-protocol]).
+
+ There is a mechanism for security aware name servers to signal
+ security-aware stub resolvers that data was found to be secure (using
+ the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).
+
+ This specification does not define a format for communicating why
+ responses were found to be bogus or marked as insecure. The current
+ signaling mechanism does not distinguish between indeterminate and
+ insecure.
+
+ A method for signaling advanced error codes and policy between a
+ security aware stub resolver and security aware recursive nameservers
+ is a topic for future work, as is the interface between a security
+ aware resolver and the applications that use it. Note, however, that
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 12]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ the lack of the specification of such communication does not prohibit
+ deployment of signed zones or the deployment of security aware
+ recursive name servers that prohibit propagation of bogus data to the
+ applications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 13]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+6. Resolver Considerations
+
+ A security-aware resolver needs to be able to perform cryptographic
+ functions necessary to verify digital signatures using at least the
+ mandatory-to-implement algorithm(s). Security-aware resolvers must
+ also be capable of forming an authentication chain from a newly
+ learned zone back to an authentication key, as described above. This
+ process might require additional queries to intermediate DNS zones to
+ obtain necessary DNSKEY, DS and RRSIG records. A security-aware
+ resolver should be configured with at least one trust anchor as the
+ starting point from which it will attempt to establish authentication
+ chains.
+
+ If a security-aware resolver is separated from the relevant
+ authoritative name servers by a recursive name server or by any sort
+ of device which acts as a proxy for DNS, and if the recursive name
+ server or proxy is not security-aware, the security-aware resolver
+ may not be capable of operating in a secure mode. For example, if a
+ security-aware resolver's packets are routed through a network
+ address translation device that includes a DNS proxy which is not
+ security-aware, the security-aware resolver may find it difficult or
+ impossible to obtain or validate signed DNS data.
+
+ If a security-aware resolver must rely on an unsigned zone or a name
+ server that is not security aware, the resolver may not be able to
+ validate DNS responses, and will need a local policy on whether to
+ accept unverified responses.
+
+ A security-aware resolver should take a signature's validation period
+ into consideration when determining the TTL of data in its cache, to
+ avoid caching signed data beyond the validity period of the
+ signature, but should also allow for the possibility that the
+ security-aware resolver's own clock is wrong. Thus, a security-aware
+ resolver which is part of a security-aware recursive name server will
+ need to pay careful attention to the DNSSEC "checking disabled" (CD)
+ bit [I-D.ietf-dnsext-dnssec-records]. 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.
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 14]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+7. Stub Resolver Considerations
+
+ Although not strictly required to do so by the protocol, most DNS
+ queries originate from stub resolvers. Stub resolvers, by
+ definition, are minimal DNS resolvers which use recursive query mode
+ to offload most of the work of DNS resolution to a recursive name
+ server. Given the widespread use of stub resolvers, the DNSSEC
+ architecture has to take stub resolvers into account, but the
+ security features needed in a stub resolver differ in some respects
+ from those needed in a full security-aware resolver.
+
+ Even a security-oblivious stub resolver may get some benefit from
+ DNSSEC if the recursive name servers it uses are security-aware, but
+ for the stub resolver to place any real reliance on DNSSEC services,
+ the stub resolver must trust both the recursive name servers in
+ question and the communication channels between itself and those name
+ servers. The first of these issues is a local policy issue: in
+ essence, a 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 that does trust both its recursive
+ name servers and its communication channel to them may choose to
+ examine the setting of the AD bit in the message header of the
+ response messages it receives. The stub resolver can use this flag
+ bit as a hint to find out whether the recursive name server was able
+ to validate signatures for all of the data in the Answer and
+ Authority sections of the response.
+
+ There is one more step that a security-aware stub resolver can take
+ if, for whatever reason, it is not able to establish a useful trust
+ relationship with the recursive name servers which it uses: it can
+ perform its own signature validation, by setting the Checking
+ Disabled (CD) bit in its query messages. A validating stub resolver
+ is thus able to treat the DNSSEC signatures as a trust relationship
+ between the zone administrator and the stub resolver itself.
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 15]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+8. Zone Considerations
+
+ There are several differences between signed and unsigned zones. A
+ signed zone will contain additional security-related records (RRSIG,
+ DNSKEY, DS and NSEC records). RRSIG and NSEC records may be
+ generated by a signing process prior to serving the zone. The RRSIG
+ records that accompany zone data have defined inception and
+ expiration times, which establish a validity period for the
+ signatures and the zone data the signatures cover.
+
+8.1 TTL values vs. RRSIG validity period
+
+ It is important to note the distinction between a RRset's TTL value
+ and the signature validity period specified by the RRSIG RR covering
+ that RRset. DNSSEC does not change the definition or function of the
+ TTL value, which is intended to maintain database coherency in
+ caches. A caching resolver purges RRsets from its cache no later
+ than the end of the time period specified by the TTL fields of those
+ RRsets, regardless of whether or not the resolver is security-aware.
+
+ The inception and expiration fields in the RRSIG RR
+ [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time
+ period during which the signature can be used to validate the covered
+ RRset. The signatures associated with signed zone data are only
+ valid for the time period specified by these fields in the RRSIG RRs
+ in question. TTL values cannot extend the validity period of signed
+ RRsets in a resolver's cache, but the resolver may use the time
+ remaining before expiration of the signature validity period of a
+ signed RRset as an upper bound for the TTL of the signed RRset and
+ its associated RRSIG RR in the resolver's cache.
+
+8.2 New Temporal Dependency Issues for Zones
+
+ Information in a signed zone has a temporal dependency which did not
+ exist in the original DNS protocol. A signed zone requires regular
+ maintenance to ensure that each RRset in the zone has a current valid
+ RRSIG RR. The signature validity period of an RRSIG RR is an
+ interval during which the signature for one particular signed RRset
+ can be considered valid, and the signatures of different RRsets in a
+ zone may expire at different times. Re-signing one or more RRsets in
+ a zone will change one or more RRSIG RRs, which in turn will require
+ incrementing the zone's SOA serial number to indicate that a zone
+ change has occurred and re-signing the SOA RRset itself. Thus,
+ re-signing any RRset in a zone may also trigger DNS NOTIFY messages
+ and zone transfers operations.
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 16]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+9. Name Server Considerations
+
+ A security-aware name server should include the appropriate DNSSEC
+ records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from
+ resolvers which have signaled their willingness to receive such
+ records via use of the DO bit in the EDNS header, subject to message
+ size limitations. Since inclusion of these DNSSEC RRs could easily
+ cause UDP message truncation and fallback to TCP, a security-aware
+ name server must also support the EDNS "sender's UDP payload"
+ mechanism.
+
+ If possible, the private half of each DNSSEC key pair should be kept
+ offline, but this will not be possible for a zone for which DNS
+ dynamic update has been enabled. In the dynamic update case, the
+ primary master server for the zone will have to re-sign the zone when
+ updated, so the private key corresponding to 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 signing
+ key(s) in such a case can still be kept offline and may have a longer
+ useful lifetime than the zone signing key(s).
+
+ DNSSEC, by itself, is not enough to protect the integrity of an
+ entire zone during zone transfer operations, since even a signed zone
+ contains some unsigned, nonauthoritative data if the zone has any
+ children. Therefore, zone maintenance operations will require some
+ additional mechanisms (most likely some form of channel security,
+ such as TSIG, SIG(0), or IPsec).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 17]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+10. DNS Security Document Family
+
+ The DNSSEC document set can be partitioned into several main groups,
+ under the larger umbrella of the DNS base protocol documents.
+
+ The "DNSSEC protocol document set" refers to the three documents
+ which form the core of the DNS security extensions:
+ 1. DNS Security Introduction and Requirements (this document)
+ 2. Resource Records for DNS Security Extensions
+ [I-D.ietf-dnsext-dnssec-records]
+ 3. Protocol Modifications for the DNS Security Extensions
+ [I-D.ietf-dnsext-dnssec-protocol]
+
+ Additionally, any document that would add to, or change the core DNS
+ Security extensions would fall into this category. This includes any
+ future work on the communication between security-aware stub
+ resolvers and upstream security-aware recursive name servers.
+
+ The "Digital Signature Algorithm Specification" document set refers
+ to the group of documents that describe how specific digital
+ signature algorithms should be implemented to fit the DNSSEC resource
+ record format. Each document in this set deals with a specific
+ digital signature algorithm.
+
+ The "Transaction Authentication Protocol" document set refers to the
+ group of documents that deal with DNS message authentication,
+ including secret key establishment and verification. While not
+ strictly part of the DNSSEC specification as defined in this set of
+ documents, this group is noted because of its relationship to DNSSEC.
+
+ The final document set, "New Security Uses", refers to documents that
+ seek to use proposed DNS Security extensions for other security
+ related purposes. DNSSEC does not provide any direct security for
+ these new uses, but may be used to support them. Documents that fall
+ in this category include the use of DNS in the storage and
+ distribution of certificates [RFC2538].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 18]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+11. IANA Considerations
+
+ This overview document introduces no new IANA considerations. Please
+ see [I-D.ietf-dnsext-dnssec-records] for a complete review of the
+ IANA considerations introduced by DNSSEC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 19]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+12. Security Considerations
+
+ This document introduces the DNS security extensions and describes
+ the document set that contains the new security records and DNS
+ protocol modifications. The extensions provide data origin
+ authentication and data integrity using digital signatures over
+ resource record sets.This document discusses the capabilities and
+ limitations of these extensions.
+
+ In order for a security-aware resolver to validate a DNS response,
+ all zones along the path from the trusted starting point to the zone
+ containing the response zones must be signed, and all name servers
+ and resolvers involved in the resolution process must be
+ security-aware, as defined in this document set. A security-aware
+ resolver cannot verify responses originating from an unsigned zone,
+ from a zone not served by a security-aware name server, or for any
+ DNS data which the resolver is only able to obtain through a
+ recursive name server which is not security-aware. If there is a
+ break in the authentication chain such that a security-aware resolver
+ cannot obtain and validate the authentication keys it needs, then the
+ security-aware resolver cannot validate the affected DNS data.
+
+ This document briefly discusses other methods of adding security to a
+ DNS query, such as using a channel secured by IPsec or using a DNS
+ transaction authentication mechanism, but transaction security is not
+ part of DNSSEC per se.
+
+ A non-validating security-aware stub resolver, by definition, does
+ not perform DNSSEC signature validation on its own, and thus is
+ vulnerable both to attacks on (and by) the security-aware recursive
+ name servers which perform these checks on its behalf and also to
+ attacks on its communication with those security-aware recursive name
+ servers. Non-validating security-aware stub resolvers should use
+ some form of channel security to defend against the latter threat.
+ The only known defense against the former threat would be for the
+ security-aware stub resolver to perform its own signature validation,
+ at which point, again by definition, it would no longer be a
+ non-validating security-aware stub resolver.
+
+ DNSSEC does not protect against denial of service attacks. DNSSEC
+ makes DNS vulnerable to a new class of denial of service attacks
+ based on cryptographic operations against security-aware resolvers
+ and security-aware name servers, since an attacker can attempt to use
+ DNSSEC mechanisms to consume a victim's resources. This class of
+ attacks takes at least two forms. An attacker may be able to consume
+ resources in a security-aware resolver's signature validation code by
+ tampering with RRSIG RRs in response messages or by constructing
+ needlessly complex signature chains. An attacker may also be able to
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 20]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ consume resources in a security-aware name server which supports DNS
+ dynamic update, by sending a stream of update messages that force the
+ security-aware name server to re-sign some RRsets in the zone more
+ frequently than would otherwise be necessary.
+
+ DNSSEC does not provide confidentiality, due to a deliberate design
+ choice.
+
+ DNSSEC introduces the ability for a hostile party to enumerate all
+ the names in a zone by following the NSEC chain. NSEC RRs assert
+ which names do not exist in a zone by linking from existing name to
+ existing name along a canonical ordering of all the names within a
+ zone. Thus, an attacker can query these NSEC RRs in sequence to
+ obtain all the names in a zone. While not an attack on the DNS
+ itself, this could allow an attacker to map network hosts or other
+ resources by enumerating the contents of a zone.
+
+ DNSSEC introduces significant additional complexity to the DNS, and
+ thus introduces many new opportunities for implementation bugs and
+ misconfigured zones. In particular, enabling DNSSEC signature
+ validation in a resolver may cause entire legitimate zones to become
+ effectively unreachable due to DNSSEC configuration errors or bugs.
+
+ DNSSEC does not protect against tampering with unsigned zone data.
+ Non-authoritative data at zone cuts (glue and NS RRs in the parent
+ zone) are not signed. This does not pose a problem when validating
+ the authentication chain, but does mean that the non-authoritative
+ data itself is vulnerable to tampering during zone transfer
+ operations. Thus, while DNSSEC can provide data origin
+ authentication and data integrity for RRsets, it cannot do so for
+ zones, and other mechanisms 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 21]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+13. Acknowledgements
+
+ 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: Jaap Akkerhuis,
+ Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
+ David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
+ Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
+ Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip
+ Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
+ Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
+ Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
+ Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
+ Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
+ Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid,
+ Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob
+ Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and
+ Suzanne Woolf.
+
+ No doubt the above list is incomplete. We apologize to anyone we
+ left out.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 22]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+14. References
+
+14.1 Normative References
+
+ [I-D.ietf-dnsext-dnssec-protocol]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
+ progress), May 2004.
+
+ [I-D.ietf-dnsext-dnssec-records]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Resource Records for DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-08 (work in progress),
+ May 2004.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+ message size requirements", RFC 3226, December 2001.
+
+ [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
+ Resource Record (RR)", RFC 3445, December 2002.
+
+14.2 Informative References
+
+ [I-D.ietf-dnsext-dns-threats]
+ Atkins, D. and R. Austein, "Threat Analysis Of The Domain
+ Name System", draft-ietf-dnsext-dns-threats-07 (work in
+ progress), April 2004.
+
+ [I-D.ietf-dnsext-nsec-rdata]
+ Schlyter, J., "DNSSEC NSEC RDATA Format",
+ draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
+ 2004.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 23]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+ [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.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+ [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
+ Signing Authority", RFC 3008, November 2000.
+
+ [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+ Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+ [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer", RFC 3755, April 2004.
+
+ [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
+ Entry Point Flag", RFC 3757, April 2004.
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 24]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ EMail: roy.arends@telin.nl
+
+
+ Rob Austein
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ EMail: sra@isc.org
+
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Dan Massey
+ USC Information Sciences Institute
+ 3811 N. Fairfax Drive
+ Arlington, VA 22203
+ USA
+
+ EMail: masseyd@isi.edu
+
+
+ Scott Rose
+ National Institute for Standards and Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 25]
+
+Internet-Draft DNSSEC Introduction and Requirements July 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 26]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
new file mode 100644
index 00000000000..5728b35c9ba
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt
@@ -0,0 +1,3193 @@
+
+
+DNS Extensions R. Arends
+Internet-Draft Telematica Instituut
+Expires: January 13, 2005 M. Larson
+ VeriSign
+ R. Austein
+ ISC
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ July 15, 2004
+
+
+ Protocol Modifications for the DNS Security Extensions
+ draft-ietf-dnsext-dnssec-protocol-07
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 13, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document is part of a family of documents which describe the DNS
+ Security Extensions (DNSSEC). The DNS Security Extensions are a
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 1]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ collection of new resource records and protocol modifications which
+ add data origin authentication and data integrity to the DNS. This
+ document describes the DNSSEC protocol modifications. This document
+ defines the concept of a signed zone, along with the requirements for
+ serving and resolving using DNSSEC. These techniques allow a
+ security-aware resolver to authenticate both DNS resource records and
+ authoritative DNS error indications.
+
+ This document obsoletes RFC 2535 and incorporates changes from all
+ updates to RFC 2535.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Background and Related Documents . . . . . . . . . . . . . 4
+ 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5
+ 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5
+ 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6
+ 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7
+ 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7
+ 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8
+ 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8
+ 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10
+ 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10
+ 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11
+ 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11
+ 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14
+ 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15
+ 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16
+ 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17
+ 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17
+ 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17
+ 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18
+ 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18
+ 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19
+ 4.2 Signature Verification Support . . . . . . . . . . . . . . 19
+ 4.3 Determining Security Status of Data . . . . . . . . . . . 20
+ 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20
+ 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21
+ 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22
+ 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22
+ 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23
+ 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23
+ 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 2]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23
+ 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24
+ 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
+ 5.1 Special Considerations for Islands of Security . . . . . . 26
+ 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26
+ 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27
+ 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28
+ 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28
+ 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 Resolver Behavior When Signatures Do Not Validate . . . . 32
+ 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
+ 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
+ 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36
+ 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 . . . . . . . . . . . . . . . . . . . . 50
+ B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51
+ B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52
+ C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54
+ C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54
+ C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54
+ C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55
+ C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55
+ C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55
+ C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55
+ C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56
+ C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56
+ C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56
+ Intellectual Property and Copyright Statements . . . . . . . . 57
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 3]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) are a collection of new resource
+ records and protocol modifications which add data origin
+ authentication and data integrity to the DNS. This document defines
+ the DNSSEC protocol modifications. Section 2 of this document
+ defines the concept of a signed zone and lists the requirements for
+ zone signing. Section 3 describes the modifications to authoritative
+ name server behavior necessary to handle signed zones. Section 4
+ describes the behavior of entities which include security-aware
+ resolver functions. Finally, Section 5 defines how to use DNSSEC RRs
+ to authenticate a response.
+
+1.1 Background and Related Documents
+
+ The reader is assumed to be familiar with the basic DNS concepts
+ described in [RFC1034] and [RFC1035].
+
+ This document is part of a family of documents that define DNSSEC.
+ An introduction to DNSSEC and definition of common terms can be found
+ in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be
+ familiar with this document. A definition of the DNSSEC resource
+ records can be found in [I-D.ietf-dnsext-dnssec-records].
+
+1.2 Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119. [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 4]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+2. Zone Signing
+
+ DNSSEC introduces the concept of signed zones. A signed zone
+ includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to
+ the rules specified in Section 2.1, Section 2.2, Section 2.3 and
+ Section 2.4, respectively. A zone that does not include these
+ records according to the rules in this section is an unsigned zone.
+
+ DNSSEC requires a change to the definition of the CNAME resource
+ record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG
+ and NSEC RRs to appear at the same owner name as a CNAME RR.
+
+ DNSSEC specifies the placement of two new RR types, NSEC and DS,
+ which can be placed at the parental side of a zone cut (that is, at a
+ delegation point). This is an exception to the general prohibition
+ against putting data in the parent zone at a zone cut. Section 2.6
+ describes this change.
+
+2.1 Including DNSKEY RRs in a Zone
+
+ To sign a zone, the zone's administrator generates one or more
+ public/private key pairs and uses the private key(s) to sign
+ authoritative RRsets in the zone. For each private key used to
+ create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
+ containing the corresponding public key. A zone key DNSKEY RR MUST
+ have the Zone Key bit of the flags RDATA field set -- see Section
+ 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated
+ with other DNS operations MAY be stored in DNSKEY RRs that are not
+ marked as zone keys but MUST NOT be used to verify RRSIGs.
+
+ If the zone administrator intends a signed zone to be usable other
+ than as an island of security, the zone apex MUST contain at least
+ one DNSKEY RR to act as a secure entry point into the zone. This
+ secure entry point could then be used as the target of a secure
+ delegation via a corresponding DS RR in the parent zone (see
+ [I-D.ietf-dnsext-dnssec-records]).
+
+2.2 Including RRSIG RRs in a Zone
+
+ For each authoritative RRset in a signed zone, there MUST be at least
+ one RRSIG record that meets all of the following requirements:
+ o The RRSIG owner name is equal to the RRset owner name;
+ o The RRSIG class is equal to the RRset class;
+ o The RRSIG Type Covered field is equal to the RRset type;
+ o The RRSIG Original TTL field is equal to the TTL of the RRset;
+ o The RRSIG RR's TTL is equal to the TTL of the RRset;
+ o The RRSIG Labels field is equal to the number of labels in the
+ RRset owner name, not counting the null root label and not
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 5]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ counting the leftmost label if it is a wildcard;
+ o The RRSIG Signer's Name field is equal to the name of the zone
+ containing the RRset; and
+ o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
+ zone key DNSKEY record at the zone apex.
+
+ The process for constructing the RRSIG RR for a given RRset is
+ described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have
+ multiple RRSIG RRs associated with it.
+
+ An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR
+ would add no value and would create an infinite loop in the signing
+ process.
+
+ The NS RRset that appears at the zone apex name MUST be signed, but
+ the NS RRsets that appear at delegation points (that is, the NS
+ RRsets in the parent zone that delegate the name to the child zone's
+ name servers) MUST NOT be signed. Glue address RRsets associated
+ with delegations MUST NOT be signed.
+
+ There MUST be an RRSIG for each RRset using at least one DNSKEY of
+ each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset
+ itself MUST be signed by each algorithm appearing in the DS RRset
+ located at the delegating parent (if any).
+
+2.3 Including NSEC RRs in a Zone
+
+ Each owner name in the zone which has authoritative data or a
+ delegation point NS RRset MUST have an NSEC resource record. The
+ format of NSEC RRs and the process for constructing the NSEC RR for a
+ given name is described in [I-D.ietf-dnsext-dnssec-records].
+
+ The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
+ value field in the zone SOA RR.
+
+ An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
+ RRset at any particular owner name. That is, the signing process
+ MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
+ not the owner name of any RRset before the zone was signed. The main
+ reasons for this are a desire for namespace consistency between
+ signed and unsigned versions of the same zone and a desire to reduce
+ the risk of response inconsistency in security oblivious recursive
+ name servers.
+
+ The type bitmap of every NSEC resource record in a signed zone MUST
+ indicate the presence of both the NSEC record itself and its
+ corresponding RRSIG record.
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 6]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ The difference between the set of owner names that require RRSIG
+ records and the set of owner names that require NSEC records is
+ subtle and worth highlighting. RRSIG records are present at the
+ owner names of all authoritative RRsets. NSEC records are present at
+ the owner names of all names for which the signed zone is
+ authoritative and also at the owner names of delegations from the
+ signed zone to its children. Neither NSEC nor RRSIG records are
+ present (in the parent zone) at the owner names of glue address
+ RRsets. Note, however, that this distinction is for the most part is
+ only visible during the zone signing process, because NSEC RRsets are
+ authoritative data, and are therefore signed, thus any owner name
+ which has an NSEC RRset will have RRSIG RRs as well in the signed
+ zone.
+
+ The bitmap for the NSEC RR at a delegation point requires special
+ attention. Bits corresponding to the delegation NS RRset and any
+ RRsets for which the parent zone has authoritative data MUST be set;
+ bits corresponding to any non-NS RRset for which the parent is not
+ authoritative MUST be clear.
+
+2.4 Including DS RRs in a Zone
+
+ The DS resource record establishes authentication chains between DNS
+ zones. A DS RRset SHOULD be present at a delegation point when the
+ child zone is signed. The DS RRset MAY contain multiple records,
+ each referencing a public key in the child zone used to verify the
+ RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS
+ RRsets MUST NOT appear at a zone's apex.
+
+ A DS RR SHOULD point to a DNSKEY RR which is present in the child's
+ apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
+ by the corresponding private key.
+
+ The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
+ (that is, the NS RRset from the same zone containing the DS RRset).
+
+ Construction of a DS RR requires knowledge of the corresponding
+ DNSKEY RR in the child zone, which implies communication between the
+ child and parent zones. This communication is an operational matter
+ not covered by this document.
+
+2.5 Changes to the CNAME Resource Record.
+
+ If a CNAME RRset is present at a name in a signed zone, appropriate
+ RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that
+ name for secure dynamic update purposes is also allowed. Other types
+ MUST NOT be present at that name.
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 7]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ This is a modification to the original CNAME definition given in
+ [RFC1034]. The original definition of the CNAME RR did not allow any
+ other types to coexist with a CNAME record, but a signed zone
+ requires NSEC and RRSIG RRs for every authoritative name. To resolve
+ this conflict, this specification modifies the definition of the
+ CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
+
+2.6 DNSSEC RR Types Appearing at Zone Cuts.
+
+ DNSSEC introduced two new RR types that are unusual in that they can
+ appear at the parental side of a zone cut. At the parental side of a
+ zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
+ the owner name. A DS RR could also be present if the zone being
+ delegated is signed and wishes to have a chain of authentication to
+ the parent zone. This is an exception to the original DNS
+ specification ([RFC1034]) which states that only NS RRsets could
+ appear at the parental side of a zone cut.
+
+ This specification updates the original DNS specification to allow
+ NSEC and DS RR types at the parent side of a zone cut. These RRsets
+ are authoritative for the parent when they appear at the parent side
+ of a zone cut.
+
+2.7 Example of a Secure Zone
+
+ Appendix A shows a complete example of a small signed zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 8]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+3. Serving
+
+ This section describes the behavior of entities that include
+ security-aware name server functions. In many cases such functions
+ will be part of a security-aware recursive name server, but a
+ security-aware authoritative name server has some of the same
+ requirements. Functions specific to security-aware recursive name
+ servers are described in Section 3.2; functions specific to
+ authoritative servers are described in Section 3.1.
+
+ The terms "SNAME", "SCLASS", and "STYPE" in the following discussion
+ are as used in [RFC1034].
+
+ A security-aware name server MUST support the EDNS0 [RFC2671] message
+ size extension, MUST support a message size of at least 1220 octets,
+ and SHOULD support a message size of 4000 octets [RFC3226].
+
+ A security-aware name server which receives a DNS query that does not
+ include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
+ treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset,
+ and MUST NOT perform any of the additional processing described
+ below. Since the DS RR type has the peculiar property of only
+ existing in the parent zone at delegation points, DS RRs always
+ require some special processing, as described in Section 3.1.4.1.
+
+ Security aware name servers that receive explicit queries for
+ security RR types which match the content of more than one zone that
+ it serves (for example, NSEC and RRSIG RRs above and below a
+ delegation point where the server is authoritative for both zones)
+ should behave self-consistently. The name server MAY return one of
+ the following:
+ o The above-delegation RRsets
+ o The below-delegation RRsets
+ o Both above and below-delegation RRsets
+ o Empty answer section (no records)
+ o Some other response
+ o An error
+ As long as the response is always consistent for each query to the
+ name server.
+
+ DNSSEC allocates two new bits in the DNS message header: the CD
+ (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit
+ is controlled by resolvers; a security-aware name server MUST copy
+ the CD bit from a query into the corresponding response. The AD bit
+ is controlled by name servers; a security-aware name server MUST
+ ignore the setting of the AD bit in queries. See Section 3.1.6,
+ Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details
+ on the behavior of these bits.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 9]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ A security aware name server which synthesizes CNAME RRs from DNAME
+ RRs as described in [RFC2672] SHOULD NOT generate signatures for the
+ synthesized CNAME RRs.
+
+3.1 Authoritative Name Servers
+
+ Upon receiving a relevant query that has the EDNS [RFC2671] OPT
+ pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name
+ server for a signed zone MUST include additional RRSIG, NSEC, and DS
+ RRs according to the following rules:
+ o RRSIG RRs that can be used to authenticate a response MUST be
+ included in the response according to the rules in Section 3.1.1;
+ o NSEC RRs that can be used to provide authenticated denial of
+ existence MUST be included in the response automatically according
+ to the rules in Section 3.1.3;
+ o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
+ be included in referrals automatically according to the rules in
+ Section 3.1.4.
+
+ These rules only apply to responses the semantics of which convey
+ information about the presence or absence of resource records. That
+ is, these rules are not intended to rule out responses such as RCODE
+ 4 ("Not Implemented") or RCODE 5 ("Refused").
+
+ DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5
+ discusses zone transfer requirements.
+
+3.1.1 Including RRSIG RRs in a Response
+
+ When responding to a query that has the DO bit set, a security-aware
+ authoritative name server SHOULD attempt to send RRSIG RRs that a
+ security-aware resolver can use to authenticate the RRsets in the
+ response. A name server SHOULD make every attempt to keep the RRset
+ and its associated RRSIG(s) together in a response. Inclusion of
+ RRSIG RRs in a response is subject to the following rules:
+ o When placing a signed RRset in the Answer section, the name server
+ MUST also place its RRSIG RRs in the Answer section. The RRSIG
+ RRs have a higher priority for inclusion than any other RRsets
+ that may need to be included. If space does not permit inclusion
+ of these RRSIG RRs, the name server MUST set the TC bit.
+ o When placing a signed RRset in the Authority section, the name
+ server MUST also place its RRSIG RRs in the Authority section.
+ The RRSIG RRs have a higher priority for inclusion than any other
+ RRsets that may need to be included. If space does not permit
+ inclusion of these RRSIG RRs, the name server MUST set the TC bit.
+ o When placing a signed RRset in the Additional section, the name
+ server MUST also place its RRSIG RRs in the Additional section.
+ If space does not permit inclusion of both the RRset and its
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 10]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If
+ this happens, the name server MUST NOT set the TC bit solely
+ because these RRSIG RRs didn't fit.
+
+3.1.2 Including DNSKEY RRs In a Response
+
+ When responding to a query that has the DO bit set and that requests
+ the SOA or NS RRs at the apex of a signed zone, a security-aware
+ authoritative name server for that zone MAY return the zone apex
+ DNSKEY RRset in the Additional section. In this situation, the
+ DNSKEY RRset and associated RRSIG RRs have lower priority than any
+ other information that would be placed in the additional section.
+ The name server SHOULD NOT include the DNSKEY RRset unless there is
+ enough space in the response message for both the DNSKEY RRset and
+ its associated RRSIG RR(s). If there is not enough space to include
+ these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
+ NOT set the TC bit solely because these RRs didn't fit (see Section
+ 3.1.1).
+
+3.1.3 Including NSEC RRs In a Response
+
+ When responding to a query that has the DO bit set, a security-aware
+ authoritative name server for a signed zone MUST include NSEC RRs in
+ each of the following cases:
+
+ No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>,
+ but does not contain any RRsets that exactly match <SNAME, SCLASS,
+ STYPE>.
+
+ Name Error: The zone does not contain any RRsets that match <SNAME,
+ SCLASS> either exactly or via wildcard name expansion.
+
+ Wildcard Answer: The zone does not contain any RRsets that exactly
+ match <SNAME, SCLASS> but does contain an RRset that matches
+ <SNAME, SCLASS, STYPE> via wildcard name expansion.
+
+ Wildcard No Data: The zone does not contain any RRsets that exactly
+ match <SNAME, SCLASS>, does contain one or more RRsets that match
+ <SNAME, SCLASS> via wildcard name expansion, but does not contain
+ any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name
+ expansion.
+
+ In each of these cases, the name server includes NSEC RRs in the
+ response to prove that an exact match for <SNAME, SCLASS, STYPE> was
+ not present in the zone and that the response that the name server is
+ returning is correct given the data that are in the zone.
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 11]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+3.1.3.1 Including NSEC RRs: No Data Response
+
+ If the zone contains RRsets matching <SNAME, SCLASS> but contains no
+ RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
+ include the NSEC RR for <SNAME, SCLASS> along with its associated
+ RRSIG RR(s) in the Authority section of the response (see Section
+ 3.1.1). If space does not permit inclusion of the NSEC RR or its
+ associated RRSIG RR(s), the name server MUST set the TC bit (see
+ Section 3.1.1).
+
+ Since the search name exists, wildcard name expansion does not apply
+ to this query, and a single signed NSEC RR suffices to prove the
+ requested RR type does not exist.
+
+3.1.3.2 Including NSEC RRs: Name Error Response
+
+ If the zone does not contain any RRsets matching <SNAME, SCLASS>
+ either exactly or via wildcard name expansion, then the name server
+ MUST include the following NSEC RRs in the Authority section, along
+ with their associated RRSIG RRs:
+ o An NSEC RR proving that there is no exact match for <SNAME,
+ SCLASS>; and
+ o An NSEC RR proving that the zone contains no RRsets that would
+ match <SNAME, SCLASS> via wildcard name expansion.
+
+ In some cases a single NSEC RR may prove both of these points, in
+ that case the name server SHOULD only include the NSEC RR and its
+ RRSIG RR(s) once in the Authority section.
+
+ If space does not permit inclusion of these NSEC and RRSIG RRs, the
+ name server MUST set the TC bit (see Section 3.1.1).
+
+ The owner names of these NSEC and RRSIG RRs are not subject to
+ wildcard name expansion when these RRs are included in the Authority
+ section of the response.
+
+ Note that this form of response includes cases in which SNAME
+ corresponds to an empty non-terminal name within the zone (a name
+ which is not the owner name for any RRset but which is the parent
+ name of one or more RRsets).
+
+3.1.3.3 Including NSEC RRs: Wildcard Answer Response
+
+ If the zone does not contain any RRsets which exactly match <SNAME,
+ SCLASS> but does contain an RRset which matches <SNAME, SCLASS,
+ STYPE> via wildcard name expansion, the name server MUST include the
+ wildcard-expanded answer and the corresponding wildcard-expanded
+ RRSIG RRs in the Answer section, and MUST include in the Authority
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 12]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ section an NSEC RR and associated RRSIG RR(s) proving that the zone
+ does not contain a closer match for <SNAME, SCLASS>. If space does
+ not permit inclusion of the answer, NSEC and RRSIG RRs, the name
+ server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.4 Including NSEC RRs: Wildcard No Data Response
+
+ This case is a combination of the previous cases. The zone does not
+ contain an exact match for <SNAME, SCLASS>, and while the zone does
+ contain RRsets which match <SNAME, SCLASS> via wildcard expansion,
+ none of those RRsets match STYPE. The name server MUST include the
+ following NSEC RRs in the Authority section, along with their
+ associated RRSIG RRs:
+ o An NSEC RR proving that there are no RRsets matching STYPE at the
+ wildcard owner name which matched <SNAME, SCLASS> via wildcard
+ expansion; and
+ o An NSEC RR proving that there are no RRsets in the zone which
+ would have been a closer match for <SNAME, SCLASS>.
+
+ 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).
+
+3.1.3.5 Finding The Right NSEC RRs
+
+ As explained above, there are several situations in which a
+ security-aware authoritative name server needs to locate an NSEC RR
+ which proves that no RRsets matching a particular SNAME exist.
+ Locating such an NSEC RR within an authoritative zone is relatively
+ simple, at least in concept. The following discussion assumes that
+ the name server is authoritative for the zone which would have held
+ the nonexistent RRsets matching SNAME. The algorithm below is
+ written for clarity, not efficiency.
+
+ To find the NSEC which proves that no RRsets matching name N exist in
+ the zone Z which would have held them, construct sequence S
+ consisting of the owner names of every RRset in Z, sorted into
+ canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate
+ names. Find the name M which would have immediately preceded N in S
+ if any RRsets with owner name N had existed. M is the owner name of
+ the NSEC RR which proves that no RRsets exist with owner name N.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 13]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ The algorithm for finding the NSEC RR which proves that a given name
+ is not covered by any applicable wildcard is similar, but requires an
+ extra step. More precisely, the algorithm for finding the NSEC
+ proving that no RRsets exist with the applicable wildcard name is
+ precisely the same as the algorithm for finding the NSEC RR which
+ proves that RRsets with any other owner name do not exist: the part
+ that's missing is how to determine the name of the nonexistent
+ applicable wildcard. In practice, this is easy, because the
+ authoritative name server has already checked for the presence of
+ precisely this wildcard name as part of step (1)(c) of the normal
+ lookup algorithm described in Section 4.3.2 of [RFC1034].
+
+3.1.4 Including DS RRs In a Response
+
+ When responding to a query which has the DO bit set, a security-aware
+ authoritative name server returning a referral includes DNSSEC data
+ along with the NS RRset.
+
+ If a DS RRset is present at the delegation point, the name server
+ MUST return both the DS RRset and its associated RRSIG RR(s) in the
+ Authority section along with the NS RRset. The name server MUST
+ place the NS RRset before the DS RRset and its associated RRSIG
+ RR(s).
+
+ If no DS RRset is present at the delegation point, the name server
+ MUST return both the NSEC RR which proves that the DS RRset is not
+ present and the NSEC RR's associated RRSIG RR(s) along with the NS
+ RRset. The name server MUST place the NS RRset before the NSEC RRset
+ and its associated RRSIG RR(s).
+
+ Including these DS, NSEC, and RRSIG RRs increases the size of
+ referral messages, and may cause some or all glue RRs to be omitted.
+ If space does not permit inclusion of the DS or NSEC RRset and
+ associated RRSIG RRs, the name server MUST set the TC bit (see
+ Section 3.1.1).
+
+3.1.4.1 Responding to Queries for DS RRs
+
+ The DS resource record type is unusual in that it appears only on the
+ parent zone's side of a zone cut. For example, the DS RRset for the
+ delegation of "foo.example" is stored in the "example" zone rather
+ than in the "foo.example" zone. This requires special processing
+ rules for both name servers and resolvers, since the name server for
+ the child zone is authoritative for the name at the zone cut by the
+ normal DNS rules but the child zone does not contain the DS RRset.
+
+ A security-aware resolver sends queries to the parent zone when
+ looking for a needed DS RR at a delegation point (see Section 4.2).
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 14]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ However, special rules are necessary to avoid confusing
+ security-oblivious resolvers which might become involved in
+ processing such a query (for example, in a network configuration that
+ forces a security-aware resolver to channel its queries through a
+ security-oblivious recursive name server). The rest of this section
+ describes how a security-aware name server processes DS queries in
+ order to avoid this problem.
+
+ The need for special processing by a security-aware name server only
+ arises when all the following conditions are met:
+ o the name server has received a query for the DS RRset at a zone
+ cut; and
+ o the name server is authoritative for the child zone; and
+ o the name server is not authoritative for the parent zone; and
+ o the name server does not offer recursion.
+
+ In all other cases, the name server either has some way of obtaining
+ the DS RRset or could not have been expected to have the DS RRset
+ even by the pre-DNSSEC processing rules, so the name server can
+ return either the DS RRset or an error response according to the
+ normal processing rules.
+
+ If all of the above conditions are met, however, the name server is
+ authoritative for SNAME but cannot supply the requested RRset. In
+ this case, the name server MUST return an authoritative "no data"
+ response showing that the DS RRset does not exist in the child zone's
+ apex. See Appendix B.8 for an example of such a response.
+
+3.1.5 Responding to Queries for Type AXFR or IXFR
+
+ DNSSEC does not change the DNS zone transfer process. A signed zone
+ will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
+ records have no special meaning with respect to a zone transfer
+ operation.
+
+ An authoritative name server is not required to verify that a zone is
+ properly signed before sending or accepting a zone transfer.
+ However, an authoritative name server MAY choose to reject the entire
+ zone transfer if the zone fails meets any of the signing requirements
+ described in Section 2. The primary objective of a zone transfer is
+ to ensure that all authoritative name servers have identical copies
+ of the zone. An authoritative name server that chooses to perform
+ its own zone validation MUST NOT selectively reject some RRs and
+ accept others.
+
+ DS RRsets appear only on the parental side of a zone cut and are
+ authoritative data in the parent zone. As with any other
+ authoritative RRset, the DS RRset MUST be included in zone transfers
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 15]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ of the zone in which the RRset is authoritative data: in the case of
+ the DS RRset, this is the parent zone.
+
+ NSEC RRs appear in both the parent and child zones at a zone cut, and
+ are authoritative data in both the parent and child zones. The
+ parental and child NSEC RRs at a zone cut are never identical to each
+ other, since the NSEC RR in the child zone's apex will always
+ indicate the presence of the child zone's SOA RR while the parental
+ NSEC RR at the zone cut will never indicate the presence of an SOA
+ RR. As with any other authoritative RRs, NSEC RRs MUST be included
+ in zone transfers of the zone in which they are authoritative data:
+ the parental NSEC RR at a zone cut MUST be included zone transfers of
+ the parent zone, while the NSEC at the zone apex of the child zone
+ MUST be included in zone transfers of the child zone.
+
+ RRSIG RRs appear in both the parent and child zones at a zone cut,
+ and are authoritative in whichever zone contains the authoritative
+ RRset for which the RRSIG RR provides the signature. That is, the
+ RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be
+ authoritative in the parent zone, while the RRSIG for any RRset in
+ the child zone's apex will be authoritative in the child zone.
+ Parental and child RRSIG RRs at a zone cut will never be identical to
+ each other, since the Signer's Name field of an RRSIG RR in the child
+ zone's apex will indicate a DNSKEY RR in the child zone's apex while
+ the same field of a parental RRSIG RR at the zone cut will indicate a
+ DNSKEY RR in the parent zone's apex. As with any other authoritative
+ RRs, RRSIG RRs MUST be included in zone transfers of the zone in
+ which they are authoritative data.
+
+3.1.6 The AD and CD Bits in an Authoritative Response
+
+ The CD and AD bits are designed for use in communication between
+ security-aware resolvers and security-aware recursive name servers.
+ These bits are for the most part not relevant to query processing by
+ security-aware authoritative name servers.
+
+ A security-aware name server does not perform signature validation
+ for authoritative data during query processing even when the CD bit
+ is clear. A security-aware name server SHOULD clear the CD bit when
+ composing an authoritative response.
+
+ A security-aware name server MUST NOT set the AD bit in a response
+ unless the name server considers all RRsets in the Answer and
+ Authority sections of the response to be authentic. A security-aware
+ name server's local policy MAY consider data from an authoritative
+ zone to be authentic without further validation, but the name server
+ MUST NOT do so unless the name server obtained the authoritative zone
+ via secure means (such as a secure zone transfer mechanism), and MUST
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 16]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ NOT do so unless this behavior has been configured explicitly.
+
+ A security-aware name server which supports recursion MUST follow the
+ rules for the CD and AD bits given in Section 3.2 when generating a
+ response that involves data obtained via recursion.
+
+3.2 Recursive Name Servers
+
+ As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware
+ recursive name server is an entity which acts in both the
+ security-aware name server and security-aware resolver roles. This
+ section uses the terms "name server side" and "resolver side" to
+ refer to the code within a security-aware recursive name server which
+ implements the security-aware name server role and the code which
+ implements the security-aware resolver role, respectively.
+
+ The resolver side follows the usual rules for caching and negative
+ caching which would apply to any security-aware resolver.
+
+3.2.1 The DO bit
+
+ The resolver side of a security-aware recursive name server MUST set
+ the DO bit when sending requests, regardless of the state of the DO
+ bit in the initiating request received by the name server side. If
+ the DO bit in an initiating query is not set, the name server side
+ MUST strip any authenticating DNSSEC RRs from the response, but MUST
+ NOT strip any DNSSEC RR types that the initiating query explicitly
+ requested.
+
+3.2.2 The CD bit
+
+ The CD bit exists in order to allow a security-aware resolver to
+ disable signature validation in a security-aware name server's
+ processing of a particular query.
+
+ The name server side MUST copy the setting of the CD bit from a query
+ to the corresponding response.
+
+ The name server side of a security-aware recursive name server MUST
+ pass the sense of the CD bit to the resolver side along with the rest
+ of an initiating query, so that the resolver side will know whether
+ or not it is required to verify the response data it returns to the
+ name server side. If the CD bit is set, it indicates that the
+ originating resolver is willing to perform whatever authentication
+ its local policy requires, thus the resolver side of the recursive
+ name server need not perform authentication on the RRsets in the
+ response. When the CD bit is set the recursive name server SHOULD,
+ if possible, return the requested data to the originating resolver
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 17]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ even if the recursive name server's local authentication policy would
+ reject the records in question. That is, by setting the CD bit, the
+ originating resolver has indicated that it takes responsibility for
+ performing its own authentication, and the recursive name server
+ should not interfere.
+
+ If the resolver side implements a BAD cache (see Section 4.7) and the
+ name server side receives a query 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,
+ the name server side SHOULD return the data from the BAD cache; if
+ the CD bit is not set, the name server side MUST return RCODE 2
+ (server failure).
+
+ The intent of the above rule is to provide the raw data to clients
+ which are capable of performing their own signature verification
+ checks while protecting clients which depend on the resolver side of
+ a security-aware recursive name server to perform such checks.
+ Several of the possible reasons why signature validation might fail
+ involve conditions which may not apply equally to the recursive name
+ server and the client which invoked it: for example, the recursive
+ name server's clock may be set incorrectly, or the client may have
+ knowledge of a relevant island of security which the recursive name
+ server does not share. In such cases, "protecting" a client which is
+ capable of performing its own signature validation from ever seeing
+ the "bad" data does not help the client.
+
+3.2.3 The AD bit
+
+ The name server side of a security-aware recursive name server MUST
+ NOT set the AD bit in a response unless the name server considers all
+ RRsets in the Answer and Authority sections of the response to be
+ authentic. The name server side SHOULD set the AD bit if and only if
+ the resolver side considers all RRsets in the Answer section and any
+ relevant negative response RRs in the Authority section to be
+ authentic. The resolver side MUST follow the procedure described in
+ Section 5 to determine whether the RRs in question are authentic.
+ However, for backwards compatibility, a recursive name server MAY set
+ the AD bit when a response includes unsigned CNAME RRs if those CNAME
+ RRs demonstrably could have been synthesized from an authentic DNAME
+ RR which is also included in the response according to the synthesis
+ rules described in [RFC2672].
+
+3.3 Example DNSSEC Responses
+
+ See Appendix B for example response packets.
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 18]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+4. Resolving
+
+ This section describes the behavior of entities that include
+ security-aware resolver functions. In many cases such functions will
+ be part of a security-aware recursive name server, but a stand-alone
+ security-aware resolver has many of the same requirements. Functions
+ specific to security-aware recursive name servers are described in
+ Section 3.2.
+
+4.1 EDNS Support
+
+ A security-aware resolver MUST include an EDNS [RFC2671] OPT
+ pseudo-RR with the DO [RFC3225] bit set when sending queries.
+
+ A security-aware resolver MUST support a message size of at least
+ 1220 octets, SHOULD support a message size of 4000 octets, and MUST
+ advertise the supported message size using the "sender's UDP payload
+ size" field in the EDNS OPT pseudo-RR. A security-aware resolver
+ MUST handle fragmented UDP packets correctly regardless of whether
+ any such fragmented packets were received via IPv4 or IPv6. Please
+ see [RFC3226] for discussion of these requirements.
+
+4.2 Signature Verification Support
+
+ A security-aware resolver MUST support the signature verification
+ mechanisms described in Section 5, and SHOULD apply them to every
+ received response except when:
+ o The security-aware resolver is part of a security-aware recursive
+ name server, and the response is the result of recursion on behalf
+ of a query received with the CD bit set;
+ o The response is the result of a query generated directly via some
+ form of application interface which instructed the security-aware
+ resolver not to perform validation for this query; or
+ o Validation for this query has been disabled by local policy.
+
+ A security-aware resolver's support for signature verification MUST
+ include support for verification of wildcard owner names.
+
+ Security aware resolvers MAY query for missing security RRs in an
+ attempt to perform validation; implementations that choose to do so
+ must be aware that the answers received may not be sufficient to
+ validate the original response.
+
+ When attempting to retrieve missing NSEC 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.
+
+ When attempting to retrieve a missing DS, a security-aware
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 19]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ iterative-mode resolver MUST query the name servers for the parent
+ zone, not the child zone. As explained in Section 3.1.4.1,
+ security-aware name servers need to apply special processing rules to
+ handle the DS RR, and in some situations the resolver may also need
+ to apply special rules to locate the name servers for the parent zone
+ if the resolver does not already have the parent's NS RRset. To
+ locate the parent NS RRset, the resolver can start with the
+ delegation name, strip off the leftmost label, and query for an NS
+ RRset by that name; if no NS RRset is present at that name, the
+ resolver then strips of the leftmost remaining label and retries the
+ query for that name, repeating this process of walking up the tree
+ until it either finds the NS RRset or runs out of labels.
+
+4.3 Determining Security Status of Data
+
+ A security-aware resolver MUST be able to determine whether or not it
+ should expect a particular RRset to be signed. More precisely, a
+ security-aware resolver must be able to distinguish between four
+ cases:
+
+ Secure: An RRset for which the resolver is able to build a chain of
+ signed DNSKEY and DS RRs from a trusted security anchor to the
+ RRset. In this case, the RRset should be signed, and is subject
+ to signature validation as described above.
+
+ Insecure: An RRset for which the resolver knows that it has no chain
+ of signed DNSKEY and DS RRs from any trusted starting point to the
+ RRset. This can occur when the target RRset lies in an unsigned
+ zone or in a descendent of an unsigned zone. In this case, the
+ RRset may or may not be signed, but the resolver will not be able
+ to verify the signature.
+
+ Bogus: An RRset for which the resolver believes that it ought to be
+ able to establish a chain of trust but is unable to do so, either
+ due to signatures that for some reason fail to validate or due to
+ missing data which the relevant DNSSEC RRs indicate should be
+ present. This case may indicate an attack, but may also indicate
+ a configuration error or some form of data corruption.
+
+ Indeterminate: An RRset for which the resolver is not able to
+ determine whether or not the RRset should be signed, because the
+ resolver is not able to obtain the necessary DNSSEC RRs. This can
+ occur when the security-aware resolver is not able to contact
+ security-aware name servers for the relevant zones.
+
+4.4 Configured Trust Anchors
+
+ A security-aware resolver MUST be capable of being configured with at
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 20]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ least one trusted public key or DS RR, and SHOULD be capable of being
+ configured with multiple trusted public keys or DS RRs. Since a
+ security-aware resolver will not be able to validate signatures
+ without such a configured trust anchor, the resolver SHOULD have some
+ reasonably robust mechanism for obtaining such keys when it boots;
+ examples of such a mechanism would be some form of non-volatile
+ storage (such as a disk drive) or some form of trusted local network
+ configuration mechanism.
+
+ Note that trust anchors also covers key material that is updated in a
+ secure manner. This secure manner could be through physical media, a
+ key exchange protocol, or some other out of band means.
+
+4.5 Response Caching
+
+ A security-aware resolver SHOULD cache each response as a single
+ atomic entry containing the entire answer, including the named RRset
+ and any associated DNSSEC RRs. The resolver SHOULD discard the
+ entire atomic entry when any of the RRs contained in it expire. In
+ most cases the appropriate cache index for the atomic entry will be
+ the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
+ form described in Section 3.1.3.2 the appropriate cache index will be
+ the double <QNAME,QCLASS>.
+
+ The reason for these recommendations is that, between the initial
+ query and the expiration of the data from the cache, the
+ authoritative data might have been changed (for example, via dynamic
+ update).
+
+ There are two situations for which this is relevant:
+ 1. By using the RRSIG record, it is possible to deduce that an
+ answer was synthesized from a wildcard. A security aware
+ recursive name server could store this wildcard data and use it
+ to generate positive responses to queries other than the name for
+ which the original answer was first received.
+ 2. NSEC RRs received to prove the non-existence of a name could be
+ reused by a security aware resolver to prove the non-existence of
+ any name in the name range it spans.
+
+ In theory, a resolver could use wildcards or NSEC RRs to generate
+ positive and negative responses (respectively) until the TTL or
+ signatures on the records in question expire. However, it seems
+ prudent for resolvers to avoid blocking new authoritative data or
+ synthesizing new data on their own. Resolvers which follow this
+ recommendation will have a more consistent view of the namespace.
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 21]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+4.6 Handling of the CD and AD bits
+
+ A security-aware resolver MAY set a query's CD bit in order to
+ indicate that the resolver takes responsibility for performing
+ whatever authentication its local policy requires on the RRsets in
+ the response. See Section 3.2 for the effect this bit has on the
+ behavior of security-aware recursive name servers.
+
+ A security-aware resolver MUST clear the AD bit when composing query
+ messages to protect against buggy name servers which blindly copy
+ header bits which they do not understand from the query message to
+ the response message.
+
+ A resolver MUST disregard the meaning of the CD and AD bits in a
+ response unless the response was obtained using a secure channel or
+ the resolver was specifically configured to regard the message header
+ bits without using a secure channel.
+
+4.7 Caching BAD Data
+
+ While many validation errors will be transient, some are likely to be
+ more persistent, such as those caused by administrative error
+ (failure to re-sign a zone, clock skew, and so forth). Since
+ requerying will not help in these cases, validating resolvers might
+ generate a significant amount of unnecessary DNS traffic as a result
+ of repeated queries for RRsets with persistent validation failures.
+
+ To prevent such unnecessary DNS traffic, security-aware resolvers MAY
+ cache data with invalid signatures, with some restrictions.
+ Conceptually, caching such data is similar to negative caching
+ [RFC2308], except that instead of caching a valid negative response,
+ the resolver is caching the fact that a particular answer failed to
+ validate. This document refers to a cache of data with invalid
+ signatures as a "BAD cache".
+
+ Resolvers which implement a BAD cache MUST take steps to prevent the
+ cache from being useful as a denial-of-service attack amplifier. In
+ particular:
+ o Since RRsets which fail to validate do not have trustworthy TTLs,
+ the implementation MUST assign a TTL. This TTL SHOULD be small,
+ in order to mitigate the effect of caching the results of an
+ attack.
+ o In order to prevent caching of a transient validation failure
+ (which might be the result of an attack), resolvers SHOULD track
+ queries that result in validation failures, and SHOULD only answer
+ from the BAD cache after the number of times that responses to
+ queries for that particular <QNAME, QTYPE, QCLASS> have failed to
+ validate exceeds a threshold value.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 22]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ Resolvers MUST NOT return RRsets from the BAD cache unless the
+ resolver is not required to validate the signatures of the RRsets in
+ question under the rules given in Section 4.2 of this document. See
+ Section 3.2.2 for discussion of how the responses returned by a
+ security-aware recursive name server interact with a BAD cache.
+
+4.8 Synthesized CNAMEs
+
+ A validating security-aware resolver MUST treat the signature of a
+ valid signed DNAME RR as also covering unsigned CNAME RRs which could
+ have been synthesized from the DNAME RR as described in [RFC2672], at
+ least to the extent of not rejecting a response message solely
+ because it contains such CNAME RRs. The resolver MAY retain such
+ CNAME RRs in its cache or in the answers it hands back, but is not
+ required to do so.
+
+4.9 Stub resolvers
+
+ A security-aware stub resolver MUST support the DNSSEC RR types, at
+ least to the extent of not mishandling responses just because they
+ contain DNSSEC RRs.
+
+4.9.1 Handling of the DO Bit
+
+ A non-validating security-aware stub resolver MAY include the DNSSEC
+ RRs returned by a security-aware recursive name server as part of the
+ data that the stub resolver hands back to the application which
+ invoked it but is not required to do so. A non-validating stub
+ resolver that wishes to do this will need to set the DO bit in
+ receive DNSSEC RRs from the recursive name server.
+
+ A validating security-aware stub resolver MUST set the DO bit, since
+ otherwise it will not receive the DNSSEC RRs it needs to perform
+ signature validation.
+
+4.9.2 Handling of the CD Bit
+
+ A non-validating security-aware stub resolver SHOULD NOT set the CD
+ bit when sending queries unless requested by the application layer,
+ since by definition, a non-validating stub resolver depends on the
+ security-aware recursive name server to perform validation on its
+ behalf.
+
+ A validating security-aware stub resolver SHOULD set the CD bit,
+ since otherwise the security-aware recursive name server will answer
+ the query using the name server's local policy, which may prevent the
+ stub resolver from receiving data which would be acceptable to the
+ stub resolver's local policy.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 23]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+4.9.3 Handling of the AD Bit
+
+ A non-validating security-aware stub resolver MAY chose to examine
+ the setting of the AD bit in response messages that it receives in
+ order to determine whether the security-aware recursive name server
+ which sent the response claims to have cryptographically verified the
+ data in the Answer and Authority sections of the response message.
+ Note, however, that the responses received by a security-aware stub
+ resolver are heavily dependent on the local policy of the
+ security-aware recursive name server, so as a practical matter there
+ may be little practical value to checking the status of the AD bit
+ except perhaps as a debugging aid. In any case, a security-aware
+ stub resolver MUST NOT place any reliance on signature validation
+ allegedly performed on its behalf except when the security-aware stub
+ resolver obtained the data in question from a trusted security-aware
+ recursive name server via a secure channel.
+
+ A validating security-aware stub resolver SHOULD NOT examine the
+ setting of the AD bit in response messages, since, by definition, the
+ stub resolver performs its own signature validation regardless of the
+ setting of the AD bit.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 24]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+5. Authenticating DNS Responses
+
+ In order to use DNSSEC RRs for authentication, a security-aware
+ resolver requires configured knowledge of at least one authenticated
+ DNSKEY or DS RR. The process for obtaining and authenticating this
+ initial trust anchors is achieved via some external mechanism. For
+ example, a resolver could use some off-line authenticated exchange to
+ obtain a zone's DNSKEY RR or obtain a DS RR that identifies and
+ authenticates a zone's DNSKEY RR. The remainder of this section
+ assumes that the resolver has somehow obtained an initial set of
+ trust anchors.
+
+ An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
+ RRset. To authenticate an apex DNSKEY RRset using an initial key,
+ the resolver MUST:
+ 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY
+ RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag
+ (DNSKEY RDATA bit 7) set.
+ 2. Verify that there is some RRSIG RR that covers the apex DNSKEY
+ RRset, and that the combination of the RRSIG RR and the initial
+ DNSKEY RR authenticates the DNSKEY RRset. The process for using
+ an RRSIG RR to authenticate an RRset is described in Section 5.3.
+
+ Once the resolver has authenticated the apex DNSKEY RRset using an
+ initial DNSKEY RR, delegations from that zone can be authenticated
+ using DS RRs. This allows a resolver to start from an initial key,
+ and use DS RRsets to proceed recursively down the DNS tree obtaining
+ other apex DNSKEY RRsets. If the resolver were configured with a
+ root DNSKEY RR, and if every delegation had a DS RR associated with
+ it, then the resolver could obtain and validate any apex DNSKEY
+ RRset. The process of using DS RRs to authenticate referrals is
+ described in Section 5.2.
+
+ Once the resolver has authenticated a zone's apex DNSKEY RRset,
+ Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
+ DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
+ RRsets in the zone. Section 5.4 shows how the resolver can use
+ authenticated NSEC RRsets from the zone to prove that an RRset is not
+ present in the zone.
+
+ When a resolver indicates support for DNSSEC (by setting the DO bit),
+ a security-aware name server should attempt to provide the necessary
+ DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
+ However, a security-aware resolver may still receive a response that
+ that lacks the appropriate DNSSEC RRs, whether due to configuration
+ issues such as an upstream security-oblivious recursive name server
+ that accidentally interferes with DNSSEC RRs or due to a deliberate
+ attack in which an adversary forges a response, strips DNSSEC RRs
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 25]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ from a response, or modifies a query so that DNSSEC RRs appear not to
+ be requested. The absence of DNSSEC data in a response MUST NOT by
+ itself be taken as an indication that no authentication information
+ exists.
+
+ A resolver SHOULD expect authentication information from signed
+ zones. A resolver SHOULD believe that a zone is signed if the
+ resolver has been configured with public key information for the
+ zone, or if the zone's parent is signed and the delegation from the
+ parent contains a DS RRset.
+
+5.1 Special Considerations for Islands of Security
+
+ Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed
+ zones for which it is not possible to construct an authentication
+ chain to the zone from its parent. Validating signatures within an
+ island of security requires the validator to have some other means of
+ obtaining an initial authenticated zone key for the island. If a
+ validator cannot obtain such a key, it SHOULD switch to operating as
+ if the zones in the island of security are unsigned.
+
+ All the normal processes for validating responses apply to islands of
+ security. The only difference between normal validation and
+ validation within an island of security is in how the validator
+ obtains a trust anchor for the authentication chain.
+
+5.2 Authenticating Referrals
+
+ Once the apex DNSKEY RRset for a signed parent zone has been
+ authenticated, DS RRsets can be used to authenticate the delegation
+ to a signed child zone. A DS RR identifies a DNSKEY RR in the child
+ zone's apex DNSKEY RRset, and contains a cryptographic digest of the
+ child zone's DNSKEY RR. A strong cryptographic digest algorithm
+ ensures that an adversary can not easily generate a DNSKEY RR that
+ matches the digest. Thus, authenticating the digest allows a
+ resolver to authenticate the matching DNSKEY RR. The resolver can
+ then use this child DNSKEY RR to authenticate the entire child apex
+ DNSKEY RRset.
+
+ Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
+ can be authenticated if all of the following hold:
+ o The DS RR has been authenticated using some DNSKEY RR in the
+ parent's apex DNSKEY RRset (see Section 5.3);
+ o The Algorithm and Key Tag in the DS RR match the Algorithm field
+ and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
+ RRset and, when hashed using the digest algorithm specified in the
+ DS RR's Digest Type field, results in a digest value that matches
+ the Digest field of the DS RR; and
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 26]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ o The matching DNSKEY RR in the child zone has the Zone Flag bit
+ set, the corresponding private key has signed the child zone's
+ apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
+ child zone's apex DNSKEY RRset.
+
+ If the referral from the parent zone did not contain a DS RRset, the
+ response should have included a signed NSEC RRset proving that no DS
+ RRset exists for the delegated name (see Section 3.1.4). A
+ security-aware resolver MUST query the name servers for the parent
+ zone for the DS RRset if the referral includes neither a DS RRset nor
+ a NSEC RRset proving that the DS RRset does not exist (see Section
+ 4).
+
+ If the validator authenticates an NSEC RRset that proves that no DS
+ RRset is present for this zone, then there is no authentication path
+ leading from the parent to the child. If the resolver has an initial
+ DNSKEY or DS RR that belongs to the child zone or to any delegation
+ below the child zone, this initial DNSKEY or DS RR MAY be used to
+ re-establish an authentication path. If no such initial DNSKEY or DS
+ RR exists, the validator can not authenticate RRsets in or below the
+ child zone.
+
+ If the validator does not support any of the algorithms listed in an
+ authenticated DS RRset, then the resolver has no supported
+ authentication path leading from the parent to the child. The
+ resolver should treat this case as it would the case of an
+ authenticated NSEC RRset proving that no DS RRset exists, as
+ described above.
+
+ Note that, for a signed delegation, there are two NSEC RRs associated
+ with the delegated name. One NSEC RR resides in the parent zone, and
+ can be used to prove whether a DS RRset exists for the delegated
+ name. The second NSEC RR resides in the child zone, and identifies
+ which RRsets are present at the apex of the child zone. The parent
+ NSEC RR and child NSEC RR can always be distinguished, since the SOA
+ bit will be set in the child NSEC RR and clear in the parent NSEC RR.
+ A security-aware resolver MUST use the parent NSEC RR when attempting
+ to prove that a DS RRset does not exist.
+
+ If the resolver does not support any of the algorithms listed in an
+ authenticated DS RRset, then the resolver will not be able to verify
+ the authentication path to the child zone. In this case, the
+ resolver SHOULD treat the child zone as if it were unsigned.
+
+5.3 Authenticating an RRset Using an RRSIG RR
+
+ A validator can use an RRSIG RR and its corresponding DNSKEY RR to
+ attempt to authenticate RRsets. The validator first checks the RRSIG
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 27]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ RR to verify that it covers the RRset, has a valid time interval, and
+ identifies a valid DNSKEY RR. The validator then constructs the
+ canonical form of the signed data by appending the RRSIG RDATA
+ (excluding the Signature Field) with the canonical form of the
+ covered RRset. Finally, the validator uses the public key and
+ signature to authenticate the signed data. Section 5.3.1, Section
+ 5.3.2, and Section 5.3.3 describe each step in detail.
+
+5.3.1 Checking the RRSIG RR Validity
+
+ A security-aware resolver can use an RRSIG RR to authenticate an
+ RRset if all of the following conditions hold:
+ o The RRSIG RR and the RRset MUST have the same owner name and the
+ same class;
+ o The RRSIG RR's Signer's Name field MUST be the name of the zone
+ that contains the RRset;
+ o The RRSIG RR's Type Covered field MUST equal the RRset's type;
+ o The number of labels in the RRset owner name MUST be greater than
+ or equal to the value in the RRSIG RR's Labels field;
+ o The validator's notion of the current time MUST be less than or
+ equal to the time listed in the RRSIG RR's Expiration field;
+ o The validator's notion of the current time MUST be greater than or
+ equal to the time listed in the RRSIG RR's Inception field;
+ o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
+ match the owner name, algorithm, and key tag for some DNSKEY RR in
+ the zone's apex DNSKEY RRset;
+ o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
+ RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
+ set.
+
+ It is possible for more than one DNSKEY RR to match the conditions
+ above. In this case, the validator cannot predetermine which DNSKEY
+ RR to use to authenticate the signature, MUST try each matching
+ DNSKEY RR until either the signature is validated or the validator
+ has run out of matching public keys to try.
+
+ Note that this authentication process is only meaningful if the
+ validator authenticates the DNSKEY RR before using it to validate
+ signatures. The matching DNSKEY RR is considered to be authentic if:
+ o The apex DNSKEY RRset containing the DNSKEY RR is considered
+ authentic; or
+ o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
+ and the DNSKEY RR either matches an authenticated DS RR from the
+ parent zone or matches a trust anchor.
+
+5.3.2 Reconstructing the Signed Data
+
+ Once the RRSIG RR has met the validity requirements described in
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 28]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ Section 5.3.1, the validator needs to reconstruct the original signed
+ data. The original signed data includes RRSIG RDATA (excluding the
+ Signature field) and the canonical form of the RRset. Aside from
+ being ordered, the canonical form of the RRset might also differ from
+ the received RRset due to DNS name compression, decremented TTLs, or
+ wildcard expansion. The validator should use the following to
+ reconstruct the original signed data:
+
+ signed_data = RRSIG_RDATA | RR(1) | RR(2)... where
+
+ "|" denotes concatenation
+
+ RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+ with the Signature field excluded and the Signer's Name
+ in canonical form.
+
+ RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
+
+ name is calculated according to the function below
+
+ class is the RRset's class
+
+ type is the RRset type and all RRs in the class
+
+ OrigTTL is the value from the RRSIG Original TTL field
+
+ All names in the RDATA field are in canonical form
+
+ The set of all RR(i) is sorted into canonical order.
+
+ To calculate the name:
+ let rrsig_labels = the value of the RRSIG Labels field
+
+ let fqdn = RRset's fully qualified domain name in
+ canonical form
+
+ let fqdn_labels = Label count of the fqdn above.
+
+ if rrsig_labels = fqdn_labels,
+ name = fqdn
+
+ if rrsig_labels < fqdn_labels,
+ name = "*." | the rightmost rrsig_label labels of the
+ fqdn
+
+ if rrsig_labels > fqdn_labels
+ the RRSIG RR did not pass the necessary validation
+ checks and MUST NOT be used to authenticate this
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 29]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ RRset.
+
+ The canonical forms for names and RRsets are defined in
+ [I-D.ietf-dnsext-dnssec-records].
+
+ NSEC RRsets at a delegation boundary require special processing.
+ There are two distinct NSEC RRsets associated with a signed delegated
+ name. One NSEC RRset resides in the parent zone, and specifies which
+ RRset are present at the parent zone. The second NSEC RRset resides
+ at the child zone, and identifies which RRsets are present at the
+ apex in the child zone. The parent NSEC RRset and child NSEC RRset
+ can always be distinguished since only the child NSEC RRs will
+ specify an SOA RRset exists at the name. When reconstructing the
+ original NSEC RRset for the delegation from the parent zone, the NSEC
+ RRs MUST NOT be combined with NSEC RRs from the child zone, and when
+ reconstructing the original NSEC RRset for the apex of the child
+ zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent
+ zone.
+
+ Note also that each of the two NSEC RRsets at a delegation point has
+ a corresponding RRSIG RR with an owner name matching the delegated
+ name, and each of these RRSIG RRs is authoritative data associated
+ with the same zone that contains the corresponding NSEC RRset. If
+ necessary, a resolver can tell these RRSIG RRs apart by checking the
+ Signer's Name field.
+
+5.3.3 Checking the Signature
+
+ Once the resolver has validated the RRSIG RR as described in Section
+ 5.3.1 and reconstructed the original signed data as described in
+ Section 5.3.2, the validator can attempt to use the cryptographic
+ signature to authenticate the signed data, and thus (finally!)
+ authenticate the RRset.
+
+ The Algorithm field in the RRSIG RR identifies the cryptographic
+ algorithm used to generate the signature. The signature itself is
+ contained in the Signature field of the RRSIG RDATA, and the public
+ key used to verify the signature is contained in the Public Key field
+ of the matching DNSKEY RR(s) (found in Section 5.3.1).
+ [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types
+ and provides pointers to the documents that define each algorithm's
+ use.
+
+ Note that it is possible for more than one DNSKEY RR to match the
+ conditions in Section 5.3.1. In this case, the validator can only
+ determine which DNSKEY RR by trying each matching public key until
+ the validator either succeeds in validating the signature or runs out
+ of keys to try.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 30]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ If the Labels field of the RRSIG RR is not equal to the number of
+ labels in the RRset's fully qualified owner name, then the RRset is
+ either invalid or the result of wildcard expansion. The resolver
+ MUST verify that wildcard expansion was applied properly before
+ considering the RRset to be authentic. Section 5.3.4 describes how
+ to determine whether a wildcard was applied properly.
+
+ If other RRSIG RRs also cover this RRset, the local resolver security
+ policy determines whether the resolver also 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 validator MUST
+ set the TTL of the RRSIG RR and each RR in the authenticated RRset to
+ a value no greater than the minimum of:
+ o The RRset's TTL as received in the response;
+ o The RRSIG RR's TTL as received in the response;
+ o The value in the RRSIG RR's Original TTL field; and
+ o The difference of the RRSIG RR's Signature Expiration time and the
+ current time.
+
+5.3.4 Authenticating A Wildcard Expanded RRset Positive Response
+
+ If the number of labels in an RRset's owner name is greater than the
+ Labels field of the covering RRSIG RR, then the RRset and its
+ covering RRSIG RR were created as a result of wildcard expansion.
+ Once the validator has verified the signature as described in Section
+ 5.3, it must take additional steps to verify the non-existence of an
+ exact match or closer wildcard match for the query. Section 5.4
+ discusses these steps.
+
+ Note that the response received by the resolver should include all
+ NSEC RRs needed to authenticate the response (see Section 3.1.3).
+
+5.4 Authenticated Denial of Existence
+
+ A resolver can use authenticated NSEC RRs to prove that an RRset is
+ not present in a signed zone. Security-aware name servers should
+ automatically include any necessary NSEC RRs for signed zones in
+ their responses to security-aware resolvers.
+
+ Denial of existence is determined by the following rules:
+ o If the requested RR name matches the owner name of an
+ authenticated NSEC RR, then the NSEC RR's type bit map field lists
+ all RR types present at that owner name, and a resolver can prove
+ that the requested RR type does not exist by checking for the RR
+ type in the bit map. If the number of labels in an authenticated
+ NSEC RR's owner name equals the Labels field of the covering RRSIG
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 31]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ RR, then the existence of the NSEC RR proves that wildcard
+ expansion could not have been used to match the request.
+ o If the requested RR name would appear after an authenticated NSEC
+ RR's owner name and before the name listed in that NSEC RR's Next
+ Domain Name field according to the canonical DNS name order
+ defined in [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 that could
+ have been used to generate a positive response.
+
+ In addition, security-aware resolvers MUST authenticate the NSEC
+ RRsets that comprise the non-existence proof as described in Section
+ 5.3.
+
+ To prove 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 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 validated NSEC RR proves the existence of both itself and its
+ corresponding RRSIG RR, a validator MUST ignore the settings of the
+ NSEC and RRSIG bits in an NSEC RR.
+
+5.5 Resolver Behavior When Signatures Do Not Validate
+
+ If for whatever reason none of the RRSIGs can be validated, the
+ response SHOULD be considered BAD. If the validation was being done
+ to service a recursive query, the name server MUST return RCODE 2 to
+ the originating client. However, it MUST return the full response if
+ and only if the original query had the CD bit set. See also Section
+ 4.7 on caching responses that do not validate.
+
+5.6 Authentication Example
+
+ Appendix C shows an example the authentication process.
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 32]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+6. IANA Considerations
+
+ [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA
+ considerations introduced by DNSSEC. The additional IANA
+ considerations discussed in this document:
+
+ [RFC2535] reserved the CD and AD bits in the message header. The
+ meaning of the AD bit was redefined in [RFC3655] and the meaning of
+ both the CD and AD bit are restated in this document. No new bits in
+ the DNS message header are defined in this document.
+
+ [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit
+ and defined its use. The use is restated but not altered in this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 33]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+7. Security Considerations
+
+ This document describes how the DNS security extensions use public
+ key cryptography to sign and authenticate DNS resource record sets.
+ Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general
+ security considerations related to DNSSEC; 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.9 for further discussion.
+
+ 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 accidentally denying service to the clients it
+ is intended to support.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 34]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+8. Acknowledgements
+
+ This document was created from the input and ideas of the members of
+ the DNS Extensions Working Group and working group mailing list. The
+ editors would like to express their thanks for the comments and
+ suggestions received during the revision of these security extension
+ specifications. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 35]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+9. References
+
+9.1 Normative References
+
+ [I-D.ietf-dnsext-dnssec-intro]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
+ 2004.
+
+ [I-D.ietf-dnsext-dnssec-records]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Resource Records for DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-08 (work in progress),
+ May 2004.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+ August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+ 2672, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+ message size requirements", RFC 3226, December 2001.
+
+9.2 Informative References
+
+ [I-D.ietf-dnsext-nsec-rdata]
+ Schlyter, J., "DNSSEC NSEC RDATA Format",
+ draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 36]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ 2004.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+ Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ EMail: roy.arends@telin.nl
+
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Rob Austein
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ EMail: sra@isc.org
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 37]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ Dan Massey
+ USC Information Sciences Institute
+ 3811 N. Fairfax Drive
+ Arlington, VA 22203
+ USA
+
+ EMail: masseyd@isi.edu
+
+
+ Scott Rose
+ National Institute for Standards and Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 38]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+Appendix A. Signed Zone Example
+
+ The following example shows a (small) complete signed zone.
+
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ 3600 NS ns1.example.
+ 3600 NS ns2.example.
+ 3600 RRSIG NS 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+ EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+ 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+ RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+ 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+ 3600 MX 1 xx.example.
+ 3600 RRSIG MX 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
+ 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
+ VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
+ 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
+ W6OISukd1EQt7a0kygkg+PEDxdI= )
+ 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
+ 3600 RRSIG NSEC 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+ FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+ Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+ SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+ jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+ 3600 DNSKEY 256 3 5 (
+ AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
+ rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
+ k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
+ vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 39]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
+ )
+ 3600 DNSKEY 257 3 5 (
+ AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
+ LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
+ syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
+ RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
+ Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
+ )
+ 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
+ 20040409183619 9465 example.
+ ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
+ xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
+ XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
+ hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
+ NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
+ 3600 RRSIG DNSKEY 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
+ DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
+ bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
+ eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
+ 7z5OXogYVaFzHKillDt3HRxHIZM= )
+ a.example. 3600 IN NS ns1.a.example.
+ 3600 IN NS ns2.a.example.
+ 3600 DS 57855 5 1 (
+ B6DCD485719ADCA18E5F3D48A2331627FDD3
+ 636B )
+ 3600 RRSIG DS 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+ kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+ EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+ Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+ 3600 NSEC ai.example. NS DS RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
+ U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
+ 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
+ BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
+ sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+ ai.example. 3600 IN A 192.0.2.9
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 40]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+ ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+ hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+ ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+ 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+ 3600 HINFO "KLH-10" "ITS"
+ 3600 RRSIG HINFO 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
+ e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
+ ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
+ AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
+ FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
+ 3600 AAAA 2001:db8::f00:baa9
+ 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+ kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+ 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+ cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+ sZM6QjBBLmukH30+w1z3h8PUP2o= )
+ 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
+ CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
+ P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
+ 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
+ AhS+JOVfDI/79QtyTI0SaDWcg8U= )
+ b.example. 3600 IN NS ns1.b.example.
+ 3600 IN NS ns2.b.example.
+ 3600 NSEC ns1.example. NS RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+ 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+ xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+ 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+ ns1.example. 3600 IN A 192.0.2.1
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+ 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+ im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 41]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ v/iVXSYC0b7mPSU+EOlknFpVECs= )
+ 3600 NSEC ns2.example. A RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+ 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+ jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+ ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+ IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+ ns2.example. 3600 IN A 192.0.2.2
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+ Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+ yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+ 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+ rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+ 3600 NSEC *.w.example. A RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
+ VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
+ 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
+ l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
+ Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
+ *.w.example. 3600 IN MX 1 ai.example.
+ 3600 RRSIG MX 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+ f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+ tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+ TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+ 4kX18MMR34i8lC36SR5xBni8vHI= )
+ 3600 NSEC x.w.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+ HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+ 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+ 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+ s1InQ2UoIv6tJEaaKkP701j8OLA= )
+ x.w.example. 3600 IN MX 1 xx.example.
+ 3600 RRSIG MX 5 3 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+ XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+ H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+ kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 42]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+ 3600 NSEC x.y.w.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 5 3 3600 20040509183619 (
+ 20040409183619 38519 example.
+ aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
+ vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
+ mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
+ NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
+ IjgiM8PXkBQtxPq37wDKALkyn7Q= )
+ x.y.w.example. 3600 IN MX 1 xx.example.
+ 3600 RRSIG MX 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
+ t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
+ q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
+ GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
+ +gLcMZBnHJ326nb/TOOmrqNmQQE= )
+ 3600 NSEC xx.example. MX RRSIG NSEC
+ 3600 RRSIG NSEC 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+ ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+ xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+ a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+ QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+ xx.example. 3600 IN A 192.0.2.10
+ 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+ 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+ 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+ VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+ kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+ 3600 HINFO "KLH-10" "TOPS-20"
+ 3600 RRSIG HINFO 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
+ t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
+ BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
+ 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
+ RgNvuwbioFSEuv2pNlkq0goYxNY= )
+ 3600 AAAA 2001:db8::f00:baaa
+ 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+ aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+ ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+ U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 43]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ xS9cL2QgW7FChw16mzlkH6/vsfs= )
+ 3600 NSEC example. A HINFO AAAA RRSIG NSEC
+ 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
+ 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
+ mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
+ asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
+ GghLahumFIpg4MO3LS/prgzVVWo= )
+
+ The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
+ Flags indicate that each of these DNSKEY RRs is a zone key. One of
+ these DNSKEY RRs also has the SEP flag set and has been used to sign
+ the apex DNSKEY RRset; this is the key which should be hashed to
+ generate a DS record to be inserted into the parent zone. The other
+ DNSKEY is used to sign all the other RRsets in the zone.
+
+ The zone includes a wildcard entry "*.w.example". Note that the name
+ "*.w.example" is used in constructing NSEC chains, and that the RRSIG
+ covering the "*.w.example" MX RRset has a label count of 2.
+
+ The zone also includes two delegations. The delegation to
+ "b.example" includes an NS RRset, glue address records, and an NSEC
+ RR; note that only the NSEC RRset is signed. The delegation to
+ "a.example" provides a DS RR; note that only the NSEC and DS RRsets
+ are signed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 44]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+Appendix B. Example Responses
+
+ The examples in this section show response messages using the signed
+ zone example in Appendix A.
+
+B.1 Answer
+
+ A successful query to an authoritative server.
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ x.w.example. IN MX
+
+ ;; Answer
+ x.w.example. 3600 IN MX 1 xx.example.
+ x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+ XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+ H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+ kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+ jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+
+ ;; Authority
+ example. 3600 NS ns1.example.
+ example. 3600 NS ns2.example.
+ example. 3600 RRSIG NS 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+ EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+ 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+ RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+ 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+
+ ;; Additional
+ xx.example. 3600 IN A 192.0.2.10
+ xx.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+ 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+ 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+ VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+ kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+ xx.example. 3600 AAAA 2001:db8::f00:baaa
+ xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 45]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+ ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+ U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+ xS9cL2QgW7FChw16mzlkH6/vsfs= )
+ ns1.example. 3600 IN A 192.0.2.1
+ ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+ 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+ im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+ +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+ v/iVXSYC0b7mPSU+EOlknFpVECs= )
+ ns2.example. 3600 IN A 192.0.2.2
+ ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+ Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+ yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+ 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+ rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+
+
+B.2 Name Error
+
+ An authoritative name error. The NSEC RRs prove that the name does
+ not exist and that no covering wildcard exists.
+
+ ;; Header: QR AA DO RCODE=3
+ ;;
+ ;; Question
+ ml.example. IN A
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 46]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
+ b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+ 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+ xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+ 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+ example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
+ example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+ FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+ Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+ SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+ jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+ ;; Additional
+ ;; (empty)
+
+
+B.3 No Data Error
+
+ A "no data" response. The NSEC RR proves that the name exists and
+ that the requested RR type does not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 47]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ ns1.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC
+ ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+ 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+ jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+ ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+ IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+
+ ;; Additional
+ ;; (empty)
+
+
+B.4 Referral to Signed Zone
+
+ Referral to a signed zone. The DS RR contains the data which the
+ resolver will need to validate the corresponding DNSKEY RR in the
+ child zone's apex.
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 48]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+ ;; Question
+ mc.a.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ a.example. 3600 IN NS ns1.a.example.
+ a.example. 3600 IN NS ns2.a.example.
+ a.example. 3600 DS 57855 5 1 (
+ B6DCD485719ADCA18E5F3D48A2331627FDD3
+ 636B )
+ a.example. 3600 RRSIG DS 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+ oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+ kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+ EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+ Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+
+ ;; Additional
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+
+
+B.5 Referral to Unsigned Zone
+
+ Referral to an unsigned zone. The NSEC RR proves that no DS RR for
+ this delegation exists in the parent zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 49]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+ ;; Question
+ mc.b.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ b.example. 3600 IN NS ns1.b.example.
+ b.example. 3600 IN NS ns2.b.example.
+ b.example. 3600 NSEC ns1.example. NS RRSIG NSEC
+ b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+ 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+ xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+ 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+ vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+
+ ;; Additional
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+
+
+B.6 Wildcard Expansion
+
+ A successful query which was answered via wildcard expansion. The
+ label count in the answer's RRSIG RR indicates that a wildcard RRset
+ was expanded to produce this response, and the NSEC RR proves that no
+ closer match exists in the zone.
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN MX
+
+ ;; Answer
+ a.z.w.example. 3600 IN MX 1 ai.example.
+ a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+ f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+ tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+ TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+ 4kX18MMR34i8lC36SR5xBni8vHI= )
+
+ ;; Authority
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 50]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ example. 3600 NS ns1.example.
+ example. 3600 NS ns2.example.
+ example. 3600 RRSIG NS 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+ EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+ 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+ RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+ 0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+ x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
+ x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+ ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+ xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+ a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+ QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+
+ ;; Additional
+ ai.example. 3600 IN A 192.0.2.9
+ ai.example. 3600 RRSIG A 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+ ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+ hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+ ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+ 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+ ai.example. 3600 AAAA 2001:db8::f00:baa9
+ ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+ kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+ 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+ cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+ sZM6QjBBLmukH30+w1z3h8PUP2o= )
+
+
+B.7 Wildcard No Data Error
+
+ A "no data" response for a name covered by a wildcard. The NSEC RRs
+ prove that the matching wildcard name does not have any RRs of the
+ requested type and that no closer match exists in the zone.
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN AAAA
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 51]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC
+ x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 (
+ 20040409183619 38519 example.
+ OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+ ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+ xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+ a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+ QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+ *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC
+ *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 (
+ 20040409183619 38519 example.
+ r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+ HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+ 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+ 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+ s1InQ2UoIv6tJEaaKkP701j8OLA= )
+
+ ;; Additional
+ ;; (empty)
+
+
+B.8 DS Child Zone No Data Error
+
+ A "no data" response for a QTYPE=DS query which was mistakenly sent
+ to a name server for the child zone.
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 52]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ example. IN DS
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1081539377
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 RRSIG SOA 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+ 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+ vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+ DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+ jV7j86HyQgM5e7+miRAz8V01b0I= )
+ example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY
+ example. 3600 RRSIG NSEC 5 1 3600 20040509183619 (
+ 20040409183619 38519 example.
+ O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+ FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+ Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+ SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+ jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+ ;; Additional
+ ;; (empty)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 53]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+Appendix C. Authentication Examples
+
+ The examples in this section show how the response messages in
+ Appendix B are authenticated.
+
+C.1 Authenticating An Answer
+
+ The query in section Appendix B.1 returned an MX RRset for
+ "x.w.example.com". The corresponding RRSIG indicates the MX RRset
+ was signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
+ The resolver needs the corresponding DNSKEY RR in order to
+ authenticate this answer. The discussion below describes how a
+ resolver might obtain this DNSKEY RR.
+
+ The RRSIG indicates the original TTL of the MX RRset was 3600 and,
+ for the purpose of authentication, the current TTL is replaced by
+ 3600. The RRSIG labels field value of 3 indicates the answer was not
+ the result of wildcard expansion. The "x.w.example.com" MX RRset is
+ placed in canonical form and, assuming the current time falls between
+ the signature inception and expiration dates, the signature is
+ authenticated.
+
+C.1.1 Authenticating the example DNSKEY RR
+
+ This example shows the logical authentication process that starts
+ from the a configured root DNSKEY (or DS RR) and moves down the tree
+ to authenticate the desired "example" DNSKEY RR. Note the logical
+ order is presented for clarity and an implementation may choose to
+ construct the authentication as referrals are received or may choose
+ to construct the authentication chain only after all RRsets have been
+ obtained, or in any other combination it sees fit. The example here
+ demonstrates only the logical process and does not dictate any
+ implementation rules.
+
+ We assume the resolver starts with an configured DNSKEY RR for the
+ root zone (or a configured DS RR for the root zone). The resolver
+ checks this configured DNSKEY RR is present in the root DNSKEY RRset
+ (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this
+ DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime
+ is valid. If all these conditions are met, all keys in the DNSKEY
+ RRset are considered authenticated. The resolver then uses one (or
+ more) of the root DNSKEY RRs to authenticate the "example" DS RRset.
+ Note the resolver may need to query the root zone to obtain the root
+ DNSKEY RRset or "example" DS RRset.
+
+ Once the DS RRset has been authenticated using the root DNSKEY, the
+ resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+ RR that matches one of the authenticated "example" DS RRs. If such a
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 54]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ matching "example" DNSKEY is found, the resolver checks this DNSKEY
+ RR has signed the "example" DNSKEY RRset and the signature lifetime
+ is valid. If all these conditions are met, all keys in the "example"
+ DNSKEY RRset are considered authenticated.
+
+ Finally the resolver checks that some DNSKEY RR in the "example"
+ DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This
+ DNSKEY is used to authenticated the RRSIG included in the response.
+ If multiple "example" DNSKEY RRs match this algorithm and key tag,
+ then each DNSKEY RR is tried and the answer is authenticated if any
+ of the matching DNSKEY RRs validates the signature as described
+ above.
+
+C.2 Name Error
+
+ The query in section Appendix B.2 returned NSEC RRs that prove the
+ requested data does not exist and no wildcard applies. The negative
+ reply is authenticated by verifying both NSEC RRs. The NSEC RRs are
+ authenticated in a manner identical to that of the MX RRset discussed
+ above.
+
+C.3 No Data Error
+
+ The query in section Appendix B.3 returned an NSEC RR that proves the
+ requested name exists, but the requested RR type does not exist. The
+ negative reply is authenticated by verifying the NSEC RR. The NSEC
+ RR is authenticated in a manner identical to that of the MX RRset
+ discussed above.
+
+C.4 Referral to Signed Zone
+
+ The query in section Appendix B.4 returned a referral to the signed
+ "a.example." zone. The DS RR is authenticated in a manner identical
+ to that of the MX RRset discussed above. This DS RR is used to
+ authenticate the "a.example" DNSKEY RRset.
+
+ Once the "a.example" DS RRset has been authenticated using the
+ "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+ for some "a.example" DNSKEY RR that matches the DS RR. If such a
+ matching "a.example" DNSKEY is found, the resolver checks this DNSKEY
+ RR has signed the "a.example" DNSKEY RRset and the signature lifetime
+ is valid. If all these conditions are met, all keys in the
+ "a.example" DNSKEY RRset are considered authenticated.
+
+C.5 Referral to Unsigned Zone
+
+ The query in section Appendix B.5 returned a referral to an unsigned
+ "b.example." zone. The NSEC proves that no authentication leads from
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 55]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+ "example" to "b.example" and the NSEC RR is authenticated in a manner
+ identical to that of the MX RRset discussed above.
+
+C.6 Wildcard Expansion
+
+ The query in 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 5 and key tag 38519.
+ The RRSIG indicates the original TTL of the MX RRset was 3600 and,
+ for the purpose of authentication, the current TTL is replaced by
+ 3600. The RRSIG labels field value of 2 indicates the answer the
+ result of wildcard expansion since the "a.z.w.example" name contains
+ 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example",
+ the MX RRset is placed in canonical form and, assuming the current
+ time falls between the signature inception and expiration dates, the
+ signature is authenticated.
+
+ The NSEC proves that no closer match (exact or closer wildcard) could
+ have been used to answer this query and the NSEC RR must also be
+ authenticated before the answer is considered valid.
+
+C.7 Wildcard No Data Error
+
+ The query in section Appendix B.7 returned NSEC RRs that prove the
+ requested data does not exist and no wildcard applies. The negative
+ reply is authenticated by verifying both NSEC RRs.
+
+C.8 DS Child Zone No Data Error
+
+ The query in section Appendix B.8 returned NSEC RRs that shows the
+ requested was answered by a child server ("example" server). The
+ NSEC RR indicates the presence of an SOA RR, showing the answer is
+ from the child . Queries for the "example" DS RRset should be sent
+ to the parent servers ("root" servers).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 56]
+
+Internet-Draft DNSSEC Protocol Modifications July 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 57]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
new file mode 100644
index 00000000000..79a17284357
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt
@@ -0,0 +1,1849 @@
+
+
+DNS Extensions R. Arends
+Internet-Draft Telematica Instituut
+Expires: January 13, 2005 R. Austein
+ ISC
+ M. Larson
+ VeriSign
+ D. Massey
+ USC/ISI
+ S. Rose
+ NIST
+ July 15, 2004
+
+
+ Resource Records for the DNS Security Extensions
+ draft-ietf-dnsext-dnssec-records-09
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 13, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document is part of a family of documents that describes the DNS
+ Security Extensions (DNSSEC). The DNS Security Extensions are a
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 1]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ collection of resource records and protocol modifications that
+ provide source authentication for the DNS. This document defines the
+ public key (DNSKEY), delegation signer (DS), resource record digital
+ signature (RRSIG), and authenticated denial of existence (NSEC)
+ resource records. The purpose and format of each resource record is
+ described in detail, and an example of each resource record is given.
+
+ This document obsoletes RFC 2535 and incorporates changes from all
+ updates to RFC 2535.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Background and Related Documents . . . . . . . . . . . . . 4
+ 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5
+ 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5
+ 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5
+ 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6
+ 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6
+ 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6
+ 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6
+ 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6
+ 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7
+ 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8
+ 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8
+ 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9
+ 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9
+ 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9
+ 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10
+ 3.1.5 Signature Expiration and Inception Fields . . . . . . 10
+ 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10
+ 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11
+ 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11
+ 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12
+ 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12
+ 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14
+ 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14
+ 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14
+ 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15
+ 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16
+ 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16
+ 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16
+ 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.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 2]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ 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 . . . . . . . . . . . . . . . . . . . 24
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26
+ 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
+ A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29
+ A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29
+ A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29
+ A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30
+ B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31
+ B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32
+ Intellectual Property and Copyright Statements . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 3]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) introduce four new DNS resource
+ record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the
+ purpose of each resource record (RR), the RR's RDATA format, and its
+ presentation format (ASCII representation).
+
+1.1 Background and Related Documents
+
+ The reader is assumed to be familiar with the basic DNS concepts
+ described in [RFC1034], [RFC1035] and subsequent RFCs that update
+ them: [RFC2136], [RFC2181] and [RFC2308].
+
+ This document is part of a family of documents that define the DNS
+ security extensions. The DNS security extensions (DNSSEC) are a
+ collection of resource records and DNS protocol modifications that
+ add source authentication and data integrity to the Domain Name
+ System (DNS). An introduction to DNSSEC and definitions of common
+ terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is
+ assumed to be familiar with this document. A description of DNS
+ protocol modifications can be found in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+ This document defines the DNSSEC resource records.
+
+1.2 Reserved Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 4]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+2. The DNSKEY Resource Record
+
+ DNSSEC uses public key cryptography to sign and authenticate DNS
+ resource record sets (RRsets). The public keys are stored in DNSKEY
+ resource records and are used in the DNSSEC authentication process
+ described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its
+ authoritative RRsets using a private key and stores the corresponding
+ public key in a DNSKEY RR. A resolver can then use the public key to
+ authenticate signatures covering the RRsets in the zone.
+
+ The DNSKEY RR is not intended as a record for storing arbitrary
+ public keys and MUST NOT be used to store certificates or public keys
+ that do not directly relate to the DNS infrastructure.
+
+ The Type value for the DNSKEY RR type is 48.
+
+ The DNSKEY RR is class independent.
+
+ The DNSKEY RR has no special TTL requirements.
+
+2.1 DNSKEY RDATA Wire Format
+
+ The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
+ octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
+ Field.
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags | Protocol | Algorithm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / /
+ / Public Key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+2.1.1 The Flags Field
+
+ Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
+ then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner
+ name MUST be the name of a zone. If bit 7 has value 0, then the
+ DNSKEY record holds some other type of DNS public key and MUST NOT be
+ used to verify RRSIGs that cover RRsets.
+
+ Bit 15 of the Flags field is the Secure Entry Point flag, described
+ in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a
+ key intended for use as a secure entry point. This flag is only
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 5]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ intended to be to a hint to zone signing or debugging software as to
+ the intended use of this DNSKEY record; validators MUST NOT alter
+ their behavior during the signature validation process in any way
+ based on the setting of this bit. This also means a DNSKEY RR with
+ the SEP bit set would also need the Zone Key flag set in order to
+ legally be able to generate signatures. A DNSKEY RR with the SEP set
+ and the Zone Key flag not set MUST NOT be used to verify RRSIGs that
+ cover RRsets.
+
+ Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
+ creation of the DNSKEY RR, and MUST be ignored upon reception.
+
+2.1.2 The Protocol Field
+
+ The Protocol Field MUST have value 3 and the DNSKEY RR MUST be
+ treated as invalid during signature verification if found to be some
+ value other than 3.
+
+2.1.3 The Algorithm Field
+
+ The Algorithm field identifies the public key's cryptographic
+ algorithm and determines the format of the Public Key field. A list
+ of DNSSEC algorithm types can be found in Appendix A.1
+
+2.1.4 The Public Key Field
+
+ The Public Key Field holds the public key material. The format
+ depends on the algorithm of the key being stored and are described in
+ separate documents.
+
+2.1.5 Notes on DNSKEY RDATA Design
+
+ Although the Protocol Field always has value 3, it is retained for
+ backward compatibility with early versions of the KEY record.
+
+2.2 The DNSKEY RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Flag field MUST be represented as an unsigned decimal integer.
+ Given the currently defined flags, the possible values are: 0, 256,
+ or 257.
+
+ The Protocol Field MUST be represented as an unsigned decimal integer
+ with a value of 3.
+
+ The Algorithm field MUST be represented either as an unsigned decimal
+ integer or as an algorithm mnemonic as specified in Appendix A.1.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 6]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ The Public Key field MUST be represented as a Base64 encoding of the
+ Public Key. Whitespace is allowed within the Base64 text. For a
+ definition of Base64 encoding, see [RFC3548].
+
+2.3 DNSKEY RR Example
+
+ The following DNSKEY RR stores a DNS zone key for example.com.
+
+ example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
+ Cbl+BBZH4b/0PY1kxkmvHjcZc8no
+ kfzj31GajIQKY+5CptLr3buXA10h
+ WqTkF7H6RfoRqXQeogmMHfpftf6z
+ Mv1LyBUgia7za6ZEzOJBOztyvhjL
+ 742iU/TpPSEDhm2SNKLijfUppn1U
+ aNvv4w== )
+
+ The first four text fields specify the owner name, TTL, Class, and RR
+ type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in
+ the Flags field has value 1. Value 3 is the fixed Protocol value.
+ Value 5 indicates the public key algorithm. Appendix A.1 identifies
+ algorithm type 5 as RSA/SHA1 and indicates that the format of the
+ RSA/SHA1 public key field is defined in [RFC3110]. The remaining
+ text is a Base64 encoding of the public key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 7]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+3. The RRSIG Resource Record
+
+ DNSSEC uses public key cryptography to sign and authenticate DNS
+ resource record sets (RRsets). Digital signatures are stored in
+ RRSIG resource records and are used in the DNSSEC authentication
+ process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator
+ can use these RRSIG RRs to authenticate RRsets from the zone. The
+ RRSIG RR MUST only be used to carry verification material (digital
+ signatures) used to secure DNS operations.
+
+ An RRSIG record contains the signature for an RRset with a particular
+ name, class, and type. The RRSIG RR specifies a validity interval
+ for the signature and uses the Algorithm, the Signer's Name, and the
+ Key Tag to identify the DNSKEY RR containing the public key that a
+ validator can use to verify the signature.
+
+ Because every authoritative RRset in a zone must be protected by a
+ digital signature, RRSIG RRs must be present for names containing a
+ CNAME RR. This is a change to the traditional DNS specification
+ [RFC1034] 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 signed
+ zone.
+
+ The Type value for the RRSIG RR type is 46.
+
+ The RRSIG RR is class independent.
+
+ An RRSIG RR MUST have the same class as the RRset it covers.
+
+ The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
+ covers. This is an exception to the [RFC2181] rules for TTL values
+ of individual RRs within a RRset: individual RRSIG with the same
+ owner name will have different TTL values if the RRsets they cover
+ have different TTL values.
+
+3.1 RRSIG RDATA Wire Format
+
+ The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
+ 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
+ TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
+ Inception field, a 2 octet Key tag, the Signer's Name field, and the
+ Signature field.
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 8]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type Covered | Algorithm | Labels |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Original TTL |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Signature Expiration |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Signature Inception |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Tag | /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / /
+ / Signature /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1 The Type Covered Field
+
+ The Type Covered field identifies the type of the RRset that is
+ covered by this RRSIG record.
+
+3.1.2 The Algorithm Number Field
+
+ The Algorithm Number field identifies the cryptographic algorithm
+ used to create the signature. A list of DNSSEC algorithm types can
+ be found in Appendix A.1
+
+3.1.3 The Labels Field
+
+ The Labels field specifies the number of labels in the original RRSIG
+ RR owner name. The significance of this field is that a validator
+ uses it to determine if the answer was synthesized from a wildcard.
+ If so, it can be used to determine what owner name was used in
+ generating the signature.
+
+ To validate a signature, the validator needs the original owner name
+ that was used to create the signature. If the original owner name
+ contains a wildcard label ("*"), the owner name may have been
+ expanded by the server during the response process, in which case the
+ validator will need to reconstruct the original owner name in order
+ to validate the signature. [I-D.ietf-dnsext-dnssec-protocol]
+ describes how to use the Labels field to reconstruct the original
+ owner name.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 9]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ The value of the Labels field MUST NOT count either the null (root)
+ label that terminates the owner name or the wildcard label (if
+ present). The value of the Labels field MUST be less than or equal
+ to the number of labels in the RRSIG owner name. For example,
+ "www.example.com." has a Labels field value of 3, and
+ "*.example.com." has a Labels field value of 2. Root (".") has a
+ Labels field value of 0.
+
+ Although the wildcard label is not included in the count stored in
+ the Labels field of the RRSIG RR, the wildcard label is part of the
+ RRset's owner name when generating or verifying the signature.
+
+3.1.4 Original TTL Field
+
+ The Original TTL field specifies the TTL of the covered RRset as it
+ appears in the authoritative zone.
+
+ The Original TTL field is necessary because a caching resolver
+ decrements the TTL value of a cached RRset. In order to validate a
+ signature, a validator requires the original TTL.
+ [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original
+ TTL field value to reconstruct the original TTL.
+
+3.1.5 Signature Expiration and Inception Fields
+
+ The Signature Expiration and Inception fields specify a validity
+ period for the signature. The RRSIG record MUST NOT be used for
+ authentication prior to the inception date and MUST NOT be used for
+ authentication after the expiration date.
+
+ Signature Expiration and Inception field values are in POSIX.1 time
+ format: a 32-bit unsigned number of seconds elapsed since 1 January
+ 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The
+ longest interval which can be expressed by this format without
+ wrapping is approximately 136 years. An RRSIG RR can have an
+ Expiration field value which is numerically smaller than the
+ Inception field value if the expiration field value is near the
+ 32-bit wrap-around point or if the signature is long lived. Because
+ of this, all comparisons involving these fields MUST use "Serial
+ number arithmetic" as defined in [RFC1982]. As a direct consequence,
+ the values contained in these fields cannot refer to dates more than
+ 68 years in either the past or the future.
+
+3.1.6 The Key Tag Field
+
+ The Key Tag field contains the key tag value of the DNSKEY RR that
+ validates this signature, in network byte order. Appendix B explains
+ how to calculate Key Tag values.
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 10]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+3.1.7 The Signer's Name Field
+
+ The Signer's Name field value identifies the owner name of the DNSKEY
+ RR which a validator is supposed to use to validate this signature.
+ The Signer's Name field MUST contain the name of the zone of the
+ covered RRset. A sender MUST NOT use DNS name compression on the
+ Signer's Name field when transmitting a RRSIG RR.
+
+3.1.8 The Signature Field
+
+ The Signature field contains the cryptographic signature that covers
+ the RRSIG RDATA (excluding the Signature field) and the RRset
+ specified by the RRSIG owner name, RRSIG class, and RRSIG Type
+ Covered field. The format of this field depends on the algorithm in
+ use and these formats are described in separate companion documents.
+
+3.1.8.1 Signature Calculation
+
+ A signature covers the RRSIG RDATA (excluding the Signature Field)
+ and covers the data RRset specified by the RRSIG owner name, RRSIG
+ class, and RRSIG Type Covered fields. The RRset is in canonical form
+ (see Section 6) and the set RR(1),...RR(n) is signed as follows:
+
+ signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
+
+ "|" denotes concatenation;
+
+ RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+ with the Signer's Name field in canonical form and
+ the Signature field excluded;
+
+ RR(i) = owner | type | class | TTL | RDATA length | RDATA
+
+ "owner" is the fully qualified owner name of the RRset in
+ canonical form (for RRs with wildcard owner names, the
+ wildcard label is included in the owner name);
+
+ Each RR MUST have the same owner name as the RRSIG RR;
+
+ Each RR MUST have the same class as the RRSIG RR;
+
+ Each RR in the RRset MUST have the RR type listed in the
+ RRSIG RR's Type Covered field;
+
+ Each RR in the RRset MUST have the TTL listed in the
+ RRSIG Original TTL Field;
+
+ Any DNS names in the RDATA field of each RR MUST be in
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 11]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ canonical form; and
+
+ The RRset MUST be sorted in canonical order.
+
+ See Section 6.2 and Section 6.3 for details on canonical form and
+ ordering of RRsets.
+
+3.2 The RRSIG RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Type Covered field is represented as a RR type mnemonic. When
+ the mnemonic is not known, the TYPE representation as described in
+ [RFC3597] (section 5) MUST be used.
+
+ The Algorithm field value MUST be represented either as an unsigned
+ decimal integer or as an algorithm mnemonic as specified in Appendix
+ A.1.
+
+ The Labels field value MUST be represented as an unsigned decimal
+ integer.
+
+ The Original TTL field value MUST be represented as an unsigned
+ decimal integer.
+
+ The Signature Expiration Time and Inception Time field values MUST be
+ represented either as seconds since 1 January 1970 00:00:00 UTC or in
+ the form YYYYMMDDHHmmSS in UTC, where:
+ YYYY is the year (0001-9999, but see Section 3.1.5);
+ MM is the month number (01-12);
+ DD is the day of the month (01-31);
+ HH is the hour in 24 hours notation (00-23);
+ mm is the minute (00-59); and
+ SS is the second (00-59).
+
+ The Key Tag field MUST be represented as an unsigned decimal integer.
+
+ The Signer's Name field value MUST be represented as a domain name.
+
+ The Signature field is represented as a Base64 encoding of the
+ signature. Whitespace is allowed within the Base64 text. See
+ Section 2.2.
+
+3.3 RRSIG RR Example
+
+ The following RRSIG RR stores the signature for the A RRset of
+ host.example.com:
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 12]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
+ 20030220173103 2642 example.com.
+ oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
+ PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
+ B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
+ GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
+ J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
+
+ The first four fields specify the owner name, TTL, Class, and RR type
+ (RRSIG). The "A" represents the Type Covered field. The value 5
+ identifies the algorithm used (RSA/SHA1) to create the signature.
+ The value 3 is the number of Labels in the original owner name. The
+ value 86400 in the RRSIG RDATA is the Original TTL for the covered A
+ RRset. 20030322173103 and 20030220173103 are the expiration and
+ inception dates, respectively. 2642 is the Key Tag, and example.com.
+ is the Signer's Name. The remaining text is a Base64 encoding of the
+ signature.
+
+ Note that combination of RRSIG RR owner name, class, and Type Covered
+ indicate that this RRSIG covers the "host.example.com" A RRset. The
+ Label value of 3 indicates that no wildcard expansion was used. The
+ Algorithm, Signer's Name, and Key Tag indicate this signature can be
+ authenticated using an example.com zone DNSKEY RR whose algorithm is
+ 5 and key tag is 2642.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 13]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+4. The NSEC Resource Record
+
+ The NSEC resource record lists two separate things: the next owner
+ name (in the canonical ordering of the zone) which contains
+ authoritative data or a delegation point NS RRset, and the set of RR
+ types present at the NSEC RR's owner name. The complete set of NSEC
+ RRs in a zone both indicate which authoritative RRsets exist in a
+ zone and also form a chain of authoritative owner names in the zone.
+ This information is used to provide authenticated denial of existence
+ for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol].
+
+ 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 signed zone.
+
+ See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone
+ signer determines precisely which NSEC RRs it needs to include in a
+ zone.
+
+ The type value for the NSEC RR is 47.
+
+ The NSEC RR is class independent.
+
+ The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+ field. This is in the spirit of negative caching [RFC2308].
+
+4.1 NSEC RDATA Wire Format
+
+ The RDATA of the NSEC RR is as shown below:
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Next Domain Name /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Type Bit Maps /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+4.1.1 The Next Domain Name Field
+
+ The Next Domain field contains the next owner name (in the canonical
+ ordering of the zone) which has authoritative data or contains a
+ delegation point NS RRset; see Section 6.1 for an explanation of
+ canonical ordering. The value of the Next Domain Name field in the
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 14]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ last NSEC record in the zone is the name of the zone apex (the owner
+ name of the zone's SOA RR). This indicates that the owner name of
+ the NSEC RR is the last name in the canonical ordering of the zone.
+
+ A sender MUST NOT use DNS name compression on the Next Domain Name
+ field when transmitting an NSEC RR.
+
+ Owner names of RRsets 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
+
+ The Type Bit Maps field identifies the RRset types which exist at the
+ NSEC RR's owner name.
+
+ The RR type space is split into 256 window blocks, each representing
+ the low-order 8 bits of the 16-bit RR type space. Each block that
+ has at least one active RR type is encoded using a single octet
+ window number (from 0 to 255), a single octet bitmap length (from 1
+ to 32) indicating the number of octets used for the window block's
+ bitmap, and up to 32 octets (256 bits) of bitmap.
+
+ Blocks are present in the NSEC RR RDATA in increasing numerical
+ order.
+
+ Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+ where "|" denotes concatenation.
+
+ 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,
+ it indicates that an RRset of that type is present for the NSEC RR's
+ owner name. If a bit is clear, it indicates that no RRset of that
+ type is present for the NSEC RR's owner name.
+
+ Bits representing pseudo-types MUST be clear, 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
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 15]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ interpreted as zero octets.
+
+ The bitmap for the NSEC RR at a delegation point requires special
+ attention. Bits corresponding to the delegation NS RRset and the RR
+ types for which the parent zone has authoritative data MUST be set;
+ bits corresponding to any non-NS RRset for which the parent is not
+ authoritative MUST be clear.
+
+ A zone MUST NOT include an NSEC RR for any domain name that only
+ holds glue records.
+
+4.1.3 Inclusion of Wildcard Names in NSEC RDATA
+
+ If a wildcard owner name appears in a zone, the wildcard label ("*")
+ is treated as a literal symbol and is treated the same as any other
+ owner name for purposes of generating NSEC RRs. Wildcard owner names
+ appear in the Next Domain Name field without any wildcard expansion.
+ [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards
+ on authenticated denial of existence.
+
+4.2 The NSEC RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Next Domain Name field is represented as a domain name.
+
+ 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
+
+ The following NSEC RR identifies the RRsets associated with
+ alfa.example.com. and identifies the next authoritative name after
+ alfa.example.com.
+
+ alfa.example.com. 86400 IN NSEC host.example.com. (
+ A MX RRSIG NSEC TYPE1234 )
+
+ The first four text fields specify the name, TTL, Class, and RR type
+ (NSEC). The entry host.example.com. is the next authoritative name
+ after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC,
+ and TYPE1234 mnemonics indicate 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:
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 16]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ 0x04 'h' 'o' 's' 't'
+ 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
+ 0x03 'c' 'o' 'm' 0x00
+ 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+ 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x20
+
+ Assuming that the validator can authenticate this NSEC record, it
+ could be used to prove that beta.example.com does not exist, or could
+ be used to prove there is no AAAA record associated with
+ alfa.example.com. Authenticated denial of existence is discussed in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 17]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+5. The DS Resource Record
+
+ The DS Resource Record refers to a DNSKEY RR and is used in the DNS
+ DNSKEY authentication process. A DS RR refers to a DNSKEY RR by
+ storing the key tag, algorithm number, and a digest of the DNSKEY RR.
+ Note that while the digest should be sufficient to identify the
+ public key, storing the key tag and key algorithm helps make the
+ identification process more efficient. By authenticating the DS
+ record, a resolver can authenticate the DNSKEY RR to which the DS
+ record points. The key authentication process is described in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+ The DS RR and its corresponding DNSKEY RR have the same owner name,
+ but they are stored in different locations. The DS RR appears only
+ on the upper (parental) side of a delegation, and is authoritative
+ data in the parent zone. For example, the DS RR for "example.com" is
+ stored in the "com" zone (the parent zone) rather than in the
+ "example.com" zone (the child zone). The corresponding DNSKEY RR is
+ stored in the "example.com" zone (the child zone). This simplifies
+ DNS zone management and zone signing, but introduces special response
+ processing requirements for the DS RR; these are described in
+ [I-D.ietf-dnsext-dnssec-protocol].
+
+ The type number for the DS record is 43.
+
+ The DS resource record is class independent.
+
+ The DS RR has no special TTL requirements.
+
+5.1 DS RDATA Wire Format
+
+ The RDATA for a DS RR consists of a 2 octet Key Tag field, a one
+ octet Algorithm field, a one octet Digest Type field, and a Digest
+ field.
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Tag | Algorithm | Digest Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / /
+ / Digest /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 18]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+5.1.1 The Key Tag Field
+
+ The Key Tag field lists the key tag of the DNSKEY RR referred to by
+ the DS record, in network byte order.
+
+ The Key Tag used by the DS RR is identical to the Key Tag used by
+ RRSIG RRs. Appendix B describes how to compute a Key Tag.
+
+5.1.2 The Algorithm Field
+
+ The Algorithm field lists the algorithm number of the DNSKEY RR
+ referred to by the DS record.
+
+ The algorithm number used by the DS RR is identical to the algorithm
+ number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the
+ algorithm number types.
+
+5.1.3 The Digest Type Field
+
+ The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
+ RR. The Digest Type field identifies the algorithm used to construct
+ the digest. Appendix A.2 lists the possible digest algorithm types.
+
+5.1.4 The Digest Field
+
+ The DS record refers to a DNSKEY RR by including a digest of that
+ DNSKEY RR.
+
+ The digest is calculated by concatenating the canonical form of the
+ fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
+ and then applying the digest algorithm.
+
+ digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
+
+ "|" denotes concatenation
+
+ DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
+
+
+ The size of the digest may vary depending on the digest algorithm and
+ DNSKEY RR size. As of the time of writing, the only defined digest
+ algorithm is SHA-1, which produces a 20 octet digest.
+
+5.2 Processing of DS RRs When Validating Responses
+
+ The DS RR links the authentication chain across zone boundaries, so
+ the DS RR requires extra care in processing. The DNSKEY RR referred
+ to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 19]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC
+ zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in
+ the validation process.
+
+5.3 The DS RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Key Tag field MUST be represented as an unsigned decimal integer.
+
+ The Algorithm field MUST be represented either as an unsigned decimal
+ integer or as an algorithm mnemonic specified in Appendix A.1.
+
+ The Digest Type field MUST be represented as an unsigned decimal
+ integer.
+
+ The Digest MUST be represented as a sequence of case-insensitive
+ hexadecimal digits. Whitespace is allowed within the hexadecimal
+ text.
+
+5.4 DS RR Example
+
+ The following example shows a DNSKEY RR and its corresponding DS RR.
+
+ dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+ fwJr1AYtsmx3TGkJaNXVbfi/
+ 2pHm822aJ5iI9BMzNXxeYCmZ
+ DRD99WYwYqUSdjMmmAphXdvx
+ egXd/M5+X7OrzKBaMbCVdFLU
+ Uh6DhweJBjEVv5f2wwjM9Xzc
+ nOf+EPbtG9DMBmADjFDc2w/r
+ ljwvFw==
+ ) ; key id = 60485
+
+ dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
+ 98631FAD1A292118 )
+
+
+ The first four text fields specify the name, TTL, Class, and RR type
+ (DS). Value 60485 is the key tag for the corresponding
+ "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
+ used by this "dskey.example.com." DNSKEY RR. The value 1 is the
+ algorithm used to construct the digest, and the rest of the RDATA
+ text is the digest in hexadecimal.
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 20]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+6. Canonical Form and Order of Resource Records
+
+ This section defines a canonical form for resource records, a
+ canonical ordering of DNS names, and a canonical ordering of resource
+ records within an RRset. A canonical name order is required to
+ construct the NSEC name chain. A canonical RR form and ordering
+ within an RRset are required to construct and verify RRSIG RRs.
+
+6.1 Canonical DNS Name Order
+
+ For purposes of DNS security, owner names are ordered by treating
+ individual labels as unsigned left-justified octet strings. The
+ absence of a octet sorts before a zero value octet, and upper case
+ US-ASCII letters are treated as if they were lower case US-ASCII
+ letters.
+
+ To compute the canonical ordering of a set of DNS names, start by
+ sorting the names according to their most significant (rightmost)
+ labels. For names in which the most significant label is identical,
+ continue sorting according to their next most significant label, and
+ so forth.
+
+ For example, the following names are sorted in canonical DNS name
+ order. The most significant label is "example". At this level,
+ "example" sorts first, followed by names ending in "a.example", then
+ names ending "z.example". The names within each level are sorted in
+ the same way.
+
+ example
+ a.example
+ yljkjljk.a.example
+ Z.a.example
+ zABC.a.EXAMPLE
+ z.example
+ \001.z.example
+ *.z.example
+ \200.z.example
+
+
+6.2 Canonical RR Form
+
+ For purposes of DNS security, the canonical form of an RR is the wire
+ format of the RR where:
+ 1. Every domain name in the RR is fully expanded (no DNS name
+ compression) and fully qualified;
+ 2. All uppercase US-ASCII letters in the owner name of the RR are
+ replaced by the corresponding lowercase US-ASCII letters;
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 21]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+ HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
+ SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in
+ the DNS names contained within the RDATA are replaced by the
+ corresponding lowercase US-ASCII letters;
+ 4. If the owner name of the RR is a wildcard name, the owner name is
+ in its original unexpanded form, including the "*" label (no
+ wildcard substitution); and
+ 5. The RR's TTL is set to its original value as it appears in the
+ originating authoritative zone or the Original TTL field of the
+ covering RRSIG RR.
+
+6.3 Canonical RR Ordering Within An RRset
+
+ For purposes of DNS security, RRs with the same owner name, class,
+ and type are sorted by treating the RDATA portion of the canonical
+ form of each RR as a left-justified unsigned octet sequence where the
+ absence of an octet sorts before a zero octet.
+
+ [RFC2181] specifies that an RRset is not allowed to contain duplicate
+ records (multiple RRs with the same owner name, class, type, and
+ RDATA). Therefore, if an implementation detects duplicate RRs when
+ putting the RRset in canonical form, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 22]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+7. IANA Considerations
+
+ This document introduces no new IANA considerations, because all of
+ the protocol parameters used in this document have already been
+ assigned by previous specifications. However, since the evolution of
+ DNSSEC has been long and somewhat convoluted, this section attempts
+ to describe the current state of the IANA registries and other
+ protocol parameters which are (or once were) related to DNSSEC.
+
+ Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA
+ considerations.
+
+ DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
+ the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS
+ Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47,
+ and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
+ [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted
+ use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
+ security protocol described in [RFC2931] and the transaction KEY
+ Resource Record described in [RFC2930].
+
+ DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
+ for DNSSEC Resource Record Algorithm field numbers, and assigned
+ values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755]
+ altered this registry to include flags for each entry regarding
+ its use with the DNS security extensions. Each algorithm entry
+ could refer to an algorithm that can be used for zone signing,
+ transaction security (see [RFC2931]) or both. Values 6-251 are
+ available for assignment by IETF standards action. 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.
+
+ [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and
+ assigned value 0 to reserved and value 1 to SHA-1.
+
+ KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
+ Protocol Values, but [RFC3445] re-assigned all values other than 3
+ to reserved and closed this IANA registry. The registry remains
+ closed, and all KEY and DNSKEY records are required to have
+ Protocol Octet value of 3.
+
+ Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
+ registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially,
+ this registry only contains an assignment for bit 7 (the ZONE bit)
+ and a reservation for bit 15 for the Secure Entry Point flag (SEP
+ bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by
+ IETF Standards Action.
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 23]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+8. Security Considerations
+
+ This document describes the format of four DNS resource records used
+ by the DNS security extensions, and presents an algorithm for
+ calculating a key tag for a public key. Other than the items
+ described below, the resource records themselves introduce no
+ security considerations. Please see [I-D.ietf-dnsext-dnssec-intro]
+ and [I-D.ietf-dnsext-dnssec-protocol] for 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
+ identify an existing DNSKEY RR, but it is theoretically possible for
+ an attacker to generate a DNSKEY that matches all the DS fields. The
+ probability of constructing such a matching DNSKEY depends on the
+ type of digest algorithm in use. The only currently defined digest
+ algorithm is SHA-1, and the working group believes that constructing
+ a public key which would match the algorithm, key tag, and SHA-1
+ digest given in a DS record would be a sufficiently difficult problem
+ that such an attack is not a serious threat at this time.
+
+ The key tag is used to help select DNSKEY resource records
+ efficiently, but it does not uniquely identify a single DNSKEY
+ resource record. It is possible for two distinct DNSKEY RRs to have
+ the same owner name, the same algorithm type, and the same key tag.
+ An implementation which uses only the key tag to select a DNSKEY RR
+ might select the wrong public key in some circumstances.
+
+ The table of algorithms in Appendix A and the key tag calculation
+ algorithms in Appendix B include the RSA/MD5 algorithm for
+ completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
+ explained in [RFC3110].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 24]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+9. Acknowledgments
+
+ 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. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 25]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+10. References
+
+10.1 Normative References
+
+ [I-D.ietf-dnsext-dnssec-intro]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-10 (work in progress), May
+ 2004.
+
+ [I-D.ietf-dnsext-dnssec-protocol]
+ Arends, R., Austein, R., Larson, M., Massey, D. and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in
+ progress), May 2004.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+ August 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+ Name System (DNS)", RFC 3110, May 2001.
+
+ [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 26]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ Resource Record (RR)", RFC 3445, December 2002.
+
+ [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 3548, July 2003.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
+ (RR) Types", RFC 3597, September 2003.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+ [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer", RFC 3755, April 2004.
+
+ [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure
+ Entry Point Flag", RFC 3757, April 2004.
+
+10.2 Informative References
+
+ [I-D.ietf-dnsext-nsec-rdata]
+ Schlyter, J., "DNSSEC NSEC RDATA Format",
+ draft-ietf-dnsext-nsec-rdata-06 (work in progress), May
+ 2004.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ EMail: roy.arends@telin.nl
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 27]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ Rob Austein
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ EMail: sra@isc.org
+
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ EMail: mlarson@verisign.com
+
+
+ Dan Massey
+ USC Information Sciences Institute
+ 3811 N. Fairfax Drive
+ Arlington, VA 22203
+ USA
+
+ EMail: masseyd@isi.edu
+
+
+ Scott Rose
+ National Institute for Standards and Technology
+ 100 Bureau Drive
+ Gaithersburg, MD 20899-8920
+ USA
+
+ EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 28]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+Appendix A. DNSSEC Algorithm and Digest Types
+
+ The DNS security extensions are designed to be independent of the
+ underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS
+ resource records all use a DNSSEC Algorithm Number to identify the
+ cryptographic algorithm in use by the resource record. The DS
+ resource record also specifies a Digest Algorithm Number to identify
+ the digest algorithm used to construct the DS record. The currently
+ defined Algorithm and Digest Types are listed below. Additional
+ Algorithm or Digest Types could be added as advances in cryptography
+ warrant.
+
+ A DNSSEC aware resolver or name server MUST implement all MANDATORY
+ algorithms.
+
+A.1 DNSSEC Algorithm Types
+
+ 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.
+
+ 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 January 13, 2005 [Page 29]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ domain name, which MUST NOT be compressed. The domain name indicates
+ the private algorithm to use and the remainder of the public key area
+ is determined by that algorithm. Entities should only use domain
+ names they control to designate their private algorithms.
+
+ Algorithm number 254 is reserved for private use and will never be
+ assigned to a specific algorithm. The public key area in the DNSKEY
+ RR and the signature area in the RRSIG RR begin with an unsigned
+ length byte followed by a BER encoded Object Identifier (ISO OID) of
+ that length. The OID indicates the private algorithm in use and the
+ remainder of the area is whatever is required by that algorithm.
+ Entities should only use OIDs they control to designate their private
+ algorithms.
+
+A.2 DNSSEC Digest Types
+
+ A "Digest Type" field in the DS resource record types identifies the
+ cryptographic digest algorithm used by the resource record. The
+ following table lists the currently defined digest algorithm types.
+
+ VALUE Algorithm STATUS
+ 0 Reserved -
+ 1 SHA-1 MANDATORY
+ 2-255 Unassigned -
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 30]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+Appendix B. Key Tag Calculation
+
+ The Key Tag field in the RRSIG and DS resource record types provides
+ a mechanism for selecting a public key efficiently. In most cases, a
+ combination of owner name, algorithm, and key tag can efficiently
+ identify a DNSKEY record. Both the RRSIG and DS resource records
+ have corresponding DNSKEY records. The Key Tag field in the RRSIG
+ and DS records can be used to help select the corresponding DNSKEY RR
+ efficiently when more than one candidate DNSKEY RR is available.
+
+ However, it is essential to note that the key tag is not a unique
+ identifier. It is theoretically possible for two distinct DNSKEY RRs
+ to have the same owner name, the same algorithm, and the same key
+ tag. The key tag is used to limit the possible candidate keys, but
+ it does not uniquely identify a DNSKEY record. Implementations MUST
+ NOT assume that the key tag uniquely identifies a DNSKEY RR.
+
+ The key tag is the same for all DNSKEY algorithm types except
+ algorithm 1 (please see Appendix B.1 for the definition of the key
+ tag for algorithm 1). The key tag algorithm is the sum of the wire
+ format of the DNSKEY RDATA broken into 2 octet groups. First the
+ RDATA (in wire format) is treated as a series of 2 octet groups,
+ these groups are then added together ignoring any carry bits.
+
+ A reference implementation of the key tag algorithm is as an ANSI C
+ function is given below with the RDATA portion of the DNSKEY RR is
+ used as input. It is not necessary to use the following reference
+ code verbatim, but the numerical value of the Key Tag MUST be
+ identical to what the reference implementation would generate for the
+ same input.
+
+ Please note that the algorithm for calculating the Key Tag is almost
+ but not completely identical to the familiar ones complement checksum
+ used in many other Internet protocols. Key Tags MUST be calculated
+ using the algorithm described here rather than the ones complement
+ checksum.
+
+ The following ANSI C reference implementation calculates the value of
+ a Key Tag. This reference implementation applies to all algorithm
+ types except algorithm 1 (see Appendix B.1). The input is the wire
+ format of the RDATA portion of the DNSKEY RR. The code is written
+ for clarity, not efficiency.
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 31]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+ /*
+ * Assumes that int is at least 16 bits.
+ * First octet of the key tag is the most significant 8 bits of the
+ * return value;
+ * Second octet of the key tag is the least significant 8 bits of the
+ * return value.
+ */
+
+ unsigned int
+ keytag (
+ unsigned char key[], /* the RDATA part of the DNSKEY RR */
+ unsigned int keysize /* the RDLENGTH */
+ )
+ {
+ unsigned long ac; /* assumed to be 32 bits or larger */
+ int i; /* loop index */
+
+ for ( ac = 0, i = 0; i < keysize; ++i )
+ ac += (i & 1) ? key[i] : key[i] << 8;
+ ac += (ac >> 16) & 0xFFFF;
+ return ac & 0xFFFF;
+ }
+
+
+B.1 Key Tag for Algorithm 1 (RSA/MD5)
+
+ The key tag for algorithm 1 (RSA/MD5) is defined differently than the
+ key tag for all other algorithms, for historical reasons. For a
+ DNSKEY RR with algorithm 1, the key tag is defined to be the most
+ significant 16 bits of the least significant 24 bits in the public
+ key modulus (in other words, the 4th to last and 3rd to last octets
+ of the public key modulus).
+
+ Please note that Algorithm 1 is NOT RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 32]
+
+Internet-Draft DNSSEC Resource Records July 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Arends, et al. Expires January 13, 2005 [Page 33]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt
new file mode 100644
index 00000000000..4cfd417804d
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-insensitive-04.txt
@@ -0,0 +1,639 @@
+
+INTERNET-DRAFT Donald E. Eastlake 3rd
+Clarifies STD0013 Motorola Laboratories
+Expires December 2004 July 2004
+
+
+
+ Domain Name System (DNS) Case Insensitivity Clarification
+ ------ ---- ------ ----- ---- ------------- -------------
+ <draft-ietf-dnsext-insensitive-04.txt>
+
+ Donald E. Eastlake 3rd
+
+
+
+Status of This Document
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the DNSEXT working group at namedroppers@ops.ietf.org.
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC 2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
+ Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+ Domain Name System (DNS) names are "case insensitive". This document
+ explains exactly what that means and provides a clear specification
+ of the rules. This clarification should not have any interoperability
+ consequences.
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 1]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Acknowledgements
+
+ The contributions to this document of Rob Austein, Olafur
+ Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
+ Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully
+ acknowledged.
+
+
+
+Table of Contents
+
+ Status of This Document....................................1
+ Abstract...................................................1
+
+ Acknowledgements...........................................2
+ Table of Contents..........................................2
+
+ 1. Introduction............................................3
+ 2. Case Insensitivity of DNS Labels........................3
+ 2.1 Escaping Unusual DNS Label Octets......................3
+ 2.2 Example Labels with Escapes............................4
+ 3. Name Lookup, Label Types, and CLASS.....................4
+ 3.1 Original DNS Label Types...............................5
+ 3.2 Extended Label Type Case Insensitivity Considerations..5
+ 3.3 CLASS Case Insensitivity Considerations................5
+ 4. Case on Input and Output................................6
+ 4.1 DNS Output Case Preservation...........................6
+ 4.2 DNS Input Case Preservation............................6
+ 5. Internationalized Domain Names..........................7
+ 6. Security Considerations.................................7
+
+ Copyright and Disclaimer...................................9
+ Normative References.......................................9
+ Informative References....................................10
+ -02 to -03 Changes........................................10
+ -03 to -04 Changes........................................11
+ Author's Address..........................................11
+ Expiration and File Name..................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 2]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+1. Introduction
+
+ The Domain Name System (DNS) is the global hierarchical replicated
+ distributed database system for Internet addressing, mail proxy, and
+ other information. Each node in the DNS tree has a name consisting of
+ zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
+ case insensitive fashion. This document clarifies the meaning of
+ "case insensitive" for the DNS.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC 2119].
+
+
+
+2. Case Insensitivity of DNS Labels
+
+ DNS was specified in the era of [ASCII]. DNS names were expected to
+ look like most host names or Internet email address right halves (the
+ part after the at-sign, "@") or be numeric as in the in-addr.arpa
+ part of the DNS name space. For example,
+
+ foo.example.net.
+ aol.com.
+ www.gnu.ai.mit.edu.
+ or 69.2.0.192.in-addr.arpa.
+
+ Case varied alternatives to the above would be DNS names like
+
+ Foo.ExamplE.net.
+ AOL.COM.
+ WWW.gnu.AI.mit.EDU.
+ or 69.2.0.192.in-ADDR.ARPA.
+
+ However, the individual octets of which DNS names consist are not
+ limited to valid ASCII character codes. They are 8-bit bytes and all
+ values are allowed. Many applications, however, interpret them as
+ ASCII characters.
+
+
+
+2.1 Escaping Unusual DNS Label Octets
+
+ In Master Files [STD 13] and other human readable and writable ASCII
+ contexts, an escape is needed for the byte value for period (0x2E,
+ ".") and all octet values outside of the inclusive range of 0x21
+ ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
+ the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
+
+ One typographic convention for octets that do not correspond to an
+
+
+D. Eastlake 3rd [Page 3]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ ASCII printing graphic is to use a back-slash followed by the value
+ of the octet as an unsigned integer represented by exactly three
+ decimal digits.
+
+ The same convention can be used for printing ASCII characters so that
+ they will be treated as a normal label character. This includes the
+ back-slash character used in this convention itself which can be
+ expressed as \092 or \\ and the special label separator period (".")
+ which can be expressed as and \046 or \. respectively. It is
+ advisable to avoid using a backslash to quote an immediately
+ following non-printing ASCII character code to avoid implementation
+ difficulties.
+
+ A back-slash followed by only one or two decimal digits is undefined.
+ A back-slash followed by four decimal digits produces two octets, the
+ first octet having the value of the first three digits considered as
+ a decimal number and the second octet being the character code for
+ the fourth decimal digit.
+
+
+
+2.2 Example Labels with Escapes
+
+ The first example below shows embedded spaces and a period (".")
+ within a label. The second one show a 5 octet label where the second
+ octet has all bits zero, the third is a backslash, and the fourth
+ octet has all bits one.
+
+ Donald\032E\.\032Eastlake\0323rd.example.
+ and a\000\\\255z.example.
+
+
+
+3. Name Lookup, Label Types, and CLASS
+
+ The design decision was made that comparisons on name lookup for DNS
+ queries should be case insensitive [STD 13]. That is to say, a lookup
+ string octet with a value in the inclusive range of 0x41 to 0x5A, the
+ upper case ASCII letters, MUST match the identical value and also
+ match the corresponding value in the inclusive range 0x61 to 0x7A,
+ the lower case ASCII letters. And a lookup string octet with a lower
+ case ASCII letter value MUST similarly match the identical value and
+ also match the corresponding value in the upper case ASCII letter
+ range.
+
+ (Historical Note: the terms "upper case" and "lower case" were
+ invented after movable type. The terms originally referred to the
+ two font trays for storing, in partitioned areas, the different
+ physical type elements. Before movable type, the nearest equivalent
+ terms were "majuscule" and "minuscule".)
+
+
+D. Eastlake 3rd [Page 4]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ One way to implement this rule would be, when comparing octets, to
+ subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
+ before the comparison. Such an operation is commonly known as "case
+ folding" but implementation via case folding is not required. Note
+ that the DNS case insensitivity does NOT correspond to the case
+ folding specified in iso-8859-1 or iso-8859-2. For example, the
+ octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
+ contexts, where they are interpreted as the upper and lower case
+ version of "Y" with an acute accent, they might.
+
+
+
+3.1 Original DNS Label Types
+
+ DNS labels in wire encoded names have a type associated with them.
+ The original DNS standard [RFC 1035] had only two types. ASCII
+ labels, with a length of from zero to 63 octets, and indirect labels
+ which consist of an offset pointer to a name location elsewhere in
+ the wire encoding on a DNS message. (The ASCII label of length zero
+ is reserved for use as the name of the root node of the name tree.)
+ ASCII labels follow the ASCII case conventions described herein and,
+ as stated above, can actually contain arbitrary byte values. Indirect
+ labels are, in effect, replaced by the name to which they point which
+ is then treated with the case insensitivity rules in this document.
+
+
+
+3.2 Extended Label Type Case Insensitivity Considerations
+
+ DNS was extended by [RFC 2671] to have additional label type numbers
+ available. (The only such type defined so far is the BINARY type [RFC
+ 2673].)
+
+ The ASCII case insensitivity conventions only apply to ASCII labels,
+ that is to say, label type 0x0, whether appearing directly or invoked
+ by indirect labels.
+
+
+
+3.3 CLASS Case Insensitivity Considerations
+
+ As described in [STD 13] and [RFC 2929], DNS has an additional axis
+ for data location called CLASS. The only CLASS in global use at this
+ time is the "IN" or Internet CLASS.
+
+ The handling of DNS label case is not CLASS dependent.
+
+
+
+
+
+
+D. Eastlake 3rd [Page 5]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+4. Case on Input and Output
+
+ While ASCII label comparisons are case insensitive, [STD 13] says
+ case MUST be preserved on output, and preserved when convenient on
+ input. However, this means less than it would appear since the
+ preservation of case on output is NOT required when output is
+ optimized by the use of indirect labels, as explained below.
+
+
+
+4.1 DNS Output Case Preservation
+
+ [STD 13] views the DNS namespace as a node tree. ASCII output is as
+ if a name was marshaled by taking the label on the node whose name is
+ to be output, converting it to a typographically encoded ASCII
+ string, walking up the tree outputting each label encountered, and
+ preceding all labels but the first with a period ("."). Wire output
+ follows the same sequence but each label is wire encoded and no
+ periods inserted. No "case conversion" or "case folding" is done
+ during such output operations, thus "preserving" case. However, to
+ optimize output, indirect labels may be used to point to names
+ elsewhere in the DNS answer. In determining whether the name to be
+ pointed to, for example the QNAME, is the "same" as the remainder of
+ the name being optimized, the case insensitive comparison specified
+ above is done. Thus such optimization MAY easily destroy the output
+ preservation of case. This type of optimization is commonly called
+ "name compression".
+
+
+
+4.2 DNS Input Case Preservation
+
+ Originally, DNS input came from an ASCII Master File as defined in
+ [STD 13] or a zone transfer. DNS Dynamic update and incremental zone
+ transfers [RFC 1995] have been added as a source of DNS data [RFC
+ 2136, 3007]. When a node in the DNS name tree is created by any of
+ such inputs, no case conversion is done. Thus the case of ASCII
+ labels is preserved if they are for nodes being created. However,
+ when a name label is input for a node that already exist in DNS data
+ being held, the situation is more complex. Implementations may retain
+ the case first input for such a label or allow new input to override
+ the old case or even maintain separate copies preserving the input
+ case.
+
+ For example, if data with owner name "foo.bar.example" is input and
+ then later data with owner name "xyz.BAR.example" is input, the name
+ of the label on the "bar.example" node, i.e. "bar", might or might
+ not be changed to "BAR" or the actual input case could be preserved.
+ Thus later retrieval of data stored under "xyz.bar.example" in this
+ case can easily return data with "xyz.BAR.example". The same
+
+
+D. Eastlake 3rd [Page 6]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ considerations apply when inputting multiple data records with owner
+ names differing only in case. For example, if an "A" record is stored
+ as the first resourced record under owner name "xyz.BAR.example" and
+ then a second "A" record is stored under "XYZ.BAR.example", the
+ second MAY be stored with the first (lower case initial label) name
+ or the second MAY override the first so that only an upper case
+ initial label is retained or both capitalizations MAY be kept.
+
+ Note that the order of insertion into a server database of the DNS
+ name tree nodes that appear in a Master File is not defined so that
+ the results of inconsistent capitalization in a Master File are
+ unpredictable output capitalization.
+
+
+
+5. Internationalized Domain Names
+
+ A scheme has been adopted for "internationalized domain names" and
+ "internationalized labels" as described in [RFC 3490, 3454, 3491, and
+ 3492]. It makes most of [UNICODE] available through a separate
+ application level transformation from internationalized domain name
+ to DNS domain name and from DNS domain name to internationalized
+ domain name. Any case insensitivity that internationalized domain
+ names and labels have varies depending on the script and is handled
+ entirely as part of the transformation described in [RFC 3454] and
+ [RFC 3491] which should be seen for further details. This is not a
+ part of the DNS as standardized in STD 13.
+
+
+
+6. Security Considerations
+
+ The equivalence of certain DNS label types with case differences, as
+ clarified in this document, can lead to security problems. For
+ example, a user could be confused by believing two domain names
+ differing only in case were actually different names.
+
+ Furthermore, a domain name may be used in contexts other than the
+ DNS. It could be used as a case sensitive index into some data base
+ system. Or it could be interpreted as binary data by some integrity
+ or authentication code system. These problems can usually be handled
+ by using a standardized or "canonical" form of the DNS ASCII type
+ labels, that is, always mapping the ASCII letter value octets in
+ ASCII labels to some specific pre-chosen case, either upper case or
+ lower case. An example of a canonical form for domain names (and also
+ a canonical ordering for them) appears in Section 8 of [RFC 2535].
+ See also [RFC 3597].
+
+ Finally, a non-DNS name may be stored into DNS with the false
+ expectation that case will always be preserved. For example, although
+
+
+D. Eastlake 3rd [Page 7]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ this would be quite rare, on a system with case sensitive email
+ address local parts, an attempt to store two "RP" records that
+ differed only in case would probably produce unexpected results that
+ might have security implications. That is because the entire email
+ address, including the possibly case sensitive local or left hand
+ part, is encoded into a DNS name in a readable fashion where the case
+ of some letters might be changed on output as described above.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 8]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Copyright and Disclaimer
+
+ Copyright (C) The Internet Society 2004. This document is subject to
+ the rights, licenses and restrictions contained in BCP 78, and except
+ as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Normative References
+
+ [ASCII] - ANSI, "USA Standard Code for Information Interchange",
+ X3.4, American National Standards Institute: New York, 1968.
+
+ [RFC 1034, 1035] - See [STD 13].
+
+ [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
+ 1996.
+
+ [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", March 1997.
+
+ [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
+
+ [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
+ March 1999.
+
+ [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
+ Update", November 2000.
+
+ [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
+ draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
+
+ [STD 13]
+ - P. Mockapetris, "Domain names - concepts and facilities", RFC
+ 1034, November 1987.
+ - P. Mockapetris, "Domain names - implementation and
+ specification", RFC 1035, November 1987.
+
+
+
+
+
+
+D. Eastlake 3rd [Page 9]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Informative References
+
+ [RFC 1591] - J. Postel, "Domain Name System Structure and
+ Delegation", March 1994.
+
+ [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
+ June 1999.
+
+ [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
+ Name System (DNS) IANA Considerations", September 2000.
+
+ [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
+ 1999.
+
+ [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
+ August 1999.
+
+ [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
+ Foo", 1 April 2001.
+
+ [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
+ Internationalized String ("stringprep")", December 2002.
+
+ [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)", March 2003.
+
+ [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
+ for Internationalized Domain Names (IDN)", March 2003.
+
+ [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
+ for Internationalized Domain Names in Applications (IDNA)", March
+ 2003.
+
+ [UNICODE] - The Unicode Consortium, "The Unicode Standard",
+ <http://www.unicode.org/unicode/standard/standard.html>.
+
+
+
+-02 to -03 Changes
+
+ The following changes were made between draft version -02 and -03:
+
+ 1. Add internationalized domain name section and references.
+
+ 2. Change to indicate that later input of a label for an existing DNS
+ name tree node may or may not be normalized to the earlier input or
+ override it or both may be preserved.
+
+ 3. Numerous minor wording changes.
+
+
+
+D. Eastlake 3rd [Page 10]
+
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+-03 to -04 Changes
+
+ The following changes were made between draft version -03 and -04:
+
+ 1. Change to conform to the new IPR, Copyright, etc., notice
+ requirements.
+
+ 2. Change in some section headers for clarity.
+
+ 3. Drop section on wildcards.
+
+ 4. Add emphasis on loss of case preservation due to name compression.
+
+ 5. Add references to RFCs 1995 and 3092.
+
+
+
+Author's Address
+
+ Donald E. Eastlake 3rd
+ Motorola Laboratories
+ 155 Beaver Street
+ Milford, MA 01757 USA
+
+ Telephone: +1 508-786-7554 (w)
+ +1 508-634-2066 (h)
+ EMail: Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+ This draft expires December 2004.
+
+ Its file name is draft-ietf-dnsext-insensitive-04.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 11]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt
new file mode 100644
index 00000000000..123d3cc0961
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-interop3597-01.txt
@@ -0,0 +1,335 @@
+
+DNS Extensions Working Group J. Schlyter
+Internet-Draft August 24, 2004
+Expires: February 22, 2005
+
+
+ RFC 3597 Interoperability Report
+ draft-ietf-dnsext-interop3597-01.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3667.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on February 22, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This memo documents the result from the RFC 3597 (Handling of Unknown
+ DNS Resource Record Types) interoperability testing.
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires February 22, 2005 [Page 1]
+
+Internet-Draft RFC 3597 Interoperability Report August 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3
+ 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3
+ 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3
+ 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ Normative References . . . . . . . . . . . . . . . . . . . . . 4
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
+ A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
+ Intellectual Property and Copyright Statements . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires February 22, 2005 [Page 2]
+
+Internet-Draft RFC 3597 Interoperability Report August 2004
+
+
+1. Introduction
+
+ This memo documents the result from the RFC 3597 (Handling of Unknown
+ DNS Resource Record Types) interoperability testing. The test was
+ performed during June and July 2004 by request of the IETF DNS
+ Extensions Working Group.
+
+2. Implementations
+
+ The following is a list, in alphabetic order, of implementations for
+ compliance of RFC 3597:
+
+ DNSJava 1.6.4
+ ISC BIND 8.4.5rc4
+ ISC BIND 9.3.0rc2
+ NSD 2.1.1
+ Net::DNS 0.47 patchlevel 1
+ Nominum ANS 2.2.1.0.d
+
+ These implementations covers the following functions (number of
+ implementations tested for each function in paranthesis):
+
+ Authoritative Name Servers (4)
+ Full Recursive Resolver (2)
+ Stub Resolver (4)
+ DNSSEC Zone Signers (2)
+
+3. Tests
+
+3.1 Authoritative Primary Name Server
+
+ The test zone data (Appendix A) was loaded into the name server
+ implementation and the server was queried for the loaded information.
+
+3.2 Authoritative Secondary Name Server
+
+ The test zone data (Appendix A) was transferred using AXFR from
+ another name server implementation and the server was queried for the
+ transferred information.
+
+3.3 Full Recursive Resolver
+
+ A recursive resolver was queried for resource records from a domain
+ with the test zone data (Appendix A).
+
+3.4 Stub Resolver
+
+ A stub resolver was used to query resource records from a domain with
+
+
+
+Schlyter Expires February 22, 2005 [Page 3]
+
+Internet-Draft RFC 3597 Interoperability Report August 2004
+
+
+ the test zone data (Appendix A).
+
+3.5 DNSSEC Signer
+
+ A DNSSEC signer was used to sign a zone with test zone data (Appendix
+ A).
+
+4. Problems found
+
+ Two implementations had problems with text presentation of zero
+ length RDATA.
+
+ One implementation had problems with text presentation of RR type
+ code and classes >= 4096.
+
+ Bug reports were filed for problems found.
+
+5. Summary
+
+ Unknown type codes works in the tested authoritative servers,
+ recursive resolvers and stub clients.
+
+ No changes are needed to advance RFC 3597 to draft standard.
+
+Normative References
+
+ [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+ Types", RFC 3597, September 2003.
+
+
+Author's Address
+
+ Jakob Schlyter
+
+ EMail: jakob@rfc.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires February 22, 2005 [Page 4]
+
+Internet-Draft RFC 3597 Interoperability Report August 2004
+
+
+Appendix A. Test zone data
+
+ ; A-record encoded as TYPE1
+ a TYPE1 \# 4 7f000001
+ a TYPE1 192.0.2.1
+ a A \# 4 7f000002
+
+ ; draft-ietf-secsh-dns-05.txt
+ sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
+
+ ; bogus test record (from RFC 3597)
+ type731 TYPE731 \# 6 abcd (
+ ef 01 23 45 )
+
+ ; zero length RDATA (from RFC 3597)
+ type62347 TYPE62347 \# 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires February 22, 2005 [Page 5]
+
+Internet-Draft RFC 3597 Interoperability Report August 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Schlyter Expires February 22, 2005 [Page 6]
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt b/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt
new file mode 100644
index 00000000000..8dcacc8bb9e
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-mdns-33.txt
@@ -0,0 +1,1559 @@
+
+
+
+
+
+
+DNSEXT Working Group Levon Esibov
+INTERNET-DRAFT Bernard Aboba
+Category: Standards Track Dave Thaler
+<draft-ietf-dnsext-mdns-33.txt> Microsoft
+18 July 2004
+
+
+ Linklocal Multicast Name Resolution (LLMNR)
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 2, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society 2004. All rights reserved.
+
+Abstract
+
+ Today, with the rise of home networking, there are an increasing
+ number of ad-hoc networks operating without a Domain Name System
+ (DNS) server. The goal of Link-Local Multicast Name Resolution
+ (LLMNR) is to enable name resolution in scenarios in which
+ conventional DNS name resolution is not possible. LLMNR supports all
+ current and future DNS formats, types and classes, while operating on
+ a separate port from DNS, and with a distinct resolver cache. Since
+ LLMNR only operates on the local link, it cannot be considered a
+ substitute for DNS.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 1]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+Table of Contents
+
+1. Introduction .......................................... 3
+ 1.1 Requirements .................................... 4
+ 1.2 Terminology ..................................... 4
+2. Name resolution using LLMNR ........................... 4
+ 2.1 LLMNR packet format ............................. 6
+ 2.2 Sender behavior ................................. 8
+ 2.3 Responder behavior .............................. 8
+ 2.4 Unicast queries ................................. 11
+ 2.5 Off-link detection .............................. 11
+ 2.6 Responder responsibilities ...................... 12
+ 2.7 Retransmission and jitter ....................... 13
+ 2.8 DNS TTL ......................................... 13
+ 2.9 Use of the authority and additional sections .... 14
+3. Usage model ........................................... 14
+ 3.1 LLMNR configuration ............................. 15
+4. Conflict resolution ................................... 16
+ 4.1 Considerations for multiple interfaces .......... 18
+ 4.2 API issues ...................................... 19
+5. Security considerations ............................... 20
+ 5.1 Scope restriction ............................... 20
+ 5.2 Usage restriction ............................... 21
+ 5.3 Cache and port separation ....................... 22
+ 5.4 Authentication .................................. 22
+6. IANA considerations ................................... 22
+7. References ............................................ 22
+ 7.1 Normative References ............................ 22
+ 7.2 Informative References .......................... 23
+Acknowledgments .............................................. 24
+Authors' Addresses ........................................... 25
+Intellectual Property Statement .............................. 25
+Disclaimer of Validity ....................................... 26
+Full Copyright Statement ..................................... 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 2]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+1. Introduction
+
+ This document discusses Link Local Multicast Name Resolution (LLMNR),
+ which utilizes the DNS packet format and supports all current and
+ future DNS formats, types and classes. LLMNR operates on a separate
+ port from the Domain Name System (DNS), with a distinct resolver
+ cache.
+
+ The goal of LLMNR is to enable name resolution in scenarios in which
+ conventional DNS name resolution is not possible. These include
+ scenarios in which hosts are not configured with the address of a DNS
+ server, where configured DNS servers do not reply to a query, or
+ where 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.
+
+ 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.4.
+
+ 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.1.
+
+ In the future, it may be desirable to consider use of multicast name
+ resolution with multicast scopes beyond the link-scope. This could
+ occur if LLMNR deployment is successful, the need arises for
+ multicast name resolution beyond the link-scope, or multicast routing
+ becomes ubiquitous. For example, expanded support for multicast name
+ resolution might be required for mobile ad-hoc networking scenarios,
+ or where no DNS server is available that is authoritative for the
+ names of local hosts, and can support dynamic DNS, such as in
+ wireless hotspots.
+
+ Once we have experience in LLMNR deployment in terms of
+ administrative issues, usability and impact on the network, it will
+ be possible to reevaluate which multicast scopes are appropriate for
+ use with multicast name resolution.
+
+ 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.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 3]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+1.1. Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. 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].
+
+1.2. Terminology
+
+ This document assumes familiarity with DNS terminology defined in
+ [RFC1035]. Other terminology used in this document includes:
+
+Positively Resolved
+ Responses with RCODE set to zero are referred to in this document
+ as "positively resolved".
+
+Routable Address
+ An address other than a Link-Local address. This includes globally
+ routable addresses, as well as private addresses.
+
+Reachable
+ An address is considered reachable over a link if either an ARP or
+ neighbor discovery cache entry exists for the address on the link.
+
+Responder
+ A host that listens to LLMNR queries, and responds to those for
+ which it is authoritative.
+
+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. LLMNR queries are sent to and received on
+ port 5355. 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 224.0.0.252. The IPv6 link-scope multicast
+ address a given responder listens to, and to which a sender sends all
+ queries, is FF02:0:0:0:0:0:1:3.
+
+ 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.
+ This document does not specify how names are chosen or configured.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 4]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ 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 interfaces, at all times. Enabling LLMNR for use in situations
+ where a DNS server has been configured will result in a change in
+ default behavior without a simultaneous update to configuration
+ information. Where this is considered undesirable, LLMNR SHOULD NOT
+ be enabled by default, so that hosts will neither listen on the link-
+ scope multicast address, nor will they send queries to that address.
+
+ 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 mechanism on that interface, although
+ it MAY be used as a name resolution mechanism of last resort.
+
+ [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.
+
+ A typical sequence of events for LLMNR usage is as follows:
+
+ [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.
+
+ [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.4.
+
+ [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.4.
+
+ [d] Upon reception of the response, the sender processes it.
+
+ Further details of sender and responder behavior are provided in the
+ sections that follow.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 5]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+2.1. LLMNR packet format
+
+ LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4
+ for both queries and responses. LLMNR implementations SHOULD send
+ UDP queries and responses only as large as are known to be
+ permissible without causing fragmentation. When in doubt a maximum
+ packet size of 512 octets SHOULD be used. LLMNR implementations MUST
+ accept UDP queries and responses as large as permitted by the link
+ MTU.
+
+2.1.1. LLMNR header format
+
+ LLMNR queries and responses utilize the DNS header format defined in
+ [RFC1035] with exceptions noted below:
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ID |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QDCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ANCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | NSCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ARCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ where:
+
+ID A 16 bit identifier assigned by the program that generates any kind
+ of query. This identifier is copied from the query to the response
+ and can be used by the sender to match responses to outstanding
+ queries. The ID field in a query SHOULD be set to a pseudo-random
+ value.
+
+QR A one bit field that specifies whether this message is an LLMNR
+ query (0), or an LLMNR response (1).
+
+OPCODE
+ A four bit field that specifies the kind of query in this message.
+ This value is set by the originator of a query and copied into the
+ response. This specification defines the behavior of standard
+ queries and responses (opcode value of zero). Future
+ specifications may define the use of other opcodes with LLMNR.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 6]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ LLMNR senders and responders MUST support standard queries (opcode
+ value of zero). LLMNR queries with unsupported OPCODE values MUST
+ be silently discarded by responders.
+
+TC TrunCation - specifies that this message was truncated due to
+ length greater than that permitted on the transmission channel.
+ The TC bit MUST NOT be set in an LLMNR query and if set is ignored
+ by an LLMNR responder. If the TC bit is set an LLMNR response,
+ then the sender MAY use the response if it contains all necessary
+ information, or the sender MAY discard the response and resend the
+ LLMNR query over TCP using the unicast address of the responder as
+ the destination address. See [RFC2181] and Section 2.4 of this
+ specification for further discussion of the TC bit.
+
+Z Reserved for future use. Implementations of this specification
+ MUST set these bits to zero in both queries and responses. If
+ these bits are set in a LLMNR query or response, implementations of
+ this specification MUST ignore them. Since reserved bits could
+ conceivably be used for different purposes than in DNS,
+ implementors are advised not to enable processing of these bits in
+ an LLMNR implementation starting from a DNS code base.
+
+RCODE
+ Response code -- this 4 bit field is set as part of LLMNR
+ responses. In an LLMNR query, the RCODE MUST be zero, and is
+ ignored by the responder. The response to a multicast LLMNR query
+ MUST have RCODE set to zero. A sender MUST silently discard an
+ LLMNR response with a non-zero RCODE sent in response to a
+ multicast query.
+
+ If an LLMNR responder is authoritative for the name in a multicast
+ query, but an error is encountered, the responder SHOULD send an
+ LLMNR response with an RCODE of zero, no RRs in the answer section,
+ and the TC bit set. This will cause the query to be resent using
+ TCP, and allow the inclusion of a non-zero RCODE in the response to
+ the TCP query. Responding with the TC bit set is preferrable to
+ not sending a response, since it enables errors to be diagnosed.
+
+ Since LLMNR responders only respond to LLMNR queries for names for
+ which they are authoritative, LLMNR responders MUST NOT respond
+ with an RCODE of 3; instead, they should not respond at all.
+
+ LLMNR implementations MUST support EDNS0 [RFC2671] and extended
+ RCODE values.
+
+QDCOUNT
+ An unsigned 16 bit integer specifying the number of entries in the
+ question section. A sender MUST place only one question into the
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 7]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ question section of an LLMNR query. LLMNR responders MUST silently
+ discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
+ MUST silently discard LLMNR responses with QDCOUNT not equal to
+ one.
+
+ANCOUNT
+ An unsigned 16 bit integer specifying the number of resource
+ records in the answer section. LLMNR responders MUST silently
+ discard LLMNR queries with ANCOUNT not equal to zero.
+
+NSCOUNT
+ An unsigned 16 bit integer specifying the number of name server
+ resource records in the authority records section. Authority
+ record section processing is described in Section 2.9.
+
+ARCOUNT
+ An unsigned 16 bit integer specifying the number of resource
+ records in the additional records section. Additional record
+ section processing is described in Section 2.9.
+
+2.2. Sender behavior
+
+ A sender may send an LLMNR query for any legal resource record type
+ (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.
+
+ As described in Section 2.4, a sender may also send a unicast query.
+ Sections 2 and 3 describe the circumstances in which LLMNR queries
+ may 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.
+
+2.3. Responder behavior
+
+ An LLMNR 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. An SOA RR is synthesized only when a
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 8]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ 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.
+
+ For example, a host configured to have computer name "host1" and to
+ be a member of the "example.com" domain, and with IPv4 address
+ 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
+ authoritative for the following records:
+
+ host1. IN A 10.1.1.1
+ IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+ host1.example.com. IN A 10.1.1.1
+ IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
+
+ 1.1.1.10.in-addr.arpa. IN PTR host1.
+ IN PTR host1.example.com.
+
+ 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
+ IN PTR host1.
+ IN PTR host1.example.com
+
+ An LLMNR responder might be further manually configured with the name
+ of a local mail server with an MX RR included in the "host1." and
+ "host1.example.com." records.
+
+ In responding to queries:
+
+[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
+ address(es) defined in Section 2, and on UDP and TCP port 5355 on
+ the unicast address(es) that could be set as the source address(es)
+ when the responder responds to the LLMNR query.
+
+[b] Responders MUST direct responses to the port from which the query
+ was sent. When queries are received via TCP this is an inherent
+ part of the transport protocol. For queries received by UDP the
+ responder MUST take note of the source port and use that as the
+ destination port in the response. Responses SHOULD always be sent
+ from the port to which they were directed.
+
+[c] Responders MUST respond to LLMNR queries for names and addresses
+ they are authoritative for. This applies to both forward and
+ reverse lookups.
+
+[d] Responders MUST NOT respond to LLMNR queries for names they are not
+ authoritative for.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 9]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+[e] Responders MUST NOT respond using cached data.
+
+[f] 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.
+
+[g] 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.
+
+ 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 apex except
+ for the branches delegated into separate zones. Contrary to
+ conventional DNS terminology, an LLMNR responder is authoritative
+ only for the zone apex.
+
+ For example the host "foo.example.com." is not authoritative for the
+ name "child.foo.example.com." unless the host is configured with
+ multiple names, including "foo.example.com." and
+ "child.foo.example.com.". As a result, "foo.example.com." cannot
+ reply to an LLMNR query for "child.foo.example.com." with RCODE=3
+ (authoritative name error). The purpose of limiting the name
+ authority scope of a responder is to prevent complications that could
+ be caused by coexistence of two or more hosts with the names
+ representing child and parent (or grandparent) nodes in the DNS tree,
+ for example, "foo.example.com." and "child.foo.example.com.".
+
+ In this example (unless this limitation is introduced) an LLMNR query
+ for an A resource record for the name "child.foo.example.com." would
+ result in two authoritative responses: RCODE=3 (authoritative name
+ error) received from "foo.example.com.", and a requested A record -
+ from "child.foo.example.com.". To prevent this ambiguity, LLMNR
+ enabled hosts could perform a dynamic update of the parent (or
+ grandparent) zone with a delegation to a child zone. In this example
+ a host "child.foo.example.com." would send a dynamic update for the
+ NS and glue A record to "foo.example.com.", but this approach
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 10]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ significantly complicates implementation of LLMNR and would not be
+ acceptable for lightweight hosts.
+
+2.4. Unicast queries and responses
+
+ 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
+
+ [b] The sender queries for a PTR RR of a fully formed IP address
+ within the "in-addr.arpa" or "ip6.arpa" zones.
+
+ Unicast LLMNR queries MUST be done using TCP and the responses MUST
+ be sent using the same TCP connection as the query. Senders MUST
+ support sending TCP queries, and responders MUST support listening
+ for TCP queries. 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 MUST be silently discarded.
+
+ If TCP connection setup cannot be completed in order to send a
+ unicast TCP query, this is treated 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.5. "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 link. For IPv6 [RFC2460] an "on link" address is either a
+ link-local address, defined in [RFC2373], or an address whose prefix
+ belongs to a subnet on the local link.
+
+ 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
+ discarded.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 11]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ Section 2.4 discusses use of TCP for LLMNR queries and responses. In
+ composing an LLMNR query using TCP, the sender MUST set the Hop Limit
+ field in the IPv6 header and the TTL field in the IPv4 header of the
+ response to one (1). 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.
+
+ For UDP queries and responses the Hop Limit field in the IPv6 header,
+ and the TTL field in the IPV4 header MAY be set to any value.
+ However, it is RECOMMENDED that the value 255 be used for
+ compatibility with Apple Rendezvous.
+
+ Implementation note:
+
+ In the sockets API for IPv4 [POSIX], the IP_TTL and
+ IP_MULTICAST_TTL socket options are used to set the TTL of
+ outgoing unicast and multicast packets. The IP_RECVTTL socket
+ option is available on some platforms to retrieve the IPv4 TTL of
+ received packets with recvmsg(). [RFC2292] specifies similar
+ options for setting and retrieving the IPv6 Hop Limit.
+
+2.6. 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.
+
+ Routable addresses MUST be included first in the response, if
+ available. This encourages use of routable address(es) for
+ establishment of new connections.
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 12]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+2.7. Retransmission and jitter
+
+ An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
+ when to retransmit an LLMNR query and how long to collect responses
+ to an LLMNR query.
+
+ If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
+ then a sender MAY repeat the transmission of the query in order to
+ assure that it was received by a host capable of 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.
+
+ Because an LLMNR sender cannot know in advance if a query sent using
+ multicast will receive no response, one response, or more than one
+ response, the sender SHOULD wait for LLMNR_TIMEOUT in order to
+ collect all possible responses, rather than considering the multicast
+ query answered after the first response is received. A unicast query
+ sender considers the query answered after the first response is
+ received, so that it only waits for LLMNR_TIMEOUT if no response has
+ been received.
+
+ An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT
+ for each transmission. It is suggested that the computation of
+ LLMNR_TIMEOUT be based on the response times for earlier LLMNR
+ queries sent on the same interface.
+
+ For example, the algorithms described in RFC 2988 [RFC2988]
+ (including exponential backoff) compute an RTO, which is used as the
+ value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial
+ RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum
+ RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the
+ maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5).
+
+ Recommended values are an initial RTO of 1 second, a minimum RTO of
+ 200ms, and a maximum RTO of 5 seconds. In order to avoid
+ synchronization, the transmission of each LLMNR query and response
+ SHOULD delayed by a time randomly selected from the interval 0 to 100
+ ms. This delay MAY be avoided by responders responding with RRs
+ which they have previously determined to be UNIQUE (see Section 4 for
+ details).
+
+2.8. DNS TTL
+
+ The responder should use a pre-configured TTL value in the records
+ returned an LLMNR 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.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 13]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ Due to the TTL minimalization necessary when caching an RRset, all
+ TTLs in an RRset MUST be set to the same value.
+
+2.9. 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,
+ except as required for EDNS0 and DNSSEC.
+
+ 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.
+
+3. Usage model
+
+ Since LLMNR is a secondary name resolution mechanism, its usage is in
+ part determined by the behavior of DNS implementations. This
+ document does not specify any changes to DNS resolver behavior, such
+ as searchlist processing or retransmission/failover policy. However,
+ robust DNS resolver implementations are more likely to avoid
+ unnecessary LLMNR queries.
+
+ As noted in [DNSPerf], even when DNS servers are configured, a
+ significant fraction of DNS queries do not receive a response, or
+ result in negative responses due to missing inverse mappings or NS
+ records that point to nonexistent or inappropriate hosts. This has
+ the potential to result in a large number of unnecessary LLMNR
+ queries.
+
+ [RFC1536] describes common DNS implementation errors and fixes. If
+ the proposed fixes are implemented, unnecessary LLMNR queries will be
+ reduced substantially, and so implementation of [RFC1536] is
+ recommended.
+
+ For example, [RFC1536] Section 1 describes issues with retransmission
+ and recommends implementation of a retransmission policy based on
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 14]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ round trip estimates, with exponential backoff. [RFC1536] Section 4
+ describes 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. 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
+ DNS server over IPv4, while remaining unconfigured with a DNS server
+ suitable for use over IPv6.
+
+ In these situations, a dual stack host will send AAAA queries to the
+ configured DNS server over IPv4. However, an IPv6-only host
+ unconfigured with a DNS server suitable for use over IPv6 will be
+ unable to resolve names using DNS. Automatic IPv6 DNS configuration
+ mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
+ deployed, and not all DNS servers support IPv6. Therefore lack of
+ IPv6 DNS configuration may be a common problem in the short term, and
+ LLMNR may prove useful in enabling linklocal name resolution over
+ IPv6.
+
+ Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
+ IPv6-only hosts may not be configured with a DNS server. Where there
+ is no DNS server authoritative for the name of a host or the
+ authoritative DNS server does not support dynamic client update over
+ IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
+ be able to do DNS dynamic update, and other hosts will not be able to
+ resolve its name.
+
+ For example, if the configured DNS server responds to AAAA RR queries
+ sent over IPv4 or IPv6 with an authoritative name error (RCODE=3),
+ then it will not be possible to resolve the names of IPv6-only hosts.
+ In this situation, LLMNR over IPv6 can be used for local name
+ resolution.
+
+ Similarly, if a DHCPv4 server is available providing DNS server
+ configuration, and DNS server(s) exist which are authoritative for
+ the A RRs of local hosts and support either dynamic client update
+ over IPv4 or DHCPv4-based dynamic update, then the names of local
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 15]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ 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 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 using the Name Service Search Option (NSSO) for DHCP
+ [RFC2937], using the LLMNR Enable Option code carried in the NSSO
+ data.
+
+ It is possible that DNS configuration mechanisms will go in and out
+ of service. In these circumstances, it is possible for hosts within
+ an administrative domain to be inconsistent in their DNS
+ configuration.
+
+ For example, where DHCP is used for configuring DNS servers, one or
+ more DHCP servers can fail. As a result, hosts configured prior to
+ the outage will be configured with a DNS server, while hosts
+ configured after the outage will not. Alternatively, it is possible
+ for the DNS configuration mechanism to continue functioning while
+ configured DNS servers fail.
+
+ Unless unconfigured hosts periodically retry configuration, an outage
+ in the DNS configuration mechanism will result in hosts continuing to
+ use 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. 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
+
+ The sender MUST anticipate receiving multiple replies to the same
+ LLMNR query, in the event that several LLMNR enabled computers
+ receive the query and respond with valid answers. When this occurs,
+ the responses may first be concatenated, and then treated in the same
+ manner that multiple RRs received from the same DNS server would; the
+ sender perceives no inherent conflict in the receipt of multiple
+ responses.
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 16]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ There are some scenarios when multiple responders MAY respond to the
+ same query. There are other scenarios when only one responder MAY
+ respond to a query. Resource records for which the latter queries
+ are submitted are referred as UNIQUE throughout this document. The
+ uniqueness of a resource record depends on a nature of the name in
+ the 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
+ 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.
+
+ Where a host is configured to issue LLMNR queries on more than one
+ interface, each interface should have its own independent LLMNR
+ cache. For each UNIQUE resource record in a given interface's
+ configuration, the host MUST verify resource record uniqueness on
+ that interface. To accomplish this, the host MUST send an LLMNR
+ query for each UNIQUE resource record.
+
+ By default, a host SHOULD be configured to behave as though all RRs
+ are UNIQUE. Uniqueness verification is carried out when the host:
+
+ - starts up or is rebooted
+ - wakes from sleep (if the network interface was inactive during sleep)
+ - is configured to respond to the LLMNR queries on an interface
+ enabled for transmission and reception of IP traffic
+ - is configured to respond to the LLMNR queries using additional
+ UNIQUE resource records
+ - detects that an interface is connected and is usable
+ (e.g. an IEEE 802 hardware link-state change indicating
+ that a cable was attached or completion of authentication
+ (and if needed, association) with a wireless base station
+ or adhoc network
+
+ 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,
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 17]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ 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 different interface, the client can use the UNIQUE resource record
+ in response to LLMNR queries. If not, then it MUST NOT use the
+ UNIQUE resource record in response to LLMNR queries.
+
+ The name conflict detection mechanism doesn't prevent name conflicts
+ when previously partitioned segments are connected by a bridge. In
+ order to minimize the chance of conflicts in such a situation, it is
+ recommended that steps be taken to ensure name uniqueness. For
+ example, the name could be chosen randomly from a large pool of
+ potential names, or the name could be assigned via a process designed
+ to guarantee 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.
+ 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.
+
+4.1. Considerations for Multiple Interfaces
+
+ A multi-homed host may elect to configure LLMNR on only one of its
+ active interfaces. In many situations this will be adequate.
+ However, should a host need to configure LLMNR on more than one of
+ its active interfaces, there are some additional precautions it MUST
+ take. Implementers who are not planning to support LLMNR on multiple
+ interfaces simultaneously may skip this section.
+
+ A multi-homed host checks the uniqueness of UNIQUE records as
+ described in Section 4. The situation is illustrated in figure 1.
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [myhost]
+
+ Figure 1. Link-scope name conflict
+
+ In this situation, the multi-homed myhost will probe for, and defend,
+ its host name on both interfaces. A conflict will be detected on one
+ interface, but not the other. The multi-homed myhost will not be
+ able to respond with a host RR for "myhost" on the interface on the
+ right (see Figure 1). The multi-homed host may, however, be
+ configured to use the "myhost" name on the interface on the left.
+
+ Since names are only unique per-link, hosts on different links could
+ be using the same name. If an LLMNR client sends requests over
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 18]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ multiple interfaces, and receives replies from more than one, the
+ result returned to the client is defined by the implementation. The
+ situation is illustrated in figure 2.
+
+ ---------- ----------
+ | | | |
+ [A] [myhost] [A]
+
+
+ Figure 2. Off-segment name conflict
+
+ If host myhost is configured to use LLMNR on both interfaces, it will
+ send LLMNR queries on both interfaces. When host myhost sends a
+ query for the host RR for name "A" it will receive a response from
+ hosts on both interfaces.
+
+ Host myhost cannot distinguish between the situation shown in Figure
+ 2, and that shown in Figure 3 where no conflict exists.
+
+ [A]
+ | |
+ ----- -----
+ | |
+ [myhost]
+
+ Figure 3. Multiple paths to same host
+
+ This illustrates that the proposed name conflict resolution mechanism
+ does not support detection or resolution of conflicts between hosts
+ on different links. This problem can also occur with unicast DNS
+ when a multi-homed host is connected to two different networks with
+ separated name spaces. It is not the intent of this document to
+ address the issue of uniqueness of names within DNS.
+
+4.2. API issues
+
+ [RFC2553] provides an API which can partially solve the name
+ ambiguity problem for applications written to use this API, since the
+ sockaddr_in6 structure exposes the scope within which each scoped
+ address exists, and this structure can be used for both IPv4 (using
+ v4-mapped IPv6 addresses) and IPv6 addresses.
+
+ Following the example in Figure 2, an application on 'myhost' issues
+ the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
+ ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
+ interfaces and the resolver library will return a list containing
+ multiple addrinfo structures, each with an associated sockaddr_in6
+ structure. This list will thus contain the IPv4 and IPv6 addresses
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 19]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ of both hosts responding to the name 'A'. Link-local addresses will
+ have a sin6_scope_id value that disambiguates which interface is used
+ to reach the address. Of course, to the application, Figures 2 and 3
+ are still indistinguishable, but this API allows the application to
+ communicate successfully with any address in the list.
+
+5. Security Considerations
+
+ LLMNR is by nature a peer-to-peer name resolution protocol. It is
+ therefore inherently more vulnerable than DNS, since existing DNS
+ security mechanisms are difficult to apply to LLMNR. While tools
+ exist to alllow an attacker to spoof a response to a DNS query,
+ spoofing a response to an LLMNR query is easier since the query is
+ sent to a link-scope multicast address, where every host on the
+ logical link will be made aware of it.
+
+ In order to address the security vulnerabilities, the following
+ mechanisms are contemplated:
+
+ [1] Scope restrictions.
+ [2] Usage restrictions.
+ [3] Cache and port separation.
+ [4] Authentication.
+
+ These techniques are described in the following sections.
+
+5.1. Scope restriction
+
+ With LLMNR it is possible that hosts will allocate conflicting names
+ for a period of time, or that attackers will attempt to deny service
+ to other hosts by allocating the same name. Such attacks also allow
+ hosts to receive packets destined for other hosts.
+
+ Since LLMNR is typically deployed in situations where no trust model
+ can be assumed, it is likely that LLMNR queries and responses will be
+ unauthenticated. In the absence of authentication, LLMNR reduces the
+ exposure to such threats by utilizing UDP queries sent to a link-
+ scope multicast address, as well as setting the TTL (IPv4) or Hop
+ Limit (IPv6) fields to one (1) on TCP queries and responses.
+
+ Using a TTL of one (1) to set up a TCP connection in order to send a
+ unicast LLMNR query reduces the likelihood of both denial of service
+ attacks and spoofed responses. Checking that an LLMNR query is sent
+ to a link-scope multicast address should prevent spoofing of
+ multicast queries by off-link attackers.
+
+ While this limits the ability of off-link attackers to spoof LLMNR
+ queries and responses, it does not eliminate it. For example, it is
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 20]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ possible for an attacker to spoof a response to a frequent query
+ (such as an A or AAAA query for a popular Internet host), and by
+ using a TTL or Hop Limit field larger than one (1), for the forged
+ response to reach the LLMNR sender.
+
+ When LLMNR queries are sent to a link-scope multicast address, it is
+ possible that some routers may not properly implement link-scope
+ multicast, or that link-scope multicast addresses may leak into the
+ multicast routing system.
+
+ Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than
+ one in an LLMNR UDP response may enable denial of service attacks
+ across the Internet. However, since LLMNR responders only respond to
+ queries for which they are authoritative, and LLMNR does not provide
+ wildcard query support, it is believed that this threat is minimal.
+
+ There also are scenarios such as public "hotspots" where attackers
+ can be present on the same link. These threats are most serious in
+ wireless networks such as 802.11, since attackers on a wired network
+ will require physical access to the home network, while wireless
+ attackers may reside outside the home. Link-layer security can be of
+ assistance against these threats if it is available.
+
+5.2. Usage restriction
+
+ As noted in Sections 2 and 3, LLMNR is intended for usage in a
+ limited set of scenarios.
+
+ If an LLMNR query is sent whenever a DNS server does not respond in a
+ timely way, then an attacker can poison the LLMNR cache by responding
+ to the query with incorrect information. To some extent, these
+ vulnerabilities exist today, since DNS response spoofing tools are
+ available that can allow an attacker to respond to a query more
+ quickly than a distant DNS server.
+
+ Since LLMNR queries are sent and responded to on the local-link, an
+ attacker will need to respond more quickly to provide its own
+ response prior to arrival of the response from a legitimate
+ responder. If an LLMNR query is sent for an off-link host, spoofing a
+ response in a timely way is not difficult, since a legitimate
+ response will never be received.
+
+ The vulnerability is more serious if LLMNR is given higher priority
+ than DNS among the enabled name resolution mechanisms. In such a
+ configuration, a denial of service attack on the DNS server would not
+ be necessary in order to poison the LLMNR cache, since LLMNR queries
+ would be sent even when the DNS server is available. In addition, the
+ LLMNR cache, once poisoned, would take precedence over the DNS cache,
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 21]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+ eliminating the benefits of cache separation. As a result, LLMNR is
+ only used as a name resolution mechanism of last resort.
+
+5.3. Cache and port separation
+
+ In order to prevent responses to LLMNR queries from polluting the DNS
+ cache, LLMNR implementations MUST use a distinct, isolated cache for
+ LLMNR on each interface. The use of separate caches is most effective
+ when LLMNR is used as a name resolution mechanism of last resort,
+ since this minimizes the opportunities for poisoning the LLMNR cache,
+ and decreases reliance on it.
+
+ LLMNR operates on a separate port from DNS, reducing the likelihood
+ that a DNS server will unintentionally respond to an LLMNR query.
+
+5.4. Authentication
+
+ LLMNR implementations may not support DNSSEC or TSIG, and as a
+ result, responses to LLMNR queries may be unauthenticated. If
+ authentication is desired, and a pre-arranged security configuration
+ is possible, then IPsec ESP with a null-transform MAY be used to
+ authenticate LLMNR responses. In a small network without a
+ certificate authority, this can be most easily accomplished through
+ configuration of a group pre-shared key for trusted hosts.
+
+6. IANA Considerations
+
+ This specification creates one new name space: the reserved bits in
+ the LLMNR header. These are allocated by IETF Consensus, in
+ accordance with BCP 26 [RFC2434].
+
+ LLMNR requires allocation of port 5355 for both TCP and UDP.
+
+ LLMNR requires allocation of link-scope multicast IPv4 address
+ 224.0.0.252, as well as link-scope multicast IPv6 address
+ FF02:0:0:0:0:0:1:3.
+
+7. References
+
+7.1. Normative References
+
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", RFC 1035, November 1987.
+
+[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 22]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+ RFC 2308, March 1998.
+
+[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
+ 2365, July 1998.
+
+[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.
+
+[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+ August 1999.
+
+[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
+ Timer", RFC 2988, November 2000.
+
+7.2. Informative References
+
+[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
+ Fixes", RFC 1536, October 1993.
+
+[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
+ RFC 2292, February 1998.
+
+[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
+ Socket Interface Extensions for IPv6", RFC 2553, March 1999.
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 23]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
+ 2937, September 2000.
+
+[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
+ IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
+ Caching", IEEE/ACM Transactions on Networking, Volume 10,
+ Number 5, pp. 589, October 2002.
+
+[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
+ unicast addresses to communicate with recursive DNS servers",
+ Internet draft (work in progress), draft-ietf-ipv6-dns-
+ discovery-07.txt, October 2002.
+
+[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-15.txt, May
+ 2004.
+
+[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
+ Portable Operating System Interface (POSIX). Open Group
+ Technical Standard: Base Specifications, Issue 6, December
+ 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
+
+[LLMNREnable]
+ Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
+ in progress), draft-guttman-mdns-enable-02.txt, April 2002.
+
+[NodeInfo]
+ Crawford, M., "IPv6 Node Information Queries", Internet draft
+ (work in progress), draft-ietf-ipn-gwg-icmp-name-
+ lookups-09.txt, May 2002.
+
+Acknowledgments
+
+ This work builds upon original work done on multicast DNS by Bill
+ Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
+ grant #F30602-99-1-0523. The authors gratefully acknowledge their
+ contribution to the current specification. Constructive input has
+ also been received from Mark Andrews, Stuart Cheshire, Randy Bush,
+ Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik
+ Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik
+ Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill,
+ Keith Moore and Markku Savela.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 24]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+Authors' Addresses
+
+ Levon Esibov
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ EMail: levone@microsoft.com
+
+ Bernard Aboba
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: +1 425 706 6605
+ EMail: bernarda@microsoft.com
+
+ Dave Thaler
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+
+ Phone: +1 425 703 8835
+ EMail: dthaler@microsoft.com
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 25]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 18 July 2004
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+Open Issues
+
+ Open issues with this specification are tracked on the following web
+ site:
+
+ http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Esibov, Aboba & Thaler Standards Track [Page 26]
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
new file mode 100644
index 00000000000..1133b0c87d4
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt
@@ -0,0 +1,466 @@
+
+
+INTERNET-DRAFT Donald E. Eastlake 3rd
+UPDATES RFC 2845 Motorola Laboratories
+Expires: February 2005 August 2004
+
+
+ HMAC SHA TSIG Algorithm Identifiers
+ ---- --- ---- --------- -----------
+ <draft-ietf-dnsext-tsig-sha-00.txt>
+
+
+Status of This Document
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ or will be disclosed, and any of which I become aware will be
+ disclosed, in accordance with RFC 3668.
+
+ This draft is intended to be become a Proposed Standard RFC.
+ Distribution of this document is unlimited. Comments should be sent
+ to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than a "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+Abstract
+
+ Use of the TSIG DNS resource record requires specification of a
+ cryptographic message authentication code. Currently identifiers
+ have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
+ This document standardizes identifiers for additional HMAC SHA TSIG
+ algorithms and standardizes how to specify the truncation of HMAC
+ values.
+
+
+Copyright Notice
+
+ Copyright (C) The Internet Society 2004. All Rights Reserved.
+
+
+
+
+D. Eastlake 3rd [Page 1]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+Table of Contents
+
+ Status of This Document....................................1
+ Abstract...................................................1
+ Copyright Notice...........................................1
+
+ Table of Contents..........................................2
+
+ 1. Introduction............................................3
+
+ 2. Algorithms and Identifiers..............................4
+
+ 3. Specifying Truncation...................................5
+
+ 4. IANA Considerations.....................................6
+ 5. Security Considerations.................................6
+ 6. Copyright and Disclaimer................................6
+
+ 7. Normative References....................................7
+ 8. Informative References..................................7
+
+ Authors Address............................................8
+ Expiration and File Name...................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 2]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+1. Introduction
+
+ [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
+ authenticate DNS queries and responses. This RR contains a domain
+ name syntax data item which names the authentication algorithm used.
+ [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
+ authentication codes using the HMAC [RFC 2104] algorithm with the MD5
+ [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
+ identifier for TSIG authentication where the cryptographic operations
+ are delegated to GSS [RFC 3645].
+
+ In section 2, this document specifies additional names for TSIG
+ authentication algorithms based on US NIST SHA algorithms and HMAC.
+
+ In section 3, this document specifies the meaning of inequality
+ between the normal output size of the specified hash function and the
+ length of MAC (message authentication code) data given in the TSIG
+ RR. In particular, it specifies that a shorter length field value
+ specifies truncation and a longer length field is an error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 3]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+2. Algorithms and Identifiers
+
+ TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
+ queries and responses. They are intended to be efficient symmetric
+ authentication codes based on a shared secret. (Asymmetric signatures
+ can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
+ can be used for transaction signatures.) Used with a strong hash
+ function, HMAC [RFC 2104] provides a way to calculate such symmetric
+ authentication codes. The only specified HMAC based TSIG algorithm
+ identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
+
+ The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as
+ compared with the 128 bits for MD5, and additional hash algorithms in
+ the SHA family [FIPS 180-2, RFC sha224] with 224, 256, 384, and 512
+ bits, may be preferred in some case. Use of TSIG between a DNS
+ resolver and server is by mutual agreement. That agreement can
+ include the support of additional algorithms.
+
+ For completeness in relation to HMAC based algorithms, the current
+ HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below.
+ Implementations which support TSIG MUST implement HMAC MD5, SHOULD
+ implement HMAC SHA-1, and MAY implement gss-tsig and the other
+ algorithms listed below.
+
+ Mandatory HMAC-MD5.SIG-ALG.REG.INT
+ Recommended hmac-sha1
+ Optional hmac-sha224
+ Optional hmac-sha256
+ Optional hamc-sha384
+ Optional hmac-sha512
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 4]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+3. Specifying Truncation
+
+ In some cases, it is reasonable to truncate the output of HMAC and
+ use the truncated value for authentication. HMAC SHA-1 truncated to
+ 96 bits is an optional available in several IETF protocols including
+ IPSEC and TLS.
+
+ The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
+ size of the MAC field in octets. But [RFC 2845] does not specify what
+ to do if this MAC size differs from the length of the output of HMAC
+ for a particular hash function.
+
+ The specification for TSIG handling is changed as follows:
+
+ 1. If The "MAC size" field is larger than the HMAC output length or
+ is zero: This case MUST NOT be generated and if received MUST
+ cause the packet to be dropped and RCODE 1 (FORMERR) to be
+ returned.
+
+ 2. If the "MAC size" field equals the HMAC output length: Operation
+ is as described in [RFC 2845].
+
+ 3. If the "MAC size" field is less than the HMAC output length but is
+ not zero: This is sent when the signer has truncated the HMAC
+ output as described in RFC 2104, taking initial octets and
+ discarding trailing octets. TSIG truncation can only be to an
+ integral number of octets. On receipt of a packet with truncation
+ thus indicated, the locally calculated MAC is similarly truncated
+ and only the truncated values compared for authentication.
+
+ TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12
+ octets) and MAY implement any or all other truncations valid under
+ case 3 above.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 5]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+4. IANA Considerations
+
+ This document, on approval for publication as a standards track RFC,
+ registers the new TSIG algorithm identifiers listed in Section 2 with
+ IANA.
+
+
+
+5. Security Considerations
+
+ For all of the message authentication code algorithms listed herein,
+ those producing longer values are believed to be stronger; however,
+ while there are some arguments that mild truncation can strengthen a
+ MAC by reducing the information available to an attacker, excessive
+ truncation clearly weakens authentication by reducing the number of
+ bits an attacker has to try to force. See [RFC 2104] which recommends
+ that ah HMAC never be truncated to less than half its length nor to
+ less than 80 bits (10 octets).
+
+ See also the Security Considerations section of [RFC 2845].
+
+
+
+6. Copyright and Disclaimer
+
+ Copyright (C) The Internet Society 2004. This document is subject to
+ the rights, licenses and restrictions contained in BCP 78 and except
+ as set forth therein, the authors retain all their rights.
+
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 6]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+7. Normative References
+
+ [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal
+ Information Processing Standard, Draft, 1 August 2002.
+
+ [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
+ 1321, April 1992.
+
+ [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, February 1997.
+
+ [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+ [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+ RFC 2845, May 2000.
+
+ [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R.
+ Housley, December 2003, work in progress, draft-ietf-pkix-
+ sha224-*.txt.
+
+
+
+8. Informative References.
+
+ [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information
+ Processing Standard, 17 April 1995.
+
+ [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
+ Signatures ( SIG(0)s )", RFC 2931, September 2000.
+
+ [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+ 1 (SHA1)", RFC 3174, September 2001.
+
+ [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
+ J., and R. Hall, "Generic Security Service Algorithm for Secret Key
+ Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
+ 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 7]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+Authors Address
+
+ Donald E. Eastlake 3rd
+ Motorola Laboratories
+ 155 Beaver Street
+ Milford, MA 01757 USA
+
+ Telephone: +1-508-786-7554 (w)
+ +1-508-634-2066 (h)
+ EMail: Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+ This draft expires in February 2005.
+
+ Its file name is draft-ietf-dnsext-tsig-sha-00.txt
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 8]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
new file mode 100644
index 00000000000..04815175fdb
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt
@@ -0,0 +1,1344 @@
+
+DNSOP O. Kolkman
+Internet-Draft RIPE NCC
+Expires: August 30, 2004 R. Gieben
+ NLnet Labs
+ March 2004
+
+
+ DNSSEC Operational Practices
+ draft-ietf-dnsop-dnssec-operational-practices-01.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 30, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document describes a set of practices for operating a DNSSEC
+ aware environment. The target audience is zone administrators
+ deploying DNSSEC that need a guide to help them chose appropriate
+ values for DNSSEC parameters. It also discusses operational matters
+ such as key rollovers, KSK and ZSK considerations and related
+ matters.
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 1]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3
+ 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3
+ 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5
+ 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7
+ 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8
+ 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8
+ 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8
+ 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10
+ 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13
+ 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14
+ 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16
+ 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1 Initial Key Exchanges and Parental Policies
+ Considerations . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16
+ 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17
+ 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
+ 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
+ A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20
+ C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20
+ D. Document Details and Changes . . . . . . . . . . . . . . . . . 22
+ D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22
+ D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22
+ Intellectual Property and Copyright Statements . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 2]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+1. Introduction
+
+ During workshops and early operational deployment tests, operators
+ and system administrators gained experience about operating DNSSEC
+ aware DNS services. This document translates these experiences into
+ a set of practices for zone administrators. At the time of writing,
+ there exists very little experience with DNSSEC in production
+ environments, this document should therefore explicitly not be seen
+ as represented 'Best Current Practices'.
+
+ The procedures herein are focused on the maintenance of signed zones
+ (i.e. signing and publishing zones on authoritative servers). It is
+ intended that maintenance of zones such as resigning or key rollovers
+ be transparent to any verifying clients on the Internet.
+
+ The structure of this document is as follows: It begins with
+ discussing some of the considerations with respect to timing
+ parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
+ management such as key rollover schemes are described in Section 3.
+ Emergency rollover considerations are addressed in Section 4. The
+ typographic conventions used in this document are explained in
+ Appendix C.
+
+ Since this is a document with operational suggestions and there are
+ no protocol specifications, the RFC2119 [5] language does not apply.
+
+1.1 The Use of the Term 'key'
+
+ It is assumed that the reader is familiar with the concept of
+ asymmetric keys on which DNSSEC is based (Public Key Cryptography
+ [Ref to Schneider?]). Therefore, this document will use the term
+ 'key' rather loosely. Where it is written that 'a key is used to sign
+ data' it is assumed that the reader understands that it is the
+ private part of the key-pair that is used for signing. It is also
+ assumed that the reader understands that the public part of the
+ key-pair is published in the DNSKEY resource record and that it is
+ used in key-exchanges.
+
+1.2 Keeping the Chain of Trust Intact
+
+ Maintaining a valid chain of trust is important because broken chains
+ of trust will result in data being marked as bogus, which may cause
+ entire (sub)domains to become invisible to verifying clients. The
+ administrators of secured zones have to realise that their zone is,
+ to their clients, part of a chain of trust.
+
+ As mentioned in the introduction, the procedures herein are intended
+ to ensure maintenance of zones, such as resigning or key rollovers,
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 3]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ be transparent to the verifying clients on the Internet.
+ Administrators of secured zones will have to keep in mind that data
+ published on an authoritative primary server will not be immediately
+ seen by verifying clients; it may take some time for the data to be
+ transfered to other secondary authoritative nameservers, during which
+ period clients may be fetching data from caching non-authoritative
+ servers. For the verifying clients it is important that data from
+ secured zones can be used to build chains of trust regardless of
+ whether the data came directly from an authoritative server, a
+ caching nameserver or some middle box. Only by carefully using the
+ available timing parameters can a zone administrator assure that the
+ data necessary for verification can be obtained.
+
+ The responsibility for maintaining the chain of trust is shared by
+ administrators of secured zones in the chain of trust. This is most
+ obvious in the case of a 'key compromise' when a trade off between
+ maintaining a valid chain of trust and the fact that the key has been
+ stolen, must be made.
+
+ The zone administrator will have to make a tradeoff between keeping
+ the chain of trust intact -thereby allowing for attacks with the
+ compromised key- or to deliberately break the chain of trust thereby
+ making secured subdomains invisible to security aware resolvers. Also
+ see Section 4.
+
+2. Time in DNSSEC
+
+ Without DNSSEC all times in DNS are relative. The SOA's refresh,
+ retry and expiration timers are counters that are used to determine
+ the time elapsed after a slave server syncronised (or tried to
+ syncronise) with a master server. The Time to Live (TTL) value and
+ the SOA minimum TTL parameter [6] are used to determine how long a
+ forwarder should cache data after it has been fetched from an
+ authoritative server. DNSSEC introduces the notion of an absolute
+ time in the DNS. Signatures in DNSSEC have an expiration date after
+ which the signature is marked as invalid and the signed data is to be
+ considered bogus.
+
+2.1 Time Definitions
+
+ In this document we will be using a number of time related terms.
+ Within the context of this document the following definitions apply:
+ o "Signature validity period"
+ The period that a signature is valid. It starts at the time
+ specified in the signature inception field of the RRSIG RR and
+ ends at the time specified in the expiration field of the RRSIG
+ RR.
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 4]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ o "Signature publication period"
+ Time after which a signature (made with a specific key) is
+ replaced with a new signature (made with the same key). This
+ replacement takes place by publishing the relevant RRSIG in the
+ master zone file. If a signature is published at time T0 and a
+ new signature is published at time T1, the signature
+ publication period is T1 - T0.
+ If all signatures are refreshed at zone (re)signing then the
+ signature publication period is equal signature validity
+ period.
+ o "Maximum/Minimum Zone TTL"
+ The maximum or minimum value of all the TTLs in a zone.
+
+2.2 Time Considerations
+
+ Because of the expiration of signatures, one should consider the
+ following.
+ o The Maximum Zone TTL of your zone data should be a fraction of
+ your signature validity period.
+ If the TTL would be of similar order as the signature validity
+ period, then all RRsets fetched during the validity period
+ would be cached until the signature expiration time. As a
+ result query load on authoritative servers would peak at
+ signature expiration time.
+ To avoid query load peaks we suggest the TTL on all the RRs in
+ your zone to be at least a few times smaller than your
+ signature validity period.
+ o The signature publication period should be at least one maximum
+ TTL smaller than the signature validity period.
+ Resigning a zone shortly before the end of the signature
+ validity period may cause simultaneous expiration of data from
+ caches. This in turn may lead to peaks in the load on
+ authoritative servers.
+ o The Minimum zone TTL should be long enough to both fetch and
+ verify all the RRs in the authentication chain.
+ 1. During validation, some data may expire before the
+ validation is complete. The validator should be able to keep
+ all data, until is completed. This applies to all RRs needed
+ to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and
+ the final answers i.e. the RR that is returned for the
+ initial query.
+ 2. Frequent verification causes load on recursive
+ nameservers. Data at delegation points, DSs, DNSKEYs and
+ RRSIGs benefit from caching. The TTL on those should be
+ relatively long.
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 5]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ We have seen events where data needed for verification of an
+ authentication chain had expired from caches.
+ We suggest the TTL on DNSKEY and DSs to be between ten minutes
+ and one hour. We recommend zone administrators to chose TTLs
+ longer than half a minute.
+ [Editor's Note: this observation could be implementation
+ specific. We are not sure if we should leave this item]
+ o Slave servers will need to be able to fetch newly signed zones
+ well before the data expires from your zone.
+ 'Better no answers than bad answers.'
+ If a properly implemented slave server is not able to contact a
+ master server for an extended period the data will at some
+ point expire and the slave server will not hand out any data.
+ If the server serves a DNSSEC zone than it may well happen that
+ the signatures expire well before the SOA expiration timer
+ counts down to zero. It is not possible to completely prevent
+ this from happening by tweaking the SOA parameters. However,
+ the effects can be minimized where the SOA expiration time is
+ equal or smaller than the signature validity period.
+ The consequence of an authoritative server not being able to
+ update a zone, whilst that zone includes expired signaturs, is
+ that non-secure resolvers will continue to be able to resolve
+ data served by the particular slave servers. Security aware
+ resolvers will experience problems.
+ We suggest the SOA expiration timer being approximately one
+ third or one fourth of the signature validity period. It will
+ allow problems with transfers from the master server to be
+ noticed before the actual signature time out.
+ We suggest that operators of nameservers with slave zones
+ develop 'watch dogs' to spot upcoming signature expirations in
+ slave zones, and take appropriate action.
+ When determining the value for the expiration parameter one has
+ to take the following into account: What are the chances that
+ all my secondary zones expire; How quickly can I reach an
+ administrator and load a valid zone? All these arguments are
+ not DNSSEC specific.
+
+3. Keys
+
+ In the DNSSEC protocol there is only one type of key, the zone key.
+ With this key, the data in a zone is signed.
+
+ To make zone re-signing and key rollovers procedures easier to
+ implement, it is possible to use one or more keys as Key Signing Keys
+ (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other
+ keys can be used to sign all the RRsets in a zone and are referred to
+ as Zone Signing Keys (ZSK). In this document we assume that KSKs are
+ the subset of keys that are used for key exchanges with the parents
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 6]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ and potentially for configuration as trusted anchors - the so called
+ Secure Entry Point keys (SEP). In this document we assume a
+ one-to-one mapping between KSK and SEP keys and we assume the SEP
+ flag [4] to be set on KSKs.
+
+3.1 Motivations for the KSK and ZSK Functions
+
+ Differentiating between the KSK to ZSK functions has several
+ advantages:
+
+ o Making the KSK stronger (i.e. using more bits in the key material)
+ has little operational impact since it is only used to sign a
+ small fraction of the zone data.
+ o As the KSK is only used to sign a keyset, which is most probably
+ updated less frequently than other data in the zone, it can be
+ stored separately from (and thus in a safer location than) the
+ ZSK.
+ o A KSK can be used for longer periods.
+ o No parent/child interaction is required when ZSKs are updated.
+
+ The KSK is used less than ZSK, once a keyset is signed with the KSK
+ all the keys in the keyset can be used as ZSK. If a ZSK is
+ compromised, it can be simply dropped from the keyset. The new keyset
+ is then resigned with the KSK.
+
+ Given the assumption that for KSKs the SEP flag is set, the KSK can
+ be distinguished from a ZSK by examining the flag field in the DNSKEY
+ RR. If the flag field is an odd number it is a KSK if it is an even
+ number it is a ZSK e.g. a value of 256 and a key signing key has 257.
+
+ The zone-signing key can be used to sign all the data in a zone on a
+ regular basis. When a zone-signing key is to be rolled, no
+ interaction with the parent is needed. This allows for relatively
+ short "Signature Validity Periods". That is, Signature Validity
+ Periods of the order of days.
+
+ The key-signing key is only to be used to sign the Key RR set from
+ the zone apex. If a key-signing key is to be rolled over, there will
+ be interactions with parties other than the zone administrator such
+ as the registry of the parent zone or administrators of verifying
+ resolvers that have the particular key configured as trusted entry
+ points. Hence, the "Key Usage Time" of these keys can and should be
+ made much longer. Although, given a long enough key, the "Key Usage
+ Time" can be on the order of years we suggest to plan for a "Key
+ Usage Time" of the order of a few months so that a key rollover
+ remains an operational routine.
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 7]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+3.2 Key Security Considerations
+
+ Keys in DNSSEC have a number of parameters which should all be chosen
+ with care, the most important once are: size, algorithm and the key
+ validity period (its lifetime).
+
+3.2.1 Key Validity Period
+
+ RFC2541 [2] describes a number of considerations with respect to the
+ security of keys. The document deals with the generation, lifetime,
+ size and storage of private keys.
+
+ In Section 3 of RFC2541 [2] there are some suggestions for a key
+ validity period: 13 months for long-lived keys and 36 days for
+ transaction keys but suggestions for key sizes are not made.
+
+ If we say long-lived keys are key-signing keys and transactions keys
+ are zone-signing keys, these recommendations will lead to rollovers
+ occurring frequently enough to become part of 'operational habits';
+ the procedure does not have to be reinvented every time a key is
+ replaced.
+
+3.2.2 Key Algorithm
+
+ We recommend you choose RSA/SHA-1 as the preferred algorithm for the
+ key. RSA has been developed in an open and transparent manner. As the
+ patent on RSA expired in 2001, its use is now also free. The current
+ known attacks on RSA can be defeated by making your key longer. As
+ the MD5 hashing algorithm is showing (theoretical) cracks, we
+ recommend the usage of SHA1.
+
+3.2.3 Key Sizes
+
+ When choosing key sizes, zone administrators will need to take into
+ account how long a key will be used and how much data will be signed
+ during the key publication period. It is hard to give precise
+ recommendations but Lenstra and Verheul [9] supplied the following
+ table with lower bound estimates for cryptographic key sizes. Their
+ recommendations are based on a set of explicitly formulated parameter
+ settings, combined with existing data points about cryptosystems. For
+ details we refer to the original paper.
+
+ [Editor's Note: DSA???]
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 8]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ Year RSA Key Sizes Elliptic Curve Key Size
+ 2000 952 132
+ 2001 990 135
+ 2002 1028 139
+ 2003 1068 140
+ 2004 1108 143
+
+ 2005 1149 147
+ 2006 1191 148
+ 2007 1235 152
+ 2008 1279 155
+ 2009 1323 157
+
+
+ 2010 1369 160
+ 2011 1416 163
+ 2012 1464 165
+ 2013 1513 168
+ 2014 1562 172
+
+ 2015 1613 173
+ 2016 1664 177
+ 2017 1717 180
+ 2018 1771 181
+ 2019 1825 185
+
+
+ 2020 1881 188
+ 2021 1937 190
+ 2022 1995 193
+ 2023 2054 197
+ 2024 2113 198
+
+ 2025 2174 202
+ 2026 2236 205
+ 2027 2299 207
+ 2028 2362 210
+ 2029 2427 213
+
+ For example, should you wish your key to last three years from 2003,
+ check the RSA keysize values for 2006 in this table. In this case
+ 1191.
+
+3.3 Key Rollovers
+
+ Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
+ cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone
+ administrators who are in the process of rolling their keys have to
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 9]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ take into account that data published in previous versions of their
+ zone still lives in caches. When deploying DNSSEC, this becomes an
+ important consideration; ignoring data that may be in caches may lead
+ to loss of service for clients.
+
+ The most pressing example of this is when zone material signed with
+ an old key is being validated by a resolver which does not have the
+ old zone key cached. If the old key is no longer present in the
+ current zone, this validation fails, marking the data bogus.
+ Alternatively, an attempt could be made to validate data which is
+ signed with a new key against an old key that lives in a local cache,
+ also resulting in data being marked bogus.
+
+ To appreciate the situation one could think of a number of
+ authoritative servers that may not be instantaneously running the
+ same version of a zone and a security aware non-recursive resolver
+ that sits behind security aware caching forwarders.
+
+ Note that KSK rollovers and ZSK rollovers are different. A zone-key
+ rollover can be handled in two different ways: pre-publish (Section
+ Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The
+ pre-publish technique works because the key-signing key stays the
+ same during this ZSK rollover. With this KSK a cache is able to
+ validate the new keyset of a zone. With a KSK rollover a cache can
+ not validate the new keyset, because it does not trust the new KSK.
+
+ [Editors note: This needs more verbose explanation, nobody will
+ appreciate the situation just yet. Help with text and examples is
+ appreciated]
+
+3.3.1 Zone-signing Key Rollovers
+
+ For zone-signing key rollovers there are two ways to make sure that
+ during the rollover data still cached can be verified with the new
+ keysets or newly generated signatures can be verified with the keys
+ still in caches. One schema uses double signatures, it is described
+ in Section 3.3.1.2, the other uses key pre-publication (Section
+ 3.3.1.1). The pros, cons and recommendations are described in Section
+ 3.3.1.3.
+
+3.3.1.1 Pre-publish Keyset Rollover
+
+ This section shows how to perform a ZSK rollover without the need to
+ sign all the data in a zone twice - the so called "prepublish
+ rollover". We recommend this method because it has advantages in the
+ case of key compromise. If the old key is compromised, the new key
+ has already been distributed in the DNS. The zone administrator is
+ then able to quickly switch to the new key and remove the compromised
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 10]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ key from the zone. Another major advantage is that the zone size does
+ not double, as is the case with the double signature ZSK rollover. A
+ small "HOWTO" for this kind of rollover can be found in Appendix B.
+
+ normal pre-roll roll after
+
+ SOA0 SOA1 SOA2 SOA3
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
+
+ DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
+ DNSKEY11 DNSKEY11
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+
+
+ normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
+ DNSKEY 10 is used to sign all the data of the zone, the
+ zone-signing key.
+ pre-roll: DNSKEY 11 is introduced into the keyset. Note that no
+ signatures are generated with this key yet, but this does not
+ secure against brute force attacks on the public key. The minimum
+ duration of this pre-roll phase is the time it takes for the data
+ to propagate to the authoritative servers plus TTL value of the
+ keyset. This equates to two times the Maximum Zone TTL.
+ roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign
+ the data in the zone exclusively (i.e. all the signatures from
+ DNSKEY 10 are removed from the zone). DNSKEY 10 remains published
+ in the keyset. This way data that was loaded into caches from
+ version 1 of the zone can still be verified with key sets fetched
+ from version 2 of the zone.
+ The minimum time that the keyset including DNSKEY 10 is to be
+ published is the time that it takes for zone data from the
+ previous version of the zone to expire from old caches i.e. the
+ time it takes for this zone to propagate to all authoritative
+ servers plus the Maximum Zone TTL value of any of the data in the
+ previous version of the zone.
+ after: DNSKEY 10 is removed from the zone. The keyset, now only
+ containing DNSKEY 11 is resigned with the DNSKEY 1.
+
+ The above scheme can be simplified by always publishing the "future"
+ key immediately after the rollover. The scheme would look as follows
+ (we show two rollovers); the future key is introduced in "after" as
+ DNSKEY 12 and again a newer one, numbered 13, in "2nd after":
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 11]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ normal roll after 2nd roll 2nd after
+
+ SOA0 SOA2 SOA3 SOA4 SOA5
+ RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)
+
+ DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12
+ DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13
+ RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
+ RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)
+
+
+ Note that the key introduced after the rollover is not used for
+ production yet; the private key can thus be stored in a physically
+ secure manner and does not need to be 'fetched' every time a zone
+ needs to be signed.
+
+ This scheme has the benefit that the key that is intended for future
+ use: immediately during an emergency rollover assuming that the
+ private key was stored in a physically secure manner.
+
+3.3.1.2 Double Signature Zone-signing Key Rollover
+
+ This section shows how to perform a ZSK key rollover using the double
+ zone data signature scheme, aptly named "double sig rollover".
+
+ During the rollover stage the new version of the zone file will need
+ to propagate to all authoritative servers and the data that exists in
+ (distant) caches will need to expire, this will take at least the
+ maximum Zone TTL .
+
+ normal roll after
+
+ SOA0 SOA1 SOA2
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
+ RRSIG11(SOA1)
+
+ DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY11
+ DNSKEY11
+ RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
+ RRSIG11(DNSKEY)
+
+ normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
+ DNSKEY 10 is used to sign all the data of the zone, the
+ zone-signing key.
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 12]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
+ into the keyset and all the data in the zone is signed with DNSKEY
+ 10 and DNSKEY 11. The rollover period will need to exist until all
+ data from version 0 of the zone has expired from remote caches.
+ This will take at least the maximum Zone TTL of version 0 of the
+ zone.
+ after: DNSKEY 10 is removed from the zone. All the signatures from
+ DNSKEY 10 are removed from the zone. The keyset, now only
+ containing DNSKEY 11, is resigned with DNSKEY 1.
+
+ At every instance the data from the previous version of the zone can
+ be verified with the key from the current version and vice verse. The
+ data from the current version can be verified with the data from the
+ previous version of the zone. The duration of the rollover phase and
+ the period between rollovers should be at least the "Maximum Zone
+ TTL".
+
+ Making sure that the rollover phase lasts until the signature
+ expiration time of the data in version 0 of the zone is recommended.
+ However, this date could be considerably longer than the Maximum Zone
+ TTL, making the rollover a lengthy procedure.
+
+ Note that in this example we assumed that the zone was not modified
+ during the rollover. New data can be introduced in the zone as long
+ as it is signed with both keys.
+
+3.3.1.3 Pros and Cons of the Schemes
+
+ Prepublish-keyset rollover: This rollover does not involve signing
+ the zone data twice. Instead, just before the actual rollover, the
+ new key is published in the keyset and thus available for
+ cryptanalysis attacks. A small disavantage is that this process
+ requires four steps. Also the prepublish scheme will not work for
+ KSKs as explained in Section 3.3.
+ Double signature rollover: The drawback of this signing scheme is
+ that during the rollover the number of signatures in your zone
+ doubles, this may be prohibitive if you have very big zones. An
+ advantage is that it only requires three steps.
+
+3.3.2 Key-signing Key Rollovers
+
+ For the rollover of a key-signing key the same considerations as for
+ the rollover of a zone-signing key apply. However we can use a double
+ signature scheme to guarantee that old data (only the apex keyset) in
+ caches can be verified with a new keyset and vice versa.
+
+ Since only the keyset is signed with a KSK, zone size considerations
+ do not apply.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 13]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ normal roll after
+
+ SOA0 SOA1 SOA2
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)
+
+ DNSKEY1 DNSKEY1 DNSKEY2
+ DNSKEY2
+ DNSKEY10 DNSKEY10 DNSKEY10
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
+ RRSIG2 (DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+
+ normal: Version 0 of the zone. The parental DS points to DNSKEY1.
+ Before the rollover starts the child will have to verify what the
+ TTL is of the DS RR that points to DNSKEY1 - it is needed during
+ the rollover and we refer to the value as TTL_DS.
+ roll: During the rollover phase the zone administrator generates a
+ second KSK, DNSKEY2. The key is provided to the parent and the
+ child will have to wait until a new DS RR has been generated that
+ points to DNSKEY2. After that DS RR has been published on _all_
+ servers authoritative for the parents zone, the zone administrator
+ has to wait at least TTL_DS to make sure that the old DS RR has
+ expired from distant caches.
+ after: DNSKEY1 has been removed.
+
+ The scenario above puts the responsibility for maintaining a valid
+ chain of trust with the child. It also is based on the premises that
+ the parent only has one DS RR (per algorithm) per zone. St John [The
+ draft has expired] proposed a mechanism where using an established
+ trust relation, the interaction can be performed in-band. In this
+ mechanism there are periods where there are two DS RRs at the parent.
+
+ [Editors note: We probably need to mention more]
+
+4. Planning for Emergency Key Rollover
+
+ This section deals with preparation for a possible key compromise.
+ Our advice is to have a documented procedure ready for when a key
+ compromise is suspected or confirmed.
+
+ [Editors note: We are much in favor of a rollover tactic that keeps
+ the authentication chain intact as long as possible. This means that
+ one has to take all the regular rollover properties into account.]
+
+ When the private material of one of your keys is compromised it can
+ be used for as long as a valid authentication chain exists. An
+ authentication chain remains intact for:
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 14]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ o as long as a signature over the compromised key in the
+ authentication chain is valid,
+ o as long as a parental DS RR (and signature) points to the
+ compromised key,
+ o as long as the key is anchored in a resolver and is used as a
+ starting point for validation. (This is the hardest to update.)
+ While an authentication chain to your compromised key exists, your
+ name-space is vulnerable to abuse by the malicious key holder (i.e.
+ the owner of the compromised key). Zone operators have to make a
+ trade off if the abuse of the compromised key is worse than having
+ data in caches that cannot be validated. If the zone operator chooses
+ to break the authentication chain to the compromised key, data in
+ caches signed with this key cannot be validated. However, if the zone
+ administrator chooses to take the path of a regular roll-over, the
+ malicious key holder can spoof data so that it appears to be valid,
+ note that this kind of attack will usually be localised in the
+ Internet topology.
+
+
+4.1 KSK Compromise
+
+ When the KSK has been compromised the parent must be notified as soon
+ as possible using secure means. The keyset of the zone should be
+ resigned as soon as possible. Care must be taken to not break the
+ authentication chain. The local zone can only be resigned with the
+ new KSK after the parent's zone has been updated with the new KSK.
+ Before this update takes place it would be best to drop the security
+ status of a zone all together: the parent removes the DS of the child
+ at the next zone update. After that the child can be made secure
+ again.
+
+ An additional danger of a key compromise is that the compromised key
+ can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
+ rollover at the parent. When that happens the domain can be in
+ dispute. An out of band and secure notify mechanism to contact a
+ parent is needed in this case.
+
+4.2 ZSK Compromise
+
+ Primarily because there is no parental interaction required when a
+ ZSK is compromised, the situation is less severe than with with a KSK
+ compromise. The zone must still be resigned with a new ZSK as soon
+ as possible. As this is a local operation and requires no
+ communication between the parent and child this can be achieved
+ fairly quickly. However, one has to take into account that just as
+ with a normal rollover the immediate disappearance from the old
+ compromised key may lead to verification problems. The
+ pre-publication scheme as discussed above minimises such problems.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 15]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+4.3 Compromises of Keys Anchored in Resolvers
+
+ A key can also be pre-configured in resolvers. If DNSSEC is rolled
+ out as planned the root key should be pre-configured in every secure
+ aware resolver on the planet. [Editors Note: add more about
+ authentication of a newly received resolver key]
+
+ If trust-anchor keys are compromised, the resolvers using these keys
+ should be notified of this fact. Zone administrators may consider
+ setting up a mailing list to communicate the fact that a SEP key is
+ about to be rolled over. This communication will of course need to be
+ authenticated e.g. by using digital signatures.
+
+5. Parental Policies
+
+5.1 Initial Key Exchanges and Parental Policies Considerations
+
+ The initial key exchange is always subject to the policies set by the
+ parent (or its registry). When designing a key exchange policy one
+ should take into account that the authentication and authorisation
+ mechanisms used during a key exchange should be as strong as the
+ authentication and authorisation mechanisms used for the exchange of
+ delegation information between parent and child.
+
+ Using the DNS itself as the source for the actual DNSKEY material,
+ with an off-band check on the validity of the DNSKEY, has the benefit
+ that it reduces the chances of user error. A parental DNSKEY download
+ tool can make use of the SEP bit [4] to select the proper key from a
+ DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is
+ sent. It can validate the self-signature over a key; thereby
+ verifying the ownership of the private key material. Fetching the
+ DNSKEY from the DNS ensures that the child will not become bogus once
+ the parent publishes the DS RR indicating the child is secure.
+
+ Note: the off-band verification is still needed when the key-material
+ is fetched by a tool. The parent can not be sure whether the DNSKEY
+ RRs have been spoofed.
+
+5.2 Storing Keys So Hashes Can Be Regenerated
+
+ When designing a registry system one should consider if the DNSKEYs
+ and/or the corresponding DSs are stored. Storing DNSKEYs will help
+ during troubleshooting while the overhead of calculating DS records
+ from them is minimal.
+
+ Having an out-of-band mechanism, such as a Whois database, to find
+ out which keys are used to generate DS Resource Records for specific
+ owners may also help with troubleshooting.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 16]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+5.3 Security Lameness Checks
+
+ Security Lameness is defined as what happens when a parent has a DS
+ Resource Record pointing to a non-existing DNSKEY RR. During key
+ exchange a parent should make sure that the child's key is actually
+ configured in the DNS before publishing a DS RR in its zone. Failure
+ to do so would render the child's zone being marked as bogus.
+
+ Child zones should be very careful removing DNSKEY material,
+ specifically SEP keys, for which a DS RR exists.
+
+ Once a zone is "security lame" a fix (e.g. by removing a DS RR) will
+ take time to propagate through the DNS.
+
+5.4 DS Signature Validity Period
+
+ Since the DS can be replayed as long as it has a valid signature a
+ short signature validity period over the DS minimises the time a
+ child is vulnerable in the case of a compromise of the child's
+ KSK(s). A signature validity period that is too short introduces the
+ possibility that a zone is marked bogus in case of a configuration
+ error in the signer; there may not be enough time to fix the problems
+ before signatures expire. Something as mundane as operator
+ unavailability during weekends shows the need for DS signature
+ lifetimes longer than 2 days. We recommend the minimum for a DS
+ signature validity period to be a few days.
+
+ The maximum signature lifetime of the DS record depends on how long
+ child zones are willing to be vulnerable after a key compromise. We
+ consider a signature validity period of around one week to be a good
+ compromise between the operational constraints of the parent and
+ minimising damage for the child.
+
+6. Security Considerations
+
+ DNSSEC adds data integrity to the DNS. This document tries to assess
+ considerations to operate a stable and secure DNSSEC service. Not
+ taking into account the 'data propagation' properties in the DNS will
+ cause validation failures and may make secured zones unavailable to
+ security aware resolvers.
+
+7. Acknowledgments
+
+ We, the folk mentioned as authors, only acted as editors. Most of the
+ ideas in this draft were the result of collective efforts during
+ workshops, discussions and try outs.
+
+ At the risk of forgetting individuals who where the original
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 17]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ contributors of the ideas we would like to acknowledge people who
+ where actively involved in the compilation of this document. In
+ random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,
+ Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier
+ Courtay, Sam Weiler.
+
+ Emma Bretherick and Adrian Bedford corrected many of the spelling and
+ style issues.
+
+ Kolkman and Gieben take the blame for introducing all miscakes(SIC).
+
+8. References
+
+8.1 Normative References
+
+ [1] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [2] Eastlake, D., "DNS Security Operational Considerations", RFC
+ 2541, March 1999.
+
+ [3] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+ [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
+ (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
+ in progress), February 2003.
+
+8.2 Informative References
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
+ 2308, March 1998.
+
+ [7] Gudmundsson, O., "Delegation Signer Resource Record",
+ draft-ietf-dnsext-delegation-signer-13 (work in progress), March
+ 2003.
+
+ [8] Arends, R., "Protocol Modifications for the DNS Security
+ Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
+ progress), March 2003.
+
+ [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",
+ The Journal of Cryptology 14 (255-293), 2001.
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 18]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+Authors' Addresses
+
+ Olaf M. Kolkman
+ RIPE NCC
+ Singel 256
+ Amsterdam 1016 AB
+ The Netherlands
+
+ Phone: +31 20 535 4444
+ EMail: olaf@ripe.net
+ URI: http://www.ripe.net/
+
+
+ Miek Gieben
+ NLnet Labs
+ Kruislaan 419
+ Amsterdam 1098 VA
+ The Netherlands
+
+ EMail: miek@nlnetlabs.nl
+ URI: http://www.nlnetlabs.nl
+
+Appendix A. Terminology
+
+ In this document there is some jargon used that is defined in other
+ documents. In most cases we have not copied the text from the
+ documents defining the terms but given a more elaborate explanation
+ of the meaning. Note that these explanations should not be seen as
+ authoritative.
+
+ Private and Public Keys: DNSSEC secures the DNS through the use of
+ public key cryptography. Public key cryptography is based on the
+ existence of two keys, a public key and a private key. The public
+ keys are published in the DNS by use of the DNSKEY Resource Record
+ (DNSKEY RR). Private keys should remain private i.e. should not be
+ exposed to parties not-authorised to do the actual signing.
+ Signer: The system that has access to the private key material and
+ signs the Resource Record sets in a zone. A signer may be
+ configured to sign only parts of the zone e.g. only those RRsets
+ for which existing signatures are about to expire.
+ KSK: A Key-Signing Key (KSK) is a key that is used exclusively for
+ signing the apex keyset. The fact that a key is a KSK is only
+ relevant to the signing tool.
+ ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all
+ data in a zone. The fact that a key is a ZSK is only relevant to
+ the signing tool.
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 19]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ SEP Key: A KSK that has a parental DS record pointing to it. Note:
+ this is not enforced in the protocol. A SEP Key with no parental
+ DS is security lame.
+ Anchored Key: A DNSKEY configured in resolvers around the globe. This
+ Key is hard to update, hence the term anchored.
+ Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked
+ "Bogus" when a signature of a RRset does not validate against the
+ DNSKEY. Even if the key itself was not marked Bogus. A cache may
+ choose to cache Bogus data for various reasons.
+ Singing the Zone File: The term used for the event where an
+ administrator joyfully signs its zone file while producing melodic
+ sound patterns.
+ Zone Administrator: The 'role' that is responsible for signing a zone
+ and publishing it on the primary authoritative server.
+
+Appendix B. Zone-signing Key Rollover Howto
+
+ Using the pre-published signature scheme and the most conservative
+ method to assure oneself that data does not live in distant caches
+ here follows the "HOWTO". [WES: has some comments about this]
+ Key notation:
+ Step 0: The preparation: Create two keys and publish both in your
+ keyset. Mark one of the keys as "active" and the other as
+ "published". Use the "active" key for signing your zone data.
+ Store the private part of the "published" key, preferably
+ off-line.
+ Step 1: Determine expiration: At the beginning of the rollover make a
+ note of the highest expiration time of signatures in your zone
+ file created with the current key marked as "active".
+ Wait until the expiration time marked in Step 1 has passed
+ Step 2: Then start using the key that was marked as "published" to
+ sign your data i.e. mark it as "active". Stop using the key that
+ was marked as "active", mark it as "rolled".
+ Step 3: It is safe to engage in a new rollover (Step 1) after at
+ least one "signature validity period".
+
+Appendix C. Typographic Conventions
+
+ The following typographic conventions are used in this document:
+ Key notation: A key is denoted by KEYx, where x is a number, x could
+ be thought of as the key id.
+ RRset notations: RRs are only denoted by the type. All other
+ information - owner, class, rdata and TTL - is left out. Thus:
+ example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a
+ list of RRs. A example of this would be: A1,A2, specifying the
+ RRset containing two A records. This could again be abbreviated to
+ just: A.
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 20]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ Signature notation: Signatures are denoted as RRSIGx(RRset), which
+ means that RRset is signed with DNSKEYx.
+ Zone representation: Using the above notation we have simplified the
+ representation of a signed zone by leaving out all unnecessary
+ details such as the names and by representing all data by "SOAx"
+ SOA representation: SOA's are represented as SOAx, where x is the
+ serial number.
+ Using this notation the following zone :
+
+
+ example.net. 600 IN SOA ns.example.net. ernie.example.net. (
+ 10 ; serial
+ 450 ; refresh (7 minutes 30 seconds)
+ 600 ; retry (10 minutes)
+ 345600 ; expire (4 days)
+ 300 ; minimum (5 minutes)
+ )
+ 600 RRSIG SOA 5 2 600 20130522213204 (
+ 20130422213204 14 example.net.
+ cmL62SI6iAX46xGNQAdQ... )
+ 600 NS a.iana-servers.net.
+ 600 NS b.iana-servers.net.
+ 600 RRSIG NS 5 2 600 20130507213204 (
+ 20130407213204 14 example.net.
+ SO5epiJei19AjXoUpFnQ ... )
+ 3600 DNSKEY 256 3 5 (
+ EtRB9MP5/AvOuVO0I8XDxy0...
+ ) ; key id = 14
+ 3600 DNSKEY 256 3 5 (
+ gsPW/Yy19GzYIY+Gnr8HABU...
+ ) ; key id = 15
+ 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
+ 20130422213204 14 example.net.
+ J4zCe8QX4tXVGjV4e1r9... )
+ 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
+ 20130422213204 15 example.net.
+ keVDCOpsSeDReyV6O... )
+ 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
+ 600 RRSIG NSEC 5 2 600 20130507213204 (
+ 20130407213204 14 example.net.
+ obj3HEp1GjnmhRjX... )
+ a.example.net. 600 IN TXT "A label"
+ 600 RRSIG TXT 5 3 600 20130507213204 (
+ 20130407213204 14 example.net.
+ IkDMlRdYLmXH7QJnuF3v... )
+ 600 NSEC b.example.com. TXT RRSIG NSEC
+ 600 RRSIG NSEC 5 3 600 20130507213204 (
+ 20130407213204 14 example.net.
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 21]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ bZMjoZ3bHjnEz0nIsPMM... )
+
+ ...
+
+
+ is reduced to the following represenation:
+
+ SOA10
+ RRSIG14(SOA10)
+
+ DNSKEY14
+ DNSKEY15
+
+ RRSIG14(KEY)
+ RRSIG15(KEY)
+
+ The rest of the zone data has the same signature as the SOA record,
+ i.e a RRSIG created with DNSKEY 14.
+
+Appendix D. Document Details and Changes
+
+ This section is to be removed by the RFC editor if and when the
+ document is published.
+
+ $Header: /var/cvs/dnssec-key/
+ draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12
+ 08:29:11 dnssec Exp $
+
+D.1 draft-ietf-dnsop-dnssec-operational-practices-00
+
+ Submission as working group document. This document is a modified and
+ updated version of draft-kolkman-dnssec-operational-practices-00.
+
+D.2 draft-ietf-dnsop-dnssec-operational-practices-01
+
+ changed the definition of "Bogus" to reflect the one in the protocol
+ draft.
+
+ Bad to Bogus
+
+ Style and spelling corrections
+
+ KSK - SEP mapping made explicit.
+
+ Updates from Sam Weiler added
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 22]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 23]
+
+Internet-Draft DNSSEC Operational Practices March 2004
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires August 30, 2004 [Page 24]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
new file mode 100644
index 00000000000..42c3c0b7c7e
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt
@@ -0,0 +1,1321 @@
+
+DNS Operations WG
+Internet-Draft J. Jeong (ed.)
+ ETRI
+
+Expires: January 2005 18 July 2004
+
+
+ IPv6 Host Configuration of DNS Server Information Approaches
+ draft-ietf-dnsop-ipv6-dns-configuration-02.txt
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which we become aware will be disclosed, in accordance
+ with RFC3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-Drafts
+ as reference material or to cite them other than as "work in
+ progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 17, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document describes three approaches for IPv6 recursive DNS
+ server address configuration. It details the operational
+ attributes of three solutions: RA option, DHCPv6 option, and Well-
+ known anycast addresses for recursive DNS servers. Additionally,
+ it suggests four deployment scenarios considering multi-solution
+ resolution. Therefore, this document will give the audience a
+
+
+
+Jeong, et al. Expires - January 2005 [Page 1]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ guideline of IPv6 DNS configuration to select approaches suitable
+ for their host DNS configuration.
+
+Table of Contents
+
+ 1. Introduction...................................................3
+ 2. Terminology....................................................3
+ 3. IPv6 DNS Configuration Approaches..............................3
+ 3.1 RA Option..................................................3
+ 3.1.1 Advantages...........................................4
+ 3.1.2 Disadvantages........................................5
+ 3.1.3 Observations.........................................5
+ 3.2 DHCPv6 Option..............................................6
+ 3.2.1 Advantages...........................................7
+ 3.2.2 Disadvantages........................................8
+ 3.2.3 Observations.........................................9
+ 3.3 Well-known Anycast Addresses...............................9
+ 3.3.1 Advantages...........................................9
+ 3.3.2 Disadvantages.......................................10
+ 3.3.3 Observations........................................10
+ 4. Interworking among IPv6 DNS Configuration Approaches..........11
+ 5. Deployment Scenarios..........................................12
+ 5.1 ISP Network...............................................12
+ 5.1.1 RA Option Approach..................................12
+ 5.1.2 DHCPv6 Option Approach..............................13
+ 5.1.3 Well-known Addresses Approach.......................13
+ 5.2 Enterprise Network........................................14
+ 5.3 3GPP Network..............................................14
+ 5.3.1 Currently Available Mechanisms and Recommendations..15
+ 5.3.2 RA Extension........................................16
+ 5.3.3 Stateless DHCPv6....................................16
+ 5.3.4 Well-known Addresses................................17
+ 5.3.5 Recommendations.....................................17
+ 5.4 Unmanaged Network.........................................18
+ 5.4.1 Case A: Gateway does not provide IPv6 at all........18
+ 5.4.2 Case B: A dual-stack gateway connected to a dual-stack
+ ISP.........................................18
+ 5.4.3 Case C: A dual-stack gateway connected to an IPv4-only
+ ISP.........................................19
+ 5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19
+ 6. Security Considerations.......................................19
+ 7. Acknowledgements..............................................19
+ 8. Normative References..........................................20
+ 9. Informative References........................................20
+ 10. Authors' Addresses...........................................21
+ Intellectual Property Statement..................................23
+ Full Copyright Statement.........................................23
+ Acknowledgement..................................................24
+
+
+Jeong, et al. Expires - January 2005 [Page 2]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+
+1. Introduction
+
+ Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+ Autoconfiguration provide ways to configure either fixed or mobile
+ nodes with one or more IPv6 addresses, default routes and some
+ other parameters [3][4]. To support access to additional services
+ in the Internet that are identified by a DNS name, such as a web
+ server, the configuration of at least one recursive DNS server is
+ also needed for DNS name resolution.
+
+ This document describes three approaches of recursive DNS server
+ address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
+ option [5]-[7], and (c) Well-known anycast addresses for recursive
+ DNS servers [9]. Also, it suggests applicable scenarios for four
+ kinds of networks: (a) ISP network, (b) Enterprise network, (c)
+ 3GPP network, and (d) Unmanaged network.
+
+ This document is just an analysis of each possible approach, and
+ does not make any recommendation on particular one or on a
+ combination of particular ones. Some approaches may even not be
+ adopted at all as a result of further discussion.
+
+ Therefore, the objective of this document is to help the audience
+ select approaches suitable for IPv6 host configuration of recursive
+ DNS server.
+
+2. Terminology
+
+ This document uses the terminology described in [3]-[9]. In
+ addition, a new term is defined below:
+
+ Recursive DNS Server (RDNSS) A Recursive DNS Server is a name
+ server that offers the recursive
+ service of DNS name resolution.
+
+3. IPv6 DNS Configuration Approaches
+
+ In this section, the operational attributes of three solutions are
+ described in detail.
+
+3.1 RA Option
+
+ RA approach is to define a new ND option called RDNSS option that
+ contains a recursive DNS server address. Existing ND transport
+ mechanisms (i.e., advertisements and solicitations) are used. This
+ works in the same way that nodes learn about routers and prefixes,
+ etc. An IPv6 host can configure the IPv6 addresses of one or more
+
+
+Jeong, et al. Expires - January 2005 [Page 3]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ RDNSSes via RA message periodically sent by router or solicited by
+ a Router Solicitation (RS) [8]. This approach needs RDNSS
+ information to be configured in the routers doing the
+ advertisements. The configuration of RDNSS address can be
+ performed manually by operator or other ways, such as automatic
+ configuration through DHCPv6 client running on the router. When
+ advertising more than one RDNSS options, an RA message includes as
+ many RDNSS options as RDNSSes. Through ND protocol and RDNSS
+ option along with prefix information option, an IPv6 host can
+ perform its network configuration of its IPv6 address and RDNSS
+ simultaneously [3][4]. The RA option for RDNSS can be used on any
+ network that supports the use of ND. However, RA approach performs
+ poorly in some wireless environments where RA message is used for
+ IPv6 address autoconfiguration, such as WLAN networks.
+
+ The RA approach is useful in some non-WLAN mobile environments
+ where the addresses of the RDNSSes are changing because the RA
+ option includes a lifetime field. This can be configured to a
+ value that will require the client to time out the entry and switch
+ over to another RDNSS address [8]. However, from the viewpoint of
+ implementation, lifetime would seem to make matters a bit more
+ complex. Instead of just writing DNS configuration file, such as
+ resolv.conf for the list of RDNSS addresses, we have to have a
+ daemon around (or a program that is called at the defined
+ intervals) that keeps monitoring the lifetime of RDNSSes all the
+ time.
+
+ The preference value of RDNSS, included in RDNSS option, allows
+ IPv6 hosts to select primary RDNSS among several RDNSSes; this can
+ be used for load balancing of RDNSSes [8].
+
+3.1.1 Advantages
+
+ The RA option for RDNSS has a number of advantages. These include:
+
+ 1) The RA option is an extension of existing ND/Autoconfig
+ mechanisms [3][4], and does not require a change in the base ND
+ protocol.
+
+ 2) This approach, like ND, works well on a variety of link types
+ including point-to-point links, point-to-multipoint, and multi-
+ point (i.e., Ethernet LANs), etc. RFC2461 [3] states, however,
+ that there may be some link type on which ND is not possible; on
+ such a link, some other mechanism will be needed for DNS
+ configuration.
+
+ 3) All of the information a host needs to run basic Internet
+ applications such as email, the web, ftp, etc., can be performed
+
+
+Jeong, et al. Expires - January 2005 [Page 4]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ with the addition of this option to ND and address auto-
+ configuration. The use of a single mechanism is more reliable and
+ easier to provide than when the RDNSS information is learned via
+ another protocol mechanism. Debugging problems when multiple
+ protocol mechanisms are being used is harder and much more complex.
+
+ 4) This mechanism works over a broad range of scenarios and
+ leverages IPv6 ND. This works well on links that support broadcast
+ reliably (e.g., Ethernet LANs) but not necessarily on other links
+ (e.g., Wireless LANs). Also, this works well on links that are
+ high performance (e.g., Ethernet LANs) and low performance (e.g.,
+ Cellular networks). In the latter case, combining the RDNSS
+ information with the other information in the RA, the host can
+ learn all of the information needed to use most Internet
+ applications such as the web in a single packet. This not only
+ saves bandwidth where this is an issue, but also minimizes the
+ delay to learn the RDNSS information.
+
+ 5) The RA approach could be used as a model for other similar types
+ of configuration information. New RA options for other server
+ addresses that are common to all clients on a subnet would be easy
+ to define. This includes things like NTP servers, SIP servers, etc.
+
+3.1.2 Disadvantages
+
+ 1) ND is mostly implemented in kernel part of operating system.
+ Therefore, if ND supports the configuration of some additional
+ services, such as DNS, NTP and SIP servers, ND should be extended
+ in kernel part. DHCPv6, however, has more flexibility for
+ extension of service discovery because it is an application layer
+ protocol.
+
+ 2) The current ND framework should be modified due to the
+ synchronization between another ND cache for RDNSSes in kernel
+ space and DNS configuration file in user space. Because it is
+ unacceptable to write and rewrite the DNS configuration file (e.g.,
+ resolv.conf) from the kernel, another approach is needed. One
+ simple approach to solve this is to have a daemon listening to what
+ the kernel conveys, and to have the daemon do these steps, but such
+ a daemon is not necessary with the current ND framework.
+
+ 3) It is necessary to configure RDNSS addresses at least at one
+ router on every link where this information needs to be configured
+ by RA option.
+
+3.1.3 Observations
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 5]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ The proposed RDNSS RA option along with IPv6 ND and Auto-
+ configuration allows a host to obtain all of the information it
+ needs to access basic Internet services like the web, email, ftp,
+ etc. This is preferable in environments where hosts use RAs to
+ autoconfigure their addresses and all hosts on the subnet share the
+ same router and server addresses. If the configuration information
+ can be obtained from a single mechanism, it is preferable because
+ it does not add additional delay, and it uses a minimum of
+ bandwidth. Environments like this include homes, public cellular
+ networks, and enterprise environments where no per host
+ configuration is needed, but exclude public WLAN hot spots.
+
+ DHCPv6 is preferable where it is being used for address
+ configuration and if there is a need for host specific
+ configuration [5]-[7]. Environments like this are most likely
+ enterprise environments where the local administration chooses to
+ have per host configuration control.
+
+ Note: the observation section is based on what the proponents of
+ each approach think makes a good overall solution.
+
+3.2 DHCPv6 Option
+
+ DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
+ which a host can obtain a list of IP addresses of recursive DNS
+ servers [7]. The DNS Recursive Name Server option carries a list
+ of IPv6 addresses of RDNSSes to which the host may send DNS queries.
+ The DNS servers are listed in the order of preference for use by
+ the DNS resolver on the host.
+
+ The DNS Recursive Name Server option can be carried in any DHCPv6
+ Reply message, in response to either a Request or an Information-
+ request message. Thus, the DNS Recursive Name Server option can be
+ used either when DHCPv6 is used for address assignment, or when
+ DHCPv6 is used only for other configuration information as
+ stateless DHCPv6 [6].
+
+ Stateless DHCPv6 can be deployed either using DHCPv6 servers
+ running on general-purpose computers, or on router hardware.
+ Several router vendors currently implement stateless DHCPv6 servers.
+ Deploying stateless DHCPv6 in routers has the advantage that no
+ special hardware is required, and should work well for networks
+ where DHCPv6 is needed for very straightforward configuration of
+ network devices.
+
+ However, routers can also act as DHCPv6 relay agents. In this case,
+ the DHCPv6 server need not be on the router - it can be on a
+ general purpose computer. This has the potential to give the
+
+
+Jeong, et al. Expires - January 2005 [Page 6]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ operator of the DHCPv6 server more flexibility in how the DHCPv6
+ server responds to individual clients - clients can easily be given
+ different configuration information based on their identity, or for
+ any other reason. Nothing precludes adding this flexibility to a
+ router, but generally in current practice, DHCP servers running on
+ general-purpose hosts tend to have more configuration options than
+ those that are embedded in routers.
+
+ DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
+ clients that use stateful configuration assignment. To do this,
+ the DHCPv6 server sends a Reconfigure message to the client. The
+ client validates the Reconfigure message, and then contacts the
+ DHCPv6 server to obtain updated configuration information. Using
+ this mechanism, it is currently possible to propagate new
+ configuration information to DHCPv6 clients as this information
+ changes.
+
+ The DHC Working Group is currently studying an additional mechanism
+ through which configuration information, including the list of
+ RDNSSes, can be updated. The Lifetime Option for DHCPv6 [10],
+ assigns a lifetime to configuration information obtained through
+ DHCPv6. At the expiration of the lifetime, the host contacts the
+ DHCPv6 server to obtain updated configuration information,
+ including the list of RDNSSes. This lifetime gives the network
+ administrator another mechanism to configure hosts with new RDNSSes
+ by controlling the time at which the host refreshes the list.
+
+ The DHC Working Group has also discussed the possibility of
+ defining an extension to DHCPv6 that would allow the use of
+ multicast to provide configuration information to multiple hosts
+ with a single DHCPv6 message. Because of the lack of deployment
+ experience, the WG has deferred consideration of multicast DHCPv6
+ configuration at this time. Experience with DHCPv4 has not
+ identified a requirement for multicast message delivery, even in
+ large service provider networks with tens of thousands of hosts
+ that may initiate a DHCPv4 message exchange simultaneously.
+
+3.2.1 Advantages
+
+ The DHCPv6 option for RDNSS has a number of advantages. These
+ include:
+
+ 1) DHCPv6 currently provides a general mechanism for conveying
+ network configuration information to clients. So configuring
+ DHCPv6 servers allows the network administrator to configure
+ RDNSSes along with the addresses of other network services, as well
+ as location-specific information like time zones.
+
+
+
+Jeong, et al. Expires - January 2005 [Page 7]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ 2) As a consequence, when the network administrator goes to
+ configure DHCPv6, all the configuration information can be managed
+ through a single service, typically with a single user interface
+ and a single configuration database.
+
+ 3) DHCPv6 allows for the configuration of a host with information
+ specific to that host, so that hosts on the same link can be
+ configured with different RDNSSes as well as other configuration
+ information. This capability is important in some network
+ deployments such as service provider networks or WiFi hot spots.
+
+ 4) A mechanism exists for extending DHCPv6 to support the
+ transmission of additional configuration that has not yet been
+ anticipated.
+
+ 5) Hosts that require other configuration information such as the
+ addresses of SIP servers and NTP servers are likely to need DHCPv6
+ for other configuration information.
+
+ 6) The specification for configuration of RDNSSes through DHCPv6 is
+ available as an RFC. No new protocol extensions such as new
+ options are necessary.
+
+ 7) Interoperability among independent implementations has been
+ demonstrated.
+
+3.2.2 Disadvantages
+
+ The DHCPv6 option for RDNSS has a few disadvantages. These
+ include:
+
+ 1) Update currently requires message from server (however, see
+ [10]).
+
+ 2) Because DNS information is not contained in RA message, the host
+ must receive two messages from the router, and must transmit at
+ least one message to the router. On networks where bandwidth is at
+ a premium, this is a disadvantage, although on most networks it is
+ not a practical concern.
+
+ 3) Increased latency for initial configuration - in addition to
+ waiting for an RA message, the client must now exchange packets
+ with a DHCPv6 server; even if it is locally installed on a router,
+ this will slightly extend the time required to configure the client.
+ For clients that are moving rapidly from one network to another,
+ this will be a disadvantage.
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 8]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+3.2.3 Observations
+
+ In the general case, on general-purpose networks, stateless DHCPv6
+ provides significant advantages and no significant disadvantages.
+ Even in the case where bandwidth is at a premium and low latency is
+ desired, if hosts require other configuration information in
+ addition to a list of RDNSSes or if hosts must be configured
+ selectively, those hosts will use DHCPv6 and the use of the DHCPv6
+ DNS recursive name server option will be advantageous.
+
+ However, we are aware of some applications where it would be
+ preferable to put the RDNSS information into an RA packet; for
+ example, on a cell phone network, where bandwidth is at a premium
+ and extremely low latency is desired. The final DNS configuration
+ draft should be written so as to allow these special applications
+ to be handled using DNS information in the RA packet.
+
+3.3 Well-known Anycast Addresses
+
+ First of all, the well-known anycast addresses approach is much
+ different from that discussed in IPv6 Working Group in the past.
+
+ The approach with well-known anycast addresses is to set well-known
+ anycast addresses in clients' resolver configuration files from the
+ beginning, say, as factory default. Thus, there is no transport
+ mechanism and no packet format [9].
+
+ An anycast address is an address shared by multiple servers (in
+ this case, the servers are RDNSSes). Request from a client to the
+ anycast address is routed to a server selected by the routing
+ system. However, it is a bad idea to mandate "site" boundary on
+ anycast addresses, because most users just do not have their own
+ servers and want to access their ISPs' across their site boundaries.
+ Larger sites may also depend on their ISPs or may have their own
+ RDNSSes within "site" boundaries.
+
+ It should be noted that "anycast" in this memo is simpler than that
+ of RFC1546 [11] and RFC3513 [12] where it is assumed to be
+ prohibited to have multiple servers on a single link sharing an
+ anycast address. That is, on a link, anycast address is assumed to
+ be unique. DNS clients today already have redundancy by having
+ multiple well-known anycast addresses configured as RDNSS addresses.
+ There is no point to have multiple RDNSSes sharing an anycast
+ address on a single link.
+
+3.3.1 Advantages
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 9]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ The basic advantage of the well-known addresses approach is that it
+ uses no transport mechanism. Thus,
+ 1) There is no delay to get response and no further delay by packet
+ losses.
+
+ 2) The approach can be combined with any other configuration
+ mechanisms including but not limited to factory default
+ configuration, RA-based approach and DHCP based approach.
+
+ 3) The approach works over any environment where DNS works.
+
+ Another advantage is that the approach needs to configure DNS
+ servers as a router, but nothing else. Considering that DNS
+ servers do need configuration, the amount of overall configuration
+ effort is proportional to the number of the DNS servers and scales
+ linearly. It should be noted that, in the simplest case where a
+ subscriber to an ISP does not have any DNS server, the subscriber
+ naturally access DNS servers of the ISP even though the subscriber
+ and the ISP do nothing and there is no protocol to exchange DNS
+ server information between the subscriber and the ISP.
+
+3.3.2 Disadvantages
+
+ Well-known anycast addresses approach requires that DNS servers (or
+ routers near it as a proxy) act as routers to advertise their
+ anycast addresses to the routing system, which requires some
+ configuration (see the last paragraph of the previous section on
+ the scalability of the effort).
+
+3.3.3 Observations
+
+ If other approaches are used in addition, the well-known anycast
+ addresses should also be set in RA or DHCP configuration files to
+ reduce configuration effort of users.
+
+ Redundancy by multiple RDNSSes is better provided by multiple
+ servers having different anycast addresses than multiple servers
+ sharing same anycast address because the former approach allows
+ stale servers to still generate routes to their anycast addresses.
+ Thus, in a routing domain (or domains sharing DNS servers), there
+ will be only one server having an anycast address unless the domain
+ is so large that load distribution is necessary.
+
+ Small ISPs will operate one RDNSS at each anycast address which is
+ shared by all the subscribers. Large ISPs may operate multiple
+ RDNSSes at each anycast address to distribute and reduce load,
+ where boundary between RDNSSes may be fixed (redundancy is still
+ provided by multiple addresses) or change dynamically. DNS packets
+
+
+Jeong, et al. Expires - January 2005 [Page 10]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ with the well-known anycast addresses are not expected (though not
+ prohibited) to cross ISP boundaries, as ISPs are expected to be
+ able to take care of themselves.
+
+ Because "anycast" in this memo is simpler than that of RFC1546 [11]
+ and RFC3513 [12] where it is assumed to be administratively
+ prohibited to have multiple servers on a single link sharing an
+ anycast address, anycast in this memo should be implemented as
+ UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related
+ instability disappears. Thus, anycast in well-known anycast
+ addresses approach can and should use the anycast address as a
+ source unicast (according to RFC3513 [12]) address of packets of
+ UDP and TCP responses. With TCP, if route flips and packets to an
+ anycast address are routed to a new server, it is expected that the
+ flip is detected by ICMP or sequence number inconsistency and the
+ TCP connection is reset and retried.
+
+4. Interworking among IPv6 DNS Configuration Approaches
+
+ Three approaches can work together for IPv6 host configuration of
+ RDNSS. This section shows a consideration on how these approaches
+ can interwork each other.
+
+ For ordering between RA and DHCP approaches, O (Other stateful
+ configuration) flag in RA message can be used [8]. If no RDNSS
+ option is included, an IPv6 Host may perform DNS configuration
+ through DHCPv6 [5]-[7] regardless of whether the O flag is set or
+ not.
+
+ The well-known anycast addresses approach fully interworks with the
+ other approaches. That is, the other approaches can remove
+ configuration effort on servers by using the well-known addresses
+ as the default configuration. Moreover, clients preconfigured with
+ well-known anycast addresses can be further configured to use other
+ approaches to override the well-known addresses, if configuration
+ information from other approaches are available. That is, all the
+ clients should have the well-known anycast addresses preconfigured,
+ in the case where there are no other mechanisms available. In
+ order to fly anycast approach with the other solutions, there are
+ three options.
+
+ The first option is that well-known addresses are used as last
+ resort, when an IPv6 host can not get RDNSS information through RA
+ and DHCP. The well-known anycast addresses have to be pre-
+ configured in IPv6 hosts' resolver configuration files.
+
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 11]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ The second is that an IPv6 host can configure well-known addresses
+ as the most preferable in its configuration file even though either
+ RA option or DHCP option is available.
+
+ The last is that the well-known anycast addresses can be set in RA
+ or DHCP configuration to reduce configuration effort of users.
+ According to either RA or DHCP mechanism, the well-known addresses
+ can be obtained by IPv6 host. Because this approach is the most
+ convenient for users, the last option is recommended.
+
+ Note: this section does not necessarily mean this document suggests
+ adopting all these three approaches and making them interwork in
+ the way described here. In fact, some approaches may even not be
+ adopted at all as a result of further discussion.
+
+5. Deployment Scenarios
+
+ Regarding DNS configuration on the IPv6 host, several mechanisms
+ have being considered at the DNSOP Working Group such as RA option,
+ DHCPv6 option and well-known preconfigured anycast addresses as of
+ today, and this document is a final result from the long thread.
+ In this section, we suggest four applicable scenarios of three
+ approaches for IPv6 DNS configuration.
+
+ Note: in the applicable scenarios, authors do not implicitly push
+ any specific approaches into the restricted environments. No
+ enforcement is in each scenario and all mentioned scenarios are
+ probable. The main objective of this work is to provide a useful
+ guideline of IPv6 DNS configuration.
+
+5.1 ISP Network
+
+ A characteristic of ISP network is that multiple Customer Premises
+ Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+ routers and each PE connects multiple CPE devices to the backbone
+ network infrastructure [13]. The CPEs may be hosts or routers.
+
+ In the case where the CPE is a router, there is a customer network
+ that is connected to the ISP backbone through the CPE. Typically,
+ each customer network gets a different IPv6 prefix from an IPv6 PE
+ router, but the same RDNSS configuration will be distributed.
+
+ This section discusses how the different approaches to distributing
+ DNS information are compared in an ISP network.
+
+5.1.1 RA Option Approach
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 12]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ When the CPE is a host, the RA option for RDNSS can be used to
+ allow the CPE to get RDNSS information as well as /64 prefix
+ information for stateless address autoconfiguration at the same
+ time when the host is attached to a new subnet [8]. Because an
+ IPv6 host must receive at least one RA message for stateless
+ address autoconfiguration and router configuration, the host could
+ receive RDNSS configuration information in that RA without the
+ overhead of an additional message exchange.
+
+ When the CPE is a router, the CPE may accept the RDNSS information
+ from the RA on the interface connected to the ISP, and copy that
+ information into the RAs advertised in the customer network.
+
+ This approach is more valuable in the mobile host scenario, in
+ which the host must receive at least an RA message for detecting a
+ new network, than in other scenarios generally although
+ administrator should configure RDNSS information on the routers.
+ Secure ND [14] can provide extended security when using RA message.
+
+5.1.2 DHCPv6 Option Approach
+
+ DHCPv6 can be used for RDNSS configuration through the use of the
+ DNS option, and can provide other configuration information in the
+ same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option
+ is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6-
+ lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6
+ implementation. DHCP is a client-server model protocol, so ISP can
+ handle user identification on its network intentionally, and also
+ authenticated DHCP [15] can be used for secure message exchange.
+
+ The expected model for deployment of IPv6 service by ISPs is to
+ assign a prefix to each customer, which will be used by the
+ customer gateway to assign a /64 prefix to each network in the
+ customer's network. Prefix delegation with DHCP (DHCPv6 PD) has
+ already been adopted by ISPs for automating the assignment of the
+ customer prefix to the customer gateway [17]. DNS configuration
+ can be carried in the same DHCPv6 message exchange used for DHCPv6
+ to efficiently provide that information, along with any other
+ configuration information needed by the customer gateway or
+ customer network. This service model can be useful to Home or SOHO
+ subscribers. The Home or SOHO gateway, which is a customer gateway
+ for ISP, can then pass that RDNSS configuration information to the
+ hosts in the customer network through DHCP.
+
+5.1.3 Well-known Addresses Approach
+
+ Well-known anycast addresses approach is also a feasible and simple
+ mechanism for ISP [9]. The use of well-known anycast addresses
+
+
+Jeong, et al. Expires - January 2005 [Page 13]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ avoids some of the security risks in rogue messages sent through an
+ external protocol like RA or DHCPv6. The configuration of hosts
+ for the use of well-known anycast addresses requires no protocol or
+ manual configuration, but the configuration of routing for the
+ anycast addresses requires intervention on the part of the network
+ administrator. Also, the number of special addresses would be
+ equal to the number of RDNSSes that could be made available to
+ subscribers.
+
+5.2 Enterprise Network
+
+ Enterprise network is defined as a network that has multiple
+ internal links, one or more router connections, to one or more
+ Providers and is actively managed by a network operations entity
+ [16]. An enterprise network can get network prefixes from ISP by
+ either manual configuration or prefix delegation [17]. In most
+ cases, because an enterprise network manages its own DNS domains,
+ it operates its own DNS servers for the domains. These DNS servers
+ within enterprise network process recursive DNS name resolution
+ requests of IPv6 hosts as RDNSS. RDNSS configuration in enterprise
+ network can be performed like in Section 4, in which three
+ approaches can be used together.
+
+ IPv6 host can decide which approach is or may be used in its subnet
+ with O flag in RA message [8]. As the first option in Section 4,
+ well-known anycast addresses can be used as a last resort when
+ RDNSS information can not be obtained through either RA option or
+ DHCP option. This case needs IPv6 hosts to preconfigure the well-
+ known anycast addresses in their DNS configuration files.
+
+ When the enterprise prefers well-known anycast approach to the
+ others, IPv6 hosts should preconfigure the well-known anycast
+ addresses like in the first option.
+
+ The last option, a more convenient and transparent way, does not
+ need IPv6 hosts to preconfigure the well-known anycast addresses
+ because the addresses are delivered to IPv6 hosts through either RA
+ option or DHCPv6 option as if they were unicast addresses. This
+ way is most recommended for the sake of user's convenience.
+
+5.3 3GPP Network
+
+ IPv6 DNS configuration is a missing part of IPv6 autoconfiguration
+ and an important part of the basic IPv6 functionality in the 3GPP
+ User Equipment (UE). Higher level description of the 3GPP
+ architecture can be found in [18], and transition to IPv6 in 3GPP
+ networks is analyzed in [19] and [20].
+
+
+
+Jeong, et al. Expires - January 2005 [Page 14]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ In 3GPP architecture, there is a dedicated link between the UE and
+ the GGSN called the Packet Data Protocol (PDP) Context. This link
+ is created through the PDP Context activation procedure [21].
+ There is a separate PDP context type for IPv4 and IPv6 traffic. If
+ a 3GPP UE user is communicating using IPv6 (having an active IPv6
+ PDP context), it can not be assumed that (s)he has simultaneously
+ active IPv4 PDP context, and DNS queries could be done using IPv4.
+ A 3GPP UE can thus be an IPv6 node, and it needs to somehow
+ discover the address of the RDNSS. Before IP-based services (e.g.,
+ web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS
+ addresses need to be discovered in the 3GPP UE.
+
+ Section 5.3.1 briefly summarizes currently available mechanisms in
+ 3GPP networks and recommendations. 5.3.2 analyzes the Router
+ Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
+ mechanism, and 5.3.4 analyzes the Well-known addresses approach.
+ Section 5.3.5 finally summarizes the recommendations.
+
+5.3.1 Currently Available Mechanisms and Recommendations
+
+ 3GPP has defined a mechanism, in which RDNSS addresses can be
+ received in the PDP context activation (a control plane mechanism).
+ That is called the Protocol Configuration Options Information
+ Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be
+ received over the air (using text messages), or typed in manually
+ in the UE. Note that the two last mechanisms are not very well
+ scalable. The UE user most probably does not want to type IPv6
+ RDNSS addresses manually in his/her UE. The use of well-known
+ addresses is briefly discussed in section 5.3.4.
+
+ It is seen that the mechanisms above most probably are not
+ sufficient for the 3GPP environment. IPv6 is intended to operate
+ in a zero-configuration manner, no matter what the underlying
+ network infrastructure is. Typically, the RDNSS address is needed
+ to make an IPv6 node operational - and the DNS configuration should
+ be as simple as the address autoconfiguration mechanism. It must
+ also be noted that there will be additional IP interfaces in some
+ near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific
+ DNS configuration mechanisms (such as PCO-IE [22]) do not work for
+ those IP interfaces. In other words, a good IPv6 DNS configuration
+ mechanism should also work in a multi-access network environment.
+
+ From 3GPP point of view, the best IPv6 DNS configuration solution
+ is feasible for a very large number of IPv6-capable UEs (can be
+ even hundreds of millions in one operator's network), is automatic
+ and thus requires no user action. It is suggested to standardize a
+ lightweight, stateless mechanism that works in all network
+ environments. The solution could then be used for 3GPP, 3GPP2,
+
+
+Jeong, et al. Expires - January 2005 [Page 15]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ WLAN and other access network technologies. A light, stateless
+ IPv6 DNS configuration mechanism is thus not only needed in 3GPP
+ networks, but also 3GPP networks and UEs would certainly benefit
+ from the new mechanism.
+
+5.3.2 RA Extension
+
+ Router Advertisement extension [8] is a lightweight IPv6 DNS
+ configuration mechanism that requires minor changes in 3GPP UE IPv6
+ stack and Gateway GPRS Support Node (GGSN, the default router in
+ the 3GPP architecture) IPv6 stack. This solution can be specified
+ in the IETF (no action needed in the 3GPP) and taken in use in 3GPP
+ UEs and GGSNs.
+
+ In this solution, an IPv6-capable UE configures DNS information
+ via RA message sent by its default router (GGSN), i.e., RDNSS
+ option for recursive DNS server is included in the RA message.
+ This solution is easily scalable for a very large number of UEs.
+ The operator can configure the RDNSS addresses in the GGSN as a
+ part of normal GGSN configuration. The IPv6 RDNSS address is
+ received in the Router Advertisement, and an extra Round Trip Time
+ (RTT) for asking RDNSS addresses can be avoided.
+
+ If thinking about cons, this mechanism still requires
+ standardization effort in the IETF, and the end nodes and routers
+ need to support this mechanism. The equipment software update
+ should, however, be pretty straightforward, and new IPv6 equipment
+ could support RA extension already from the beginning.
+
+5.3.3 Stateless DHCPv6
+
+ DHCPv6-based solution needs the implementation of Stateless DHCP
+ [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in
+ the operator's network. A possible configuration is such that the
+ GGSN works as a DHCP relay.
+
+ Pros for Stateless DHCPv6-based solution are
+ 1) Stateless DHCPv6 is a standardized mechanism.
+
+ 2) DHCPv6 can be used for receiving other configuration information
+ than RDNSS addresses, e.g., SIP server addresses.
+
+ 3) DHCPv6 works in different network environments.
+
+ 4) When DHCPv6 service is deployed through a single, centralized
+ server, the RDNSS configuration information can be updated by the
+ network administrator at a single source.
+
+
+
+Jeong, et al. Expires - January 2005 [Page 16]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ Some issues with DHCPv6 in 3GPP networks are listed below:
+ 1) DHCPv6 requires an additional server in the network unless the
+ (Stateless) DHCPv6 functionality is integrated into an existing
+ router already, and it is one box more to be maintained.
+
+ 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+ (3GPP Stateless Address Autoconfiguration is typically used), and
+ not automatically implemented in 3GPP IPv6 UEs.
+
+ 3) Scalability and reliability of DHCPv6 in very large 3GPP
+ networks (with tens or hundreds of millions of UEs) may be an issue,
+ at least the redundancy needs to be taken care of. However, if the
+ DHCPv6 service is integrated into the network elements, such as
+ router operating system, scalability and reliability is comparable
+ with other DNS configuration approaches.
+
+ 4) It is sub-optimal to utilize the radio resources in 3GPP
+ networks for DHCPv6 messages if there is a simpler alternative
+ available.
+
+ a) Use of Stateless DHCPv6 adds one round trip delay to the case
+ in which the UE can start transmitting data right after the
+ Router Advertisement.
+
+ 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can
+ not automatically update the UE, see [23].
+
+5.3.4 Well-known Addresses
+
+ Using well-known addresses is also a feasible and a light mechanism
+ for 3GPP UEs. Those well-known addresses can be preconfigured in
+ the UE software and the operator makes the corresponding
+ configuration on the network side. So this is a very easy
+ mechanism for the UE, but requires some configuration work in the
+ network. When using well-known addresses, UE forwards queries to
+ any of the preconfigured addresses. In the current proposal [9],
+ IPv6 anycast addresses are suggested.
+
+ Note: IPv6 DNS configuration proposal based on the use of well-
+ known site-local addresses developed at the IPv6 Working Group was
+ seen as a feasible mechanism for 3GPP UEs, but opposition by some
+ people in the IETF and finally deprecating IPv6 site-local
+ addresses made it impossible to standardize it. Note that this
+ mechanism is implemented in some existing operating systems today
+ (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration.
+
+5.3.5 Recommendations
+
+
+
+Jeong, et al. Expires - January 2005 [Page 17]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ It is suggested that a lightweight, stateless DNS configuration
+ mechanism is specified as soon as possible. From 3GPP UE's and
+ networks' point of view, Router Advertisement based mechanism looks
+ most promising. The sooner a light, stateless mechanism is
+ specified, the sooner we can get rid of using well-known site-local
+ addresses for IPv6 DNS configuration.
+
+5.4 Unmanaged Network
+
+ There are 4 deployment scenarios of interest in unmanaged networks
+ [24]:
+
+ 1) A gateway which does not provide IPv6 at all;
+
+ 2) A dual-stack gateway connected to a dual-stack ISP;
+
+ 3) A dual-stack gateway connected to an IPv4-only ISP; and
+
+ 4) A gateway connected to an IPv6-only ISP.
+
+5.4.1 Case A: Gateway does not provide IPv6 at all
+
+ In this case, the gateway does not provide IPv6; the ISP may or may
+ not provide IPv6. Automatic or Configured tunnels are the
+ recommended transition mechanisms for this scenario.
+
+ The case where dual-stack hosts behind an NAT, that need access to
+ an IPv6 RDNSS, can not be entirely ruled out. The DNS
+ configuration mechanism has to work over the tunnel, and the
+ underlying tunneling mechanism could be implementing NAT traversal.
+ The tunnel server assumes the role of a relay (both for DHCP and
+ Well-known anycast addresses approaches).
+
+ RA-based mechanism is relatively straightforward in its operation,
+ assuming the tunnel server is also the IPv6 router emitting RAs.
+ Well-known anycast addresses approach seems also simple in
+ operation across the tunnel, but the deployment model using Well-
+ known anycast addresses in a tunneled environment is unclear or not
+ well understood.
+
+5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP
+
+ This is similar to a typical IPv4 home user scenario, where DNS
+ configuration parameters are obtained using DHCP. Except that
+ Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
+ DHCP server is stateful (maintains the state for clients).
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 18]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP
+
+ This is similar to Case B. If a gateway provides IPv6 connectivity
+ by managing tunnels, then it is also supposed to provide access to
+ an RDNSS. Like this, the tunnel for IPv6 connectivity originates
+ from the dual-stack gateway instead of the host.
+
+5.4.4 Case D: A gateway connected to an IPv6-only ISP
+
+ This is similar to Case B.
+
+6. Security Considerations
+
+ As security requirements depend solely on applications and are
+ different application by application, there can be no generic
+ requirement defined at higher IP or lower application layer of DNS.
+
+ However, it should be noted that cryptographic security requires
+ configured secret information that full autoconfiguration and
+ cryptographic security are mutually exclusive. People insisting on
+ secure full autoconfiguration will get false security, false
+ autoconfiguration or both.
+
+ In some deployment scenario [19], where cryptographic security is
+ required for applications, secret information for the cryptographic
+ security is preconfigured through which application specific
+ configuration data, including those for DNS, can be securely
+ configured. It should be noted that if applications requiring
+ cryptographic security depend on DNS, the applications also require
+ cryptographic security to DNS. Therefore, the full auto-
+ configuration of DNS is not acceptable.
+
+ However, with full autoconfiguration, weaker but still reasonable
+ security is being widely accepted and will continue to be
+ acceptable. That is, with full autoconfiguration, which means
+ there is no cryptographic security for the autoconfiguration, it is
+ already assumed that local environment is secure enough that
+ information from local autoconfiguration server has acceptable
+ security even without cryptographic security. Thus, communication
+ between a local DNS client and a local DNS server has the
+ acceptable security.
+
+ For security considerations of each approach, refer to the
+ corresponding drafts [5]-[9].
+
+7. Acknowledgements
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 19]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ This draft has greatly benefited from inputs by David Meyer, Rob
+ Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
+ Christian Huitema, and Thomas Narten. The authors appreciate their
+ contribution.
+
+8. Normative References
+
+ [1] S. Bradner, "Intellectual Property Rights in IETF Technology",
+ RFC 3668, February 2004.
+
+ [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February
+ 2004.
+
+ [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for
+ IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+ [4] S. Thomson and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 3315, July 2003.
+
+ [6] R. Droms, "Stateless Dynamic Host Configuration Protocol
+ (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+ [7] R. Droms et al., "DNS Configuration options for Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
+ 2003.
+
+9. Informative References
+
+ [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS
+ Discovery based on Router Advertisement", draft-jeong-dnsop-
+ ipv6-dns-discovery-02.txt, July 2004.
+
+ [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta-
+ preconfigured-dns-01.txt, February 2004.
+
+ [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft-
+ ietf-dhc-lifetime-00.txt, March 2004.
+
+ [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting
+ Service", RFC 1546, November 1993.
+
+ [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
+ Addressing Architecture", RFC 3513, April 2003.
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 20]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
+ into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-
+ 02.txt, April 2004.
+
+ [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-
+ ietf-send-ndopt-05.txt, April 2004.
+
+ [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages",
+ RFC 3118, June 2001.
+
+ [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft-
+ ietf-v6ops-ent-scenarios-01.txt, February 2004.
+
+ [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host
+ Configuration Protocol (DHCP) version 6", RFC 3633, December
+ 2003.
+
+ [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP
+ Standards", RFC 3314, September 2002.
+
+ [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks",
+ RFC 3574, August 2003.
+
+ [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP
+ Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 2004.
+
+ [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
+ Service description; Stage 2 (Release 5)", December 2002.
+
+ [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+ specification; Core network protocols; Stage 3 (Release 5)",
+ June 2003.
+
+ [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering
+ Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless-
+ dhcpv6-renumbering-00.txt, March 2004.
+
+ [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition
+ Scenarios", RFC 3750, April 2004.
+
+10. Authors' Addresses
+
+ Jaehoon Paul Jeong, Editor
+ ETRI / PEC
+ 161 Gajeong-dong, Yuseong-gu
+ Daejeon 305-350
+ Korea
+
+
+
+Jeong, et al. Expires - January 2005 [Page 21]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ Phone: +82 42 860 1664
+ Fax: +82 42 861 5404
+ EMail: paul@etri.re.kr
+
+ Ralph Droms
+ Cisco Systems
+ 1414 Massachusetts Ave.
+ Boxboro, MA 01719
+ USA
+
+ Phone: +1 978 936 1674
+ EMail: rdroms@cisco.com
+
+ Robert M. Hinden
+ Nokia
+ 313 Fairchild Drive
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 625 2004
+ EMail: bob.hinden@nokia.com
+
+ Ted Lemon
+ Nominum, Inc.
+ 950 Charter Street
+ Redwood City, CA 94043
+ USA
+
+ EMail: Ted.Lemon@nominum.com
+
+ Masataka Ohta
+ Graduate School of Information Science and Engineering
+ Tokyo Institute of Technology
+ 2-12-1, O-okayama, Meguro-ku
+ Tokyo 152-8552
+ Japan
+
+ Phone: +81 3 5734 3299
+ Fax: +81 3 5734 3299
+ EMail: mohta@necom830.hpcl.titech.ac.jp
+
+ Soohong Daniel Park
+ Mobile Platform Laboratory, SAMSUNG Electronics
+ 416, Maetan-3dong, Paldal-gu, Suwon
+ Gyeonggi-Do
+ Korea
+
+ Phone: +82 31 200 4508
+
+
+Jeong, et al. Expires - January 2005 [Page 22]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ EMail: soohong.park@samsung.com
+
+ Suresh Satapati
+ Cisco Systems, Inc.
+ San Jose, CA 95134
+ USA
+
+ EMail: satapati@cisco.com
+
+ Juha Wiljakka
+ Nokia
+ Visiokatu 3
+ FIN-33720 TAMPERE
+ Finland
+
+ Phone: +358 7180 48372
+ EMail: juha.wiljakka@nokia.com
+
+Intellectual Property Statement
+
+ The following intellectual property notice is copied from RFC3668,
+ Section 5.
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology described
+ in this document or the extent to which any license under such
+ rights might or might not be available; nor does it represent that
+ it has made any independent effort to identify any such rights.
+ Information on the procedures with respect to rights in RFC
+ documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Full Copyright Statement
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 23]
+
+Internet-Draft IPv6 Host Configuration of DNS Server July 2004
+
+
+ The following copyright notice is copied from RFC3667, Section 5.4.
+ It describes the applicable copyright for this document.
+
+ Copyright (C) The Internet Society (2004). This document is
+ subject to the rights, licenses and restrictions contained in BCP
+ 78, and except as set forth therein, the authors retain all their
+ rights.
+
+ This document and the information contained herein are provided on
+ an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
+ THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
+ ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+ PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al. Expires - January 2005 [Page 24]
+
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
new file mode 100644
index 00000000000..b14f711d531
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt
@@ -0,0 +1,1969 @@
+
+
+DNS Operations WG A. Durand
+Internet-Draft SUN Microsystems, Inc.
+Expires: February 7, 2005 J. Ihren
+ Autonomica
+ P. Savola
+ CSC/FUNET
+ August 9, 2004
+
+
+
+ Operational Considerations and Issues with IPv6 DNS
+ draft-ietf-dnsop-ipv6-dns-issues-09.txt
+
+
+Status of this Memo
+
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+ This Internet-Draft will expire on February 7, 2005.
+
+
+Copyright Notice
+
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+
+Abstract
+
+
+ This memo presents operational considerations and issues with IPv6
+ Domain Name System (DNS), including a summary of special IPv6
+ addresses, documentation of known DNS implementation misbehaviour,
+ recommendations and considerations on how to perform DNS naming for
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 1]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ service provisioning and for DNS resolver IPv6 support,
+ considerations for DNS updates for both the forward and reverse
+ trees, and miscellaneous issues. This memo is aimed to include a
+ summary of information about IPv6 DNS considerations for those who
+ have experience with IPv4 DNS.
+
+
+Table of Contents
+
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4
+ 1.2 Independence of DNS Transport and DNS Records . . . . . . 4
+ 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
+ 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
+ 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
+ 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
+ 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
+ 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6
+ 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
+ 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
+ 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
+ 4. Recommendations for Service Provisioning using DNS . . . . . . 8
+ 4.1 Use of Service Names instead of Node Names . . . . . . . . 8
+ 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
+ 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9
+ 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
+ 4.4.1 Description of Additional Data Scenarios . . . . . . . 10
+ 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11
+ 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12
+ 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13
+ 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13
+ 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14
+ 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15
+ 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16
+ 6. Considerations about Forward DNS Updating . . . . . . . . . . 16
+ 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
+ 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17
+ 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18
+ 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18
+ 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19
+ 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19
+ 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20
+ 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21
+ 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22
+ 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22
+ 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . 22
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 2]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
+ 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
+ A. Site-local Addressing Considerations for DNS . . . . . . . . . 28
+ B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28
+ Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 3]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+1. Introduction
+
+
+ This memo presents operational considerations and issues with IPv6
+ DNS; it is meant to be an extensive summary and a list of pointers
+ for more information about IPv6 DNS considerations for those with
+ experience with IPv4 DNS.
+
+
+ The purpose of this document is to give information about various
+ issues and considerations related to DNS operations with IPv6; it is
+ not meant to be a normative specification or standard for IPv6 DNS.
+
+
+ The first section gives a brief overview of how IPv6 addresses and
+ names are represented in the DNS, how transport protocols and
+ resource records (don't) relate, and what IPv4/IPv6 name space
+ fragmentation means and how to avoid it; all of these are described
+ at more length in other documents.
+
+
+ The second section summarizes the special IPv6 address types and how
+ they relate to DNS. The third section describes observed DNS
+ implementation misbehaviours which have a varying effect on the use
+ of IPv6 records with DNS. The fourth section lists recommendations
+ and considerations for provisioning services with DNS. The fifth
+ section in turn looks at recommendations and considerations about
+ providing IPv6 support in the resolvers. The sixth and seventh
+ sections describe considerations with forward and reverse DNS
+ updates, respectively. The eighth section introduces several
+ miscellaneous IPv6 issues relating to DNS for which no better place
+ has been found in this memo. Appendix A looks briefly at the
+ requirements for site-local addressing.
+
+
+1.1 Representing IPv6 Addresses in DNS Records
+
+
+ In the forward zones, IPv6 addresses are represented using AAAA
+ records. In the reverse zones, IPv6 address are represented using
+ PTR records in the nibble format under the ip6.arpa. tree. See
+ [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
+ for background information.
+
+
+ In particular one should note that the use of A6 records in the
+ forward tree or Bitlabels in the reverse tree is not recommended
+ [RFC3363]. Using DNAME records is not recommended in the reverse
+ tree in conjunction with A6 records; the document did not mean to
+ take a stance on any other use of DNAME records [RFC3364].
+
+
+1.2 Independence of DNS Transport and DNS Records
+
+
+ DNS has been designed to present a single, globally unique name space
+ [RFC2826]. This property should be maintained, as described here and
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 4]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ in Section 1.3.
+
+
+ The IP version used to transport the DNS queries and responses is
+ independent of the records being queried: AAAA records can be queried
+ over IPv4, and A records over IPv6. The DNS servers must not make
+ any assumptions about what data to return for Answer and Authority
+ sections based on the underlying transport used in a query.
+
+
+ However, there is some debate whether the addresses in Additional
+ section could be selected or filtered using hints obtained from which
+ transport was being used; this has some obvious problems because in
+ many cases the transport protocol does not correlate with the
+ requests, and because a "bad" answer is in a way worse than no answer
+ at all (consider the case where the client is led to believe that a
+ name received in the additional record does not have any AAAA records
+ at all).
+
+
+ As stated in [RFC3596]:
+
+
+ The IP protocol version used for querying resource records is
+ independent of the protocol version of the resource records; e.g.,
+ IPv4 transport can be used to query IPv6 records and vice versa.
+
+
+
+1.3 Avoiding IPv4/IPv6 Name Space Fragmentation
+
+
+ To avoid the DNS name space from fragmenting into parts where some
+ parts of DNS are only visible using IPv4 (or IPv6) transport, the
+ recommendation is to always keep at least one authoritative server
+ IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
+ See DNS IPv6 transport guidelines
+ [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information.
+
+
+1.4 Query Type '*' and A/AAAA Records
+
+
+ QTYPE=* is typically only used for debugging or management purposes;
+ it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
+ any available RRsets, not *all* the RRsets, because the caches do not
+ necessarily have all the RRsets and have no way of guaranteeing that
+ they have all the RRsets. Therefore, to get both A and AAAA records
+ reliably, two separate queries must be made.
+
+
+2. DNS Considerations about Special IPv6 Addresses
+
+
+ There are a couple of IPv6 address types which are somewhat special;
+ these are considered here.
+
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 5]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+2.1 Limited-scope Addresses
+
+
+ The IPv6 addressing architecture [RFC3513] includes two kinds of
+ local-use addresses: link-local (fe80::/10) and site-local (fec0::/
+ 10). The site-local addresses have been deprecated
+ [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in
+ Appendix A.
+
+
+ Link-local addresses should never be published in DNS (whether in
+ forward or reverse tree), because they have only local (to the
+ connected link) significance
+ [I-D.ietf-dnsop-dontpublish-unreachable].
+
+
+2.2 Temporary Addresses
+
+
+ Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
+ "privacy addresses") use a random number as the interface identifier.
+ Publishing (useful) DNS records relating to such addresses would
+ defeat the purpose of the mechanism and is not recommended. However,
+ it would still be possible to return a non-identifiable name (e.g.,
+ the IPv6 address in hexadecimal format), as described in [RFC3041].
+
+
+2.3 6to4 Addresses
+
+
+ 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
+ a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
+
+
+ If the reverse DNS population would be desirable (see Section 7.1 for
+ applicability), there are a number of possible ways to do so
+ [I-D.moore-6to4-dns], some more applicable than the others.
+
+
+ The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
+ autonomous reverse-delegation system that anyone being capable of
+ communicating using a specific 6to4 address would be able to set up a
+ reverse delegation to the corresponding 6to4 prefix. This could be
+ deployed by e.g., Regional Internet Registries (RIRs). This is a
+ practical solution, but may have some scalability concerns.
+
+
+2.4 Other Transition Mechanisms
+
+
+ 6to4, above, is mentioned as a case of an IPv6 transition mechanism
+ requiring special considerations. In general, mechanisms which
+ include a special prefix may need a custom solution; otherwise, for
+ example when IPv4 address is embedded as the suffix or not embedded
+ at all, special solutions are likely not needed. This is why only
+ 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.
+
+
+ Note that it does not seem feasible to provide reverse DNS with
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 6]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ another automatic tunneling mechanism, Teredo; this is because the
+ IPv6 address is based on the IPv4 address and UDP port of the current
+ NAT mapping which is likely to be relatively short-lived.
+
+
+3. Observed DNS Implementation Misbehaviour
+
+
+ Several classes of misbehaviour in DNS servers, load-balancers and
+ resolvers have been observed. Most of these are rather generic, not
+ only applicable to IPv6 -- but in some cases, the consequences of
+ this misbehaviour are extremely severe in IPv6 environments and
+ deserve to be mentioned.
+
+
+3.1 Misbehaviour of DNS Servers and Load-balancers
+
+
+ There are several classes of misbehaviour in certain DNS servers and
+ load-balancers which have been noticed and documented
+ [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations
+ silently drop queries for unimplemented DNS records types, or provide
+ wrong answers to such queries (instead of a proper negative reply).
+ While typically these issues are not limited to AAAA records, the
+ problems are aggravated by the fact that AAAA records are being
+ queried instead of (mainly) A records.
+
+
+ The problems are serious because when looking up a DNS name, typical
+ getaddrinfo() implementations, with AF_UNSPEC hint given, first try
+ to query the AAAA records of the name, and after receiving a
+ response, query the A records. This is done in a serial fashion --
+ if the first query is never responded to (instead of properly
+ returning a negative answer), significant timeouts will occur.
+
+
+ In consequence, this is an enormous problem for IPv6 deployments, and
+ in some cases, IPv6 support in the software has even been disabled
+ due to these problems.
+
+
+ The solution is to fix or retire those misbehaving implementations,
+ but that is likely not going to be effective. There are some
+ possible ways to mitigate the problem, e.g., by performing the
+ lookups somewhat in parallel and reducing the timeout as long as at
+ least one answer has been received; but such methods remain to be
+ investigated; slightly more on this is included in Section 5.
+
+
+3.2 Misbehaviour of DNS Resolvers
+
+
+ Several classes of misbehaviour have also been noticed in DNS
+ resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem
+ to directly impair IPv6 use, and are only referred to for
+ completeness.
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 7]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+4. Recommendations for Service Provisioning using DNS
+
+
+ When names are added in the DNS to facilitate a service, there are
+ several general guidelines to consider to be able to do it as
+ smoothly as possible.
+
+
+4.1 Use of Service Names instead of Node Names
+
+
+ When a node provides multiple services which should not be
+ fate-sharing, or might support different IP versions, one should keep
+ them logically separate in the DNS. Using SRV records [RFC2782]
+ would avoid these problems. Unfortunately, those are not
+ sufficiently widely used to be applicable in most cases. Hence an
+ operation technique is to use service names instead of node names
+ (or, "hostnames"). This operational technique is not specific to
+ IPv6, but required to understand the considerations described in
+ Section 4.2 and Section 4.3.
+
+
+ For example, assume a node named "pobox.example.com" provides both
+ SMTP and IMAP service. Instead of configuring the MX records to
+ point at "pobox.example.com", and configuring the mail clients to
+ look up the mail via IMAP from "pobox.example.com", one should use
+ e.g., "smtp.example.com" for SMTP (for both message submission and
+ mail relaying between SMTP servers) and "imap.example.com" for IMAP.
+ Note that in the specific case of SMTP relaying, the server itself
+ must typically also be configured to know all its names to ensure
+ loops do not occur. DNS can provide a layer of indirection between
+ service names and where the service actually is, and using which
+ addresses. (Obviously, when wanting to reach a specific node, one
+ should use the hostname rather than a service name.)
+
+
+ This is a good practice with IPv4 as well, because it provides more
+ flexibility and enables easier migration of services from one host to
+ another. A specific reason why this is relevant for IPv6 is that the
+ different services may have a different level of IPv6 support -- that
+ is, one node providing multiple services might want to enable just
+ one service to be IPv6-visible while keeping some others as
+ IPv4-only, improving flexibility.
+
+
+4.2 Separate vs the Same Service Names for IPv4 and IPv6
+
+
+ The service naming can be achieved in basically two ways: when a
+ service is named "service.example.com" for IPv4, the IPv6-enabled
+ service could be either added to "service.example.com", or added
+ separately under a different name, e.g., in a sub-domain, like,
+ "service.ipv6.example.com".
+
+
+ These two methods have different characteristics. Using a different
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 8]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ name allows for easier service piloting, minimizing the disturbance
+ to the "regular" users of IPv4 service; however, the service would
+ not be used transparently, without the user/application explicitly
+ finding it and asking for it -- which would be a disadvantage in most
+ cases. When the different name is under a sub-domain, if the
+ services are deployed within a restricted network (e.g., inside an
+ enterprise), it's possible to prefer them transparently, at least to
+ a degree, by modifying the DNS search path; however, this is a
+ suboptimal solution. Using the same service name is the "long-term"
+ solution, but may degrade performance for those clients whose IPv6
+ performance is lower than IPv4, or does not work as well (see Section
+ 4.3 for more).
+
+
+ In most cases, it makes sense to pilot or test a service using
+ separate service names, and move to the use of the same name when
+ confident enough that the service level will not degrade for the
+ users unaware of IPv6.
+
+
+4.3 Adding the Records Only when Fully IPv6-enabled
+
+
+ The recommendation is that AAAA records for a service should not be
+ added to the DNS until all of following are true:
+
+
+ 1. The address is assigned to the interface on the node.
+
+
+ 2. The address is configured on the interface.
+
+
+ 3. The interface is on a link which is connected to the IPv6
+ infrastructure.
+
+
+ In addition, if the AAAA record is added for the node, instead of
+ service as recommended, all the services of the node should be
+ IPv6-enabled prior to adding the resource record.
+
+
+ For example, if an IPv6 node is isolated from an IPv6 perspective
+ (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
+ that it should not have an address in the DNS.
+
+
+ Consider the case of two dual-stack nodes, which both have IPv6
+ enabled, but the server does not have (global) IPv6 connectivity. As
+ the client looks up the server's name, only A records are returned
+ (if the recommendations above are followed), and no IPv6
+ communication, which would have been unsuccessful, is even attempted.
+
+
+ The issues are not always so black-and-white. Usually it's important
+ if the service offered using both protocols is of roughly equal
+ quality, using the appropriate metrics for the service (e.g.,
+ latency, throughput, low packet loss, general reliability, etc.) --
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 9]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ this is typically very important especially for interactive or
+ real-time services. In many cases, the quality of IPv6 connectivity
+ may not yet be equal to that of IPv4, at least globally -- this has
+ to be taken into consideration when enabling services
+ [I-D.savola-v6ops-6bone-mess].
+
+
+4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
+
+
+4.4.1 Description of Additional Data Scenarios
+
+
+ Consider the case where the query name is so long, the number of the
+ additional records is so high, or for other reasons that the entire
+ response would not fit in a single UDP packet. In some cases, the
+ responder truncates the response with the TC bit being set (leading
+ to a retry with TCP), in order for the querier to get the entire
+ response later.
+
+
+ There are two kinds of additional data:
+
+
+ 1. glue, i.e., "critical" additional data; this must be included in
+ all scenarios, with all the RRsets as possible, and
+
+
+ 2. "courtesy" additional data; this could be sent in full, with only
+ a few RRsets, or with no RRsets, and can be fetched separately as
+ well, but at the cost of additional queries. This data must
+ never cause setting of the TC bit.
+
+
+ The responding server can algorithmically determine which type the
+ additional data is by checking whether it's at or below a zone cut.
+
+
+ Meanwhile, resource record sets (RRsets) are never "broken up", so if
+ a name has 4 A records and 5 AAAA records, you can either return all
+ 9, all 4 A records, all 5 AAAA records or nothing. In particular,
+ notice that for the "critical" additional data getting all the RRsets
+ can be critical.
+
+
+ An example of the "courtesy" additional data is A/AAAA records in
+ conjunction of MX records as shown in Section 4.5; an example of the
+ "critical" additional data is shown below (where getting both the A
+ and AAAA RRsets is critical):
+
+
+ child.example.com. IN NS ns.child.example.com.
+ ns.child.example.com. IN A 192.0.2.1
+ ns.child.example.com. IN AAAA 2001:db8::1
+
+
+ When there is too much courtesy additional data, some or all of it
+ need to be removed [RFC2181]; if some is left in the response, the
+ issue is which data should be retained. When there is too much
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 10]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ critical additional data, TC bit will have to be set, and some or all
+ of it need to be removed; if some is left in the response, the issue
+ is which data should be retained.
+
+
+ If the implementation decides to keep as much data as possible, it
+ might be tempting to use the transport of the DNS query as a hint in
+ either of these cases: return the AAAA records if the query was done
+ over IPv6, or return the A records if the query was done over IPv4.
+ However, this breaks the model of independence of DNS transport and
+ resource records, as noted in Section 1.2.
+
+
+ It is worth remembering that often the host using the records is
+ different from the node requesting them from the authoritative DNS
+ server (or even a caching resolver). So, whichever version the
+ requestor (e.g., a recursive server in the middle) uses makes no
+ difference to the ultimate user of the records, whose transport
+ capabilities might differ from those of the requestor. This might
+ result in e.g., inappropriately returning A records to an IPv6-only
+ node, going through a translation, or opening up another IP-level
+ session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
+ Therefore, at least in many scenarios, it would be very useful if the
+ information returned would be consistent and complete -- or if that
+ is not feasible, return no misleading information but rather leave it
+ to the client to query again.
+
+
+4.4.2 Discussion of the Problems
+
+
+ As noted above, the temptation for omitting only some of the
+ additional data based on the transport of the query could be
+ problematic. In particular, there appears to be little justification
+ for doing so in the case of "courtesy" data.
+
+
+ However, with critical additional data, the alternatives are either
+ returning nothing (and requiring a retry with TCP) or returning
+ something (possibly obviating the need for a retry with TCP). If the
+ process for selecting "something" from the critical data would
+ otherwise be practically "flipping the coin" between A and AAAA
+ records, it could be argued that if one looked at the transport of
+ the query, it would have a larger possibility of being right than
+ just 50/50. In other words, if the returned critical additional data
+ would have to be selected somehow, using something more sophisticated
+ than a random process would seem justifiable.
+
+
+ The problem of too much additional data seems to be an operational
+ one: the zone administrator entering too many records which will be
+ returned either truncated or missing some RRsets to the users. A
+ protocol fix for this is using EDNS0 [RFC2671] to signal the capacity
+ for larger UDP packet sizes, pushing up the relevant threshold.
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 11]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ Further, DNS server implementations should rather omit courtesy
+ additional data completely rather than including only some RRsets
+ [RFC2181]. An operational fix for this is having the DNS server
+ implementations return a warning when the administrators create zones
+ which would result in too much additional data being returned.
+ Further, DNS server implementations should warn of or disallow such
+ zone configurations which are recursive or otherwise difficult to
+ manage by the protocol.
+
+
+ Additionally, to avoid the case where an application would not get an
+ address at all due to some of "courtesy" additional data being
+ omitted, the resolvers should be able to query the specific records
+ of the desired protocol, not just rely on getting all the required
+ RRsets in the additional section.
+
+
+4.5 The Use of TTL for IPv4 and IPv6 RRs
+
+
+ In the previous section, we discussed a danger with queries,
+ potentially leading to omitting RRsets from the additional section;
+ this could happen to both critical and "courtesy" additional data.
+ This section discusses another problem with the latter, leading to
+ omitting RRsets in cached data, highlighted in the IPv4/IPv6
+ environment.
+
+
+ The behaviour of DNS caching when different TTL values are used for
+ different RRsets of the same name requires explicit discussion. For
+ example, let's consider a part of a zone:
+
+
+ example.com. 300 IN MX foo.example.com.
+ foo.example.com. 300 IN A 192.0.2.1
+ foo.example.com. 100 IN AAAA 2001:db8::1
+
+
+ When a caching resolver asks for the MX record of example.com, it
+ gets back "foo.example.com". It may also get back either one or both
+ of the A and AAAA records in the additional section. So, there are
+ three cases about returning records for the MX in the additional
+ section:
+
+
+ 1. We get back no A or AAAA RRsets: this is the simplest case,
+ because then we have to query which information is required
+ explicitly, guaranteeing that we get all the information we're
+ interested in.
+
+
+ 2. We get back all the RRsets: this is an optimization as there is
+ no need to perform more queries, causing lower latency. However,
+ it is impossible to guarantee that in fact we would always get
+ back all the records (the only way to ensure that is to send a
+ AAAA query for the name after getting the cached reply with A
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 12]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ records or vice versa).
+
+
+ 3. We only get back A or AAAA RRsets even if both existed: this is
+ indistinguishable from the previous case, and may have problems
+ at least in certain environments as described in the previous
+ section.
+
+
+ As the third case was considered in the previous section, we assume
+ we get back both A and AAAA records of foo.example.com, or the stub
+ resolver explicitly asks, in two separate queries, both A and AAAA
+ records.
+
+
+ After 100 seconds, the AAAA record is removed from the cache(s)
+ because its TTL expired. It could be argued to be useful for the
+ caching resolvers to discard the A record when the shorter TTL (in
+ this case, for the AAAA record) expires; this would avoid the
+ situation where there would be a window of 200 seconds when
+ incomplete information is returned from the cache. The behaviour in
+ this scenario is unspecified.
+
+
+ To simplify the situation, it might help to use the same TTL for all
+ the resource record sets referring to the same name, unless there is
+ a particular reason for not doing so. However, there are some
+ scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
+ a different strategy is preferable.
+
+
+ Thus, applications that use the response should not rely on a
+ particular TTL configuration. For example, even if an application
+ gets a response that only has the A record in the example described
+ above, it should be still aware that there could be a AAAA record for
+ "foo.example.com". That is, the application should try to fetch the
+ missing records itself if it needs the record.
+
+
+4.6 IPv6 Transport Guidelines for DNS Servers
+
+
+ As described in Section 1.3 and
+ [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to
+ be at least one authoritative IPv4 DNS server for every zone, even if
+ the zone has only IPv6 records. (Note that obviously, having more
+ servers with robust connectivity would be preferable, but this is the
+ minimum recommendation; also see [RFC2182].)
+
+
+5. Recommendations for DNS Resolver IPv6 Support
+
+
+ When IPv6 is enabled on a node, there are several things to consider
+ to ensure that the process is as smooth as possible.
+
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 13]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+5.1 DNS Lookups May Query IPv6 Records Prematurely
+
+
+ The system library that implements the getaddrinfo() function for
+ looking up names is a critical piece when considering the robustness
+ of enabling IPv6; it may come in basically three flavours:
+
+
+ 1. The system library does not know whether IPv6 has been enabled in
+ the kernel of the operating system: it may start looking up AAAA
+ records with getaddrinfo() and AF_UNSPEC hint when the system is
+ upgraded to a system library version which supports IPv6.
+
+
+ 2. The system library might start to perform IPv6 queries with
+ getaddrinfo() only when IPv6 has been enabled in the kernel.
+ However, this does not guarantee that there exists any useful
+ IPv6 connectivity (e.g., the node could be isolated from the
+ other IPv6 networks, only having link-local addresses).
+
+
+ 3. The system library might implement a toggle which would apply
+ some heuristics to the "IPv6-readiness" of the node before
+ starting to perform queries; for example, it could check whether
+ only link-local IPv6 address(es) exists, or if at least one
+ global IPv6 address exists.
+
+
+ First, let us consider generic implications of unnecessary queries
+ for AAAA records: when looking up all the records in the DNS, AAAA
+ records are typically tried first, and then A records. These are
+ done in serial, and the A query is not performed until a response is
+ received to the AAAA query. Considering the misbehaviour of DNS
+ servers and load-balancers, as described in Section 3.1, the look-up
+ delay for AAAA may incur additional unnecessary latency, and
+ introduce a component of unreliability.
+
+
+ One option here could be to do the queries partially in parallel; for
+ example, if the final response to the AAAA query is not received in
+ 0.5 seconds, start performing the A query while waiting for the
+ result (immediate parallelism might be unoptimal, at least without
+ information sharing between the look-up threads, as that would
+ probably lead to duplicate non-cached delegation chain lookups).
+
+
+ An additional concern is the address selection, which may, in some
+ circumstances, prefer AAAA records over A records even when the node
+ does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
+ In some cases, the implementation may attempt to connect or send a
+ datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
+ incurring very long protocol timeouts, instead of quickly failing
+ back to IPv4.
+
+
+ Now, we can consider the issues specific to each of the three
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 14]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ possibilities:
+
+
+ In the first case, the node performs a number of completely useless
+ DNS lookups as it will not be able to use the returned AAAA records
+ anyway. (The only exception is where the application desires to know
+ what's in the DNS, but not use the result for communication.) One
+ should be able to disable these unnecessary queries, for both latency
+ and reliability reasons. However, as IPv6 has not been enabled, the
+ connections to IPv6 addresses fail immediately, and if the
+ application is programmed properly, the application can fall
+ gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].
+
+
+ The second case is similar to the first, except it happens to a
+ smaller set of nodes when IPv6 has been enabled but connectivity has
+ not been provided yet; similar considerations apply, with the
+ exception that IPv6 records, when returned, will be actually tried
+ first which may typically lead to long timeouts.
+
+
+ The third case is a bit more complex: optimizing away the DNS lookups
+ with only link-locals is probably safe (but may be desirable with
+ different lookup services which getaddrinfo() may support), as the
+ link-locals are typically automatically generated when IPv6 is
+ enabled, and do not indicate any form of IPv6 connectivity. That is,
+ performing DNS lookups only when a non-link-local address has been
+ configured on any interface could be beneficial -- this would be an
+ indication that either the address has been configured either from a
+ router advertisement, DHCPv6 [RFC3315], or manually. Each would
+ indicate at least some form of IPv6 connectivity, even though there
+ would not be guarantees of it.
+
+
+ These issues should be analyzed at more depth, and the fixes found
+ consensus on, perhaps in a separate document.
+
+
+5.2 Obtaining a List of DNS Recursive Resolvers
+
+
+ In scenarios where DHCPv6 is available, a host can discover a list of
+ DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
+ option [RFC3646]. This option can be passed to a host through a
+ subset of DHCPv6 [RFC3736].
+
+
+ The IETF is considering the development of alternative mechanisms for
+ obtaining the list of DNS recursive name servers when DHCPv6 is
+ unavailable or inappropriate. No decision about taking on this
+ development work has been reached as of this writing (Aug 2004)
+ [I-D.ietf-dnsop-ipv6-dns-configuration].
+
+
+ In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
+ under consideration for development include the use of well-known
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 15]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ addresses [I-D.ohta-preconfigured-dns] and the use of Router
+ Advertisements to convey the information
+ [I-D.jeong-dnsop-ipv6-dns-discovery].
+
+
+ Note that even though IPv6 DNS resolver discovery is a recommended
+ procedure, it is not required for dual-stack nodes in dual-stack
+ networks as IPv6 DNS records can be queried over IPv4 as well as
+ IPv6. Obviously, nodes which are meant to function without manual
+ configuration in IPv6-only networks must implement the DNS resolver
+ discovery function.
+
+
+5.3 IPv6 Transport Guidelines for Resolvers
+
+
+ As described in Section 1.3 and
+ [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers
+ should be IPv4-only or dual-stack to be able to reach any IPv4-only
+ DNS server. Note that this requirement is also fulfilled by an
+ IPv6-only stub resolver pointing to a dual-stack recursive DNS
+ resolver.
+
+
+6. Considerations about Forward DNS Updating
+
+
+ While the topic how to enable updating the forward DNS, i.e., the
+ mapping from names to the correct new addresses, is not specific to
+ IPv6, it should be considered especially due to the advent of
+ Stateless Address Autoconfiguration [RFC2462].
+
+
+ Typically forward DNS updates are more manageable than doing them in
+ the reverse DNS, because the updater can often be assumed to "own" a
+ certain DNS name -- and we can create a form of security relationship
+ with the DNS name and the node which is allowed to update it to point
+ to a new address.
+
+
+ A more complex form of DNS updates -- adding a whole new name into a
+ DNS zone, instead of updating an existing name -- is considered out
+ of scope for this memo as it could require zone-wide authentication.
+ Adding a new name in the forward zone is a problem which is still
+ being explored with IPv4, and IPv6 does not seem to add much new in
+ that area.
+
+
+6.1 Manual or Custom DNS Updates
+
+
+ The DNS mappings can also be maintained by hand, in a semi-automatic
+ fashion or by running non-standardized protocols. These are not
+ considered at more length in this memo.
+
+
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 16]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+6.2 Dynamic DNS
+
+
+ Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized
+ mechanism for dynamically updating the DNS. It works equally well
+ with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
+ address configuration. It is important to consider how each of these
+ behave if IP address-based authentication, instead of stronger
+ mechanisms [RFC3007], was used in the updates.
+
+
+ 1. manual addresses are static and can be configured
+
+
+ 2. DHCPv6 addresses could be reasonably static or dynamic, depending
+ on the deployment, and could or could not be configured on the
+ DNS server for the long term
+
+
+ 3. SLAAC addresses are typically stable for a long time, but could
+ require work to be configured and maintained.
+
+
+ As relying on IP addresses for Dynamic DNS is rather insecure at
+ best, stronger authentication should always be used; however, this
+ requires that the authorization keying will be explicitly configured
+ using unspecified operational methods.
+
+
+ Note that with DHCP it is also possible that the DHCP server updates
+ the DNS, not the host. The host might only indicate in the DHCP
+ exchange which hostname it would prefer, and the DHCP server would
+ make the appropriate updates. Nonetheless, while this makes setting
+ up a secure channel between the updater and the DNS server easier, it
+ does not help much with "content" security, i.e., whether the
+ hostname was acceptable -- if the DNS server does not include
+ policies, they must be included in the DHCP server (e.g., a regular
+ host should not be able to state that its name is "www.example.com").
+ DHCP-initiated DDNS updates have been extensively described in
+ [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
+ [I-D.ietf-dnsext-dhcid-rr].
+
+
+ The nodes must somehow be configured with the information about the
+ servers where they will attempt to update their addresses, sufficient
+ security material for authenticating themselves to the server, and
+ the hostname they will be updating. Unless otherwise configured, the
+ first could be obtained by looking up the authoritative name servers
+ for the hostname; the second must be configured explicitly unless one
+ chooses to trust the IP address-based authentication (not a good
+ idea); and lastly, the nodename is typically pre-configured somehow
+ on the node, e.g., at install time.
+
+
+ Care should be observed when updating the addresses not to use longer
+ TTLs for addresses than are preferred lifetimes for the addresses, so
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 17]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ that if the node is renumbered in a managed fashion, the amount of
+ stale DNS information is kept to the minimum. That is, if the
+ preferred lifetime of an address expires, the TTL of the record needs
+ be modified unless it was already done before the expiration. For
+ better flexibility, the DNS TTL should be much shorter (e.g., a half
+ or a third) than the lifetime of an address; that way, the node can
+ start lowering the DNS TTL if it seems like the address has not been
+ renewed/refreshed in a while. Some discussion on how an
+ administrator could manage the DNS TTL is included in
+ [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to
+ (smart) hosts as well.
+
+
+7. Considerations about Reverse DNS Updating
+
+
+ Updating the reverse DNS zone may be difficult because of the split
+ authority over an address. However, first we have to consider the
+ applicability of reverse DNS in the first place.
+
+
+7.1 Applicability of Reverse DNS
+
+
+ Today, some applications use reverse DNS to either look up some hints
+ about the topological information associated with an address (e.g.
+ resolving web server access logs), or as a weak form of a security
+ check, to get a feel whether the user's network administrator has
+ "authorized" the use of the address (on the premises that adding a
+ reverse record for an address would signal some form of
+ authorization).
+
+
+ One additional, maybe slightly more useful usage is ensuring that the
+ reverse and forward DNS contents match (by looking up the pointer to
+ the name by the IP address from the reverse tree, and ensuring that a
+ record under the name in the forward tree points to the IP address)
+ and correspond to a configured name or domain. As a security check,
+ it is typically accompanied by other mechanisms, such as a user/
+ password login; the main purpose of the reverse+forward DNS check is
+ to weed out the majority of unauthorized users, and if someone
+ managed to bypass the checks, he would still need to authenticate
+ "properly".
+
+
+ It may also be desirable to store IPsec keying material corresponding
+ to an IP address to the reverse DNS, as justified and described in
+ [I-D.ietf-ipseckey-rr].
+
+
+ It is not clear whether it makes sense to require or recommend that
+ reverse DNS records be updated. In many cases, it would just make
+ more sense to use proper mechanisms for security (or topological
+ information lookup) in the first place. At minimum, the applications
+ which use it as a generic authorization (in the sense that a record
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 18]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ exists at all) should be modified as soon as possible to avoid such
+ lookups completely.
+
+
+ The applicability is discussed at more length in
+ [I-D.ietf-dnsop-inaddr-required].
+
+
+7.2 Manual or Custom DNS Updates
+
+
+ Reverse DNS can of course be updated using manual or custom methods.
+ These are not further described here, except for one special case.
+
+
+ One way to deploy reverse DNS would be to use wildcard records, for
+ example, by configuring one name for a subnet (/64) or a site (/48).
+ As a concrete example, a site (or the site's ISP) could configure the
+ reverses of the prefix 2001:db8:f00::/48 to point to one name using a
+ wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
+ site.example.com." Naturally, such a name could not be verified from
+ the forward DNS, but would at least provide some form of "topological
+ information" or "weak authorization" if that is really considered to
+ be useful. Note that this is not actually updating the DNS as such,
+ as the whole point is to avoid DNS updates completely by manually
+ configuring a generic name.
+
+
+7.3 DDNS with Stateless Address Autoconfiguration
+
+
+ Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
+ some regard, while being more difficult in another, as described
+ below.
+
+
+ The address space administrator decides whether the hosts are trusted
+ to update their reverse DNS records or not. If they are, a simple
+ address-based authorization is typically sufficient (i.e., check that
+ the DNS update is done from the same IP address as the record being
+ updated); stronger security can also be used [RFC3007]. If they
+ aren't allowed to update the reverses, no update can occur. (Such
+ address-based update authorization operationally requires that
+ ingress filtering [RFC3704] has been set up at the border of the site
+ where the updates occur, and as close to the updater as possible.)
+
+
+ Address-based authorization is simpler with reverse DNS (as there is
+ a connection between the record and the address) than with forward
+ DNS. However, when a stronger form of security is used, forward DNS
+ updates are simpler to manage because the host can be assumed to have
+ an association with the domain. Note that the user may roam to
+ different networks, and does not necessarily have any association
+ with the owner of that address space -- so, assuming stronger form of
+ authorization for reverse DNS updates than an address association is
+ generally unfeasible.
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 19]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ Moreover, the reverse zones must be cleaned up by an unspecified
+ janitorial process: the node does not typically know a priori that it
+ will be disconnected, and cannot send a DNS update using the correct
+ source address to remove a record.
+
+
+ A problem with defining the clean-up process is that it is difficult
+ to ensure that a specific IP address and the corresponding record are
+ no longer being used. Considering the huge address space, and the
+ unlikelihood of collision within 64 bits of the interface
+ identifiers, a process which would remove the record after no traffic
+ has been seen from a node in a long period of time (e.g., a month or
+ year) might be one possible approach.
+
+
+ To insert or update the record, the node must discover the DNS server
+ to send the update to somehow, similar to as discussed in Section
+ 6.2. One way to automate this is looking up the DNS server
+ authoritative (e.g., through SOA record) for the IP address being
+ updated, but the security material (unless the IP address-based
+ authorization is trusted) must also be established by some other
+ means.
+
+
+ One should note that Cryptographically Generated Addresses
+ [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
+ treatment. CGAs are addresses where the interface identifier is
+ calculated from a public key, a modifier (used as a nonce), the
+ subnet prefix, and other data. Depending on the usage profile, CGAs
+ might or might not be changed periodically due to e.g., privacy
+ reasons. As the CGA address is not predicatable, a reverse record
+ can only reasonably be inserted in the DNS by the node which
+ generates the address.
+
+
+7.4 DDNS with DHCP
+
+
+ With DHCPv4, the reverse DNS name is typically already inserted to
+ the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
+ can assume similar practice may become commonplace with DHCPv6 as
+ well; all such mappings would be pre-configured, and would require no
+ updating.
+
+
+ If a more explicit control is required, similar considerations as
+ with SLAAC apply, except for the fact that typically one must update
+ a reverse DNS record instead of inserting one (if an address
+ assignment policy that reassigns disused addresses is adopted) and
+ updating a record seems like a slightly more difficult thing to
+ secure. However, it is yet uncertain how DHCPv6 is going to be used
+ for address assignment.
+
+
+ Note that when using DHCP, either the host or the DHCP server could
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 20]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ perform the DNS updates; see the implications in Section 6.2.
+
+
+ If disused addresses were to be reassigned, host-based DDNS reverse
+ updates would need policy considerations for DNS record modification,
+ as noted above. On the other hand, if disused address were not to be
+ assigned, host-based DNS reverse updates would have similar
+ considerations as SLAAC in Section 7.3. Server-based updates have
+ similar properties except that the janitorial process could be
+ integrated with DHCP address assignment.
+
+
+7.5 DDNS with Dynamic Prefix Delegation
+
+
+ In cases where a prefix, instead of an address, is being used and
+ updated, one should consider what is the location of the server where
+ DDNS updates are made. That is, where the DNS server is located:
+
+
+ 1. At the same organization as the prefix delegator.
+
+
+ 2. At the site where the prefixes are delegated to. In this case,
+ the authority of the DNS reverse zone corresponding to the
+ delegated prefix is also delegated to the site.
+
+
+ 3. Elsewhere; this implies a relationship between the site and where
+ DNS server is located, and such a relationship should be rather
+ straightforward to secure as well. Like in the previous case,
+ the authority of the DNS reverse zone is also delegated.
+
+
+ In the first case, managing the reverse DNS (delegation) is simpler
+ as the DNS server and the prefix delegator are in the same
+ administrative domain (as there is no need to delegate anything at
+ all); alternatively, the prefix delegator might forgo DDNS reverse
+ capability altogether, and use e.g., wildcard records (as described
+ in Section 7.2). In the other cases, it can be slighly more
+ difficult, particularly as the site will have to configure the DNS
+ server to be authoritative for the delegated reverse zone, implying
+ automatic configuration of the DNS server -- as the prefix may be
+ dynamic.
+
+
+ Managing the DDNS reverse updates is typically simple in the second
+ case, as the updated server is located at the local site, and
+ arguably IP address-based authentication could be sufficient (or if
+ not, setting up security relationships would be simpler). As there
+ is an explicit (security) relationship between the parties in the
+ third case, setting up the security relationships to allow reverse
+ DDNS updates should be rather straightforward as well (but IP
+ address-based authentication might not be acceptable). In the first
+ case, however, setting up and managing such relationships might be a
+ lot more difficult.
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 21]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+8. Miscellaneous DNS Considerations
+
+
+ This section describes miscellaneous considerations about DNS which
+ seem related to IPv6, for which no better place has been found in
+ this document.
+
+
+8.1 NAT-PT with DNS-ALG
+
+
+ The DNS-ALG component of NAT-PT mangles A records to look like AAAA
+ records to the IPv6-only nodes. Numerous problems have been
+ identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
+ This is a strong reason not to use NAT-PT in the first place.
+
+
+8.2 Renumbering Procedures and Applications' Use of DNS
+
+
+ One of the most difficult problems of systematic IP address
+ renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
+ an application which looks up a DNS name disregards information such
+ as TTL, and uses the result obtained from DNS as long as it happens
+ to be stored in the memory of the application. For applications
+ which run for a long time, this could be days, weeks or even months;
+ some applications may be clever enough to organize the data
+ structures and functions in such a manner that look-ups get refreshed
+ now and then.
+
+
+ While the issue appears to have a clear solution, "fix the
+ applications", practically this is not reasonable immediate advice;
+ the TTL information is not typically available in the APIs and
+ libraries (so, the advice becomes "fix the applications, APIs and
+ libraries"), and a lot more analysis is needed on how to practically
+ go about to achieve the ultimate goal of avoiding using the names
+ longer than expected.
+
+
+9. Acknowledgements
+
+
+ Some recommendations (Section 4.3, Section 5.1) about IPv6 service
+ provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
+ Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided
+ useful feedback and improvements. Scott Rose, Rob Austein, Masataka
+ Ohta, and Mark Andrews helped in clarifying the issues regarding
+ additional data and the use of TTL. Jefsey Morfin, Ralph Droms,
+ Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
+ Rob Austein provided useful feedback during the WG last call. Thomas
+ Narten provided extensive feedback during the IESG evaluation.
+
+
+10. Security Considerations
+
+
+ This document reviews the operational procedures for IPv6 DNS
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 22]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ operations and does not have security considerations in itself.
+
+
+ However, it is worth noting that in particular with Dynamic DNS
+ Updates, security models based on the source address validation are
+ very weak and cannot be recommended -- they could only be considered
+ in the environments where ingress filtering [RFC3704] has been
+ deployed. On the other hand, it should be noted that setting up an
+ authorization mechanism (e.g., a shared secret, or public-private
+ keys) between a node and the DNS server has to be done manually, and
+ may require quite a bit of time and expertise.
+
+
+ To re-emphasize which was already stated, the reverse+forward DNS
+ check provides very weak security at best, and the only
+ (questionable) security-related use for them may be in conjunction
+ with other mechanisms when authenticating a user.
+
+
+11. References
+
+
+11.1 Normative References
+
+
+ [I-D.ietf-dnsop-ipv6-dns-configuration]
+ Jeong, J., "IPv6 Host Configuration of DNS Server
+ Information Approaches",
+ draft-ietf-dnsop-ipv6-dns-configuration-02 (work in
+ progress), July 2004.
+
+
+ [I-D.ietf-dnsop-ipv6-transport-guidelines]
+ Durand, A. and J. Ihren, "DNS IPv6 transport operational
+ guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02
+ (work in progress), March 2004.
+
+
+ [I-D.ietf-dnsop-misbehavior-against-aaaa]
+ Morishita, Y. and T. Jinmei, "Common Misbehavior against
+ DNS Queries for IPv6 Addresses",
+ draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in
+ progress), April 2004.
+
+
+ [I-D.ietf-ipv6-deprecate-site-local]
+ Huitema, C. and B. Carpenter, "Deprecating Site Local
+ Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work
+ in progress), March 2004.
+
+
+ [I-D.ietf-v6ops-application-transition]
+ Shin, M., "Application Aspects of IPv6 Transition",
+ draft-ietf-v6ops-application-transition-03 (work in
+ progress), June 2004.
+
+
+ [I-D.ietf-v6ops-renumbering-procedure]
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 23]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ Baker, F., Lear, E. and R. Droms, "Procedures for
+ Renumbering an IPv6 Network without a Flag Day",
+ draft-ietf-v6ops-renumbering-procedure-01 (work in
+ progress), July 2004.
+
+
+ [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.
+
+
+ [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
+ and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+ July 1997.
+
+
+ [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+
+ [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
+ Stateless Address Autoconfiguration in IPv6", RFC 3041,
+ January 2001.
+
+
+ [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+ via IPv4 Clouds", RFC 3056, February 2001.
+
+
+ [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+ August 2001.
+
+
+ [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
+ M. Carney, "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 3315, July 2003.
+
+
+ [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T.
+ Hain, "Representing Internet Protocol version 6 (IPv6)
+ Addresses in the Domain Name System (DNS)", RFC 3363,
+ August 2002.
+
+
+ [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
+ Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+ August 2002.
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 24]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
+ (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
+ Extensions to Support IP Version 6", RFC 3596, October
+ 2003.
+
+
+ [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+ December 2003.
+
+
+ [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
+ (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+
+11.2 Informative References
+
+
+ [I-D.durand-v6ops-natpt-dns-alg-issues]
+ Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
+ draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
+ progress), February 2003.
+
+
+ [I-D.huitema-v6ops-teredo]
+ Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+ NATs", draft-huitema-v6ops-teredo-02 (work in progress),
+ June 2004.
+
+
+ [I-D.huston-6to4-reverse-dns]
+ Huston, G., "6to4 Reverse DNS",
+ draft-huston-6to4-reverse-dns-02 (work in progress), April
+ 2004.
+
+
+ [I-D.ietf-dhc-ddns-resolution]
+ Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
+ Clients", draft-ietf-dhc-ddns-resolution-07 (work in
+ progress), July 2004.
+
+
+ [I-D.ietf-dhc-fqdn-option]
+ Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
+ draft-ietf-dhc-fqdn-option-07 (work in progress), July
+ 2004.
+
+
+ [I-D.ietf-dnsext-dhcid-rr]
+ Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
+ encoding DHCP information (DHCID RR)",
+ draft-ietf-dnsext-dhcid-rr-08 (work in progress), July
+ 2004.
+
+
+ [I-D.ietf-dnsop-bad-dns-res]
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 25]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ Larson, M. and P. Barber, "Observed DNS Resolution
+ Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
+ progress), July 2004.
+
+
+ [I-D.ietf-dnsop-dontpublish-unreachable]
+ Hazel, P., "IP Addresses that should never appear in the
+ public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
+ (work in progress), February 2002.
+
+
+ [I-D.ietf-dnsop-inaddr-required]
+ Senie, D., "Requiring DNS IN-ADDR Mapping",
+ draft-ietf-dnsop-inaddr-required-05 (work in progress),
+ April 2004.
+
+
+ [I-D.ietf-ipseckey-rr]
+ Richardson, M., "A method for storing IPsec keying
+ material in DNS", draft-ietf-ipseckey-rr-11 (work in
+ progress), July 2004.
+
+
+ [I-D.ietf-ipv6-unique-local-addr]
+ Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
+ progress), June 2004.
+
+
+ [I-D.ietf-send-cga]
+ Aura, T., "Cryptographically Generated Addresses (CGA)",
+ draft-ietf-send-cga-06 (work in progress), April 2004.
+
+
+ [I-D.ietf-v6ops-3gpp-analysis]
+ Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
+ Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
+ progress), May 2004.
+
+
+ [I-D.ietf-v6ops-mech-v2]
+ Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+ for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04
+ (work in progress), July 2004.
+
+
+ [I-D.ietf-v6ops-onlinkassumption]
+ Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
+ On-Link Assumption Considered Harmful",
+ draft-ietf-v6ops-onlinkassumption-02 (work in progress),
+ May 2004.
+
+
+ [I-D.ietf-v6ops-v6onbydefault]
+ Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack
+ IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
+ (work in progress), July 2004.
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 26]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ [I-D.jeong-dnsop-ipv6-dns-discovery]
+ Jeong, J., "IPv6 DNS Discovery based on Router
+ Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
+ (work in progress), July 2004.
+
+
+ [I-D.moore-6to4-dns]
+ Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
+ in progress), October 2002.
+
+
+ [I-D.ohta-preconfigured-dns]
+ Ohta, M., "Preconfigured DNS Server Addresses",
+ draft-ohta-preconfigured-dns-01 (work in progress),
+ February 2004.
+
+
+ [I-D.savola-v6ops-6bone-mess]
+ Savola, P., "Moving from 6bone to IPv6 Internet",
+ draft-savola-v6ops-6bone-mess-01 (work in progress),
+ November 2002.
+
+
+ [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+ Translation - Protocol Translation (NAT-PT)", RFC 2766,
+ February 2000.
+
+
+ [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+
+ [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
+ Unique DNS Root", RFC 2826, May 2000.
+
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+ Networks", BCP 84, RFC 3704, March 2004.
+
+
+
+Authors' Addresses
+
+
+ Alain Durand
+ SUN Microsystems, Inc.
+ 17 Network circle UMPL17-202
+ Menlo Park, CA 94025
+ USA
+
+
+ EMail: Alain.Durand@sun.com
+
+
+
+
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 27]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ Johan Ihren
+ Autonomica
+ Bellmansgatan 30
+ SE-118 47 Stockholm
+ Sweden
+
+
+ EMail: johani@autonomica.se
+
+
+
+ Pekka Savola
+ CSC/FUNET
+ Espoo
+ Finland
+
+
+ EMail: psavola@funet.fi
+
+
+Appendix A. Site-local Addressing Considerations for DNS
+
+
+ As site-local addressing has been deprecated, the considerations for
+ site-local addressing are discussed briefly here. Unique local
+ addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
+ as a replacement, but being work-in-progress, it is not considered
+ further.
+
+
+ The interactions with DNS come in two flavors: forward and reverse
+ DNS.
+
+
+ To actually use site-local addresses within a site, this implies the
+ deployment of a "split-faced" or a fragmented DNS name space, for the
+ zones internal to the site, and the outsiders' view to it. The
+ procedures to achieve this are not elaborated here. The implication
+ is that site-local addresses must not be published in the public DNS.
+
+
+ To faciliate reverse DNS (if desired) with site-local addresses, the
+ stub resolvers must look for DNS information from the local DNS
+ servers, not e.g. starting from the root servers, so that the
+ site-local information may be provided locally. Note that the
+ experience of private addresses in IPv4 has shown that the root
+ servers get loaded for requests for private address lookups in any
+ case.
+
+
+Appendix B. Issues about Additional Data or TTL
+
+
+ [[ note to the RFC-editor: remove this section upon publication. ]]
+
+
+ This appendix tries to describe the apparent rought consensus about
+ additional data and TTL issues (sections 4.4 and 4.5), and present
+ questions when there appears to be no consensus. The point of
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 28]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+ recording them here is to focus the discussion and get feedback.
+
+
+ Resolved:
+
+
+ a. If some critical additional data RRsets wouldn't fit, you set the
+ TC bit even if some RRsets did fit.
+
+
+ b. If some courtesy additional data RRsets wouldn't fit, you never
+ set the TC bit, but rather remove (at least some of) the courtesy
+ RRsets.
+
+
+ c. DNS servers should implement sanity checks on the resulting glue,
+ e.g., to disable circular dependencies. Then the responding
+ servers can use at-or-below-a-zone-cut criterion to determine
+ whether the additional data is critical or not.
+
+
+ Open issues (at least):
+
+
+ 1. if some critical additional data RRsets would fit, but some
+ wouldn't, and TC has to be set (see above), should one rather
+ remove the additional data that did fit, keep it, or leave
+ unspecified?
+
+
+ 2. if some courtesy additional data RRsets would fit, but some
+ wouldn't, and some will have to be removed from the response (no
+ TC is set, see above), what to do -- remove all courtesy RRsets,
+ keep all that fit, or leave unspecified?
+
+
+ 3. is it acceptable to use the transport used in the DNS query as a
+ hint which records to keep if not removing all the RRsets, if: a)
+ having to decide which critical additional data to keep, or b)
+ having to decide which courtesy additional data to keep?
+
+
+ 4. (this issue was discussed in section 4.5) if one RRset has TTL of
+ 100 seconds, and another the TTL of 300 seconds, what should the
+ caching server do after 100 seconds? Keep returning just one
+ RRset when returning additional data, or discard the other RRset
+ from the cache?
+
+
+ 5. how do we move forward from here? If we manage to get to some
+ form of consensus, how do we record it: a) just in
+ draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational
+ category only!), b) a separate BCP or similar by DNSEXT WG(?),
+ clarifying and giving recommendations, c) something else, what?
+
+
+
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 29]
+Internet-Draft Considerations and Issues with IPv6 DNS August 2004
+
+
+
+Intellectual Property Statement
+
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Copyright Statement
+
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+Durand, et al. Expires February 7, 2005 [Page 30] \ No newline at end of file
diff --git a/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
new file mode 100644
index 00000000000..2311ee6c18a
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
@@ -0,0 +1,391 @@
+
+DNSOP G. Guette
+Internet-Draft IRISA / INRIA
+Expires: February 5, 2005 O. Courtay
+ Thomson R&D
+ August 7, 2004
+
+
+ Requirements for Automated Key Rollover in DNSSEC
+ draft-ietf-dnsop-key-rollover-requirements-01.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on February 5, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document describes problems that appear during an automated
+ rollover and gives the requirements for the design of communication
+ between parent zone and child zone in an automated rollover process.
+ This document is essentially about key rollover, the rollover of
+ another Resource Record present at delegation point (NS RR) is also
+ discussed.
+
+
+
+
+
+Guette & Courtay Expires February 5, 2005 [Page 1]
+
+Internet-Draft Automated Rollover Requirements August 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
+ 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Messages authentication and information exchanged . . . . . . 4
+ 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Other Resource Record concerned by automatic rollover . . . . 5
+ 7. Security consideration . . . . . . . . . . . . . . . . . . . . 5
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
+ 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
+ Intellectual Property and Copyright Statements . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guette & Courtay Expires February 5, 2005 [Page 2]
+
+Internet-Draft Automated Rollover Requirements August 2004
+
+
+1. Introduction
+
+ The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key
+ cryptography and digital signatures. It stores the public part of
+ keys in DNSKEY Resource Records (RRs). Because old keys and
+ frequently used keys are vulnerable, they must be renewed
+ periodically. In DNSSEC, this is the case for Zone Signing Keys
+ (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
+ rollover process is necessary for large zones because there are too
+ many changes to handle a manual administration.
+
+ Let us consider for example a zone with 100000 secure delegations.
+ If the child zones change their keys once a year on average, that
+ implies 300 changes per day for the parent zone. This amount of
+ changes are hard to manage manually.
+
+ Automated rollover is optional and resulting from an agreement
+ between the administrator of the parent zone and the administrator of
+ the child zone. Of course, key rollover can also be done manually by
+ administrators.
+
+ This document describes the requirements for the design of messages
+ of automated key rollover process and focusses on interaction between
+ parent and child zone.
+
+2. The Key Rollover Process
+
+ Key rollover consists in renewing the DNSSEC keys used to sign
+ resource records in a given DNS zone file. There are two types of
+ rollover, ZSK rollovers and KSK rollovers.
+
+ In a ZSK rollover, all changes are local to the zone that renews its
+ key: there is no need to contact other zones (e.g., parent zone) to
+ propagate the performed changes because a ZSK has no associated DS
+ record in the parent zone.
+
+ In a KSK rollover, new DS RR(s) must be created and stored in the
+ parent zone. In consequence, the child zone must contact its parent
+ zone and must notify it about the KSK change(s).
+
+ Manual key rollover exists and works [3]. The key rollover is built
+ from two parts of different nature:
+ o An algorithm that generates new keys and signs the zone file. It
+ could be local to the zone
+ o The interaction between parent and child zones
+
+ One example of manual key rollover is:
+
+
+
+
+Guette & Courtay Expires February 5, 2005 [Page 3]
+
+Internet-Draft Automated Rollover Requirements August 2004
+
+
+ o The child zone creates a new KSK
+ o The child zone waits for the creation of the DS RR in its parent
+ zone
+ o The child zone deletes the old key.
+
+ In manual rollover, communications are managed by the zone
+ administrators and the security of these communications is out of
+ scope of DNSSEC.
+
+ Automated key rollover should use a secure communication between
+ parent and child zones. This document concentrates on defining
+ interactions between entities present in key rollover process.
+
+3. Basic Requirements
+
+ The main constraint to respect during a key rollover is that the
+ chain of trust MUST be preserved, even if a resolver retrieves some
+ RRs from recursive cache server. Every RR MUST be verifiable at any
+ time, every RRs exchanged during the rollover should be authenticated
+ and their integrity should be guaranteed.
+
+ Two entities act during a KSK rollover: the child zone and its parent
+ zone. These zones are generally managed by different administrators.
+ These administrators should agree on some parameters like
+ availability of automated rollover, the maximum delay between
+ notification of changes in the child zone and the resigning of the
+ parent zone. The child zone needs to know this delay to schedule its
+ changes.
+
+4. Messages authentication and information exchanged
+
+ Every exchanged message MUST be authenticated and the authentication
+ tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC
+ request with verifiable SIG records.
+
+ Once the changes related to a KSK are made in a child zone, this zone
+ MUST notify its parent zone in order to create the new DS RR and
+ store this DS RR in parent zone file.
+
+ The parent zone MUST receive all the child keys that needs the
+ creation of associated DS RRs in the parent zone.
+
+ Some errors could occur during transmission between child zone and
+ parent zone. Key rollover solution MUST be fault tolerant, i.e. at
+ any time the rollover MUST be in a consistent state and all RRs MUST
+ be verifiable, even if an error occurs. That is to say that it MUST
+ remain a valid chain of trust.
+
+
+
+
+Guette & Courtay Expires February 5, 2005 [Page 4]
+
+Internet-Draft Automated Rollover Requirements August 2004
+
+
+5. Emergency Rollover
+
+ A key of a zone might be compromised and this key MUST be changed as
+ soon as possible. Fast changes could break the chain of trust. The
+ part of DNS tree having this zone as apex can become unverifiable,
+ but the break of the chain of trust is necessary if we want to no one
+ can use the compromised key to spoof DNS data.
+
+ In case of emergency rollover, the administrators of parent and child
+ zones should create new key(s) and DS RR(s) as fast as possible in
+ order to reduce the time the chain of trust is broken.
+
+6. Other Resource Record concerned by automatic rollover
+
+ NS records are also present at delegation point, so when the child
+ zone renews some NS RR, the corresponding records at delegation point
+ in parent zone (glue) MUST be updated. NS records are concerned by
+ rollover and this rollover could be automated too. In this case,
+ when the child zone notifies its parent zone that some NS records
+ have been changed, the parent zone MUST verify that these NS records
+ are present in child zone before doing any changes in its own zone
+ file. This allows to avoid inconsistency between NS records at
+ delegation point and NS records present in the child zone.
+
+7. Security consideration
+
+ This document describes requirements to design an automated key
+ rollover in DNSSEC based on DNSSEC security. In the same way, as
+ plain DNSSEC, the automatic key rollover contains no mechanism
+ protecting against denial of service (DoS). The security level
+ obtain after an automatic key rollover, is the security level
+ provided by DNSSEC.
+
+8. Acknowledgments
+
+ The authors want to acknowledge Francis Dupont, Mohsen Souissi,
+ Bernard Cousin, Bertrand L‰onard and members of IDsA project for
+ their contribution to this document.
+
+9 Normative References
+
+ [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+ RFC 3658, December 2003.
+
+ [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+ (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+ RFC 3757, May 2004.
+
+
+
+
+Guette & Courtay Expires February 5, 2005 [Page 5]
+
+Internet-Draft Automated Rollover Requirements August 2004
+
+
+ [3] Kolkman, O., "DNSSEC Operational Practices",
+ draft-ietf-dnsop-dnssec-operational-practice-01 (work in
+ progress), May 2004.
+
+ [4] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [5] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+ 2845, May 2000.
+
+ [7] Arends, R., "Resource Records for the DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-09 (work in progress), July
+ 2004.
+
+ [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
+ "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004.
+
+ [9] Arends, R., "Protocol Modifications for the DNS Security
+ Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in
+ progress), July 2004.
+
+
+Authors' Addresses
+
+ Gilles Guette
+ IRISA / INRIA
+ Campus de Beaulieu
+ 35042 Rennes CEDEX
+ FR
+
+ EMail: gilles.guette@irisa.fr
+ URI: http://www.irisa.fr
+
+
+ Olivier Courtay
+ Thomson R&D
+ 1, avenue Belle Fontaine
+ 35510 Cesson S‰vign‰ CEDEX
+ FR
+
+ EMail: olivier.courtay@thomson.net
+
+
+
+
+
+Guette & Courtay Expires February 5, 2005 [Page 6]
+
+Internet-Draft Automated Rollover Requirements August 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Guette & Courtay Expires February 5, 2005 [Page 7]
+
diff --git a/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt b/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt
new file mode 100644
index 00000000000..f6ece882103
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-respsize-01.txt
@@ -0,0 +1,485 @@
+ DNSOP Working Group Paul Vixie, ISC (Ed.)
+ INTERNET-DRAFT Akira Kato, WIDE
+ <draft-ietf-dnsop-respsize-01.txt> July, 2004
+
+
+ DNS Response Size Issues
+
+
+ Status of this Memo
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which we are aware have been or will be disclosed, and any of which
+ we become aware will be disclosed, in accordance with RFC 3668.
+
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+ Copyright Notice
+
+
+ Copyright (C) The Internet Society (2003-2004). All Rights Reserved.
+
+
+
+
+
+ Abstract
+
+
+ With a mandated default minimum maximum message size of 512 octets,
+ the DNS protocol presents some special problems for zones wishing to
+ expose a moderate or high number of authority servers (NS RRs). This
+ document explains the operational issues caused by, or related to
+ this response size limit.
+
+
+
+
+
+
+ Expires December 2004 [Page 1]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 1 - Introduction and Overview
+
+
+ 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
+ octets. Even though this limitation was due to the required minimum UDP
+ reassembly limit for IPv4, it is a hard DNS protocol limit and is not
+ implicitly relaxed by changes in transport, for example to IPv6.
+
+
+ 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
+ responses by mutual agreement of the requestor and responder. However,
+ deployment of EDNS0 cannot be expected to reach every Internet resolver
+ in the short or medium term. The 512 octet message size limit remains
+ in practical effect at this time.
+
+
+ 1.3. Since DNS responses include a copy of the request, the space
+ available for response data is somewhat less than the full 512 octets.
+ For negative responses, there is rarely a space constraint. For
+ positive and delegation responses, though, every octet must be carefully
+ and sparingly allocated. This document specifically addresses
+ delegation response sizes.
+
+
+ 2 - Delegation Details
+
+
+ 2.1. A delegation response will include the following elements:
+
+
+ Header Section: fixed length (12 octets)
+ Question Section: original query (name, class, type)
+ Answer Section: (empty)
+ Authority Section: NS RRset (nameserver names)
+ Additional Section: A and AAAA RRsets (nameserver addresses)
+
+
+ 2.2. If the total response size would exceed 512 octets, and if the data
+ that would not fit was in the question, answer, or authority section,
+ then the TC bit will be set (indicating truncation) which may cause the
+ requestor to retry using TCP, depending on what information was present
+ and what was omitted. If a retry using TCP is needed, the total cost of
+ the transaction is much higher.
+
+
+ 2.3. RRsets are never sent partially, so if truncation occurs, entire
+ RRsets are omitted. Note that the authority section consists of a
+ single RRset. It is absolutely essential that truncation not occur in
+ the authority section.
+
+
+
+
+
+
+
+
+ Expires December 2004 [Page 2]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 2.4. DNS label compression allows a domain name to be instantiated only
+ once per DNS message, and then referenced with a two-octet "pointer"
+ from other locations in that same DNS message. If all nameserver names
+ in a message are similar (for example, all ending in ".ROOT-
+ SERVERS.NET"), then more space will be available for uncompressable data
+ (such as nameserver addresses).
+
+
+ 2.5. The query name can be as long as 255 characters of presentation
+ data, which can be up to 256 octets of network data. In this worst case
+ scenario, the question section will be 260 octets in size, which would
+ leave only 240 octets for the authority and additional sections (after
+ deducting 12 octets for the fixed length header.)
+
+
+ 2.6. Average and maximum question section sizes can be predicted by the
+ zone owner, since they will know what names actually exist, and can
+ measure which ones are queried for most often. For cost and performance
+ reasons, the majority of requests should be satisfied without truncation
+ or TCP retry.
+
+
+ 2.7. Requestors who deliberately send large queries to force truncation
+ are only increasing their own costs, and cannot effectively attack the
+ resources of an authority server since the requestor would have to retry
+ using TCP to complete the attack. An attack that always used TCP would
+ have a lower cost.
+
+
+ 2.8. The minimum useful number of address records is two, since with
+ only one address, the probability that it would refer to an unreachable
+ server is too high. Truncation which occurs after two address records
+ have been added to the additional data section is therefore less
+ operationally significant than truncation which occurs earlier.
+
+
+ 2.9. The best case is no truncation. (This is because many requestors
+ will retry using TCP by reflex, without considering whether the omitted
+ data was actually necessary.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Expires December 2004 [Page 3]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 3 - Analysis
+
+
+ 3.1. An instrumented protocol trace of a best case delegation response
+ follows. Note that 13 servers are named, and 13 addresses are given.
+ This query was artificially designed to exactly reach the 512 octet
+ limit.
+
+
+ ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
+ ;; QUERY SECTION:
+ ;; [23456789.123456789.123456789.\
+ 123456789.123456789.123456789.com A IN] ;; @80
+
+
+ ;; AUTHORITY SECTION:
+ com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
+ com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
+ com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
+ com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
+ com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
+ com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
+ com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
+ com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
+ com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
+ com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
+ com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
+ com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
+ com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
+
+
+ ;; ADDITIONAL SECTION:
+ A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
+ B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
+ C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
+ D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
+ E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
+ F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
+ G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
+ H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
+ I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
+ J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
+ K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
+ L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
+ M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
+
+
+ ;; MSG SIZE sent: 80 rcvd: 512
+
+
+
+
+
+
+ Expires December 2004 [Page 4]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 3.2. For longer query names, the number of address records supplied will
+ be lower. Furthermore, it is only by using a common parent name (which
+ is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
+ fit. The following output from a response simulator demonstrates these
+ properties:
+
+
+ % perl respsize.pl 13 13 0
+ common name, average case: msg:303 nsaddr#13 (green)
+ common name, worst case: msg:495 nsaddr# 1 (red)
+ uncommon name, average case: msg:457 nsaddr# 3 (orange)
+ uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
+ % perl respsize.pl 13 13 2
+ common name, average case: msg:303 nsaddr#11 (orange)
+ common name, worst case: msg:495 nsaddr# 1 (red)
+ uncommon name, average case: msg:457 nsaddr# 2 (orange)
+ uncommon name, worst case: msg:649(*) nsaddr# 0 (red)
+
+
+ (Note: The response simulator program is shown in Section 5.)
+
+
+ Here we use the term "green" if all address records could fit, or
+ "orange" if two or more could fit, or "red" if fewer than two could fit.
+ It's clear that without a common parent for nameserver names, much space
+ would be lost.
+
+
+ We're assuming an average query name size of 64 since that is the
+ typical average maximum size seen in trace data at the time of this
+ writing. If Internationalized Domain Name (IDN) or any other technology
+ which results in larger query names be deployed significantly in advance
+ of EDNS, then more new measurements and new estimates will have to be
+ made.
+
+
+ 4 - Conclusions
+
+
+ 4.1. The current practice of giving all nameserver names a common parent
+ (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
+ responses and allows for more nameservers to be enumerated than would
+ otherwise be possible. (Note that in this case it is wise to serve the
+ common parent domain's zone from the same servers that are named within
+ it, in order to limit external dependencies when all your eggs are in a
+ single basket.)
+
+
+ 4.2. Thirteen (13) seems to be the effective maximum number of
+ nameserver names usable traditional (non-extended) DNS, assuming a
+ common parent domain name, and assuming that additional-data truncation
+ is undesirable in the average case.
+
+
+
+
+ Expires December 2004 [Page 5]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
+ prototypical delegation that currently contains thirteen (13) IPv4
+ nameserver addresses (A RRs) for thirteen (13) nameserver names under a
+ common parent, would not have a significant negative operational impact
+ on the domain name system.
+
+
+ 5 - Source Code
+
+
+ #!/usr/bin/perl -w
+
+
+ $asize = 2+2+2+4+2+4;
+ $aaaasize = 2+2+2+4+2+16;
+ ($nns, $na, $naaaa) = @ARGV;
+ test("common", "average", common_name_average($nns),
+ $na, $naaaa);
+ test("common", "worst", common_name_worst($nns),
+ $na, $naaaa);
+ test("uncommon", "average", uncommon_name_average($nns),
+ $na, $naaaa);
+ test("uncommon", "worst", uncommon_name_worst($nns),
+ $na, $naaaa);
+ exit 0;
+
+
+ sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_;
+ my $nglue = numglue($msg, $na, $naaaa);
+ printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n",
+ $namekind, $casekind,
+ $msg, ($msg > 512) ? "(*)" : " ",
+ $nglue, ($nglue == $na + $naaaa) ? "green"
+ : ($nglue >= 2) ? "orange"
+ : "red";
+ }
+
+
+ sub pnum { my ($num, $tot) = @_;
+ return sprintf "%3d%s",
+ }
+
+
+ sub numglue { my ($msg, $na, $naaaa) = @_;
+ my $space = ($msg > 512) ? 0 : (512 - $msg);
+ my $num = 0;
+
+
+ while ($space && ($na || $naaaa )) {
+ if ($na) {
+ if ($space >= $asize) {
+ $space -= $asize;
+
+
+
+
+ Expires December 2004 [Page 6]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ $num++;
+ }
+ $na--;
+ }
+ if ($naaaa) {
+ if ($space >= $aaaasize) {
+ $space -= $aaaasize;
+ $num++;
+ }
+ $naaaa--;
+ }
+ }
+ return $num;
+ }
+
+
+ sub msgsize { my ($qname, $nns, $nsns) = @_;
+ return 12 + # header
+ $qname+2+2 + # query
+ 0 + # answer
+ $nns * (4+2+2+4+2+$nsns); # authority
+ }
+
+
+ sub average_case { my ($nns, $nsns) = @_;
+ return msgsize(64, $nns, $nsns);
+ }
+
+
+ sub worst_case { my ($nns, $nsns) = @_;
+ return msgsize(256, $nns, $nsns);
+ }
+
+
+ sub common_name_average { my ($nns) = @_;
+ return 15 + average_case($nns, 2);
+ }
+
+
+ sub common_name_worst { my ($nns) = @_;
+ return 15 + worst_case($nns, 2);
+ }
+
+
+ sub uncommon_name_average { my ($nns) = @_;
+ return average_case($nns, 15);
+ }
+
+
+ sub uncommon_name_worst { my ($nns) = @_;
+ return worst_case($nns, 15);
+ }
+
+
+
+
+ Expires December 2004 [Page 7]
+ INTERNET-DRAFT June 2003 RESPSIZE
+
+
+
+ Security Considerations
+
+
+ The recommendations contained in this document have no known security
+ implications.
+
+
+ IANA Considerations
+
+
+ This document does not call for changes or additions to any IANA
+ registry.
+
+
+ IPR Statement
+
+
+ Copyright (C) The Internet Society (2003-2004). This document is
+ subject to the rights, licenses and restrictions contained in BCP 78,
+ and except as set forth therein, the authors retain all their rights.
+
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
+ IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+ Authors' Addresses
+
+
+ Paul Vixie
+ 950 Charter Street
+ Redwood City, CA 94063
+ +1 650 423 1301
+ vixie@isc.org
+
+
+ Akira Kato
+ University of Tokyo, Information Technology Center
+ 2-11-16 Yayoi Bunkyo
+ Tokyo 113-8658, JAPAN
+ +81 3 5841 2750
+ kato@wide.ad.jp
+
+
+
+
+
+
+
+
+
+
+ Expires December 2004 [Page 8] \ No newline at end of file
diff --git a/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt b/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt
new file mode 100644
index 00000000000..b593c57179e
--- /dev/null
+++ b/dist/bind/doc/draft/draft-ietf-dnsop-serverid-02.txt
@@ -0,0 +1,617 @@
+
+
+Network Working Group S. Woolf
+Internet-Draft Internet Systems Consortium, Inc.
+Expires: January 16, 2005 D. Conrad
+ Nominum, Inc.
+ July 18, 2004
+
+
+ Identifying an Authoritative Name `Server
+ draft-ietf-dnsop-serverid-02
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 16, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. A standardized mechanism to
+ determine the identity of a name server responding to a particular
+ query would be useful, particularly as a diagnostic aid. Existing ad
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 1]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+ hoc mechanisms for addressing this concern are not adequate. This
+ document attempts to describe the common ad hoc solution to this
+ problem, including its advantages and disadvantasges, and to
+ characterize an improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 2]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+1. Introduction
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. A standardized mechanism to
+ determine the identity of a name server responding to a particular
+ query would be useful, particularly as a diagnostic aid.
+
+ Unfortunately, existing ad-hoc mechanisms for providing such
+ identification have some shortcomings, not the least of which is the
+ lack of prior analysis of exactly how such a mechanism should be
+ designed and deployed. This document describes the existing
+ convention used in one widely deployed implementation of the DNS
+ protocol and discusses requirements for an improved solution to the
+ problem.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 3]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+2. Rationale
+
+ Identifying which name server is responding to queries is often
+ useful, particularly in attempting to diagnose name server
+ difficulties. However, relying on the IP address of the name server
+ has become more problematic due the deployment of various load
+ balancing solutions, including the use of shared unicast addresses as
+ documented in [RFC3258].
+
+ An unfortunate side effect of these load balancing solutions is that
+ traditional methods of determining which server is responding can be
+ unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
+ connections, or non-DNS UDP packets (e.g., as generated by tools such
+ as "traceroute"), etc., can end up going to a different server than
+ that which receives the DNS queries.
+
+ The widespread use of the existing convention suggests a need for a
+ documented, interoperable means of querying the identity of a
+ nameserver that may be part of an anycast or load-balancing cluster.
+ At the same time, however, it also has some drawbacks that argue
+ against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 4]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+3. Existing Conventions
+
+ Recent versions of the commonly deployed Berkeley Internet Name
+ Domain implementation of the DNS protocol suite from the Internet
+ Software Consortium [BIND] support a way of identifying a particular
+ server via the use of a standard, if somewhat unusual, DNS query.
+ Specifically, a query to a late model BIND server for a TXT resource
+ record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
+ return a string that can be configured by the name server
+ administrator to provide a unique identifier for the responding
+ server (defaulting to the value of a gethostname() call). This
+ mechanism, which is an extension of the BIND convention of using
+ CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
+ version information, has been copied by several name server vendors.
+
+ For reference, the other well-known name used by recent versions of
+ BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
+ query for a TXT RR for this name will return an administratively re-
+ definable string which defaults to the version of the server
+ responding.
+
+3.1 Advantages
+
+ There are several valuable attributes to this mechanism, which
+ account for its usefulness.
+ 1. This mechanism is within the DNS protocol itself. An
+ identification mechanism that relies on the DNS protocol is more
+ likely to be successful (although not guaranteed) in going to the
+ same machine as a "normal" DNS query.
+ 2. It is simple to configure. An administrator can easily turn on
+ this feature and control the results of the relevant query.
+ 3. It allows the administrator complete control of what information
+ is given out in the response, minimizing passive leakage of
+ implementation or configuration details. Such details are often
+ considered sensitive by infrastructure operators.
+
+3.2 Disadvantages
+
+ At the same time, there are some forbidding drawbacks to the
+ VERSION.BIND mechanism that argue against standardizing it as it
+ currently operates.
+ 1. It requires an additional query to correlate between the answer
+ to a DNS query under normal conditions and the supposed identity
+ of the server receiving the query. There are a number of
+ situations in which this simply isn't reliable.
+ 2. It reserves an entire class in the DNS (CHAOS) for what amounts
+ to one zone. While CHAOS class is defined in [RFC1034] and
+ [RFC1035], it's not clear that supporting it solely for this
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 5]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+ purpose is a good use of the namespace or of implementation
+ effort.
+ 3. It is implementation specific. BIND is one DNS implementation.
+ At the time of this writing, it is probably the most prevalent,
+ for authoritative servers anyway. This does not justify
+ standardizing on its ad hoc solution to a problem shared across
+ many operators and implementors.
+
+ The first of the listed disadvantages is technically the most
+ serious. It argues for an attempt to design a good answer to the
+ problem that "I need to know what nameserver is answering my
+ queries", not simply a convenient one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 6]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+4. Characteristics of an Implementation Neutral Convention
+
+ The discussion above of advantages and disadvantages to the
+ HOSTNAME.BIND mechanism suggest some requirements for a better
+ solution to the server identification problem. These are summarized
+ here as guidelines for any effort to provide appropriate protocol
+ extensions:
+ 1. The mechanism adopted MUST be in-band for the DNS protocol. That
+ is, it needs to allow the query for the server's identifying
+ information to be part of a normal, operational query. It SHOULD
+ also permit a separate, dedicated query for the server's
+ identifying information.
+ 2. The new mechanism should not require dedicated namespaces or
+ other reserved values outside of the existing protocol mechanisms
+ for these, i.e. the OPT pseudo-RR.
+ 3. Support for the identification functionality SHOULD be easy to
+ implement and easy to enable. It MUST be easy to disable and
+ SHOULD lend itself to access controls on who can query for it.
+ 4. It should be possible to return a unique identifier for a server
+ without requiring the exposure of information that may be
+ non-public and considered sensitive by the operator, such as a
+ hostname or unicast IP address maintained for administrative
+ purposes.
+ 5. The identification mechanism SHOULD NOT be
+ implementation-specific.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 7]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+5. IANA Considerations
+
+ This document proposes no specific IANA action. Protocol extensions,
+ if any, to meet the requirements described are out of scope for this
+ document. Should such extensions be specified and adopted by normal
+ IETF process, the specification will include appropriate guidance to
+ IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 8]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+6. Security Considerations
+
+ Providing identifying information as to which server is responding
+ can be seen as information leakage and thus a security risk. This
+ motivates the suggestion above that a new mechanism for server
+ identification allow the administrator to disable the functionality
+ altogether or partially restrict availability of the data. It also
+ suggests that the serverid data should not be readily correlated with
+ a hostname or unicast IP address that may be considered private to
+ the nameserver operator's management infrastructure.
+
+ Propagation of protocol or service meta-data can sometimes expose the
+ application to denial of service or other attack. As DNS is a
+ critically important infrastructure service for the production
+ Internet, extra care needs to be taken against this risk for
+ designers, implementors, and operators of a new mechanism for server
+ identification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 9]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+7. Acknowledgements
+
+ The technique for host identification documented here was initially
+ implemented by Paul Vixie of the Internet Software Consortium in the
+ Berkeley Internet Name Daemon package. Comments and questions on
+ earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+ Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+ ICANN Root Server System Advisory Committee. The newest draft takes
+ a significantly different direction from previous versions, owing to
+ discussion among contributors to the DNSOP working group and others,
+ particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler,
+ and Rob Austein.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 10]
+
+Internet-Draft Identifying an Authoritative Name `Server July 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Woolf & Conrad Expires January 16, 2005 [Page 11]
+
+
diff --git a/dist/bind/doc/draft/update b/dist/bind/doc/draft/update
index 766f15b08e6..6ac20904ab2 100644
--- a/dist/bind/doc/draft/update
+++ b/dist/bind/doc/draft/update
@@ -1,4 +1,5 @@
#!/bin/sh
+commit=
for i
do
z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
@@ -34,9 +35,12 @@ do
then
rm $old
cvs delete $old
- else
- old=
+ commit="$commit $old"
fi
- cvs commit -m "new draft" $i $old
+ commit="$commit $i"
fi
done
+if test -n "$commit"
+then
+ cvs commit -m "new draft" $commit
+fi