diff --git a/config.threads.in b/config.threads.in new file mode 100644 index 0000000000..f2816c447f --- /dev/null +++ b/config.threads.in @@ -0,0 +1,152 @@ +# +# Begin pthreads checking. +# +# First, decide whether to use multithreading or not. +# +# Enable multithreading by default on systems where it is known +# to work well, and where debugging of multithreaded programs +# is supported. +# + +AC_MSG_CHECKING(whether to build with thread support) + +case $host in +*-dec-osf*) + use_threads=true ;; +[*-solaris2.[0-6]]) + # Thread signals are broken on Solaris 2.6; they are sometimes + # delivered to the wrong thread. + use_threads=false ;; +*-solaris*) + use_threads=true ;; +*-ibm-aix*) + use_threads=true ;; +*-hp-hpux10*) + use_threads=false ;; +*-hp-hpux11*) + use_threads=true ;; +*-sgi-irix*) + use_threads=true ;; +*-sco-sysv*uw*|*-*-sysv*UnixWare*) + # UnixWare + use_threads=false ;; +*-*-sysv*OpenUNIX*) + # UnixWare + use_threads=true ;; +*-netbsd*) + if test -r /usr/lib/libpthread.so ; then + use_threads=true + else + # Socket I/O optimizations introduced in 9.2 expose a + # bug in unproven-pthreads; see PR #12650 + use_threads=false + fi + ;; +*-openbsd*) + # OpenBSD users have reported that named dumps core on + # startup when built with threads. + use_threads=false ;; +*-freebsd*) + use_threads=false ;; +*-bsdi[234]*) + # Thread signals do not work reliably on some versions of BSD/OS. + use_threads=false ;; +*-bsdi5*) + use_threads=true ;; +*-linux*) + # Threads are disabled on Linux by default because most + # Linux kernels produce unusable core dumps from multithreaded + # programs, and because of limitations in setuid(). + use_threads=false ;; +*) + use_threads=false ;; +esac + +AC_ARG_ENABLE(threads, + [ --enable-threads enable multithreading]) +case "$enable_threads" in + yes) + use_threads=true + ;; + no) + use_threads=false + ;; + '') + # Use system-dependent default + ;; + *) + AC_MSG_ERROR([--enable-threads takes yes or no]) + ;; +esac + +if $use_threads +then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi + +if $use_threads +then + # + # Search for / configure pthreads in a system-dependent fashion. + # + case "$host" in + *-netbsd*) + # NetBSD has multiple pthreads implementations. The + # recommended one to use is "unproven-pthreads". The + # older "mit-pthreads" may also work on some NetBSD + # versions. The PTL2 thread library does not + # currently work with bind9, but can be chosen with + # the --with-ptl2 option for those who wish to + # experiment with it. + CC="gcc" + AC_MSG_CHECKING(which NetBSD thread library to use) + + AC_ARG_WITH(ptl2, +[ --with-ptl2 on NetBSD, use the ptl2 thread library (experimental)], + use_ptl2="$withval", use_ptl2="no") + + : ${LOCALBASE:=/usr/pkg} + + if test "X$use_ptl2" = "Xyes" + then + AC_MSG_RESULT(PTL2) + AC_MSG_WARN( +[linking with PTL2 is highly experimental and not expected to work]) + CC=ptlgcc + else + if test -r /usr/lib/libpthread.so + then + AC_MSG_RESULT(native) + LIBS="-lpthread $LIBS" + else + if test ! -d $LOCALBASE/pthreads + then + AC_MSG_RESULT(none) + AC_MSG_ERROR("could not find thread libraries") + fi + + if $use_threads + then + AC_MSG_RESULT(mit-pthreads/unproven-pthreads) + pkg="$LOCALBASE/pthreads" + lib1="-L$pkg/lib -Wl,-R$pkg/lib" + lib2="-lpthread -lm -lgcc -lpthread" + LIBS="$lib1 $lib2 $LIBS" + CPPFLAGS="$CPPFLAGS -I$pkg/include" + STD_CINCLUDES="$STD_CINCLUDES -I$pkg/include" + fi + fi + fi + ;; + *) + AC_CHECK_LIB(pthread, pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create,, + AC_CHECK_LIB(pthread, __pthread_create_system,, + AC_CHECK_LIB(c_r, pthread_create,, + AC_CHECK_LIB(c, pthread_create,, + AC_MSG_ERROR("could not find thread libraries")))))) + ;; + esac +fi diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt new file mode 100644 index 0000000000..2cd972473d --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt @@ -0,0 +1,562 @@ + + + + +DNSEXT M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: August 13, 2005 T. Lemon + A. Gustafsson + Nominum, Inc. + February 9, 2005 + + + A DNS RR for Encoding DHCP Information (DHCID RR) + + +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 August 13, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +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] + + + +Stapp, et al. Expires August 13, 2005 [Page 1] + +Internet-Draft The DHCID RR February 2005 + + + proposes storing client identifiers in the DNS to unambiguously + 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 August 13, 2005 [Page 2] + +Internet-Draft The DHCID RR February 2005 + + +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 August 13, 2005 [Page 3] + +Internet-Draft The DHCID RR February 2005 + + +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 August 13, 2005 [Page 4] + +Internet-Draft The DHCID RR February 2005 + + + 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 August 13, 2005 [Page 5] + +Internet-Draft The DHCID RR February 2005 + + +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 August 13, 2005 [Page 6] + +Internet-Draft The DHCID RR February 2005 + + + 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 August 13, 2005 [Page 7] + +Internet-Draft The DHCID RR February 2005 + + +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 August 13, 2005 [Page 8] + +Internet-Draft The DHCID RR February 2005 + + +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 August 13, 2005 [Page 9] + +Internet-Draft The DHCID RR February 2005 + + +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 (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Stapp, et al. Expires August 13, 2005 [Page 10] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt new file mode 100644 index 0000000000..6c897b92b1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt @@ -0,0 +1,841 @@ + + +Network Working Group D. Blacka +Internet-Draft Verisign, Inc. +Expires: August 3, 2005 February 2, 2005 + + + DNSSEC Experiments + draft-ietf-dnsext-dnssec-experiments-00 + +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 August 3, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the long history of the development of the DNS security [1] + extensions (DNSSEC), a number of alternate methodologies and + modifications have been proposed and rejected for practical, rather + than strictly technical, reasons. There is a desire to be able to + experiment with these alternate methods in the public DNS. This + document describes a methodology for deploying alternate, + non-backwards-compatible, DNSSEC methodologies in an experimental + fashion without disrupting the deployment of standard DNSSEC. + + + +Blacka Expires August 3, 2005 [Page 1] + +Internet-Draft DNSSEC Experiments February 2005 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . 14 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 2] + +Internet-Draft DNSSEC Experiments February 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [4]) and the DNS security extensions ([1], [2], and [3]. + + The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 3] + +Internet-Draft DNSSEC Experiments February 2005 + + +2. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC, and to try + these changes on real zones in the public DNS. This creates a + problem when the change to DNSSEC would make all or part of the zone + using those changes appear bogus or otherwise broken to existing + DNSSEC-aware resolvers. + + This document describes a standard methodology for setting up public + DNSSEC experiments. This methodology addresses the issue of + co-existence with standard DNSSEC and DNS by using unknown algorithm + identifiers to hide the experimental DNSSEC protocol modifications + from standard DNSSEC-aware resolvers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 4] + +Internet-Draft DNSSEC Experiments February 2005 + + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and server that do implement the DNSSEC + standard. + Non-Backwards-Compatible: describes experiments that would cause a + standard DNSSEC-aware resolver to (incorrectly) determine that all + or part of a zone is bogus, or to otherwise not interoperable with + standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly could be used + if desired. + + Note that, in essence, this metholodolgy would also be used to + introduce a new DNSSEC algorithm, independently from any DNSSEC + experimental protocol change. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 5] + +Internet-Draft DNSSEC Experiments February 2005 + + +4. Method + + The core of the methodology is the use of only "unknown" algorithms + to sign the experimental zone, and more importantly, having only + unknown algorithm DS records for the delegation to the zone at the + parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithms. From [3], Section 5.2: + + 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. + + And further: + + 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. + + While this behavior isn't strictly mandatory (as marked by MUST), it + is unlikely that a validator would not implement the behavior, or, + more to the point, it will not violate this behavior in an unsafe way + (see below (Section 6).) + + Because we are talking about experiments, it is recommended that + private algorithm numbers be used (see [2], appendix A.1.1 + [Comment.1].) Normally, instead of actually inventing new signing + algorithms, the recommended path is to create alternate algorithm + identifiers that are aliases for the existing, known algorithms. + While, strictly speaking, it is only necessary to create an alternate + identifier for the mandatory algorithms (currently, this is only + algorithm 5, RSASHA1), it is RECOMMENDED that all OPTIONAL defined + algorithms be aliased as well. + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and + "5.dnssec-experiment-a.example.com". However, any unique identifier + will suffice. + + + +Blacka Expires August 3, 2005 [Page 6] + +Internet-Draft DNSSEC Experiments February 2005 + + + Using this method, resolvers (or, more specificially, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of DNSSEC-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiments algorithm identifiers and + experimental semantics), and servers and resolvers that are unware of + the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 7] + +Internet-Draft DNSSEC Experiments February 2005 + + +5. Defining an Experiment + + The DNSSEC experiment must define the particular set of (previously + unknown) algorithms that identify the experiment, and define what + each unknown algorithm identifier means. Typically, unless the + experiment is actually experimenting with a new DNSSEC algorithm, + this will be a mapping of private algorithm identifiers to existing, + known algorithms. + + Typically, the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + OID private algorithm space instead (using algorithm number 254), or + may choose non-private algorithm numbers, although this would require + an IANA allocation (see below (Section 9).) + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and provide + the mapping of "3.dnssec-experiment-a.example.com" is an alias of + DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is + an alias of DNSSEC algorithm 5 (RSASHA1). + + Resolvers MUST then only recognize the experiment's semantics when + present in a zone signed by one or more of these private algorithms. + + In general, however, resolvers involved in the experiment are + expected to understand both standard DNSSEC and the defined + experimental DNSSEC protocol, although this isn't, strictly speaking, + required. + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 8] + +Internet-Draft DNSSEC Experiments February 2005 + + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. Under some circumstances, it may be that the experiment will not + be sufficiently masked by this technique and may cause resolution + problem for resolvers not aware of the experiment. For instance, + the resolver may look at the not validatable response and + conclude that the response is bogus, either due to local policy + or implementation details. This is not expected to be the common + case, however. + 2. It will, in general, not be possible for DNSSEC-aware resolvers + not aware of the experiment to build a chain of trust through an + experimental zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 9] + +Internet-Draft DNSSEC Experiments February 2005 + + +7. Transitions + + If an experiment is successful, there may be a desire to move the + experiment to a standards-track extension. One way to do so would be + to move from private algorithm numbers to IANA allocated algorithm + numbers, with otherwise the same meaning. This would still leave a + divide between resolvers that understood the extension versus + resolvers that did not. It would, in essence, create an additional + version of DNSSEC. + + An alternate technique might be to do a typecode rollover, thus + actually creating a definitive new version of DNSSEC. There may be + other transition techniques available, as well. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 10] + +Internet-Draft DNSSEC Experiments February 2005 + + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 11] + +Internet-Draft DNSSEC Experiments February 2005 + + +9. IANA Considerations + + IANA may need to allocate new DNSSEC algorithm numbers if that + transition approach is taken, or the experiment decides to use + allocated numbers to begin with. No IANA action is required to + deploy an experiment using private algorithm identifiers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 12] + +Internet-Draft DNSSEC Experiments February 2005 + + +10. References + +10.1 Normative References + + [1] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [2] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [3] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in + progress), October 2004. + +10.2 Informative References + + [4] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 13] + +Internet-Draft DNSSEC Experiments February 2005 + + +Editorial Comments + + [Comment.1] Note: how private algorithms work in DNSSEC is not well + explained in the DNSSECbis RFCs. In particular, how to + validate that the DS records contain only unknown + algorithms is not explained at all. + + +Author's Address + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 14] + +Internet-Draft DNSSEC Experiments February 2005 + + +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 (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Blacka Expires August 3, 2005 [Page 15] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt new file mode 100644 index 0000000000..c4103183d5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt @@ -0,0 +1,1177 @@ + + +DNSEXT R. Arends +Internet-Draft Telematica Instituut +Expires: August 4, 2005 M. Kosters + D. Blacka + Verisign, Inc. + February 3, 2005 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-06 + +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 August 4, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the DNS security extensions (DNSSEC, defined in RFC 2535bis, [3], + [4], and [5]), delegations to unsigned subzones are cryptographically + secured. Maintaining this cryptography is not practical or + necessary. This document describes an experimental "Opt-In" model + that allows administrators to omit this cryptography and manage the + + + +Arends, et al. Expires August 4, 2005 [Page 1] + +Internet-Draft DNSSEC Opt-In February 2005 + + + cost of adopting DNSSEC with large zones. + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 5 + 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 7 + 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7 + 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 7 + 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 7 + 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 8 + 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 8 + 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 8 + 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 8 + 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 9 + 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 9 + 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . 21 + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 2] + +Internet-Draft DNSSEC Opt-In February 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [1]), DNS security extensions ([3], [4], and [5], referred to in this + document as "RFC 2535bis"), and DNSSEC terminology (RFC 3090 [10]) is + assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + RRset: refers to a Resource Record Set, as defined by [8]. In this + document, the RRset is also defined to include the covering RRSIG + records, if any exist. + signed name: refers to a DNS name that has, at minimum, a (signed) + NSEC record. + unsigned name: refers to a DNS name that does not (at least) have a + NSEC record. + covering NSEC record/RRset: is the NSEC record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NSEC record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + delegation: refers to a NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + insecure delegation: refers to a signed name containing a delegation + (NS RRset), but lacking a DS RRset, signifying a delegation to an + unsigned subzone. + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NSEC record uses the + Opt-In methodology described in this document. + + 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 [7]. + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 3] + +Internet-Draft DNSSEC Opt-In February 2005 + + +2. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NSEC record chain may be extremely high relative to + the gain of cryptographically authenticating existence of unsecured + zones. + + This document describes an experimental method of eliminating the + superfluous cryptography present in secure delegations to unsigned + zones. Using "Opt-In", a zone administrator can choose to remove + insecure delegations from the NSEC chain. This is accomplished by + extending the semantics of the NSEC record by using a redundant bit + in the type map. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 4] + +Internet-Draft DNSSEC Opt-In February 2005 + + +3. Experimental Status + + This document describes an EXPERIMENTAL extension to DNSSEC. It + interoperates with non-experimental DNSSEC using the technique + described in [6]. This experiment is identified with the following + private algorithms (using algorithm 253): + + "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, + and + "4.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, + RSASHA1. + + Servers wishing to sign and serve zones that utilize Opt-In MUST sign + the zone with one or more of these private algorithms. This requires + the signing tools and servers to support private algorithms, as well + as Opt-In. + + Resolvers wishing to validate Opt-In zones MUST only do so when the + zone is signed using one or more of these private algorithms. + + The remainder of this document assumes that the servers and resolvers + involved are aware of and are involved in this experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 5] + +Internet-Draft DNSSEC Opt-In February 2005 + + +4. Protocol Additions + + In RFC 2535bis, delegation NS RRsets are not signed, but are instead + accompanied by a NSEC RRset of the same name and a DS record. The + security status of the subzone is determined by the presence or + absence of the DS RRset, cryptographically proven by the NSEC record. + Opt-In expands this definition by allowing insecure delegations to + exist within an otherwise signed zone without the corresponding NSEC + record at the delegation's owner name. These insecure delegations + are proven insecure by using a covering NSEC record. + + Since this represents a change of the interpretation of NSEC records, + resolvers must be able to distinguish between RFC 2535bis NSEC + records and Opt-In NSEC records. This is accomplished by "tagging" + the NSEC records that cover (or potentially cover) insecure + delegation nodes. This tag is indicated by the absence of the NSEC + bit in the type map. Since the NSEC bit in the type map merely + indicates the existence of the record itself, this bit is redundant + and safe for use as a tag. + + An Opt-In tagged NSEC record does not assert the (non)existence of + the delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning records in the NSEC chain. + However, Opt-In tagged NSEC records do assert the (non)existence of + other RRsets. + + An Opt-In NSEC record MAY have the same name as an insecure + delegation. In this case, the delegation is proven insecure by the + lack of a DS bit in type map and the signed NSEC record does assert + the existence of the delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC + records and RFC 2535bis NSEC records. If a NSEC record is not + Opt-In, there MUST NOT be any insecure delegations (or any other + records) between it and the RRsets indicated by the 'next domain + name' in the NSEC RDATA. If it is Opt-In, there MUST only be + insecure delegations between it and the next node indicated by the + 'next domain name' in the NSEC RDATA. + + In summary, + + o An Opt-In NSEC type is identified by a zero-valued (or + not-specified) NSEC bit in the type bit map of the NSEC record. + o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in + the type bit map of the NSEC record. + + and, + + + +Arends, et al. Expires August 4, 2005 [Page 6] + +Internet-Draft DNSSEC Opt-In February 2005 + + + o An Opt-In NSEC record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + o An Opt-In NSEC record does assert the (non)existence of RRsets + with the same owner name. + +4.1 Server Considerations + + Opt-In imposes some new requirements on authoritative DNS servers. + +4.1.1 Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NSEC record. + Signing tools SHOULD NOT generate signed zones that violate this + restriction. Servers SHOULD refuse to load and/or serve zones that + violate this restriction. + +4.1.2 Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NSEC RRset in the Authority section. + + In RFC 2535bis, NSEC records already must be returned along with the + insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NSEC record will have a + different owner name from the delegation RRset. This may require + implementations to do a NSEC search on cached responses. + +4.1.3 Wildcards and Opt-In + + RFC 2535bis describes the practice of returning NSEC records to prove + the non-existence of an applicable wildcard in non-existent name + responses. This NSEC record can be described as a "negative wildcard + proof". The use of Opt-In NSEC records changes the necessity for + this practice. For non-existent name responses when the query name + (qname) is covered by an Opt-In tagged NSEC record, servers MAY + choose to omit the wildcard proof record, and clients MUST NOT treat + the absence of this NSEC record as a validation error. + + The intent of the RFC 2535bis negative wildcard proof requirement is + to prevent malicious users from undetectably removing valid wildcard + responses. In order for this cryptographic proof to work, the + resolver must be able to prove: + + 1. The exact qname does not exist. This is done by the "normal" + NSEC record. + + + + +Arends, et al. Expires August 4, 2005 [Page 7] + +Internet-Draft DNSSEC Opt-In February 2005 + + + 2. No applicable wildcard exists. This is done by returning a NSEC + record proving that the wildcard does not exist (this is the + negative wildcard proof). + + However, if the NSEC record covering the exact qname is an Opt-In + NSEC record, the resolver will not be able to prove the first part of + this equation, as the qname might exist as an insecure delegation. + Thus, since the total proof cannot be completed, the negative + wildcard proof NSEC record is not useful. + + The negative wildcard proof is also not useful when returned as part + of an Opt-In insecure delegation response for a similar reason: the + resolver cannot prove that the qname does or does not exist, and + therefore cannot prove that a wildcard expansion is valid. + + The presence of an Opt-In tagged NSEC record does not change the + practice of returning a NSEC along with a wildcard expansion. Even + though the Opt-In NSEC will not be able to prove that the wildcard + expansion is valid, it will prove that the wildcard expansion is not + masking any signed records. + +4.1.4 Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NSEC chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NSEC records. + +4.2 Client Considerations + + Opt-In imposes some new requirements on security-aware resolvers + (caching or otherwise). + +4.2.1 Delegations Only + + As stated in the "Server Considerations" section above, this + specification restricts the namespace covered by Opt-In tagged NSEC + records to insecure delegations only. Thus, resolvers MUST reject as + invalid any records that fall within an Opt-In NSEC record's span + that are not NS records or corresponding glue records. + +4.2.2 Validation Process Changes + + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + Resolvers MUST be able to use Opt-In tagged NSEC records to + + + +Arends, et al. Expires August 4, 2005 [Page 8] + +Internet-Draft DNSSEC Opt-In February 2005 + + + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: + + o In RFC 2535bis, the security status is proven by the existence or + absence of a DS RRset at the same name as the delegation. The + existence of the DS RRset indicates that the referred-to zone is + signed. The absence of the DS RRset is proven using a verified + NSEC record of the same name that does not have the DS bit set in + the type map. This NSEC record MAY also be tagged as Opt-In. + o Using Opt-In, the security status is proven by the existence of a + DS record (for signed) or the presence of a verified Opt-In tagged + NSEC record that covers the delegation name. That is, the NSEC + record does not have the NSEC bit set in the type map, and the + delegation name falls between the NSEC's owner and "next" name. + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the subzone is signed or unsigned. + + When receiving either an Opt-In insecure delegation response or a + non-existent name response where that name is covered by an Opt-In + tagged NSEC record, the resolver MUST NOT require proof (in the form + of a NSEC record) that a wildcard did not exist. + +4.2.3 NSEC Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NSEC record when returning referrals that need them. This + requirement differs from RFC 2535bis in that the covering NSEC will + not have the same owner name as the delegation. Some implementations + may have to use new methods for finding these NSEC records. + +4.2.4 Use of the AD bit + + The AD bit, as defined by [2] and [5], MUST NOT be set when: + + o sending a non-existent name (NXDOMAIN) response where the covering + NSEC is tagged as Opt-In. + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NSEC record's owner name equals the delegation + name. + + This rule is based on what the Opt-In NSEC record actually proves: + for names that exist between the Opt-In NSEC record's owner and + "next" names, the Opt-In NSEC record cannot prove the non-existence + or existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. + + + +Arends, et al. Expires August 4, 2005 [Page 9] + +Internet-Draft DNSSEC Opt-In February 2005 + + +5. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for NSEC records for + insecure delegations. This, in a zone with a large number of + delegations to unsigned subzones, can lead to substantial space + savings (both in memory and on disk). Additionally, Opt-In allows + for the addition or removal of insecure delegations without modifying + the NSEC record chain. Zones that are frequently updating insecure + delegations (e.g., TLDs) can avoid the substantial overhead of + modifying and resigning the affected NSEC records. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 10] + +Internet-Draft DNSSEC Opt-In February 2005 + + +6. Example + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NSEC records are tagged as Opt-In. + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. RRSIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. RRSIG NS ... + EXAMPLE. DNSKEY ... + EXAMPLE. RRSIG DNSKEY ... + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. RRSIG A ... + FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG + FIRST-SECURE.EXAMPLE. RRSIG NSEC ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG + NOT-SECURE-2.EXAMPLE RRSIG NSEC ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. RRSIG DS ... + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + In this example, a query for a signed RRset (e.g., + "FIRST-SECURE.EXAMPLE A"), or a secure delegation + ("WWW.SECOND-SECURE.EXAMPLE A") will result in a normal RFC 2535bis + response. + + A query for a nonexistent RRset will result in a response that + differs from RFC 2535bis by: the NSEC record will be tagged as + Opt-In, there may be no NSEC record proving the non-existence of a + matching wildcard record, and the AD bit will not be set. + + + + +Arends, et al. Expires August 4, 2005 [Page 11] + +Internet-Draft DNSSEC Opt-In February 2005 + + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NSEC record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + + + RCODE=NOERROR, AD=0 + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + Additional Section: + NS.UNSIGNED.EXAMPLE. A ... + + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NSEC record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NSEC record for EXAMPLE. + was changed to the following RR: + + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS + RRSIG DNSKEY NSEC ) + + However, the other NSEC records (FIRST-SECURE.EXAMPLE. and + SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are + insecure delegations in the range they define. (NOT-SECURE.EXAMPLE. + and UNSIGNED.EXAMPLE., respectively). + + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that + is part of the NSEC chain and also covered by an Opt-In tagged NSEC + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot + be removed from the zone without modifying and resigning the prior + NSEC record. Delegations with names that fall between + NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or + removed without resigning any NSEC records. + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 12] + +Internet-Draft DNSSEC Opt-In February 2005 + + +7. Transition Issues + + Opt-In is not backwards compatible with RFC 2535bis. RFC 2535bis + compliant DNSSEC implementations will not recognize Opt-In tagged + NSEC records as different from RFC 2535bis NSEC records. Because of + this, RFC 2535bis implementations will reject all Opt-In insecure + delegations within a zone as invalid. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 13] + +Internet-Draft DNSSEC Opt-In February 2005 + + +8. Security Considerations + + Opt-In allows for unsigned names, in the form of delegations to + unsigned subzones, to exist within an otherwise signed zone. All + unsigned names are, by definition, insecure, and their validity or + existence cannot by cryptographically proven. + + In general: + + o Records with unsigned names (whether existing or not) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilites are described in more detail in [12] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + o Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NSEC record. + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name). + + For example, if a resolver received the following response from the + example zone above: + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 14] + +Internet-Draft DNSSEC Opt-In February 2005 + + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Answer Section: + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ + RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + Additional Section: + + + The resolver would have no choice but to believe that the referral to + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to nameserver under his/her control and place whatever + records needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to Opt-In, and + MAY choose to not support Opt-In at all. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 15] + +Internet-Draft DNSSEC Opt-In February 2005 + + +9. IANA Considerations + + None. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 16] + +Internet-Draft DNSSEC Opt-In February 2005 + + +10. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, + Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian + Wellington. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 17] + +Internet-Draft DNSSEC Opt-In February 2005 + + +11. References + +11.1 Normative References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [3] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [4] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [5] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in + progress), October 2004. + + [6] Blacka, D., "DNSSEC Experiments", + draft-blacka-dnssec-experiments-00 (work in progress), December + 2004. + +11.2 Informative References + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [9] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + + [10] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + + + +Arends, et al. Expires August 4, 2005 [Page 18] + +Internet-Draft DNSSEC Opt-In February 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: markk@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 19] + +Internet-Draft DNSSEC Opt-In February 2005 + + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NSEC records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and + the zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single Opt-In zone. The following algorithm is used when responding + to each query: + V_A is the secure view as described above. + V_B is the insecure view as described above. + R_A is a response generated from V_A, following RFC 2535bis. + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + R_C is the response generated by combining R_A with R_B, as + described below. + A query is DNSSEC-aware if it either has the DO bit [11] turned + on, or is for a DNSSEC-specific record type. + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + 2. Generate R_A. + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + 4. Generate R_B and combine it with R_A to form R_C: + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + 5. Return R_C. + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 20] + +Internet-Draft DNSSEC Opt-In February 2005 + + +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 (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires August 4, 2005 [Page 21] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt new file mode 100644 index 0000000000..dd8cbf0682 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt @@ -0,0 +1,839 @@ + +DNS Extensions Working Group R. Arends +Internet-Draft Telematica Instituut +Expires: August 25, 2005 P. Koch + DENIC eG + J. Schlyter + NIC-SE + February 21, 2005 + + + Evaluating DNSSEC Transition Mechanisms + draft-ietf-dnsext-dnssec-trans-02.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 August 25, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document collects and summarizes different proposals for + alternative and additional strategies for authenticated denial in DNS + responses, evaluates these proposals and gives a recommendation for a + + + +Arends, et al. Expires August 25, 2005 [Page 1] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + way forward. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 + 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 + 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5 + 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 + 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 + 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 + 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 + 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 + 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 + 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 + 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 + 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 + 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 + 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 2] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +1. Introduction + + This report shall document the process of dealing with the NSEC + walking problem late in the Last Call for + [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, + I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion + that took place in the DNSEXT WG during the first half of June 2004 + as well as some additional ideas that came up subsequently. + + This is an edited excerpt of the chairs' mail to the WG: + The working group consents on not including NSEC-alt in the + DNSSEC-bis documents. The working group considers to take up + "prevention of zone enumeration" as a work item. + There may be multiple mechanisms to allow for co-existence with + DNSSEC-bis. The chairs allow the working group a little over a + week (up to June 12, 2004) to come to consensus on a possible + modification to the document to enable gentle rollover. If that + consensus cannot be reached the DNSSEC-bis documents will go out + as-is. + + To ease the process of getting consensus, a summary of the proposed + solutions and analysis of the pros and cons were written during the + weekend. + + This summary includes: + + An inventory of the proposed mechanisms to make a transition to + future work on authenticated denial of existence. + List the known Pros and Cons, possibly provide new arguments, and + possible security considerations of these mechanisms. + Provide a recommendation on a way forward that is least disruptive + to the DNSSEC-bis specifications as they stand and keep an open + path to other methods for authenticated denial of existence. + + The descriptions of the proposals in this document are coarse and do + not cover every detail necessary for implementation. In any case, + documentation and further study is needed before implementaion and/or + deployment, including those which seem to be solely operational in + nature. + +2. Transition Mechanisms + + In the light of recent discussions and past proposals, we have found + several ways to allow for transition to future expansion of + authenticated denial. We tried to illuminate the paths and pitfalls + in these ways forward. Some proposals lead to a versioning of + DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other + proposals are 'clean' but may cause delay, while again others may be + + + +Arends, et al. Expires August 25, 2005 [Page 3] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + plain hacks. + + Some paths do not introduce versioning, and might require the current + DNSSEC-bis documents to be fully updated to allow for extensions to + authenticated denial mechanisms. Other paths introduce versioning + and do not (or minimally) require DNSSEC-bis documents to be updated, + allowing DNSSEC-bis to be deployed, while future versions can be + drafted independent from or partially depending on DNSSEC-bis. + +2.1 Mechanisms With Need of Updating DNSSEC-bis + + Mechanisms in this category demand updates to the DNSSEC-bis document + set. + +2.1.1 Dynamic NSEC Synthesis + + This proposal assumes that NSEC RRs and the authenticating RRSIG will + be generated dynamically to just cover the (non existent) query name. + The owner name is (the) one preceding the name queried for, the Next + Owner Name Field has the value of the Query Name Field + 1 (first + successor in canonical ordering). A separate key (the normal ZSK or + a separate ZSK per authoritative server) would be used for RRSIGs on + NSEC RRs. This is a defense against enumeration, though it has the + presumption of online signing. + +2.1.1.1 Coexistence and Migration + + There is no change in interpretation other then that the next owner + name might or might not exist. + +2.1.1.2 Limitations + + This introduces an unbalanced cost between query and response + generation due to dynamic generation of signatures. + +2.1.1.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents might need to be updated to indicate + that the next owner name might not be an existing name in the zone. + This is not a real change to the spec since implementers have been + warned not to synthesize with previously cached NSEC records. A + specific bit to identify the dynamic signature generating key might + be useful as well, to prevent it from being used to fake positive + data. + +2.1.1.4 Cons + + Unbalanced cost is a ground for DDoS. Though this protects against + + + +Arends, et al. Expires August 25, 2005 [Page 4] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + enumeration, it is not really a path for versioning. + +2.1.1.5 Pros + + Hardly any amendments to DNSSEC-bis. + +2.1.2 Add Versioning/Subtyping to Current NSEC + + This proposal introduces versioning for the NSEC RR type (a.k.a. + subtyping) by adding a (one octet) version field to the NSEC RDATA. + Version number 0 is assigned to the current (DNSSEC-bis) meaning, + making this an 'Must Be Zero' (MBZ) for the to be published docset. + +2.1.2.1 Coexistence and Migration + + Since the versioning is done inside the NSEC RR, different versions + may coexist. However, depending on future methods, that may or may + not be useful inside a single zone. Resolvers cannot ask for + specific NSEC versions but may be able to indicate version support by + means of a to be defined EDNS option bit. + +2.1.2.2 Limitations + + There are no technical limitations, though it will cause delay to + allow testing of the (currently unknown) new NSEC interpretation. + + Since the versioning and signaling is done inside the NSEC RR, future + methods will likely be restricted to a single RR type authenticated + denial (as opposed to e.g. NSEC-alt, which currently proposes three + RR types). + +2.1.2.3 Amendments to DNSSEC-bis + + Full Update of the current DNSSEC-bis documents to provide for new + fields in NSEC, while specifying behavior in case of unknown field + values. + +2.1.2.4 Cons + + Though this is a clean and clear path without versioning DNSSEC, it + takes some time to design, gain consensus, update the current + dnssec-bis document, test and implement a new authenticated denial + record. + +2.1.2.5 Pros + + Does not introduce an iteration to DNSSEC while providing a clear and + clean migration strategy. + + + +Arends, et al. Expires August 25, 2005 [Page 5] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.3 Type Bit Map NSEC Indicator + + Bits in the type-bit-map are reused or allocated to signify the + interpretation of NSEC. + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + the RDATA or introduce an alternative denial mechanism, invoked by + the specific type-bit-map-bits. + +2.1.3.1 Coexistence and migration + + Old and new NSEC meaning could coexist, depending how the signaling + would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR + types are available as well as those covering meta/query types or + types to be specifically allocated. + +2.1.3.2 Limitations + + This mechanism uses an NSEC field that was not designed for that + purpose. Similar methods were discussed during the Opt-In discussion + and the Silly-State discussion. + +2.1.3.3 Amendments to DNSSEC-bis + + The specific type-bit-map-bits must be allocated and they need to be + specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) + interpretation. Also, behaviour of the resolver and validator must + be documented in case unknown values are encountered for the MBZ + field. Currently the protocol document specifies that the validator + MUST ignore the setting of the NSEC and the RRSIG bits, while other + bits are only used for the specific purpose of the type-bit-map field + +2.1.3.4 Cons + + The type-bit-map was not designed for this purpose. It is a + straightforward hack. Text in protocol section 5.4 was put in + specially to defend against this usage. + +2.1.3.5 Pros + + No change needed to the on-the-wire protocol as specified in the + current docset. + +2.1.4 New Apex Type + + This introduces a new Apex type (parallel to the zone's SOA) + indicating the DNSSEC version (or authenticated denial) used in or + + + +Arends, et al. Expires August 25, 2005 [Page 6] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + for this zone. + +2.1.4.1 Coexistence and Migration + + Depending on the design of this new RR type multiple denial + mechanisms may coexist in a zone. Old validators will not understand + and thus ignore the new type, so interpretation of the new NSEC + scheme may fail, negative responses may appear 'bogus'. + +2.1.4.2 Limitations + + A record of this kind is likely to carry additional + feature/versioning indications unrelated to the current question of + authenticated denial. + +2.1.4.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the absence of this type indicates dnssec-bis, and that the (mere) + presence of this type indicated unknown versions. + +2.1.4.4 Cons + + The only other 'zone' or 'apex' record is the SOA record. Though + this proposal is not new, it is yet unknown how it might fulfill + authenticated denial extensions. This new RR type would only provide + for a generalized signaling mechanism, not the new authenticated + denial scheme. Since it is likely to be general in nature, due to + this generality consensus is not to be reached soon. + +2.1.4.5 Pros + + This approach would allow for a lot of other per zone information to + be transported or signaled to both (slave) servers and resolvers. + +2.1.5 NSEC White Lies + + This proposal disables one part of NSEC (the pointer part) by means + of a special target (root, apex, owner, ...), leaving intact only the + ability to authenticate denial of existence of RR sets, not denial of + existence of domain names (NXDOMAIN). It may be necessary to have + one working NSEC to prove the absence of a wildcard. + +2.1.5.1 Coexistence and Migration + + The NSEC target can be specified per RR, so standard NSEC and 'white + lie' NSEC can coexist in a zone. There is no need for migration + because no versioning is introduced or intended. + + + +Arends, et al. Expires August 25, 2005 [Page 7] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.5.2 Limitations + + This proposal breaks the protocol and is applicable to certain types + of zones only (no wildcard, no deep names, delegation only). Most of + the burden is put on the resolver side and operational consequences + are yet to be studied. + +2.1.5.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the NXDOMAIN responses may be insecure. + +2.1.5.4 Cons + + Strictly speaking this breaks the protocol and doesn't fully fulfill + the requirements for authenticated denial of existence. Security + implications need to be carefully documented: search path problems + (forged denial of existence may lead to wrong expansion of non-FQDNs + [RFC1535]) and replay attacks to deny existence of records. + +2.1.5.5 Pros + + Hardly any amendments to DNSSEC-bis. Operational "trick" that is + available anyway. + +2.1.6 NSEC Optional via DNSSKEY Flag + + A new DNSKEY may be defined to declare NSEC optional per zone. + +2.1.6.1 Coexistence and Migration + + Current resolvers/validators will not understand the Flag bit and + will have to treat negative responses as bogus. Otherwise, no + migration path is needed since NSEC is simply turned off. + +2.1.6.2 Limitations + + NSEC can only be made completely optional at the cost of being unable + to prove unsecure delegations (absence of a DS RR [RFC3658]). A next + to this approach would just disable authenticated denial for + non-existence of nodes. + +2.1.6.3 Amendments to DNSSEC-bis + + New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to + be specified in the light of absence of authenticated denial. + + + + + +Arends, et al. Expires August 25, 2005 [Page 8] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.6.4 Cons + + Doesn't fully meet requirements. Operational consequences to be + studied. + +2.1.6.5 Pros + + Official version of the "trick" presented in (8). Operational + problems can be addressed during future work on validators. + +2.1.7 New Answer Pseudo RR Type + + A new pseudo RR type may be defined that will be dynamically created + (and signed) by the responding authoritative server. The RR in the + response will cover the QNAME, QCLASS and QTYPE and will authenticate + both denial of existence of name (NXDOMAIN) or RRset. + +2.1.7.1 Coexistence and Migration + + Current resolvers/validators will not understand the pseudo RR and + will thus not be able to process negative responses so testified. A + signaling or solicitation method would have to be specified. + +2.1.7.2 Limitations + + This method can only be used with online keys and online signing + capacity. + +2.1.7.3 Amendments to DNSSEC-bis + + Signaling method needs to be defined. + +2.1.7.4 Cons + + Keys have to be held and processed online with all security + implications. An additional flag for those keys identifying them as + online or negative answer only keys should be considered. + +2.1.7.5 Pros + + Expands DNSSEC authentication to the RCODE. + +2.1.8 SIG(0) Based Authenticated Denial + + +2.1.8.1 Coexistence and Migration + + + + + +Arends, et al. Expires August 25, 2005 [Page 9] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.8.2 Limitations + + +2.1.8.3 Amendments to DNSSEC-bis + + +2.1.8.4 Cons + + +2.1.8.5 Pros + + +2.2 Mechanisms Without Need of Updating DNSSEC-bis + +2.2.1 Partial Type-code and Signal Rollover + + Carefully crafted type code/signal rollover to define a new + authenticated denial space that extends/replaces DNSSEC-bis + authenticated denial space. This particular path is illuminated by + Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> + posted to 2004-06-02. + +2.2.1.1 Coexistence and Migration + + To protect the current resolver for future versions, a new DNSSEC-OK + bit must be allocated to make clear it does or does not understand + the future version. Also, a new DS type needs to be allocated to + allow differentiation between a current signed delegation and a + 'future' signed delegation. Also, current NSEC needs to be rolled + into a new authenticated denial type. + +2.2.1.2 Limitations + + None. + +2.2.1.3 Amendments to DNSSEC-bis + + None. + +2.2.1.4 Cons + + It is cumbersome to carefully craft an TCR that 'just fits'. The + DNSSEC-bis protocol has many 'borderline' cases that needs special + consideration. It might be easier to do a full TCR, since a few of + the types and signals need upgrading anyway. + + + + + + +Arends, et al. Expires August 25, 2005 [Page 10] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.2.1.5 Pros + + Graceful adoption of future versions of NSEC, while there are no + amendments to DNSSEC-bis. + +2.2.2 A Complete Type-code and Signal Rollover + + A new DNSSEC space is defined which can exist independent of current + DNSSEC-bis space. + + This proposal assumes that all current DNSSEC type-codes + (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any + future versions of DNSSEC. Any future version of DNSSEC has its own + types to allow for keys, signatures, authenticated denial, etcetera. + +2.2.2.1 Coexistence and Migration + + Both spaces can co-exist. They can be made completely orthogonal. + +2.2.2.2 Limitations + + None. + +2.2.2.3 Amendments to DNSSEC-bis + + None. + +2.2.2.4 Cons + + With this path we abandon the current DNSSEC-bis. Though it is easy + to role specific well-known and well-tested parts into the re-write, + once deployment has started this path is very expensive for + implementers, registries, registrars and registrants as well as + resolvers/users. A TCR is not to be expected to occur frequently, so + while a next generation authenticated denial may be enabled by a TCR, + it is likely that that TCR will only be agreed upon if it serves a + whole basket of changes or additions. A quick introduction of + NSEC-ng should not be expected from this path. + +2.2.2.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. It is + always there as last resort. + +2.2.3 Unknown Algorithm in RRSIG + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + + + +Arends, et al. Expires August 25, 2005 [Page 11] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + the RDATA or introduce an alternative denial mechanism, invoked by + the specific unknown signing algorithm. The different interpretation + would be signaled by use of different signature algorithms in the + RRSIG records covering the NSEC RRs. + + When an entire zone is signed with a single unknown algorithm, it + will cause implementations that follow current dnssec-bis documents + to treat individual RRsets as unsigned. + +2.2.3.1 Coexistence and migration + + Old and new NSEC RDATA interpretation or known and unknown Signatures + can NOT coexist in a zone since signatures cover complete (NSEC) + RRSets. + +2.2.3.2 Limitations + + Validating resolvers agnostic of new interpretation will treat the + NSEC RRset as "not signed". This affects wildcard and non-existence + proof, as well as proof for (un)secured delegations. Also, all + positive signatures (RRSIGs on RRSets other than DS, NSEC) appear + insecure/bogus to an old validator. + + The algorithm version space is split for each future version of + DNSSEC. Violation of the 'modular components' concept. We use the + 'validator' to protect the 'resolver' from unknown interpretations. + +2.2.3.3 Amendments to DNSSEC-bis + + None. + +2.2.3.4 Cons + + The algorithm field was not designed for this purpose. This is a + straightforward hack. + +2.2.3.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. + +3. Recommendation + + The authors recommend that the working group commits to and starts + work on a partial TCR, allowing graceful transition towards a future + version of NSEC. Meanwhile, to accomodate the need for an + immediately, temporary, solution against zone-traversal, we recommend + On-Demand NSEC synthesis. + + + + +Arends, et al. Expires August 25, 2005 [Page 12] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + This approach does not require any mandatory changes to DNSSEC-bis, + does not violate the protocol and fulfills the requirements. As a + side effect, it moves the cost of implementation and deployment to + the users (zone owners) of this mechanism. + +4. Acknowledgements + + The authors would like to thank Sam Weiler and Mark Andrews for their + input and constructive comments. + +5. References + +5.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Massey, D., Larson, M. and S. + Rose, "DNS Security Introduction and Requirements", + Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., "Protocol Modifications for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, + October 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., "Resource Records for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-records-11, + October 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. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + +5.2 Informative References + + [RFC1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, October + 1993. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + + + +Arends, et al. Expires August 25, 2005 [Page 13] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + RFC 2535, March 1999. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + Enschede 7523 XC + The Netherlands + + Phone: +31 53 4850485 + Email: roy.arends@telin.nl + + + Peter Koch + DENIC eG + Wiesenh"uttenplatz 26 + Frankfurt 60329 + Germany + + Phone: +49 69 27235 0 + Email: pk@DENIC.DE + + + Jakob Schlyter + NIC-SE + Box 5774 + Stockholm SE-114 87 + Sweden + + Email: jakob@nic.se + URI: http://www.nic.se/ + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 14] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +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 (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires August 25, 2005 [Page 15] + + diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-06.txt b/doc/draft/draft-ietf-dnsext-ecc-key-06.txt new file mode 100644 index 0000000000..6953f6e42f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ecc-key-06.txt @@ -0,0 +1,930 @@ + + +INTERNET-DRAFT ECC Keys in the DNS +Expires: June 2005 December 2004 + + + + Elliptic Curve KEYs in the DNS + -------- ----- ---- -- --- --- + + + Richard C. Schroeppel + Donald 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, + 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 DNS mailing list . + + 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 + + The standard method for storing elliptic curve cryptographic keys and + signatures in the Domain Name System is specified. + + +Copyright Notice + + Copyright (C) The Internet Society. All Rights Reserved. + + + + + +R. Schroeppel, et al [Page 1] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve Data in Resource Records.................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Elliptic Curve SIG Resource Records....................11 + 6. Performance Considerations.............................13 + 7. Security Considerations................................13 + 8. IANA Considerations....................................13 + Copyright and Disclaimer..................................14 + + Informational References..................................15 + Normative Refrences.......................................15 + + Author's Addresses........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + +INTERNET-DRAFT ECC Keys in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC intro, + protocol, records]. + + This document describes how to store elliptic curve cryptographic + (ECC) keys and signatures in the DNS so they can be used for a + variety of security purposes. Familiarity with ECC cryptography is + assumed [Menezes]. + + 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. Elliptic Curve Data in Resource Records + + Elliptic curve public keys are stored in the DNS within the RDATA + portions of key RRs, such as RRKEY and KEY [RFC records] RRs, with + the structure shown below. + + The research world continues to work on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. So, representations are + defined for every type of finite field, and every type of elliptic + curve. The reader should be aware that there is a unique finite + field with a particular number of elements, but many possible + representations of that field and its elements. If two different + representations of a field are given, they are interconvertible with + a tedious but practical precomputation, followed by a fast + computation for each field element to be converted. It is perfectly + reasonable for an algorithm to work internally with one field + representation, and convert to and from a different external + representation. + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 3] + + +INTERNET-DRAFT ECC Keys in the DNS + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + + +R. Schroeppel, et al [Page 4] + + +INTERNET-DRAFT ECC Keys in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + + + +R. Schroeppel, et al [Page 5] + + +INTERNET-DRAFT ECC Keys in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of an RR and MUST be + ignored when processing an RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range + [0,P-1]. The coefficients are packed into fixed-width fields, from + higher order to lower order. All coefficients must be present, + including any 0s and also the leading coefficient (which is required + to be 1). The coefficients are right justified into the octet string + of length specified by LF, with the low-order "constant" coefficient + at the right end. As a concession to storage efficiency, the higher + order bits of the leading coefficient may be elided, discarding high- + order 0 octets and reducing LF. The degree is calculated by + + +R. Schroeppel, et al [Page 6] + + +INTERNET-DRAFT ECC Keys in the DNS + + + determining the bit position of the left most 1-bit in the F data + (counting the right most bit as position 0), and dividing by + ceiling(log2 P). The division must be exact, with no remainder. In + this format, all of the other degree and field parameters are + omitted. The next parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of + degree D is X^D (which is not irreducible). The next is X^D+1, which + is sometimes irreducible, followed by X^D-1, which isn't. Assuming + odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + +INTERNET-DRAFT ECC Keys in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + +INTERNET-DRAFT ECC Keys in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user's public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + +INTERNET-DRAFT ECC Keys in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof's algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user's public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + +INTERNET-DRAFT ECC Keys in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Elliptic Curve SIG Resource Records + + The signature portion of an RR RDATA area when using the EC + algorithm, for example in the RRSIG and SIG [RFC records] RRs is + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + R and S are integers (mod Q). Their length is specified by the LQ + field of the corresponding KEY RR and can also be calculated from the + SIG RR's RDLENGTH. They are right justified, high-order-octet first. + The same conditional formula for calculating the length from LQ is + used as for all the other length fields above. + + The data signed is determined as specified in [RFC 2535]. Then the + following steps are taken where Q, P, G, and Y are as specified in + the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate random [RFC 1750] K such that 0 < K < Q. (Never sign two + different messages with the same K. K should be chosen from a + very large space: If an opponent learns a K value for a single + signature, the user's signing key is compromised, and a forger + can sign arbitrary messages. There is no harm in signing the + same message multiple times with the same key or different + keys.) + + R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted + + +R. Schroeppel, et al [Page 11] + + +INTERNET-DRAFT ECC Keys in the DNS + + + as an integer, and reduced (mod Q). (R must not be 0. In + this astronomically unlikely event, generate a new random K + and recalculate R.) + + S = ( K^(-1) * (hash + X*R) ) mod Q. + + S must not be 0. In this astronomically unlikely event, generate a + new random K and recalculate R and S. + + If S > Q/2, set S = Q - S. + + The pair (R,S) is the signature. + + Another party verifies the signature as follows: + + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. + + hash = SHA-1 ( data ) + + Sinv = S^(-1) mod Q. + + U1 = (hash * Sinv) mod Q. + + U2 = (R * Sinv) mod Q. + + (U1 * G + U2 * Y) is computed on the elliptic curve. + + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). + + The signature is valid if V = R. + + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for + hash(data)+Q or hash(data)-Q, if these happen to fall in the range + [0,2^160-1]. It's believed to be computationally infeasible to + find data that hashes to an assigned value, so this is only a + cosmetic blemish. The blemish can be eliminated by using Q > + 2^160, at the cost of having slightly longer signatures, 42 octets + instead of 40. + + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the + obvious thing". In the (mod P) case, E is simply a residue mod P, + and is taken as an integer in the range [0,P-1]. In the GF[2^D] + + +R. Schroeppel, et al [Page 12] + + +INTERNET-DRAFT ECC Keys in the DNS + + + case, E is in the D-bit polynomial basis representation, and is + simply taken as an integer in the range [0,(2^D)-1]. For other + fields GF[P^D], it's necessary to do some radix conversion + arithmetic. + + + + 6. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than + RSA and DSA. Creation of a curve is slow, but not done very often. + Key generation is faster than RSA or DSA. + + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of RR sets stored within the DNS + consistent with adequate security. + + + + 7. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + Some specific key generation considerations are given in the body + of this document. + + + + 8. IANA Considerations + + The key and signature data structures defined herein correspond to + the value 4 in the Algorithm number field of the IANA registry + + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in + defined in this document requires an IETF consensus as defined in + [RFC 2434]. + + + + + +R. Schroeppel, et al [Page 13] + + +INTERNET-DRAFT ECC Keys in the DNS + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Informational References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness + Recommendations for Security", 12/29/1994. + + [RFC intro] - "DNS Security Introduction and Requirements", R. + Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-intro-*.txt. + + [RFC protocol] - "Protocol Modifications for the DNS Security + Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, + work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", + August 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic + Curves", 1986, Springer Graduate Texts in mathematics #106. + + + + Normative Refrences + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC records] - "Resource Records for the DNS Security Extensions", + R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-records- *.txt. + + + + + + + + +R. Schroeppel, et al [Page 15] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Author's Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: +1-505-844-9079(w) + +1-801-423-7998(h) + Email: rschroe@sandia.gov + + + 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 June 2004. + + Its file name is draft-ietf-dnsext-ecc-key-06.txt. + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 16] + + diff --git a/doc/draft/draft-ietf-dnsext-insensitive-05.txt b/doc/draft/draft-ietf-dnsext-insensitive-05.txt new file mode 100644 index 0000000000..41fbee7a4a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-insensitive-05.txt @@ -0,0 +1,697 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Updates RFC 1034, 1035 Motorola Laboratories +Expires July 2005 January 2005 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + + + 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, + or will be 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. + + 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 + + + +Copyright Notice + + Copyright (C) The Internet Society. All Rights Reserved. + + + +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 updates RFCs 1034 and 1035. + + +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, Thomas Narten, and Scott Seligman + are gratefully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Copyright Notice...........................................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 + + Full Copyright Notice and Disclaimer.......................9 + Normative References.......................................9 + Informative References....................................10 + -02 to -03 Changes........................................10 + -03 to -04 Changes........................................11 + -04 to -05 Changes........................................11 + Author's Address..........................................11 + Expiration and File Name..................................12 + + + + + + + + + + + + +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. This clarification updates RFCs 1034 + and 1035 [STD 13]. + + 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. + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + One typographic convention for octets that do not correspond to an + 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 all + 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 + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + terms were "majuscule" and "minuscule".) + + 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 + + +Full Copyright Notice and Disclaimer + + Copyright (C) The Internet Society 2005. This document is subject to + the rights, licenses and restrictions contained in BCP 78 and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +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 + + [ISO 8859-1] - International Standards Organization, Standard for + Character Encodings, Latin-1. + + [ISO 8859-2] - International Standards Organization, Standard for + Character Encodings, Latin-2. + + [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", + . + + + +-02 to -03 Changes + + The following changes were made between draft version -02 and -03: + + 1. Add internationalized domain name section and references. + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS Case Insensitivity + + + 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. + + + +-03 to -04 Changes + + The following changes were made between draft versions -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. + + + +-04 to -05 Changes + + The following changes were made between draft versions -04 and -05: + + 1. More clearly state that this draft updates RFCs 1034, 1035 [STD + 13]. + + 2. Add informative references to ISO 8859-1 and ISO 8859-2. + + 3. Fix hyphenation and capitalization nits. + + + +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 + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Expiration and File Name + + This draft expires July 2005. + + Its file name is draft-ietf-dnsext-insensitive-05.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-38.txt b/doc/draft/draft-ietf-dnsext-mdns-38.txt new file mode 100644 index 0000000000..ac51706af2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-38.txt @@ -0,0 +1,1677 @@ + +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +19 February 2005 + + Linklocal Multicast Name Resolution (LLMNR) + +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 August 22, 2005. + +Copyright Notice + + Copyright (C) The Internet Society 2005. 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 19 February 2005 + + +Table of Contents + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 3 + 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 .............................. 9 + 2.4 Unicast queries ................................. 11 + 2.5 Off-link detection .............................. 12 + 2.6 Responder responsibilities ...................... 13 + 2.7 Retransmission and jitter ....................... 13 + 2.8 DNS TTL ......................................... 14 + 2.9 Use of the authority and additional sections .... 14 +3. Usage model ........................................... 15 + 3.1 LLMNR configuration ............................. 16 +4. Conflict resolution ................................... 17 + 4.1 Uniqueness Verification ......................... 18 + 4.2 Conflict Detection and Defense .................. 18 + 4.3 Considerations for multiple interfaces .......... 20 + 4.4 API issues ...................................... 21 +5. Security considerations ............................... 21 + 5.1 Scope restriction ............................... 22 + 5.2 Usage restriction ............................... 23 + 5.3 Cache and port separation ....................... 23 + 5.4 Authentication .................................. 24 +6. IANA considerations ................................... 24 +7. Constants ............................................. 24 +8. References ............................................ 24 + 8.1 Normative References ............................ 24 + 8.2 Informative References .......................... 25 +Acknowledgments .............................................. 26 +Authors' Addresses ........................................... 27 +Intellectual Property Statement .............................. 27 +Disclaimer of Validity ....................................... 28 +Copyright Statement .......................................... 28 + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 2] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +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 networks. + + 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. + +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", + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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 LLMNR responder considers one of its addresses reachable over a + link if it will respond to an ARP or Neighbor Discovery query for + that address sent over 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. + +UNIQUE + 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 only a single + responder is anticipated are referred to as UNIQUE. Resource + record uniqueness is configured on the responder, and therefore + uniqueness verification is the responder's responsibility. + +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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. + 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 DNS server address(es) have been + configured, then LLMNR SHOULD NOT be used as the + primary name resolution mechanism, although it MAY + be used as a secondary name resolution mechanism. + + [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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + [d] Upon reception of the response, the sender processes it. + + Further details of sender and responder behavior are provided in the + sections that follow. + +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 the smaller of the link + MTU or 8192 octets. + +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| U| C| 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. For advice on generation of pseudo-random values, please + consult [RFC1750]. + +QR A one bit field that specifies whether this message is an LLMNR + query (0), or an LLMNR response (1). + + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +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. + 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 in an LLMNR response, + then the sender SHOULD 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. + +U UNIQUE - specifies that this message is a UNIQUEness query. The U + bit MUST NOT be set in an LLMNR response, and if set is ignored by + an LLMNR sender. If the U bit is set in an LLMNR query, this + indicates that the sender believes that it is authoritative for the + name. See Section 4.1 and 4.2 for discussion of name conflict + detection. + +C Conflict - specifies that a sender has previously received multiple + LLMNR responses to this query. The C bit MUST NOT be set in an + LLMNR response, and if set is ignored by an LLMNR sender. + Responders do not respond to LLMNR queries with the 'C' bit set; + since no response is expected, LLMNR senders do not retransmit. + +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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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 preferable 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 + 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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. + + 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 multiple + valid answers are received, they 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. + +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 + 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 + 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be + authoritative for the following records: + + host1. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + host1.example.com. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + 1.2.0.192.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. (line split for formatting reasons) + IN PTR host1.example.com. + + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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 MUST 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, with the exception of queries with the 'C' bit + set, which do not elicit a response. + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + +[e] Responders MUST NOT respond using data from the LLMNR or DNS + resolver cache. + +[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 SHOULD 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. + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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 + 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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 one belonging to a + prefix that a Router Advertisement indicates is on-link [RFC2461]. + + 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. + + 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. + + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +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. + + Where multiple addresses represent valid responses to a query, the + order in which the addresses are returned is as follows: + + [d] If the source address of the query is a link-scope address, + then the responder SHOULD include a link-scope address first + in the response, if available. + + [e] If the source address of the query is a routable address, + then the responder MUST include a routable address first + in the response, if available. + +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 SHOULD 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. Queries with the 'C' bit set MUST be + sent over UDP and MUST NOT be retransmitted. + + 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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. 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). + + 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 JITTER_INTERVAL. This delay MAY be avoided by + responders responding with RRs which they have previously determined + to be UNIQUE (see Section 4 for details). + + Recommended values for constants (including LLMNR_TIMEOUT if it is + set statically) are given in Section 7. + +2.8. DNS TTL + + The responder should insert a pre-configured TTL value in the records + returned in 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. + + 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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + In LLMNR, the additional section is primarily intended for use by + EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, + senders MAY only include pseudo RR-types in the additional section of + a query; unless the 'C' bit is set, responders MUST ignore the + additional section of queries containing other RR types. + + In queries where the 'C' bit is set, the sender SHOULD include the + conflicting RRs in the additional section. Since conflict + notifications are advisory, responders SHOULD log information from + the additional section, but otherwise MUST ignore the additional + section. + + 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 + 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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 a AAAA RR query + sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or + RCODE=0 and an empty answer section, then a AAAA RR query sent using + LLMNR over IPv6 may be successful in resolving the name of an + IPv6-only host on the local link. + + 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 + 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 + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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. + + An outage in the DNS configuration mechanism may result in hosts + continuing to use LLMNR even once the outage is repaired. Since + LLMNR only enables linklocal name resolution, this represents a + degradation in capabilities. As a result, hosts without a configured + DNS server may wish to periodically attempt to obtain DNS + configuration if permitted by the configuration mechanism in use. In + the absence of other guidance, a default retry interval of one (1) + minute is RECOMMENDED. + +4. Conflict resolution + + The uniqueness of a resource record depends on the 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. + + By default, a responder SHOULD be configured to behave as though all + RRs are UNIQUE on each interface on which LLMNR is enabled. + + 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. + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +4.1. Uniqueness Verification + + Prior to including a UNIQUE resource record in a response, for each + UNIQUE resource record in a given interface's configuration, the host + MUST verify that there is no other host within the scope of LLMNR + query propagation that can return a resource record for the same + name, type and class on that interface. + + Once a responder has verified the uniqueness of a UNIQUE resource + record, if it receives an LLMNR query for that resource record, with + the 'C' bit clear, it MUST respond. + + 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 LLMNR queries on an interface + enabled for transmission and reception of IP traffic + - is configured to respond to LLMNR queries using additional + UNIQUE resource records + - verifies the acquisition of a new IP address and configuration + on an interface + + To verify uniqueness, a responder MUST send an LLMNR query with the + 'U' bit set for each UNIQUE resource record. If no response is + received, the sender retransmits the query, as specified in Section + 2.7. If a response is received, the responder MUST NOT use the UNIQUE + resource record in response to LLMNR queries. + + Periodically carrying out uniqueness verification in an attempt to + detect name conflicts is not necessary, wastes network bandwidth, and + may actually be detrimental. For example, if network links are + joined only briefly, and are separated again before any new + communication is initiated, temporary conflicts are benign and no + forced reconfiguration is required. Triggering a reconfiguration in + this case would not serve any useful purpose. LLMNR responders + SHOULD NOT periodically attempt uniqueness verification. + +4.2. Conflict Detection and Defense + + Hosts on disjoint network links may configure the same name for use + with LLMNR. If these separate network links are later joined or + bridged together, then there may be multiple hosts which are now on + the same link, trying to use the same name. + + There are several mechanisms by which ongoing name conflicts may be + detected: + + + +Esibov, Aboba & Thaler Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +[a] Receipt of a query with the 'U' bit set. Whenever an LLMNR + responder receives an LLMNR query for a UNIQUE resource record with + the 'U' bit set, if the source IP address does not match an IP + address configured on that interface, this indicates a conflict. + +[b] Conflict notification queries. When an LLMNR sender receives + multiple LLMNR responses to a query, it MUST send another query for + the same resource record, this time with the 'C' bit set, with the + answers received included in the Additional section. + + Queries with the 'C' bit set are considered advisory and responders + MUST verify the existence of a conflict by other means before + acting on it. A responder receiving a query with the 'C' bit set + MUST NOT respond. If the resource record is not UNIQUE, then the + responder MUST ignore the query. If the resource record is UNIQUE, + then the responder MUST send its own query for the same resource + record, with the 'U' bit set. If a response is received, or if a + query with the 'U' bit set is received, then a conflict has been + detected. + +An LLMNR responder MUST NOT ignore conflicts once detected. An LLMNR +responder MUST respond to a conflict as described in either [1] or [2] +below: + +[1] Upon detecting a conflict, an LLMNR responder MAY elect to + immediately stop using the conflicting UNIQUE resource record in + response to LLMNR queries. + + The responder MAY also elect to configure a new name. However, + since name reconfiguration may be disruptive, this is not required, + and a responder may have been configured to respond to multiple + names so that alternative names may already be available. + +[2] If a responder currently has reasons to prefer using the name, and + it has not seen any other conflicting LLMNR queries within the last + DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by + recording the time that the conflicting LLMNR query was received, + and then sending multicast queries for its UNIQUE resource records, + with the 'U' bit set. + + Having done this, an LLMNR responder can then continue to use the + name normally without any further special action. However, if this + is not the first conflicting LLMNR query the responder has seen, + and the time recorded for the previous conflicting LLMNR query is + recent, within DEFEND_INTERVAL, then the LLMNR responder MUST + immediately cease using the conflicting resource records. + + This is necessary to ensure that two hosts do not get stuck in an + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + endless loop with both hosts trying to defend the same name. + +4.3. 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. + + Where a host is configured to issue LLMNR queries on more than one + interface, each interface maintains its own independent LLMNR + resolver cache, containing the responses to LLMNR queries. + + 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 + 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. + + + +Esibov, Aboba & Thaler Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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.4. 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 + 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 allow 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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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 + possible for an attacker to spoof a response to a 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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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, 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. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +5.4. Authentication + + LLMNR implementations MAY support TSIG and/or SIG(0) security + mechanisms. Since LLMNR does not support "delegated trust" (CD or AD + bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice + LLMNR is not compatible with DNSSEC. + + Since LLMNR implementations MAY NOT support TSIG or SIG(0), 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 unicast + LLMNR queries and responses or LLMNR responses to multicast queries. + 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. Constants + + The following timing constants are used in this protocol; they are + not intended to be user configurable. + + DEFEND_INTERVAL 10 seconds (minimum interval between + defensive LLMNR queries). + JITTER_INTERVAL 100 ms + LLMNR_TIMEOUT 1 second (only if set statically) + RTOinit 500 ms (initial value of LLMNR_TIMEOUT) + RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT) + RTOmin 100 ms (minimum value of LLMNR_TIMEOUT) + +8. References + +8.1. Normative References + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + + + + +Esibov, Aboba & Thaler Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + +[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. + +[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, 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. + +8.2. Informative References + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + +[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + + + +Esibov, Aboba & Thaler Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +[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. + +[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. + +[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of Link-Local IPv4 Addresses", RFC 3927, October 2004. + +[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. + +[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 + + + +Esibov, Aboba & Thaler Standards Track [Page 26] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + has also been received from Mark Andrews, Rob Austein, Randy Bush, + Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur + Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, + Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, + Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike + St. Johns, Sander Van-Valkenburg, and Brian Zill. + +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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + 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. + +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 (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + +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 28] + + + + diff --git a/doc/draft/draft-ietf-dnsext-nsec3-01.txt b/doc/draft/draft-ietf-dnsext-nsec3-01.txt new file mode 100644 index 0000000000..10d8118412 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsec3-01.txt @@ -0,0 +1,1009 @@ + + +Network Working Group B. Laurie +Internet-Draft G. Sisson +Expires: August 2, 2005 Nominet + R. Arends + Telematica Instituut + february 2005 + + + DNSSEC Hash Authenticated Denial of Existence + draft-ietf-dnsext-nsec3-01 + +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 August 2, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be + used to provide authenticated denial of existence of DNS ownernames + and types; however, it permits any user to traverse a zone and obtain + a listing of all ownernames. + + + + +Laurie, et al. Expires August 2, 2005 [Page 1] + +Internet-Draft nsec3 february 2005 + + + A complete zone file can be used either directly as a source of + probable e-mail addresses for spam, or indirectly as a key for + multiple WHOIS queries to reveal registrant data which many + registries (particularly in Europe) may be under strict legal + obligations to protect. Many registries therefore prohibit copying + of their zone file; however the use of NSEC RRs makes renders + policies unenforceable. + + This document proposes a scheme which obscures original ownernames + while permitting authenticated denial of existence of non-existent + names. Non-authoritative delegation point NS RR types may be + excluded. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 + 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 + 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 + 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 + 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 6 + 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 6 + 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 6 + 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 + 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 7 + 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8 + 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9 + 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9 + 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 9 + 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 10 + 6.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 + 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11 + 6.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 + 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 12 + 6.4.1 Avoiding Hash Collisions during generation . . . . . . 12 + 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 12 + 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 13 + 7. Performance Considerations . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 10. Requirements notation . . . . . . . . . . . . . . . . . . . 14 + 11. Security Considerations . . . . . . . . . . . . . . . . . . 14 + A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + + + +Laurie, et al. Expires August 2, 2005 [Page 2] + +Internet-Draft nsec3 february 2005 + + + 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 + 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 + Intellectual Property and Copyright Statements . . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 3] + +Internet-Draft nsec3 february 2005 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduced the NSEC Resource + Record (RR) for Authenticated Denial of Existence. This document + introduces a new RR as an alternative to NSEC that provides measures + against zone traversal and allows for gradual expansion of + delegation-centric zones. + +1.1 Rationale + + The DNS Security Extensions included the NSEC RR to provide + authenticated denial of existence. Though the NSEC RR meets the + requirements for authenticated denial of Existence, it introduced a + side-effect in that the contents of a zone can be enumerated. This + property introduces undesired policy issues. + + A second requirement was that the existence of all record types in a + zone -including delegation point NS record types- can be accounted + for, despite the fact that delegation point NS RRsets are not + authoritative and not signed. This requirement has a side-effect + that the overhead of delegation centric signed zones is not related + to the increase in security of subzones. This requirement does not + allow delegation centric zones size to grow in relation to the growth + of signed subzones. + + In the past, solutions have been proposed as a measure against these + side effects but at the time were regarded as secondary over the need + to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) + a graceful transition path to future enhancements is introduced, + while current DNSSEC deployment can continue. This document + accumulates measures against the side effects introduced by NSEC, and + presents the NSEC3 Resource Record. + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs + that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 + [RFC2308]. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3 Terminology + + In this document the term "original ownername" refers to a standard + ownername. Because this proposal uses the result of a hash function + + + +Laurie, et al. Expires August 2, 2005 [Page 4] + +Internet-Draft nsec3 february 2005 + + + over the original (unmodified) ownername, this result is referred to + as "hashed ownername". + +2. The NSEC3 Resource Record + + The NSEC3 RR provides Authenticated Denial of Existence for DNS + Resource Record Sets. + + The NSEC3 Resource Record lists RR types present at the NSEC3 RR's + original ownername. It includes the next hashed ownername in the + canonical ordering of the zone. The complete set of NSEC3 RRs in a + zone indicates which RRsets exist for the original ownername of the + RRset and form a chain of hashed ownernames in the zone. This + information is used to provide authenticated denial of existence for + DNS data, as described in RFC 2535 [RFC2535]. Unsigned delegation + point NS RR sets can optionally be excluded. To provide protection + against zone traversal, the ownernames used in the NSEC3 RR are + cryptographic hash-value prepended to the name of the zone. The + NSEC3 RR record indicates which Hash Function is used to construct to + hash, which Salt is used, and how many iterations of the Hash + Function are performed over the original ownername. + + The type value for the NSEC3 RR is XX. + + The NSEC3 RR RDATA format is class independent. + + The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +2.1 NSEC3 RDATA Wire Format + + The RDATA of the NSEC3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|Hash Function| Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Hashed Ownername / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 5] + +Internet-Draft nsec3 february 2005 + + +2.1.1 The Authoritative Only Flag Field + + The Authoritative Only Flag field indicates whether the Type Bit Maps + include delegation point NS record types. + + If the flag is set to 1, the NS RR type bit for a delegation point + ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR + type bit MUST be ignored during processing of the NSEC3 RR. The NS + RR type bit has no meaning in this context (it is not authoritative), + hence the NSEC3 does not contest the existence of a NS RR type record + for this ownername. When a delegation is not secured, there exist no + DS RR type nor any other authoritative types for this delegation, + hence the unsecured delegation has no NSEC3 record associated. + Please see the Special Consideration section for implications for + unsigned delegations. + + If the flag is set to 0, the NS RR type bit for a delegation point + ownername MUST be set if the NSEC3 covers a delegation, even though + the NS RR itself is not authoritative. This implies that all + delegations, signed or unsigned, have an NSEC3 record associated. + This behaviour is identical to NSEC behaviour. + +2.1.2 The Hash Function Field + + The Hash Function field identifies the cryptographic hash function + used to construct the hash-value. + + This document defines Value 1 for SHA-1 and Value 127 for + Experimental. All other values are reserved. + + On reception, a resolver MUST discard an NSEC3 RR with an unknown + Hash Function value. + +2.1.3 The Iterations Field + + The Iterations field defines the number of times the hash has been + iterated. More iterations results in greater resiliency of the hash + value against dictionary attacks, but at a higher cost for both the + server and resolver. + +2.1.4 The Salt Length Field + + The Salt Length Field defines the length of the salt in octets. + +2.1.5 The Salt Field + + The salt field is not present when the Salt Length Field has a value + of 0. + + + +Laurie, et al. Expires August 2, 2005 [Page 6] + +Internet-Draft nsec3 february 2005 + + + The salt field is prepended to the original ownername before hashing + in order to defend against precalculated dictionary attacks. + + The salt is not prepended during iterations of the hash function. + + The Salt field value MUST be identical for all NSEC3 RRs generated + for the zone. If the salt were different for each NSEC3 RR, + collisions could occur where an NSEC3 denies the existence of + existing RRs due to the application of different salt values. + +2.1.6 The Next Hashed Ownername Field + + The Next Hashed Ownername Field contains the hash of the ownername of + the next RR in the canonical ordering of the hashed ownernames of the + zone. The value of the Next Hashed Ownername Field in the last NSEC3 + record in the zone is the same as the ownername of the first NSEC3 RR + in the zone in canonical order. + + A sender MUST NOT use DNS name compression on the Next Hashed + Ownername field when transmitting an NSEC3 RR. + + Hashed ownernames of RRsets not authoritative for the given zone + (such as glue records) MUST NOT be listed in the Hash of Next Domain + Name unless at least one authoritative RRset exists at the same owner + name. + +2.1.7 The list of Type Bit Map(s) Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC3 RR's ownername. + + The Type bit for the NSEC3 and RRSIG MUST be set during generation, + and MUST be ignored during processing. + + 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 NSEC3 RR RDATA in increasing numerical + order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + + + +Laurie, et al. Expires August 2, 2005 [Page 7] + +Internet-Draft nsec3 february 2005 + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC3 + RR's ownername. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC3 RR's ownername. + + The RR type 2 (NS) is authoritative at the apex of a zone and is not + authoritative at delegation points. If the Authoritative Only Flag + is set to 1, the delegation point NS RR type MUST NOT be included in + the type bit maps. If the Authoritative Only Flag is set to 0, the + NS RR type at a delegation point MUST be included in the type bit + maps. + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] + (section 3.1) or within the range reserved for assignment only to + QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in + zone data. If encountered, they must be ignored upon reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC3 RR's actual ownername. Trailing zero octets not specified MUST + be interpreted as zero octets. + +2.2 The NSEC3 RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Authoritative Only Field is represented as an unsigned decimal + integer. The value are either 0 or 1. + + The Hash field is presented as the name of the hash or as an unsigned + decimal integer. The value has a maximum of 127. + + The Iterations field is presented as an unsigned decimal integer. + + The Salt Length field is not presented. + + The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the sequence. + + + +Laurie, et al. Expires August 2, 2005 [Page 8] + +Internet-Draft nsec3 february 2005 + + + The Salt Field is represented as 00 when the Salt Length field has + value 0. + + The Hash of Next Domain Name field is represented as a sequence of + case-insensitive base32 digits. Whitespace is allowed within the + sequence. + + The List of Type Bit Map(s) Field is represented as a sequence of RR + type mnemonics. When the mnemonic is not known, the TYPE + representation as described in RFC 3597 [5] (section 5) MUST be used. + +3. Creating Additional NSEC3 RR for Empty Non Terminals + + In order to prove the non-existence of a record that might be covered + by a wildcard, it is necessary to prove the existence of its closest + encloser. A closest encloser might be an Empty Non Terminal. + + Additional NSEC3 RRs cover every existing intermediate label level. + Additional NSEC3 RRs are identical in format to NSEC3 RRs that cover + existing RRs in the zone. The difference is that the type-bit-maps + only indicate the existence of an NSEC3 RR and a RRSIG type. + +4. Calculation of the Hash + + Define H(x) to be the hash of x using the hash function selected by + the NSEC3 record and || to indicate concatenation. Then define: + + IH(salt,x,0)=H(x || salt) + + IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 + + Then the calculated hash of an ownername is + IH(salt,ownername,iterations-1), where the ownername is the canonical + form. + + The canonical form of the ownername is the wire format of the + ownername where: + 1. The ownername is fully expanded (no DNS name compression) and + fully qualified; + 2. All uppercase US-ASCII letters are replaced by the corresponding + lowercase US-ASCII letters; + 3. If the ownername is a wildcard name, the ownername is in its + original unexpanded form, including the "*" label (no wildcard + substitution); + +5. Including NSEC3 RRs in a Zone + + Each owner name in the zone which has authoritative data or a secured + + + +Laurie, et al. Expires August 2, 2005 [Page 9] + +Internet-Draft nsec3 february 2005 + + + delegation point NS RRset MUST have an NSEC3 resource record. + + An unsecured delegation point NS RRset MAY have an NSEC3 resource + record. This is different from NSEC records where an unsecured + delegation point NS RRset MUST have an NSEC record. + + The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + The type bitmap of every NSEC3 resource record in a signed zone MUST + indicate the presence of both the NSEC3 record itself and its + corresponding RRSIG record. + + The bitmap for the NSEC3 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. + + The following steps describe the proper construction of NSEC3 + records. + 1. Sort the zone in canonical order. + 2. For each unique original owner name, add a NSEC3 RRset, where the + ownername of the NSEC3 RR is the hashed equivalent of the + original owner name, prepended to the zone name. + 3. For each RRset at the original owner, set the corresponding bit + in the type bit map. If the RRset signifies an unsecured + delegation point, and the policy is to have Authoritative Only + RRsets, mark this NSEC3 RR. + 4. If the difference in labels between the apex and the original + ownername is greater then 1, additional NSEC3 need to be added + for every intermediate label level between the apex and the + original ownername. + 5. sort the set of NSEC3 RRs. + 6. In each NSEC3 RR, insert the Next Hashed Ownername. If the next + hashed ownername is a marked NSEC3 (from step 3), delete the + marked NSEC3 from the zone, set the Authoritative Only bit in the + current NSEC3 RRs, and repeat this step. The last NSEC3 in the + zone will contain the value of the first NSEC3 in the zone. + +6. Special Considerations + + The following paragraphs clarify specific behaviour explain special + considerations for implementations. + +6.1 delegation points + + This proposal introduces the Authoritative Only Flag which indicates + + + +Laurie, et al. Expires August 2, 2005 [Page 10] + +Internet-Draft nsec3 february 2005 + + + whether non authoritative delegation point NS records are included in + the type bit Maps. As discussed in paragraph 2.1.1, a flag value of + 0 indicates that the interpretation of the type bit maps is identical + to NSEC records. + + The following subsections describe behaviour when the flag value is + 1. + +6.1.1 Unsigned Delegations + + Delegation point NS records are not authoritative. They are + authoritative in the delegated zone. No other data exists at the + ownername of an unsigned delegation point. + + Since no authoritative data exist at this ownername, it is excluded + from the NSEC3 chain. This is an optimization since it relieves the + zone of including an NSEC3 record and its associated signature for + this name. + + An NSEC3 that denies existence of ownernames between X and X' with + the Authoritative Only Flag set to 1 can not be used to proof + presence nor absence of the delegation point NS records for unsigned + delegations in the interval X, X'. The Authoritative Only Flag + effectively states No Contest on the presence of delegation point NS + resource records. + + Since proof is absent, there exists a new attack vector. Unsigned + delegation point NS records can be deleted during a man in the middle + attack, effectively denying existence of the delegation. This is a + form of Denial of Service, where the victim has no information it is + under attack, since all signatures are valid and the fabricated + response form is a known type of response. + + The only possible mitigation is to either not use this method, hence + proving existence or absence of unsigned delegations, or signing the + delegated zone, changing the unsigned delegation into a signed + delegation. + + A second attack vector exists in that an adversary is able to + successfully fabricate a response claiming a not existent delegation + to exist, though unsigned. + + The only possible mitigation is to either not use this method, hence + proving absence of unsigned delegations. + +6.2 Additional Complexity Caused by Wildcards + + If a wildcard ownername appears in a zone, the wildcard label ("*") + + + +Laurie, et al. Expires August 2, 2005 [Page 11] + +Internet-Draft nsec3 february 2005 + + + is treated as a literal symbol and is treated in the same way as any + other ownername for purposes of generating NSEC3 RRs. RFC 2535 + [RFC2525] describes the impact of wildcards on authenticated denial + of existence. + + In order to prove there are no wildcards for a domain, as well as no + RRs that match directly, an RR must be shown for the closest + encloser, and non-existence must be shown for all enclosers that + could be closer. + +6.3 Salting + + Augmenting original ownernames with salt before hashing increases the + cost of a dictionary of pre-generated hash-values. For every bit of + salt, the cost of the dictionary doubles. The NSEC3 RR can use + maximum 2040 bits of salt, multiplying the cost by 2^2040. + + The salt value for each NSEC3 RR MUST be equal for a single version + of the zone. + +6.4 Hash Collision + + Hash collisions occur when different messages have the same hash + value. The expected number of domain names needed to give a 1 in 2 + chance of a single collision is about 2^80. Though this probability + is extremely low, the following paragraphs deal with avoiding + collisions and assessing possible damage in the event of an attack + using Hash collisions. + +6.4.1 Avoiding Hash Collisions during generation + + During generation of NSEC3 RRs, hash values are supposedly unique. + In the (academic) case of a collision occurring, an alternative salt + SHOULD be chosen and all hash values SHOULD be regenerated. + + If hash values are not regenerated on collision, the NSEC3 RR MUST + list all authoritative RR types that exist for both owners, to avoid + a replay attack, spoofing an existing type as non-existent. + +6.4.2 Second Preimage Requirement Analysis + + A collision resistant hash function has a second-preimage resistance + property. The second-preimage resistance property means that it is + computationally infeasible to find another message with the same hash + value as a given message, i.e. given preimage X, to find a second + preimage X' <> X such that hash(X) = hash(X'). The probability of + finding a second preimage is 1 in 2^160 for SHA-1 on average. To + mount an attack using an existing NSEC3 RR, an adversary needs to + + + +Laurie, et al. Expires August 2, 2005 [Page 12] + +Internet-Draft nsec3 february 2005 + + + find a second preimage. + + Assuming an adversary is capable of mounting such an extreme attack, + the actual damage is that a response message can be generated which + claims that a certain QNAME (i.e. the second pre-image) does exist, + while in reality QNAME does not exist (a false positive), which will + either cause a security aware resolver to re-query for the + non-existent name, or to fail the initial query. Note that the + adversary can't mount this attack on an existing name but only on a + name that the adversary can't choose and does not yet exist. + +6.4.3 Possible Hash Value Truncation Method + + The previous sections outlined the low probability and low impact of + a second-preimage attack. When impact and probability are low, while + space in a DNS message is costly, truncation is tempting. Truncation + might be considered to allow for shorter ownernames and rdata for + hashed labels. In general, if a cryptographic hash is truncated to n + bits, then the expected number of domains required to give a 1 in 2 + probability of a single collision is approximately 2^(n/2) and the + work factor to produce a second preimage resistance is 2^n. + + An extreme hash value truncation would be truncating to the shortest + possible unique label value. Considering that hash values are + presented in base32, which represents 5 bits per label character, + truncation must be done on a 5 bit boundary. This would be unwise, + since the work factor to produce collisions would then approximate + the size of the zone. + + Though the mentioned truncation can be maximized to a certain + extreme, the probability of collision increases exponentially for + every truncated bit. Given the low impact of hash value collisions + and limited space in DNS messages, the balance between truncation + profit and collision damage may be determined by local policy. + +7. Performance Considerations + + Iterated hashes will obviously impose a performance penalty on both + authoritative servers and resolvers. Therefore, the number of + iterations should be carefully chosen. + +8. IANA Considerations + + IANA has to create a new registry for NSEC3 Hash Functions. The + range for this registry is 0-127. Value 1 is marked as SHA-1. + Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is + marked as Experimental. + + + + +Laurie, et al. Expires August 2, 2005 [Page 13] + +Internet-Draft nsec3 february 2005 + + +9. Security Considerations + + The NSEC3 records are still susceptible to dictionary attacks (i.e. + the attacker retrieves all the NSEC3 records, then calculates the + hashes of all likely domain names, comparing against the hashes found + in the NSEC3 records, and thus enumerating the zone). These are + substantially more expensive than traversing the original NSEC + records would have been, and in any case, such an attack could also + be used directly against the name server itself by performing queries + for all likely names. The expense of this attack can be chosen by + setting the iterations in the NSEC3 RR. + + High-value domains are also susceptible to a precalculated dictionary + attack - that is, a list of hashes for all likely names is computed + once, then NSEC3 is scanned periodically and compared against the + precomputed hashes. This attack is prevented by changing the salt on + a regular basis. + + Walking the NSEC3 RRs will reveal the total number of records in the + zone, and also what types they are. This could be mitigated by + adding dummy entries, but certainly an upper limit can always be + found. + + Hash collisions may occur. If they do, it will be impossible to + prove the non-existence of the colliding domain - however, this is + fantastically unlikely, and, in any case, DNSSEC already relies on + SHA-1 to not collide. + +10. Requirements notation + + 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]. + +11. Security Considerations + +Appendix A. Example Zone + + This is a zone showing its NSEC3 records. They can also be used as + test vectors for the hash algorithm. RRSIG records have been elided. + + + + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 14] + +Internet-Draft nsec3 february 2005 + + + example.com. 1000 IN SOA localhost. + postmaster.localhost.example.com. ( + 1 ; serial + 3600 ; refresh (1 hour) + 1800 ; retry (30 minutes) + 604800 ; expire (1 week) + 3600 ; minimum (1 hour) + ) + 1000 NS ns1.example.com. + 1000 NS ns2.example.com. + f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ + NS SOA RRSIG DNSKEY NSEC3 + a.example.com. 1000 IN A 1.2.3.4 + 1000 IN A 1.2.3.5 + 1000 TXT "An example" + bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ + A TXT RRSIG NSEC3 + b.example.com. 1000 IN A 1.2.3.7 + 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ + A RRSIG NSEC3 + a.b.c.example.com. 1000 IN A 1.2.3.6 + a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ + A RRSIG NSEC3 + ns1.example.com. 1000 IN A 1.2.3.8 + 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ + A RRSIG NSEC3 + ns2.example.com. 1000 IN A 1.2.3.9 + 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ + SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ + A RRSIG NSEC3 + + +12. References + +12.1 Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + + + +Laurie, et al. Expires August 2, 2005 [Page 15] + +Internet-Draft nsec3 february 2005 + + + 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. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + +12.2 Informative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + [rollover] + Ihren, J., Kolkman, O. and B. Manning, "An In-Band + Rollover Algorithm and a Out-Of-Band Priming Method for + DNS Trust Anchors.", July 2004. + + +Authors' Addresses + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + Phone: +44 (20) 8735 0686 + EMail: ben@algroup.co.uk + + + Geoffrey Sisson + Nominet + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 16] + +Internet-Draft nsec3 february 2005 + + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + The Netherlands + + Phone: +31 (53) 485 0485 + EMail: roy.arends@telin.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 17] + +Internet-Draft nsec3 february 2005 + + +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 (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Laurie, et al. Expires August 2, 2005 [Page 18] + + diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt new file mode 100644 index 0000000000..0d0451ace1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt @@ -0,0 +1,785 @@ + + +Network Working Group S. Josefsson +Internet-Draft January 2005 +Expires: July 2, 2005 + + + Storing Certificates in the Domain Name System (DNS) + draft-ietf-dnsext-rfc2538bis-01 + +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 July 2, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Cryptographic public key are frequently published and their + authenticity demonstrated by certificates. A CERT resource record + (RR) is defined so that such certificates and related certificate + revocation lists can be stored in the Domain Name System (DNS). + + + + + + + +Josefsson Expires July 2, 2005 [Page 1] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 + 2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4 + 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5 + 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 + 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 + 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 + 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8 + 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 3.5 Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9 + 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 + A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires July 2, 2005 [Page 2] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +1. Introduction + + Public keys are frequently published in the form of a certificate and + their authenticity is commonly demonstrated by certificates and + related certificate revocation lists (CRLs). A certificate is a + binding, through a cryptographic digital signature, of a public key, + a validity interval and/or conditions, and identity, authorization, + or other information. A certificate revocation list is a list of + certificates that are revoked, and incidental information, all signed + by the signer (issuer) of the revoked certificates. Examples are + X.509 certificates/CRLs in the X.500 directory system or OpenPGP + certificates/revocations used by OpenPGP software. + + Section 2 below specifies a CERT resource record (RR) for the storage + of certificates in the Domain Name System. + + Section 3 discusses appropriate owner names for CERT RRs. + + Sections 4, 5, and 6 below cover performance, IANA, and security + considerations, respectively. + + 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 [10]. + +2. The CERT Resource Record + + The CERT resource record (RR) has the structure given below. Its RR + type code is 37. + + 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 | key tag | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | / + +---------------+ certificate or CRL / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + The type field is the certificate type as define in section 2.1 + below. + + The algorithm field has the same meaning as the algorithm field in + DNSKEY and RRSIG RRs [9] except that a zero algorithm field indicates + the algorithm is unknown to a secure DNS, which may simply be the + result of the algorithm not having been standardized for DNSSEC. + + + + +Josefsson Expires July 2, 2005 [Page 3] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + The key tag field is the 16 bit value computed for the key embedded + in the certificate, using the RRSIG Key Tag Algorithm described in + Appendix B of [9]. This field is used as an efficiency measure to + pick which CERT RRs may be applicable to a particular key. The key + tag can be calculated for the key in question and then only CERT RRs + with the same key tag need be examined. However, the key must always + be transformed to the format it would have as the public key portion + of a DNSKEY RR before the key tag is computed. This is only possible + if the key is applicable to an algorithm (and limits such as key size + limits) defined for DNS security. If it is not, the algorithm field + MUST BE zero and the tag field is meaningless and SHOULD BE zero. + +2.1 Certificate Type Values + + The following values are defined or reserved: + + Value Mnemonic Certificate Type + ----- -------- ----------- ---- + 0 reserved + 1 PKIX X.509 as per PKIX + 2 SPKI SPKI certificate + 3 PGP OpenPGP packet + 4 IPKIX The URL of an X.509 data object + 5 ISPKI The URL of an SPKI certificate + 6 IPGP The URL of an OpenPGP packet + 7-252 available for IANA assignment + 253 URI URI private + 254 OID OID private + 255-65534 available for IANA assignment + 65535 reserved + + The PKIX type is reserved to indicate an X.509 certificate conforming + to the profile being defined by the IETF PKIX working group. The + certificate section will start with a one byte unsigned OID length + and then an X.500 OID indicating the nature of the remainder of the + certificate section (see 2.3 below). (NOTE: X.509 certificates do + not include their X.500 directory type designating OID as a prefix.) + + The SPKI type is reserved to indicate a certificate formated as to be + specified by the IETF SPKI working group. + + The PGP type indicates an OpenPGP packet as described in [5] and its + extensions and successors. Two uses are to transfer public key + material and revocation signatures. The data is binary, and MUST NOT + be encoded into an ASCII armor. An implementation SHOULD process + transferable public keys as described in section 10.1 of [5], but it + MAY handle additional OpenPGP packets. + + + + +Josefsson Expires July 2, 2005 [Page 4] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the + content that would have been in the "certificate, CRL or URL" field + of the corresponding (PKIX, SPKI or PGP) packet types. These types + are known as "indirect". These packet types MUST be used when the + content is too large to fit in the CERT RR, and MAY be used at the + implementations discretion. They SHOULD NOT be used where the entire + UDP packet would have fit in 512 bytes. + + The URI private type indicates a certificate format defined by an + absolute URI. The certificate portion of the CERT RR MUST begin with + a null terminated URI [4] and the data after the null is the private + format certificate itself. The URI SHOULD be such that a retrieval + from it will lead to documentation on the format of the certificate. + Recognition of private certificate types need not be based on URI + equality but can use various forms of pattern matching so that, for + example, subtype or version information can also be encoded into the + URI. + + The OID private type indicates a private format certificate specified + by a an ISO OID prefix. The certificate section will start with a + one byte unsigned OID length and then a BER encoded OID indicating + the nature of the remainder of the certificate section. This can be + an X.509 certificate format or some other format. X.509 certificates + that conform to the IETF PKIX profile SHOULD be indicated by the PKIX + type, not the OID private type. Recognition of private certificate + types need not be based on OID equality but can use various forms of + pattern matching such as OID prefix. + +2.2 Text Representation of CERT RRs + + The RDATA portion of a CERT RR has the type field as an unsigned + decimal integer or as a mnemonic symbol as listed in section 2.1 + above. + + The key tag field is represented as an unsigned decimal integer. + + The algorithm field is represented as an unsigned decimal integer or + a mnemonic symbol as listed in [9]. + + The certificate / CRL portion is represented in base 64 [11] and may + be divided up into any number of white space separated substrings, + down to single base 64 digits, which are concatenated to obtain the + full signature. These substrings can span lines using the standard + parenthesis. + + Note that the certificate / CRL portion may have internal sub-fields + but these do not appear in the master file representation. For + example, with type 254, there will be an OID size, an OID, and then + + + +Josefsson Expires July 2, 2005 [Page 5] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + the certificate / CRL proper. But only a single logical base 64 + string will appear in the text representation. + +2.3 X.509 OIDs + + OIDs have been defined in connection with the X.500 directory for + user certificates, certification authority certificates, revocations + of certification authority, and revocations of user certificates. + The following table lists the OIDs, their BER encoding, and their + length prefixed hex format for use in CERT RRs: + + id-at-userCertificate + = { joint-iso-ccitt(2) ds(5) at(4) 36 } + == 0x 03 55 04 24 + id-at-cACertificate + = { joint-iso-ccitt(2) ds(5) at(4) 37 } + == 0x 03 55 04 25 + id-at-authorityRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 38 } + == 0x 03 55 04 26 + id-at-certificateRevocationList + = { joint-iso-ccitt(2) ds(5) at(4) 39 } + == 0x 03 55 04 27 + + +3. Appropriate Owner Names for CERT RRs + + It is recommended that certificate CERT RRs be stored under a domain + name related to their subject, i.e., the name of the entity intended + to control the private key corresponding to the public key being + certified. It is recommended that certificate revocation list CERT + RRs be stored under a domain name related to their issuer. + + Following some of the guidelines below may result in the use in DNS + names of characters that require DNS quoting which is to use a + backslash followed by the octal representation of the ASCII code for + the character such as \000 for NULL. + + The choice of name under which CERT RRs are stored is important to + clients that perform CERT queries. In some situations, the client + may not know all information about the CERT RR object it wishes to + retrieve. For example, a client may not know the subject name of an + X.509 certificate, or the e-mail address of the owner of an OpenPGP + key. Further, the client might only know the hostname of a service + that uses X.509 certificates or the Key ID of an OpenPGP key. + + This motivates describing two different owner name guidelines. We + call the two rules content-based owner names and purpose-based owner + + + +Josefsson Expires July 2, 2005 [Page 6] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + names. A content-based owner name is derived from the content of the + CERT RR data; for example the Subject field in an X.509 certificate + or the User ID field in OpenPGP keys. A purpose-based owner name is + selected to be a name that clients that wishes to retrieve CERT RRs + are expected to know; for example the host name of a X.509 protected + service or a Key ID of an OpenPGP key. Note that in some situations, + the content-based and purpose-based owner name can be the same; for + example when a client look up keys based on e-mail addresses for + incoming e-mail. + + Implementations SHOULD use the purpose-based owner name guidelines + described in this document, and MAY use CNAMEs at content-based owner + names (or other names), pointing to the purpose-based owner name. + +3.1 Content-based X.509 CERT RR Names + + Some X.509 versions permit multiple names to be associated with + subjects and issuers under "Subject Alternate Name" and "Issuer + Alternate Name". For example, x.509v3 has such Alternate Names with + an ASN.1 specification as follows: + + GeneralName ::= CHOICE { + otherName [0] INSTANCE OF OTHER-NAME, + rfc822Name [1] IA5String, + dNSName [2] IA5String, + x400Address [3] EXPLICIT OR-ADDRESS.&Type, + directoryName [4] EXPLICIT Name, + ediPartyName [5] EDIPartyName, + uniformResourceIdentifier [6] IA5String, + iPAddress [7] OCTET STRING, + registeredID [8] OBJECT IDENTIFIER + } + + The recommended locations of CERT storage are as follows, in priority + order: + 1. If a domain name is included in the identification in the + certificate or CRL, that should be used. + 2. If a domain name is not included but an IP address is included, + then the translation of that IP address into the appropriate + inverse domain name should be used. + 3. If neither of the above it used but a URI containing a domain + name is present, that domain name should be used. + 4. If none of the above is included but a character string name is + included, then it should be treated as described for OpenPGP + names below. + 5. If none of the above apply, then the distinguished name (DN) + should be mapped into a domain name as specified in [3]. + + + + +Josefsson Expires July 2, 2005 [Page 7] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + Example 1: Assume that an X.509v3 certificate is issued to /CN=John + Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative + names of (a) string "John (the Man) Doe", (b) domain name john- + doe.com, and (c) uri . Then + the storage locations recommended, in priority order, would be + 1. john-doe.com, + 2. www.secure.john-doe.com, and + 3. Doe.com.xy. + + Example 2: Assume that an X.509v3 certificate is issued to /CN=James + Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names + of (a) domain name widget.foo.example, (b) IPv4 address + 10.251.13.201, and (c) string "James Hacker + ". Then the storage locations + recommended, in priority order, would be + 1. widget.foo.example, + 2. 201.13.251.10.in-addr.arpa, and + 3. hacker.mail.widget.foo.example. + +3.2 Purpose-based X.509 CERT RR Names + + It is difficult for clients that do not already posses a certificate + to reconstruct the content-based owner name that should be used to + retrieve the certificate. For this reason, purpose-based owner names + are recommended in this section. Because purpose-based owner names + by nature depend on the specific scenario, or purpose, for which the + certificate will be used, there are more than one recommendation. + The following table summarize the purpose-based X.509 CERT RR owner + name guidelines. + + Scenario Owner name + ------------------------------------------------------------------- + S/MIME Certificate Standard translation of RFC 822 email address. + Example: A S/MIME certificate for + "postmaster@example.org" will use a standard + hostname translation of the owner name, + i.e. "postmaster.example.org". + + SSL Certificate Hostname of the SSL server. + + IPSEC Certificate Hostname of the IPSEC machine, and/or + for the in-addr.arpa reverse lookup IP address. + + An alternative approach for IPSEC is to store raw public keys [12]. + +3.3 Content-based OpenPGP CERT RR Names + + OpenPGP signed keys (certificates) use a general character string + + + +Josefsson Expires July 2, 2005 [Page 8] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + User ID [5]. However, it is recommended by OpenPGP that such names + include the RFC 2822 [7] email address of the party, as in "Leslie + Example ". If such a format is used, the CERT + should be under the standard translation of the email address into a + domain name, which would be leslie.host.example in this case. If no + RFC 2822 name can be extracted from the string name no specific + domain name is recommended. + + If a user has more than one email address, the CNAME type can be used + to reduce the amount of data stored in the DNS. For example: + + $ORIGIN example.org. + smith IN CERT PGP 0 0 + john.smith IN CNAME smith + js IN CNAME smith + + +3.4 Purpose-based OpenPGP CERT RR Names + + Applications that receive an OpenPGP packet containing encrypted or + signed data but do not know the email address of the sender will have + difficulties constructing the correct owner name and cannot use the + content-based owner name guidelines. However, these clients commonly + know the key fingerprint or the Key ID. The key ID is found in + OpenPGP packets, and the key fingerprint is commonly found in + auxilliary data that may be available. For these situations, it is + recommended to use an owner name identical to the key fingerprint and + key ID expressed in hexadecimal [11]. For example: + + $ORIGIN example.org. + 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... + F835EDA21E94B565716F IN CERT PGP ... + B565716F IN CERT PGP ... + + If the same key material is stored at several owner names, the use of + CNAME may be used to avoid data duplication. Note that CNAME is not + always applicable, because it map an owner names to the other for all + purposes, and this may be sub-optimal when two keys with the same Key + ID are stored. + +3.5 Owner names for IPKIX, ISPKI, and IPGP + + These types are stored under the same owner names, both purpose- and + content-based, as the PKIX, SPKI and PGP types, respectively. + +4. Performance Considerations + + Current Domain Name System (DNS) implementations are optimized for + + + +Josefsson Expires July 2, 2005 [Page 9] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + small transfers, typically not more than 512 bytes including + overhead. While larger transfers will perform correctly and work is + underway to make larger transfers more efficient, it is still + advisable at this time to make every reasonable effort to minimize + the size of certificates stored within the DNS. Steps that can be + taken may include using the fewest possible optional or extensions + fields and using short field values for variable length fields that + must be included. + + The RDATA field in the DNS protocol may only hold data of size 65535 + octets (64kb) or less. This means that each CERT RR cannot contain + more than 64kb worth of payload, even if the corresponding + certificate or certificate revocation list is larger. This document + address this by defining "indirect" data types for each normal type. + +5. Acknowledgements + + The majority of this document is copied verbatim from RFC 2538, by + Donald Eastlake 3rd and Olafur Gudmundsson. + + The author wishes to thank David Shaw and Michael Graff for their + contributions to the earlier work that motivated this revised + document. + + This document was improved by suggestions and comments from Olivier + Dubuisson, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt + the list is incomplete. We apologize to anyone we left out. + +6. Security Considerations + + By definition, certificates contain their own authenticating + signature. Thus it is reasonable to store certificates in non-secure + DNS zones or to retrieve certificates from DNS with DNS security + checking not implemented or deferred for efficiency. The results MAY + be trusted if the certificate chain is verified back to a known + trusted key and this conforms with the user's security policy. + + Alternatively, if certificates are retrieved from a secure DNS zone + with DNS security checking enabled and are verified by DNS security, + the key within the retrieved certificate MAY be trusted without + verifying the certificate chain if this conforms with the user's + security policy. + + When the URI type is used, it should be understood that it introduces + an additional indirection that may allow for a new attack vector. + One method to secure that indirection is to include a hash of the + certificate in the URI itself. + + + + +Josefsson Expires July 2, 2005 [Page 10] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + CERT RRs are not used by DNSSEC [8] so there are no security + considerations related to CERT RRs and securing the DNS itself. + + If DNSSEC [8] is used then the non-existence of a CERT RR, and + consequently certificates or revocation lists, can be securely + asserted. Without DNSSEC, this is not possible. + +7. IANA Considerations + + Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can + only be assigned by an IETF standards action [6]. This document + assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate + types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] + based on RFC documentation of the certificate type. The availability + of private types under 0x00FD and 0x00FE should satisfy most + requirements for proprietary or private types. + +8. Changes since RFC 2538 + + 1. Editorial changes to conform with new document requirements, + including splitting reference section into two parts and updating + the references to point at latest versions, and to add some + additional references. + 2. Improve terminology. For example replace "PGP" with "OpenPGP", + to align with RFC 2440. + 3. In section 2.1, clarify that OpenPGP public key data are binary, + not the ASCII armored format, and reference 10.1 in RFC 2440 on + how to deal with OpenPGP keys, and acknowledge that + implementations may handle additional packet types. + 4. Clarify that integers in the representation format are decimal. + 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis + terminology. Improve reference for Key Tag Algorithm + calculations. + 6. Add examples that suggest use of CNAME to reduce bandwidth. + 7. In section 3, appended the last paragraphs that discuss + "content-based" vs "purpose-based" owner names. Add section 3.2 + for purpose-based X.509 CERT owner names, and section 3.4 for + purpose-based OpenPGP CERT owner names. + 8. Added size considerations. + 9. Added indirect types IPKIX, ISPKI, and IPGP. + +9. References + +9.1 Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + + + +Josefsson Expires July 2, 2005 [Page 11] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + + [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP + Message Format", RFC 2440, November 1998. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [9] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + +9.2 Informative References + + [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + [12] Richardson, M., "A method for storing IPsec keying material in + DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004. + + +Author's Address + + Simon Josefsson + + EMail: simon@josefsson.org + +Appendix A. Copying conditions + + Regarding the portion of this document that was written by Simon + + + +Josefsson Expires July 2, 2005 [Page 12] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + Josefsson ("the author", for the remainder of this section), the + author makes no guarantees and is not responsible for any damage + resulting from its use. The author grants irrevocable permission to + anyone to use, modify, and distribute it in any way that does not + diminish the rights of anyone else to use, modify, and distribute it, + provided that redistributed derivative works do not contain + misleading author or version information. Derivative works need not + be licensed under similar terms. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires July 2, 2005 [Page 13] + +Internet-Draft Storing Certificates in the DNS January 2005 + + +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 (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Josefsson Expires July 2, 2005 [Page 14] + + diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt new file mode 100644 index 0000000000..32460b89b4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt @@ -0,0 +1,729 @@ + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Expires: April 14, 2005 October 14, 2004 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-00 + +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 April 14, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against single key compromise of a key in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor. + + This mechanism, if adopted, will require changes to resolver + + + +StJohns Expires April 14, 2005 [Page 1] + +Internet-Draft trustanchor-update October 2004 + + + management behavior (but not resolver resolution behavior), and the + addition of a single flag bit to the DNSKEY record. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 + 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 + 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 + 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 + 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 + 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 + 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 + 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 12 + + + + + + + + + + + + + + + + +StJohns Expires April 14, 2005 [Page 2] + +Internet-Draft trustanchor-update October 2004 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community + has come to the realization that there will not be one signed name + space, but rather islands of signed name space each originating from + specific points (i.e. 'trust points') in the DNS tree. Each of + those islands will be identified by the trust point name, and + validated by at least one associated public key. For the purpose of + this document we'll call the association of that name and a + particular key a 'trust anchor'. A particular trust point can have + more than one key designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key + replacement/rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1 Compliance Nomenclature + + 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 BCP 14, [RFC2119]. + +1.2 Changes since -00 + + Resubmitted draft-stjohns-dnssec-trustupdate as a working group + + + +StJohns Expires April 14, 2005 [Page 3] + +Internet-Draft trustanchor-update October 2004 + + + draft. + + Added the concept of timer triggered resolver queries to refresh the + resolvers view of the trust anchor key RRSet. + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a new SEP key is added to a trust point + DNSKEY RRSet, and when that RRSet is validated by an existing trust + anchor, then the new key can be added to the set of trust anchors. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example assuming a single key + compromise, an attacker could add a new key and revoke all the other + old keys. + +2.1 Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a + self-signed RRSet and the key has the REVOKE bit set to '1'. Once + the resolver sees the REVOKE bit, it MUST NOT use this key as a trust + anchor or for any other purposes except validating the RRSIG over the + DNSKEY RRSet specifically for the purpose of validating the + revocation. Unlike the 'Add' operation below, revocation is + immediate and permanent upon receipt of a valid revocation at the + resolver. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. [msj3] + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + + + + + + +StJohns Expires April 14, 2005 [Page 4] + +Internet-Draft trustanchor-update October 2004 + + +2.2 Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in the both + the attacker and owner being able to sign data in the zone and have + it accepted as valid by resolvers. + + To mitigate, but not completely solve, this problem, we add a + hold-down time to the addition of the trust anchor. When the + resolver sees a new SEP key in a validated trust point DNSKEY RRSet, + the resolver starts an acceptance timer, and remembers all the keys + that validated the RRSet. If the resolver ever sees the DNSKEY RRSet + without the new key but validly signed, it stops the acceptance + process and resets the acceptance timer. If all of the keys which + were originally used to validate this key are revoked prior to the + timer expiring, the resolver stops the acceptance process and resets + the timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3 Remove Hold-down + + A new key which has been seen by the resolver, but hasn't reached + it's add hold-down time, MAY be removed from the DNSKEY RRSet by the + zone owner. If the resolver sees a validated DNSKEY RRSet without + this key, it waits for the remove hold-down time and then, if the key + + + +StJohns Expires April 14, 2005 [Page 5] + +Internet-Draft trustanchor-update October 2004 + + + hasn't reappeared, SHOULD discard any information about the key. + +2.4 Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + RRSet or half the RRSIG expiration interval. The expiration interval + is the amount of time from when the RRSIG was last retrieved until + the expiration time in the RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. + +2.5 Resolver Parameters + +2.5.1 Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the TTL + of the first trust point DNSKEY RRSet which contained the key, + whichever is greater. This ensures that at least two validated + DNSKEY RRSets which contain the new key MUST be seen by the resolver + prior to the key's acceptance. + +2.5.2 Remove Hold-Down Time + + The remove hold-down time is 30 days. + +2.5.3 Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validing the revocation. + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + + + +StJohns Expires April 14, 2005 [Page 6] + +Internet-Draft trustanchor-update October 2004 + + + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + The resolver's view of the state of the key changes as various events + occur. + + [msj1] This is the state of a trust point key as seen from the + resolver. The column on the left indicates the current state. The + header at the top shows the next state. The intersection of the two + shows the event that will cause the state to transition from the + current state to the next. + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + +4.1 Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after its been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with its + "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + +4.2 States + + + + + + +StJohns Expires April 14, 2005 [Page 7] + +Internet-Draft trustanchor-update October 2004 + + + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but hasn't yet been + seen at the resolver. + AddPend The key has been seen at the resolver, has its 'SEP' bit set, + and has been included in a validated DNSKEY RRSet. There is a + hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. [Discussion + item: Should a missing key be considered revoked after some + period of time?] + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. + +5. Scenarios + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and SHOULD) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +5.1 Adding A Trust Anchor + + Assume an existing trust anchor key 'A'. + + + +StJohns Expires April 14, 2005 [Page 8] + +Internet-Draft trustanchor-update October 2004 + + + 1. Generate a new key pair. + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while. + +5.2 Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revolcation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator SHOULD include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + +5.3 Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has + been in the DNSKEY RRSet and is a valid trust anchor, but wasn't + being used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator SHOULD include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +5.4 Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 5.3) + above assuming 'A' is the active key. + +5.5 Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 5.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' SHOULD continue to be + + + +StJohns Expires April 14, 2005 [Page 9] + +Internet-Draft trustanchor-update October 2004 + + + included in the RRSet for the remove hold-down time. + +6. Security Considerations + +6.1 Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +6.2 Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + +6.3 Dynamic Updates + + Allowing a resolver to update its trust anchor set based in-band key + information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + +7 Normative References + + [DSINTRO] Arends, R., "DNS Security Introduction and Requirements", + ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004, + . + + [DSPROT] Arends, R., "Protocol Modifications for the DNS Security + Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt, + + + +StJohns Expires April 14, 2005 [Page 10] + +Internet-Draft trustanchor-update October 2004 + + + October 2004, + . + + [DSREC] Arends, R., "Resource Records for the DNS Security + Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt, + October 2004, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + +Editorial Comments + + [msj1] msj: N.B. This table is preliminary and will be revised to + match implementation experience. For example, should there + be a state for "Add hold-down expired, but haven't seen the + new RRSet"? + + [msj2] msj: To be assigned. + + [msj3] msj: For discussion: What's the implementation guidance for + resolvers currently with respect to the non-assigned flag + bits? If they consider the flag bit when doing key matching + at the trust anchor, they won't be able to match. + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + EMail: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + +StJohns Expires April 14, 2005 [Page 11] + +Internet-Draft trustanchor-update October 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. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +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. + + + + + +StJohns Expires April 14, 2005 [Page 12] + +Internet-Draft trustanchor-update October 2004 + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Expires April 14, 2005 [Page 13] + + diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt new file mode 100644 index 0000000000..9537af6534 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt @@ -0,0 +1,1123 @@ + + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: April 27, 2005 VeriSign + October 27, 2004 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-03 + +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 April 27, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This memo describes DNS name server and resolver behavior that + results in a significant query volume sent to the root and top-level + domain (TLD) name servers. In some cases we recommend minor + additions to the DNS protocol specification and corresponding changes + in iterative resolver implementations to alleviate these unnecessary + queries. The recommendations made in this document are a direct + byproduct of observation and analysis of abnormal query traffic + + + +Larson & Barber Expires April 27, 2005 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + patterns seen at two of the thirteen root name servers and all + thirteen com/net TLD name servers. + + 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 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 A note about terminology in this memo . . . . . . . . . . 3 + 2. Observed iterative resolver misbehavior . . . . . . . . . . 5 + 2.1 Aggressive requerying for delegation information . . . . . 5 + 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6 + 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 6 + 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7 + 2.3 Inability to follow multiple levels of out-of-zone glue . 7 + 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 8 + 2.4 Aggressive retransmission when fetching glue . . . . . . . 8 + 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9 + 2.5 Aggressive retransmission behind firewalls . . . . . . . . 9 + 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10 + 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 10 + 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11 + 2.7 Name server records with zero TTL . . . . . . . . . . . . 11 + 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12 + 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 12 + 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.9 Queries for domain names resembling IP addresses . . . . . 13 + 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.10 Misdirected recursive queries . . . . . . . . . . . . . 14 + 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 14 + 2.11 Suboptimal name server selection algorithm . . . . . . . 14 + 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 15 + 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 16 + 4. Security considerations . . . . . . . . . . . . . . . . . . 17 + 5. Internationalization considerations . . . . . . . . . . . . 18 + 6. Normative References . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . 20 + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question () asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses (i.e., the + same query received simultaneously from multiple IP addresses). + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of glue records must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. Some of the changes recommended affect the core DNS protocol + specification, described principally in RFC 1034 [2], RFC 1035 [3] + and RFC 2181 [4]. + +1.1 A note about terminology in this memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and cause confusion resulting from + a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + answer questions about certain zones authoritatively. Often called a + "recursive name server" or a "caching name server", it is in fact an + iterative resolver combined with an authoritative name server. + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + because the focus is usually on that component. In instances where + + + +Larson & Barber Expires April 27, 2005 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". For example, the name server + component of a recursive name server receives DNS queries and the + iterative resolver component sends queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address records" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2. Observed iterative resolver misbehavior + +2.1 Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRset in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRset to one of the parent zone's name servers. + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This implementation performs + this query to a zone's parent zone for each recursive query it + receives that fails because of a completely unresponsive set of name + servers for the target zone. Consider the effect when a popular zone + experiences a catastrophic failure of all its name servers: now every + recursive query for domain names in that zone sent to this recursive + name server implementation results in a query to the failed zone's + parent name servers. On one occasion when several dozen popular + zones became unreachable, the query load on the com/net name servers + increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent is pointless: this query to the parent would come so quickly + on the heels of the referral that it would be almost certain to + contain the same list of name servers. The chance of discovering any + new information is slim. + + The other possibility is that the iterative resolver successfully + + + +Larson & Barber Expires April 27, 2005 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [4], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the TTL of the target + zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRset left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + +2.1.1 Recommendation + + An iterative resolver MUST NOT send a query for the NS RRset of a + non-responsive zone to any of the name servers for that zone's parent + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRset: + 1. is not authoritative for the zone (i.e., lame), or, + 2. returns a server failure response (RCODE=2), or, + 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. + +2.2 Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers + are unavailable or misconfigured. Different failure modes have + different expected durations. Some symptoms indicate problems that + are potentially transient; for example, various types of ICMP + unreachable messages because a name server process is not running or + a host or network is unreachable, or a complete lack of a response to + a query. Such responses could be the result of a host rebooting or + temporary outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + + + +Larson & Barber Expires April 27, 2005 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + +2.2.1 Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e. lame servers). + Lame servers MUST be cached against the specific query tuple . Zone name can be derived from the + owner name of the NS record that was referenced to query the name + server that was discovered to be lame. Implementations that perform + lame server caching MUST refrain from sending queries to known lame + servers based on a time interval from when the server is discovered + to be lame. A minimum interval of thirty minutes is RECOMMENDED. + +2.3 Inability to follow multiple levels of out-of-zone glue + + Some iterative resolver implementations are unable to follow more + than one level of out-of-zone glue. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in other gTLDs, increasing the amount + of inter-zone glue. + + + + + +Larson & Barber Expires April 27, 2005 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2.3.1 Recommendation + + Clearly constructing a delegation that relies on multiple levels of + out-of-zone glue is not a good administrative practice. This issue + could be mitigated with an operational injunction in an RFC to + refrain from construction of such delegations. In our opinion the + practice is widespread enough to merit clarifications to the DNS + protocol specification to permit it on a limited basis. + + Iterative resolvers SHOULD be able to handle at least three levels of + indirection resulting from out-of-zone glue. + +2.4 Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers + non-recursive queries from iterative resolvers looking for + information in zones it serves. With glue fetching enabled, however, + an authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a + glue-fetching name server can send queries that reach other name + servers, but is apparently prevented from receiving the responses. + For example, perhaps the name server is authoritative-only and + therefore its administrators expect it to receive only queries and + not responses. Perhaps unaware of glue fetching and presuming that + the name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go answered. + + We have observed name server implementations whose iterative + + + +Larson & Barber Expires April 27, 2005 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1 Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5 Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it can't respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + servers, which could explain how such a situation could persist + without being detected. + + + + + +Larson & Barber Expires April 27, 2005 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2.5.1 Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries to pass through but not the resulting replies. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6 Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRset from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4 of RFC 2181 [4], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a + non-authoritative answer. Thus the "example.com" NS RRset just + received from the "example.com" authoritative server overrides the + "example.com" NS RRset received moments ago from the "com" + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + + + +Larson & Barber Expires April 27, 2005 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in address + record queries to the "com" authoritative servers. Queries for such + obviously bogus glue address records occur frequently at the com/net + name servers. + +2.6.1 Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the SOA of the zone the + NS record appears in. Note that further levels of delegation are + possible, so a missing trailing dot could inadvertently create a name + server name that actually exists in a subzone. But in any case, the + address record must still be present in this zone, either as + authoritative data or glue. + + An authoritative name server SHOULD report an error when one of a + zone's NS records references a name server below the zone's SOA when + a corresponding address record does not exist in the zone. + +2.7 Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + + + +Larson & Barber Expires April 27, 2005 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want iterative resolvers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + +2.7.1 Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone or refuse to load the zone altogether. + +2.8 Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + "internal root" design, there could conceivably be private, + non-public TLD or root zones that would be the appropriate targets + for a dynamic update. + + + +Larson & Barber Expires April 27, 2005 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining closest enclosing zones for future updates. Once + the closest enclosing zone is determined with this method, the update + will either succeed or fail and there is no need to send further + updates to higher-level zones. The important point is that walking + up the tree with queries yields cacheable information, whereas + walking up the tree by sending UPDATE messages does not. + +2.8.1 Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level zones to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9 Queries for domain names resembling IP addresses + + The root name servers receive a significant number of A record + queries where the qname is an IP address. The source of these + queries is unknown. It could be attributed to situations where a + user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1 Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. One possibility is for iterative resolver implementations + to produce the Name Error response directly. We suggest that + implementors consider the option of synthesizing Name Error responses + + + +Larson & Barber Expires April 27, 2005 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + at the iterative resolver. The server could claim authority for + synthesized TLD zones corresponding to the first octet of every + possible IP address, e.g. 1., 2., through 255. This behavior could + be configurable in the (probably unlikely) event that numeric TLDs + are ever put into use. + + Another option is to delegate these numeric TLDs from the root zone + to a separate set of servers to absorb the traffic. The "black hole + servers" used by the the AS 112 +Project [8], which are currently + delegated the in-addr.arpa zones corresponding to RFC 1918 [7] + private use address space, would be a possible choice to receive + these delegations. + +2.10 Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offers recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use name + servers that do not offer recursion, but we are not aware of any stub + resolver implementation that offers any feedback to the user when so + configured, aside from simply "not working". + +2.10.1 Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be immediately notified if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11 Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under specified, requiring + + + +Larson & Barber Expires April 27, 2005 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1 Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + o Do not make assumptions based on NS RRset order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other 12 authoritative servers for "com".) + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +3. IANA considerations + + There are no new IANA considerations introduced by this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +4. Security considerations + + Name server and resolver misbehaviors identical or similar to those + discussed in this document expose the root and TLD name servers to + increased risk of both intentional and unintentional denial of + service. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +5. Internationalization considerations + + We do not believe this document introduces any new + internationalization considerations to the DNS protocol + specification. + +6 Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + + [8] + + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior October 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. + + + + +Larson & Barber Expires April 27, 2005 [Page 20] + + diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt new file mode 100644 index 0000000000..812440c783 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt @@ -0,0 +1,424 @@ + +draft-ietf-dnsop-inaddr-required-06.txt + +INTERNET-DRAFT D. Senie +Category: BCP Amaranth Networks Inc. +Expires in six months February 2005 + + Encouraging the use of DNS IN-ADDR Mapping + +Status of this Memo + + 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 becomes + aware will be disclosed, in accordance with Section 6 of 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 + +Abstract + + Mapping of addresses to names has been a feature of DNS. Many sites, + implement it, many others don't. Some applications attempt to use it + as a part of a security strategy. The goal of this document is to + encourage proper deployment of address to name mappings, and provide + guidance for their use. + +Copyright Notice + + Copyright (C) The Internet Society. (2005) + +1. Introduction + + The Domain Name Service has provision for providing mapping of IP + addresses to host names. It is common practice to ensure both name to + address, and address to name mappings are provided for networks. This + practice, while documented, has never been required, though it is + generally encouraged. This document both encourages the presence of + + + +Senie [Page 1] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + these mappings and discourages reliance on such mappings for security + checks. + + 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]. + +2. Discussion + + + From the early days of the Domain Name Service [RFC883] a special + domain has been set aside for resolving mappings of IP addresses to + domain names. This was refined in [RFC1035], describing the .IN- + ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA + was added [RFC3152]. This document uses IPv4 CIDR block sizes and + allocation strategy where there are differences and uses IPv4 + terminology. Aside from these differences, this document can and + should be applied to both address spaces. + + The assignment of blocks of IP address space was delegated to three + regional registries. Guidelines for the registries are specified in + [RFC2050], which requires regional registries to maintain IN-ADDR + records on the large blocks of space issued to ISPs and others. + + ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger + allocations. For smaller allocations, ARIN can provide IN-ADDR for + /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to + update IN-ADDR, however the present version of its policy document + for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft + copies of this document. As of this writing, it appears APNIC has no + actual policy on IN-ADDR. RIPE appears to have the strongest policy + in this area [RIPE302] indicating Local Internet Registries should + provide IN-ADDR services, and delegate those as appropriate when + address blocks are delegated. + + As we can see, the regional registries have their own policies for + recommendations and/or requirements for IN-ADDR maintenance. It + should be noted, however, that many address blocks were allocated + before the creation of the regional registries, and thus it is + unclear whether any of the policies of the registries are binding on + those who hold blocks from that era. + + Registries allocate address blocks on CIDR [RFC1519] boundaries. + Unfortunately the IN-ADDR zones are based on classful allocations. + Guidelines [RFC2317] for delegating on non-octet-aligned boundaries + exist, but are not always implemented. + +3. Examples of impact of missing IN-ADDR + + + +Senie [Page 2] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + These are some examples of problems that may be introduced by + reliance on IN-ADDR. + + Some applications use DNS lookups for security checks. To ensure + validity of claimed names, some applications will look up IN-ADDR + records to get names, and then look up the resultant name to see if + it maps back to the address originally known. Failure to resolve + matching names is seen as a potential security concern. + + Some FTP sites will flat-out reject users, even for anonymous FTP, if + the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when + itself resolved, does not match. Some Telnet servers also implement + this check. + + Web sites are in some cases using IN-ADDR checks to verify whether + the client is located within a certain geopolitical entity. This + approach has been employed for downloads of crypto software, for + example, where export of that software is prohibited to some locales. + Credit card anti-fraud systems also use these methods for geographic + placement purposes. + + The popular TCP Wrappers program found on most Unix and Linux systems + has options to enforce IN-ADDR checks and to reject any client that + does not resolve. This program also has a way to check to see that + the name given by a PTR record then resolves back to the same IP + address. This method provdes more comfort but no appreciable + additional security. + + Some anti-spam (anti junk email) systems use IN-ADDR to verify the + presence of a PTR record, or validate the PTR value points back to + the same address. + + Many web servers look up the IN-ADDR of visitors to be used in log + analysis. This adds to the server load, but in the case of IN-ADDR + unavailability, it can lead to delayed responses for users. + + Traceroutes with descriptive IN-ADDR naming proves useful when + debugging problems spanning large areas. When this information is + missing, the traceroutes take longer, and it takes additional steps + to determine that network is the cause of problems. + + Wider-scale implementation of IN-ADDR on dialup, wireless access and + other such client-oriented portions of the Internet would result in + lower latency for queries (due to lack of negative caching), and + lower name server load and DNS traffic. + +4. Recommendations + + + + +Senie [Page 3] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + 4.1 Delegation Recommendations + + + Regional Registries and any Local Registries to whom they delegate + should establish and convey a policy to those to whom they delegate + blocks that IN-ADDR mappings are recommended. Policies should + recommend those receiving delegations to provide IN-ADDR service + and/or delegate to downstream customers. + + Network operators should define and implement policies and procedures + which delegate IN-ADDR to their clients who wish to run their own IN- + ADDR DNS services, and provide IN-ADDR services for those who do not + have the resources to do it themselves. Delegation mechanisms should + permit the downstream customer to implement and comply with IETF + recommendations application of IN-ADDR to CIDR [RFC2317]. + + All IP address space assigned and in use should be resolved by IN- + ADDR records. All PTR records must use canonical names. + + All IP addresses in use within a block should have an IN-ADDR + mapping. Those addresses not in use, and those that are not valid for + use (zeros or ones broadcast addresses within a CIDR block) need not + have mappings. + + It should be noted that due to CIDR, many addresses that appear to be + otherwise valid host addresses may actually be zeroes or ones + broadcast addresses. As such, attempting to audit a site's degree of + compliance may only be done with knowledge of the internal subnet + architecture of the site. It can be assumed, however, any host that + originates an IP packet necessarily will have a valid host address, + and must therefore have an IN-ADDR mapping. + +4.2 Application Recommendations + + + Applications SHOULD NOT rely on IN-ADDR for proper operation. The use + of IN-ADDR, sometimes in conjunction with a lookup of the name + resulting from the PTR record provides no real security, can lead to + erroneous results and generally just increases load on DNS servers. + Further, in cases where address block holders fail to properly + configure IN-ADDR, users of those blocks are penalized. + +5. Security Considerations + + This document has no negative impact on security. While it could be + argued that lack of PTR record capabilities provides a degree of + anonymity, this is really not valid. Trace routes, whois lookups and + other sources will still provide methods for discovering identity. + + + +Senie [Page 4] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + By recommending applications avoid using IN-ADDR as a security + mechanism this document points out that this practice, despite its + use by many applications, is an ineffective form of security. + Applications should use better mechanisms of authentication. + +6. IANA Considerations + + There are no IANA considerations for this document. + +7. References + +7.1 Normative References + + [RFC883] P.V. Mockapetris, "Domain names: Implementation + specification," RFC883, November 1983. + + [RFC1035] P.V. Mockapetris, "Domain Names: Implementation + Specification," RFC 1035, November 1987. + + [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): + an Address Assignment and Aggregation Strategy," RFC 1519, September + 1993. + + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", + RFC 2026, BCP 9, October 1996. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation + Guidelines", RFC2050, BCP 12, Novebmer 1996. + + [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," + RFC 2317, March 1998. + + [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August + 2001. + +7.2 Informative References + + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date + unknown, +http://www.arin.net/regserv/initial-isp.html + + [APNIC] "Policies For IPv4 Address Space Management in the Asia + Pacific Region," APNIC-086, 13 January 2003. + + [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 + Address Space in the RIPE NCC Service Region", RIPE-302, April 26, + + + +Senie [Page 5] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + 2004. +http://www.ripe.net//ripe/docs/rev-del.html + + + +8. Acknowledgements + + Thanks to Peter Koch and Gary Miller for their input, and to many + people who encouraged me to write this document. + +9. Author's Address + + Daniel Senie + Amaranth Networks Inc. + 324 Still River Road + Bolton, MA 01740 + + Phone: (978) 779-5100 + + EMail: dts@senie.com + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is + subject to the rights, licenses and restrictions contained in + BCP 78 and except as set forth therein, the authors retain + all their rights. + + This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + + + +Senie [Page 6] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Senie [Page 7] + + + + + + + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt new file mode 100644 index 0000000000..ed63a23ddf --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt @@ -0,0 +1,1427 @@ +DNS Operations WG +Internet-Draft J. Jeong (ed.) + ETRI/University of Minnesota + +Expires: August 2005 19 February 2005 + + + IPv6 Host Configuration of DNS Server Information Approaches + draft-ietf-dnsop-ipv6-dns-configuration-05.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/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html" + + This Internet-Draft will expire on August 19, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). 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. + + + +Jeong, et al. Expires - August 2005 [Page 1] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + Additionally, it suggests four deployment scenarios considering + multi-solution resolution. Therefore, this document will give the + audience a guideline for IPv6 DNS configuration to select the + 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.........................................6 + 3.2. DHCPv6 Option..............................................6 + 3.2.1. Advantages...........................................8 + 3.2.2. Disadvantages........................................8 + 3.2.3. Observations.........................................9 + 3.3. Well-known Anycast Addresses...............................9 + 3.3.1. Advantages..........................................10 + 3.3.2. Disadvantages.......................................10 + 3.3.3. Observations........................................11 + 4. Interworking among IPv6 DNS Configuration Approaches..........11 + 5. Deployment Scenarios..........................................12 + 5.1. ISP Network...............................................13 + 5.1.1. RA Option Approach..................................13 + 5.1.2. DHCPv6 Option Approach..............................13 + 5.1.3. Well-known Addresses Approach.......................14 + 5.2. Enterprise Network........................................14 + 5.3. 3GPP Network..............................................15 + 5.3.1. Currently Available Mechanisms and Recommendations..15 + 5.3.2. RA Extension........................................16 + 5.3.3. Stateless DHCPv6....................................17 + 5.3.4. Well-known Addresses................................18 + 5.3.5. Recommendations.....................................18 + 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.................................................19 + 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..............................................20 + 8. Normative References..........................................20 + 9. Informative References........................................21 + 10. Appendix A - Link-layer Multicast Acknowledgements with RA + Option.......................................................23 + + +Jeong, et al. Expires - August 2005 [Page 2] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 11. Authors' Addresses...........................................23 + 12. Intellectual Property Statement..............................25 + 13. Full Copyright Statement.....................................25 + Acknowledgement..................................................26 + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide the ways to configure either fixed or + mobile nodes with one or more IPv6 addresses, default routes and + some other parameters [3][4]. To support the 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 the 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 the 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 + + + + +Jeong, et al. Expires - August 2005 [Page 3] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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. + An IPv6 host can configure the IPv6 addresses of one or more + 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 option, 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, it is worth noting that some link layers (e.g., WLAN) need + to acknowledge multicast packets, which may increase the amount of + link-layer traffic [25]-[28]. This is discussed in Appendix A. + + The RA approach is useful in some mobile environments where the + addresses of the RDNSSes are changing because the RA option + includes a lifetime field that allows client to use RDNSSes nearer + to the client. 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, the + 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. + + + +Jeong, et al. Expires - August 2005 [Page 4] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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 types on which ND is not + possible; on such links, some other mechanisms will be needed for + DNS configuration. + + 3) All of the information a host needs to run the basic Internet + applications such as the email, web, ftp, etc., can be obtained + with the addition of this option to ND and address autoconfiguration + 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): Refer to Appendix A. 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 needed 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, such as NTP server address, that are common to all + clients on a subnet would be easy to define. + +3.1.2. Disadvantages + + 1) ND is mostly implemented in the kernel part of operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS servers, ND should be extended in the kernel + part, and complemented by a user-land process. DHCPv6, however, + has more flexibility for the 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 the kernel + space and the DNS configuration file in the 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 + + + +Jeong, et al. Expires - August 2005 [Page 5] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + what the kernel conveys, and to have the daemon do these steps, but + such a daemon is not needed 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 + + The proposed RDNSS RA option along with the IPv6 ND and + Autoconfiguration allows a host to obtain all of the information it + needs to access the basic Internet services like the web, email, + ftp, etc. This is preferable in the environments where hosts use + RAs to autoconfigure their addresses and all the 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. The environments like this include + the 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]. The environments like this are most likely + the 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]. + + + + +Jeong, et al. Expires - August 2005 [Page 6] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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 + 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. + + + +Jeong, et al. Expires - August 2005 [Page 7] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + +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. + + 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 + + +Jeong, et al. Expires - August 2005 [Page 8] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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. + +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 + + Anycast uses the same routing system as unicast [11]. However, + administrative entities are local ones. The local entities may + accept unicast routes (including default routes) to anycast servers + from adjacent entities. The administrative entities should not + advertise their peers routes to their internal anycast servers, if + they want to prohibit external access from some peers to the + servers. If some advertisement is inevitable (such as the case + with default routes), the packets to the servers should be blocked + at the boundary of the entities. Thus, for this anycast, not only + unicast routing but also unicast ND protocols can be used as is. + + First of all, the well-known anycast addresses approach is much + different from that discussed at IPv6 Working Group in the past [9]. + 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. + + +Jeong, et al. Expires - August 2005 [Page 9] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + There is no point in having multiple RDNSSes sharing an anycast + address on a single link. + + The approach with well-known anycast addresses is to set multiple + 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. + +3.3.1. Advantages + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, + + 1) There is no delay to get the response and no further delay by + packet losses. + + 2) The approach can be combined with any other configuration + mechanisms, such as RA-based approach and DHCP based approach, as + well as factory default configuration. + + 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 accesses 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). + + +Jeong, et al. Expires - August 2005 [Page 10] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + +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 the configuration effort of users. + + The redundancy by multiple RDNSSes is better provided by multiple + servers having different anycast addresses than multiple servers + sharing the 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 + 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. + + +Jeong, et al. Expires - August 2005 [Page 11] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove the + configuration effort on servers by using the well-known addresses + as the default configuration. Moreover, the clients preconfigured + with the well-known anycast addresses can be further configured to + use other approaches to override the well-known addresses, if the + 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 as follows: + + 1) 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 preconfigured + in IPv6 hosts' resolver configuration files. + + 2) 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. + + 3) 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 the DNS configuration on the IPv6 host, several + mechanisms are 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 for IPv6 DNS configuration. + + + +Jeong, et al. Expires - August 2005 [Page 12] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + +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 + + 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 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. + + + + +Jeong, et al. Expires - August 2005 [Page 13] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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 + 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 from IPv6 hosts as RDNSSes. The RDNSS configuration in + the enterprise network can be performed like in Section 4, in which + three approaches can be used together as follows: + + 1) 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. + + + +Jeong, et al. Expires - August 2005 [Page 14] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 2) 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. + + 3) 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]. + + 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. + + + +Jeong, et al. Expires - August 2005 [Page 15] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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., 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, + 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. + + + + +Jeong, et al. Expires - August 2005 [Page 16] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + +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. + + 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]. + + + +Jeong, et al. Expires - August 2005 [Page 17] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + +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 + + 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. + + + + +Jeong, et al. Expires - August 2005 [Page 18] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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). + +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 scenarios [19], where cryptographic security is + required for applications, the secret information for the + cryptographic security is preconfigured through which application + specific configuration data, including those for DNS, can be + + +Jeong, et al. Expires - August 2005 [Page 19] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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 + autoconfiguration 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 the local environment is secure enough that + the information from the local autoconfiguration server has + acceptable security even without cryptographic security. Thus, the + communication between the local DNS client and local DNS server has + the acceptable security. + + In autoconfiguring recursive servers, DNSSEC may be overkill, + because DNSSEC [29] needs the configuration and reconfiguration of + clients at root key roll-over [30][31]. Even if additional keys + for secure key roll-over are added at the initial configuration, + they are as vulnerable as the original keys to some forms of + attacks, such as social hacking. Another problem of using DNSSEC + and autoconfiguration together is that DNSSEC requires secure time, + which means secure communication with autoconfigured time servers, + which requires configured secret information. Therefore, in order + that the autoconfiguration may be secure, it requires configured + secret information. + + If DNSSEC [29] is used and the signatures are verified on the + client host, the misconfiguration of a DNS server may be simply + denial of service. Also, if local routing environment is not + reliable, clients may be directed to a false resolver with the same + IP address as the true one. + + For security considerations of each approach, refer to the + corresponding drafts [5]-[9]. + +7. Acknowledgements + + This draft has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. + The authors appreciate their contributions. + +8. Normative References + + [1] S. Bradner, "Intellectual Property Rights in IETF Technology", + RFC 3668, February 2004. + + + +Jeong, et al. Expires - August 2005 [Page 20] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + [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-04.txt, February 2005, + Work in Progress. + + [9] M. Ohta, "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01.txt, February 2004, Work in + Progress. + + [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time + Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt, January + 2005, Work in Progress. + + [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. + + [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6 + into ISP Networks", + draft-ietf-v6ops-isp-scenarios-analysis-03.txt, June 2004, + Work in Progress. + + [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", + draft-ietf-send-ndopt-06.txt, July 2004, Work in Progress. + + + +Jeong, et al. Expires - August 2005 [Page 21] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + [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-05.txt, July 2004, Work in + Progress. + + [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-11.txt, October 2004, + Work in Progress. + + [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-02.txt, October + 2004, Work in Progress. + + [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition + Scenarios", RFC 3750, April 2004. + + [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) Specifications", March + 1999. + + [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: High-speed + Physical Layer in the 5 GHZ Band", September 1999. + + [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: Higher-Speed + Physical Layer Extension in the 2.4 GHz Band", September 1999. + + + +Jeong, et al. Expires - August 2005 [Page 22] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) specifications: Further + Higher Data Rate Extension in the 2.4 GHz Band", April 2003. + + [29] D. Eastlake, "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [30] O. Kolkman and R. Gieben, "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-03.txt, + December 2004. + + [31] G. Guette and O. Courtay, "Requirements for Automated Key + Rollover in DNSSEC", + draft-ietf-dnsop-key-rollover-requirements-02.txt, January + 2005. + +10. Appendix A - Link-layer Multicast Acknowledgements with RA Option + + One benefit of RA option is to be able to multicast the + advertisements, reducing the need for duplicated unicast + communications. + + However, some link-layers may not support this as well as others. + Consider, for example, WLAN networks where multicast is unreliable. + The unreliability problem is caused by lack of ACK for multicast, + especially on the path from the Access Point (AP) to the Station + (STA), which is specific to CSMA/CA of WLAN [25]-[28]. Namely, + multicast packet is unacknowledged on the path from the AP to the + STA, but acknowledged in the reverse direction from the STA to the + AP [25]. For example, when a router is placed at wired network + connected to an AP, a host may sometimes not receive RA message + advertised through the AP. + + The fact that this problem has not been addressed in Neighbor + Discovery [3] indicates that the extra link-layer acknowledgements + have not been considered a serious problem till now. + + A possible mitigation technique could be to map all-nodes link-local + multicast address to the link-layer broadcast address, and to rely + on the ND retransmissions for message delivery. + +11. Authors' Addresses + + Jaehoon Paul Jeong, Editor + ETRI/University of Minnesota at Twin Cities + 117 Pleasant Street SE + Minneapolis, MN 55455 + USA + + +Jeong, et al. Expires - August 2005 [Page 23] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + + Phone: +1 651 587 7774 + EMail: jjeong@cs.umn.edu + + 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 - August 2005 [Page 24] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + 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 + +12. 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. + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2005). This document is + subject to the rights, licenses and restrictions contained in BCP + 78, and except as set forth therein, the authors retain all their + rights. + + +Jeong, et al. Expires - August 2005 [Page 25] + +Internet-Draft IPv6 Host Configuration of DNS Server February 2005 + + + + 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 - August 2005 [Page 26] + diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt new file mode 100644 index 0000000000..6bece56182 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt @@ -0,0 +1,389 @@ + +DNSOP G. Guette +Internet-Draft IRISA / INRIA +Expires: July 19, 2005 O. Courtay + Thomson R&D + January 18, 2005 + + Requirements for Automated Key Rollover in DNSSEC + draft-ietf-dnsop-key-rollover-requirements-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 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 July 19, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). 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 during an automated rollover + process. This document is essentially about in-band key rollover. + + + + +Guette & Courtay Expires July 19, 2005 [Page 1] +Internet-Draft Automated Rollover Requirements January 2005 + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Messages authentication and information exchanged . . . . . . 5 + 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + A. Documents details and changes . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 2] +Internet-Draft Automated Rollover Requirements January 2005 + +1. Introduction + + The DNS security extensions (DNSSEC) [4][6][5][7] 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 + exchanges between parents and children is necessary for large zones + because there are too many changes to handle. + + 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 is 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 a protocol to perform + the automated key rollover process and focusses on interaction + between parent and child zone. + +2. The Key Rollover Process + + Key rollover consists of 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. + + During a ZSK rollover, all changes are local to the zone that renews + its key: there is no need to contact other zones administrators to + propagate the performed changes because a ZSK has no associated DS + record in the parent zone. + + During a KSK rollover, new DS RR(s) must be created and stored in the + parent zone. In consequence, data must be exchanged between child + and parent zones. + + The key rollover is built from two parts of different nature: + o An algorithm that generates new keys and signs the zone file. It + can be local to the zone, + o the interaction between parent and child zones. + + One example of manual key rollover [3] is: + o The child zone creates a new KSK, + + +Guette & Courtay Expires July 19, 2005 [Page 3] +Internet-Draft Automated Rollover Requirements January 2005 + + o the child zone waits for the creation of the DS RR in its parent + zone, + o the child zone deletes the old key, + o the parent zone deletes the old DS RR. + + This document concentrates on defining interactions between entities + present in key rollover process. + +3. Basic Requirements + + This section provides the requirements for automated key rollover in + case of normal use. Exceptional case like emergency rollover is + specifically described later in this document. + + The main condition during a key rollover is that the chain of trust + must be preserved to every validating DNS client. No matter if this + client retrieves some of the RRs from recursive caching name server + or from the authoritative servers for the zone involved in the + rollover. + + Automated key rollover solution may be interrupted by a manual + intervention. This manual intervention should not compromise the + security state of the chain of trust. If the chain is safe before + the manual intervention, the chain of trust must remain safe during + and after the manual intervention + + 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 and/or to verify that the changes had been taken into account + in the parent zone. Hence, the child zone can also avoid some + critical cases where all child key are changed prior to the DS RR + creation. + + By keeping some resource records during a given time, the recursive + cache servers can act on the automated rollover. The existence of + recursive cache servers must be taken into account by automated + rollover solution. + + Indeed, during an automated key rollover a name server could have to + retrieve some DNSSEC data. An automated key rollover solution must + ensure that these data are not old DNSSEC material retrieved from a + recursive name server. + + + +Guette & Courtay Expires July 19, 2005 [Page 4] +Internet-Draft Automated Rollover Requirements January 2005 + +4. Messages authentication and information exchanged + + This section addresses in-band rollover, security of out-of-band + mechanisms is out of scope of this document. + + The security provided by DNSSEC must not be compromised by the key + rollover, thus every exchanged message must be authenticated to avoid + fake rollover messages from malicious parties. + + Once the changes related to a KSK are made in a child zone, there are + two ways for the parent zone to take this changes into account: + o the child zone notify directly or not directly its parent zone in + order to create the new DS RR and store this DS RR in parent zone + file, + o or the parent zone poll the child zone. + + In both cases, the parent zone must receive all the child keys that + need the creation of associated DS RRs in the parent zone. + + Because errors could occur during the transmission of keys between + child and parent, the key exchange protocol must be fault tolerant. + Should an error occured during the automated key rollover, an + automated key rollover solution must be able to keep the zone files + in a consistent state. + +5. Emergency Rollover + + Emergency key rollover is a special case of rollover decided by the + zone administrator generally for security reasons. In consequence, + emergency key rollover can break some of the requirement described + above. + + A zone key might be compromised and an attacker can use the + compromised key to create and sign fake records. To avoid this, the + zone administrator may change the compromised key or all its keys as + soon as possible, without waiting for the creation of new DS RRs in + its parent zone. + + Fast changes may 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 the administrator wants to prevent + the compromised key from being used (to spoof DNS data). + + Parent and child zones sharing an automated rollover mechanism, + should have an out-of-band way to re-establish a consistent state at + the delegation point (DS and DNSKEY RRs). This allows to avoid that + a malicious party uses the compromised key to roll the zone keys. + + +Guette & Courtay Expires July 19, 2005 [Page 5] +Internet-Draft Automated Rollover Requirements January 2005 + +6. Security consideration + + The automated key rollover process in DNSSEC allows automated renewal + of any kind of DNS key (ZSK or KSK). It is essential that parent + side and child side can do mutual authentication. Moreover, + integrity of the material exchanged between the parent and child zone + must be provided to ensure the right DS are created. + + As in any application using public key cryptography, in DNSSEC a key + may be compromised. What to do in such a case can be describe in the + zone local policy and can violate some requirements described in this + draft. The emergency rollover can break the chain of trust in order + to protect the zone against the use of the compromised key. + +7. Acknowledgments + + The authors want to thank members of IDsA project for their + contribution to this document. + +8 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. + + [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] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October + + +Guette & Courtay Expires July 19, 2005 [Page 6] +Internet-Draft Automated Rollover Requirements January 2005 + + 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 + +Appendix A. Documents details and changes + + This section is to be removed by the RFC editor if and when the + document is published. + + Section about NS RR rollover has been removed + + Remarks from Samuel Weiler and Rip Loomis added + + Clarification about in-band rollover and in emergency section + + Section 3, details about recursive cache servers added + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 7] +Internet-Draft Automated Rollover Requirements January 2005 + +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 + IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr.org. + + + Full Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Guette & Courtay Expires July 19, 2005 [Page 8]