From 9db418e06c6a659cad4e09e4d2bdc726f5a8c1f0 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 20 Jul 2004 23:35:21 +0000 Subject: [PATCH] new draft --- doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt | 560 --------------- doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt | 561 +++++++++++++++ .../draft-ietf-dnsext-insensitive-04.txt | 639 ++++++++++++++++++ ...s-32.txt => draft-ietf-dnsext-mdns-33.txt} | 126 ++-- 4 files changed, 1263 insertions(+), 623 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt create mode 100644 doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt create mode 100644 doc/draft/draft-ietf-dnsext-insensitive-04.txt rename doc/draft/{draft-ietf-dnsext-mdns-32.txt => draft-ietf-dnsext-mdns-33.txt} (93%) diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt deleted file mode 100644 index 4634cfdf53..0000000000 --- a/doc/draft/draft-ietf-dnsext-dhcid-rr-07.txt +++ /dev/null @@ -1,560 +0,0 @@ - - -DNSEXT Working Group M. Stapp -Internet-Draft Cisco Systems, Inc. -Expires: April 23, 2004 T. Lemon - A. Gustafsson - Nominum, Inc. - October 24, 2003 - - - A DNS RR for Encoding DHCP Information (DHCID RR) - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 23, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - It is possible for multiple DHCP clients to attempt to update the - same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or - the clients themselves perform the DNS updates, conflicts can arise. - To resolve such conflicts, "Resolution of DNS Name Conflicts"[1] - proposes storing client identifiers in the DNS to unambiguously - 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. - - - - -Stapp, et. al. Expires April 23, 2004 [Page 1] - -Internet-Draft The DHCID RR October 2003 - - -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 . . . . . . . . . . . . . . . . . . 5 - 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 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 - References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et. al. Expires April 23, 2004 [Page 2] - -Internet-Draft The DHCID RR October 2003 - - -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 April 23, 2004 [Page 3] - -Internet-Draft The DHCID RR October 2003 - - -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 (RFC 2131) - 0x0001 = The data portion from a DHCPv4 client's Client - Identifier option (RFC 2132) - 0x0002 = The data portion (i.e., the DUID) from a DHCPv6 - client's Client Identifier option - (draft-ietf-dhc-dhcpv6-*.txt) - - 0x0003 - 0xfffe = Available to be assigned by IANA - - 0xffff = RESERVED - - - - - - - -Stapp, et. al. Expires April 23, 2004 [Page 4] - -Internet-Draft The DHCID RR October 2003 - - -3.4 Computation of the RDATA - - The DHCID RDATA is formed by concatenating the two type bytes with - 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. - - - - -Stapp, et. al. Expires April 23, 2004 [Page 5] - -Internet-Draft The DHCID RR October 2003 - - -3.5 Examples - -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 - that the client desires to use to compute a client identity hash, - - -Stapp, et. al. Expires April 23, 2004 [Page 6] - -Internet-Draft The DHCID RR October 2003 - - - 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. - -Normative References - - [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients - - -Stapp, et. al. Expires April 23, 2004 [Page 7] - -Internet-Draft The DHCID RR October 2003 - - - (draft-ietf-dhc-dns-resolution-*)", November 2002. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - [3] Mockapetris, P., "Domain names - Concepts and Facilities", RFC - 1034, Nov 1987. - - [4] Mockapetris, P., "Domain names - Implementation and - Specification", RFC 1035, Nov 1987. - - [5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April - 1992. - - [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", RFC 2434, October 1998. - -Informative References - - [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - Mar 1997. - - [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, Mar 1997. - - [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - (draft-ietf-dhc-dhcpv6-*.txt)", November 2002. - - [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - -Authors' Addresses - - Mark Stapp - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxborough, MA 01719 - USA - - Phone: 978.936.1535 - EMail: mjs@cisco.com - - - - -Stapp, et. al. Expires April 23, 2004 [Page 8] - -Internet-Draft The DHCID RR October 2003 - - - 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 April 23, 2004 [Page 9] - -Internet-Draft The DHCID RR October 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Stapp, et. al. Expires April 23, 2004 [Page 10] - diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt new file mode 100644 index 0000000000..09776618f2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt @@ -0,0 +1,561 @@ + + +DNSEXT M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: January 14, 2005 T. Lemon + A. Gustafsson + Nominum, Inc. + July 16, 2004 + + + A DNS RR for Encoding DHCP Information (DHCID RR) + + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 14, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + It is possible for multiple DHCP clients to attempt to update the + same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or + the clients themselves perform the DNS updates, conflicts can arise. + To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] + proposes storing client identifiers in the DNS to unambiguously + + + +Stapp, et al. Expires January 14, 2005 [Page 1] + +Internet-Draft The DHCID RR July 2004 + + + associate domain names with the DHCP clients to which they refer. + This memo defines a distinct RR type for this purpose for use by DHCP + clients and servers, the "DHCID" RR. + +Table of Contents + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4 + 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4 + 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4 + 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4 + 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6 + 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires January 14, 2005 [Page 2] + +Internet-Draft The DHCID RR July 2004 + + +1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + +2. Introduction + + A set of procedures to allow DHCP [7] clients and servers to + automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed + in "Resolution of DNS Name Conflicts" [1]. + + Conflicts can arise if multiple DHCP clients wish to use the same DNS + name. To resolve such conflicts, "Resolution of DNS Name Conflicts" + [1] proposes storing client identifiers in the DNS to unambiguously + associate domain names with the DHCP clients using them. In the + interest of clarity, it is preferable for this DHCP information to + use a distinct RR type. This memo defines a distinct RR for this + purpose for use by DHCP clients or servers, the "DHCID" RR. + + In order to avoid exposing potentially sensitive identifying + information, the data stored is the result of a one-way MD5 [5] hash + computation. The hash includes information from the DHCP client's + REQUEST message as well as the domain name itself, so that the data + stored in the DHCID RR will be dependent on both the client + identification used in the DHCP protocol interaction and the domain + name. This means that the DHCID RDATA will vary if a single client + is associated over time with more than one name. This makes it + difficult to 'track' a client as it is associated with various domain + names. + + The MD5 hash algorithm has been shown to be weaker than the SHA-1 + algorithm; it could therefore be argued that SHA-1 is a better + choice. However, SHA-1 is significantly slower than MD5. A + successful attack of MD5's weakness does not reveal the original data + that was used to generate the signature, but rather provides a new + set of input data that will produce the same signature. Because we + are using the MD5 hash to conceal the original data, the fact that an + attacker could produce a different plaintext resulting in the same + MD5 output is not significant concern. + +3. The DHCID RR + + The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The + DHCID RR is only defined in the IN class. DHCID RRs cause no + additional section processing. The DHCID RR is not a singleton type. + + + + + +Stapp, et al. Expires January 14, 2005 [Page 3] + +Internet-Draft The DHCID RR July 2004 + + +3.1 DHCID RDATA format + + The RDATA section of a DHCID RR in transmission contains RDLENGTH + bytes of binary data. The format of this data and its interpretation + by DHCP servers and clients are described below. + + DNS software should consider the RDATA section to be opaque. DHCP + clients or servers use the DHCID RR to associate a DHCP client's + identity with a DNS name, so that multiple DHCP clients and servers + may deterministically perform dynamic DNS updates to the same zone. + From the updater's perspective, the DHCID resource record RDATA + consists of a 16-bit identifier type, in network byte order, followed + by one or more bytes representing the actual identifier: + + < 16 bits > DHCP identifier used + < n bytes > MD5 digest + + +3.2 DHCID Presentation Format + + In DNS master files, the RDATA is represented as a single block in + base 64 encoding identical to that used for representing binary data + in RFC 2535 [8]. The data may be divided up into any number of white + space separated substrings, down to single base 64 digits, which are + concatenated to form the complete RDATA. These substrings can span + lines using the standard parentheses. + +3.3 The DHCID RR Type Codes + + The DHCID RR Type Code specifies what data from the DHCP client's + request was used as input into the hash function. The type codes are + defined in a registry maintained by IANA, as specified in Section 7. + The initial list of assigned values for the type code is: + + 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7]. + 0x0001 = The data portion from a DHCPv4 client's Client Identifier + option [9]. + 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6 + client's Client Identifier option [10] or the DUID field from a + DHCPv4 client's Client Identifier option [12]). + + 0x0003 - 0xfffe = Available to be assigned by IANA. + + 0xffff = RESERVED + +3.4 Computation of the RDATA + + The DHCID RDATA is formed by concatenating the two type bytes with + + + +Stapp, et al. Expires January 14, 2005 [Page 4] + +Internet-Draft The DHCID RR July 2004 + + + some variable-length identifying data. + + < type > < data > + + The RDATA for all type codes other than 0xffff, which is reserved for + future expansion, is formed by concatenating the two type bytes and a + 16-byte MD5 hash value. The input to the hash function is defined to + be: + + data = MD5(< identifier > < FQDN >) + + The FQDN is represented in the buffer in unambiguous canonical form + as described in RFC 2535 [8], section 8.1. The type code and the + identifier are related as specified in Section 3.3: the type code + describes the source of the identifier. + + When the updater is using the client's link-layer address as the + identifier, the first two bytes of the DHCID RDATA MUST be zero. To + generate the rest of the resource record, the updater computes a + one-way hash using the MD5 algorithm across a buffer containing the + client's network hardware type, link-layer address, and the FQDN + data. Specifically, the first byte of the buffer contains the + network hardware type as it appeared in the DHCP 'htype' field of the + client's DHCPREQUEST message. All of the significant bytes of the + chaddr field in the client's DHCPREQUEST message follow, in the same + order in which the bytes appear in the DHCPREQUEST message. The + number of significant bytes in the 'chaddr' field is specified in the + 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified + above, follows. + + When the updater is using the DHCPv4 Client Identifier option sent by + the client in its DHCPREQUEST message, the first two bytes of the + DHCID RR MUST be 0x0001, in network byte order. The rest of the + DHCID RR MUST contain the results of computing an MD5 hash across the + payload of the option, followed by the FQDN. The payload of the + option consists of the bytes of the option following the option code + and length. + + When the updater is using the DHCPv6 DUID sent by the client in its + REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002, + in network byte order. The rest of the DHCID RR MUST contain the + results of computing an MD5 hash across the payload of the option, + followed by the FQDN. The payload of the option consists of the + bytes of the option following the option code and length. + +3.5 Examples + + + + + +Stapp, et al. Expires January 14, 2005 [Page 5] + +Internet-Draft The DHCID RR July 2004 + + +3.5.1 Example 1 + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client with + Ethernet MAC address 01:02:03:04:05:06 using domain name + "client.example.com" uses the client's link-layer address to identify + the client. The DHCID RDATA is composed by setting the two type + bytes to zero, and performing an MD5 hash computation across a buffer + containing the Ethernet MAC type byte, 0x01, the six bytes of MAC + address, and the domain name (represented as specified in Section + 3.4). + + client.example.com. A 10.0.0.1 + client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU + + +3.5.2 Example 2 + + A DHCP server allocates the IPv4 address 10.0.12.99 to a client which + included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c + in its DHCP request. The server updates the name "chi.example.com" + on the client's behalf, and uses the DHCP client identifier option + data as input in forming a DHCID RR. The DHCID RDATA is formed by + setting the two type bytes to the value 0x0001, and performing an MD5 + hash computation across a buffer containing the seven bytes from the + client-id option and the FQDN (represented as specified in Section + 3.4). + + chi.example.com. A 10.0.12.99 + chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 + + +4. Use of the DHCID RR + + This RR MUST NOT be used for any purpose other than that detailed in + "Resolution of DNS Name Conflicts" [1]. Although this RR contains + data that is opaque to DNS servers, the data must be consistent + across all entities that update and interpret this record. + Therefore, new data formats may only be defined through actions of + the DHC Working Group, as a result of revising [1]. + +5. Updater Behavior + + The data in the DHCID RR allows updaters to determine whether more + than one DHCP client desires to use a particular FQDN. This allows + site administrators to establish policy about DNS updates. The DHCID + RR does not establish any policy itself. + + Updaters use data from a DHCP client's request and the domain name + + + +Stapp, et al. Expires January 14, 2005 [Page 6] + +Internet-Draft The DHCID RR July 2004 + + + that the client desires to use to compute a client identity hash, and + then compare that hash to the data in any DHCID RRs on the name that + they wish to associate with the client's IP address. If an updater + discovers DHCID RRs whose RDATA does not match the client identity + that they have computed, the updater SHOULD conclude that a different + client is currently associated with the name in question. The + updater SHOULD then proceed according to the site's administrative + policy. That policy might dictate that a different name be selected, + or it might permit the updater to continue. + +6. Security Considerations + + The DHCID record as such does not introduce any new security problems + into the DNS. In order to avoid exposing private information about + DHCP clients to public scrutiny, a one-way hash is used to obscure + all client information. In order to make it difficult to 'track' a + client by examining the names associated with a particular hash + value, the FQDN is included in the hash computation. Thus, the RDATA + is dependent on both the DHCP client identification data and on each + FQDN associated with the client. + + Administrators should be wary of permitting unsecured DNS updates to + zones which are exposed to the global Internet. Both DHCP clients + and servers SHOULD use some form of update authentication (e.g., TSIG + [11]) when performing DNS updates. + +7. IANA Considerations + + IANA is requested to allocate an RR type number for the DHCID record + type. + + This specification defines a new number-space for the 16-bit type + codes associated with the DHCID RR. IANA is requested to establish a + registry of the values for this number-space. + + Three initial values are assigned in Section 3.3, and the value + 0xFFFF is reserved for future use. New DHCID RR type codes are + tentatively assigned after the specification for the associated type + code, published as an Internet Draft, has received expert review by a + designated expert. The final assignment of DHCID RR type codes is + through Standards Action, as defined in RFC 2434 [6]. + +8. Acknowledgements + + Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and + Ralph Droms for their review and suggestions. + + + + + +Stapp, et al. Expires January 14, 2005 [Page 7] + +Internet-Draft The DHCID RR July 2004 + + +9. References + +9.1 Normative References + + [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among + DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [4] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +9.2 Informative References + + [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [8] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers + for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. + + + + + + + + +Stapp, et al. Expires January 14, 2005 [Page 8] + +Internet-Draft The DHCID RR July 2004 + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + Phone: 978.936.1535 + EMail: mjs@cisco.com + + + Ted Lemon + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: mellon@nominum.com + + + Andreas Gustafsson + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: gson@nominum.com + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires January 14, 2005 [Page 9] + +Internet-Draft The DHCID RR July 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Stapp, et al. Expires January 14, 2005 [Page 10] + + diff --git a/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/doc/draft/draft-ietf-dnsext-insensitive-04.txt new file mode 100644 index 0000000000..4cfd417804 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-insensitive-04.txt @@ -0,0 +1,639 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Clarifies STD0013 Motorola Laboratories +Expires December 2004 July 2004 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + + + Donald E. Eastlake 3rd + + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group at namedroppers@ops.ietf.org. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- + Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + Domain Name System (DNS) names are "case insensitive". This document + explains exactly what that means and provides a clear specification + of the rules. This clarification should not have any interoperability + consequences. + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Acknowledgements + + The contributions to this document of Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, + Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully + acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Case Insensitivity of DNS Labels........................3 + 2.1 Escaping Unusual DNS Label Octets......................3 + 2.2 Example Labels with Escapes............................4 + 3. Name Lookup, Label Types, and CLASS.....................4 + 3.1 Original DNS Label Types...............................5 + 3.2 Extended Label Type Case Insensitivity Considerations..5 + 3.3 CLASS Case Insensitivity Considerations................5 + 4. Case on Input and Output................................6 + 4.1 DNS Output Case Preservation...........................6 + 4.2 DNS Input Case Preservation............................6 + 5. Internationalized Domain Names..........................7 + 6. Security Considerations.................................7 + + Copyright and Disclaimer...................................9 + Normative References.......................................9 + Informative References....................................10 + -02 to -03 Changes........................................10 + -03 to -04 Changes........................................11 + Author's Address..........................................11 + Expiration and File Name..................................11 + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS Case Insensitivity + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. Each node in the DNS tree has a name consisting of + zero or more labels [STD 13][RFC 1591, 2606] that are treated in a + case insensitive fashion. This document clarifies the meaning of + "case insensitive" for the DNS. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + +2. Case Insensitivity of DNS Labels + + DNS was specified in the era of [ASCII]. DNS names were expected to + look like most host names or Internet email address right halves (the + part after the at-sign, "@") or be numeric as in the in-addr.arpa + part of the DNS name space. For example, + + foo.example.net. + aol.com. + www.gnu.ai.mit.edu. + or 69.2.0.192.in-addr.arpa. + + Case varied alternatives to the above would be DNS names like + + Foo.ExamplE.net. + AOL.COM. + WWW.gnu.AI.mit.EDU. + or 69.2.0.192.in-ADDR.ARPA. + + However, the individual octets of which DNS names consist are not + limited to valid ASCII character codes. They are 8-bit bytes and all + values are allowed. Many applications, however, interpret them as + ASCII characters. + + + +2.1 Escaping Unusual DNS Label Octets + + In Master Files [STD 13] and other human readable and writable ASCII + contexts, an escape is needed for the byte value for period (0x2E, + ".") and all octet values outside of the inclusive range of 0x21 + ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in + the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. + + One typographic convention for octets that do not correspond to an + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + ASCII printing graphic is to use a back-slash followed by the value + of the octet as an unsigned integer represented by exactly three + decimal digits. + + The same convention can be used for printing ASCII characters so that + they will be treated as a normal label character. This includes the + back-slash character used in this convention itself which can be + expressed as \092 or \\ and the special label separator period (".") + which can be expressed as and \046 or \. respectively. It is + advisable to avoid using a backslash to quote an immediately + following non-printing ASCII character code to avoid implementation + difficulties. + + A back-slash followed by only one or two decimal digits is undefined. + A back-slash followed by four decimal digits produces two octets, the + first octet having the value of the first three digits considered as + a decimal number and the second octet being the character code for + the fourth decimal digit. + + + +2.2 Example Labels with Escapes + + The first example below shows embedded spaces and a period (".") + within a label. The second one show a 5 octet label where the second + octet has all bits zero, the third is a backslash, and the fourth + octet has all bits one. + + Donald\032E\.\032Eastlake\0323rd.example. + and a\000\\\255z.example. + + + +3. Name Lookup, Label Types, and CLASS + + The design decision was made that comparisons on name lookup for DNS + queries should be case insensitive [STD 13]. That is to say, a lookup + string octet with a value in the inclusive range of 0x41 to 0x5A, the + upper case ASCII letters, MUST match the identical value and also + match the corresponding value in the inclusive range 0x61 to 0x7A, + the lower case ASCII letters. And a lookup string octet with a lower + case ASCII letter value MUST similarly match the identical value and + also match the corresponding value in the upper case ASCII letter + range. + + (Historical Note: the terms "upper case" and "lower case" were + invented after movable type. The terms originally referred to the + two font trays for storing, in partitioned areas, the different + physical type elements. Before movable type, the nearest equivalent + terms were "majuscule" and "minuscule".) + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + One way to implement this rule would be, when comparing octets, to + subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A + before the comparison. Such an operation is commonly known as "case + folding" but implementation via case folding is not required. Note + that the DNS case insensitivity does NOT correspond to the case + folding specified in iso-8859-1 or iso-8859-2. For example, the + octets 0xDD (\221) and 0xFD (\253) do NOT match although in other + contexts, where they are interpreted as the upper and lower case + version of "Y" with an acute accent, they might. + + + +3.1 Original DNS Label Types + + DNS labels in wire encoded names have a type associated with them. + The original DNS standard [RFC 1035] had only two types. ASCII + labels, with a length of from zero to 63 octets, and indirect labels + which consist of an offset pointer to a name location elsewhere in + the wire encoding on a DNS message. (The ASCII label of length zero + is reserved for use as the name of the root node of the name tree.) + ASCII labels follow the ASCII case conventions described herein and, + as stated above, can actually contain arbitrary byte values. Indirect + labels are, in effect, replaced by the name to which they point which + is then treated with the case insensitivity rules in this document. + + + +3.2 Extended Label Type Case Insensitivity Considerations + + DNS was extended by [RFC 2671] to have additional label type numbers + available. (The only such type defined so far is the BINARY type [RFC + 2673].) + + The ASCII case insensitivity conventions only apply to ASCII labels, + that is to say, label type 0x0, whether appearing directly or invoked + by indirect labels. + + + +3.3 CLASS Case Insensitivity Considerations + + As described in [STD 13] and [RFC 2929], DNS has an additional axis + for data location called CLASS. The only CLASS in global use at this + time is the "IN" or Internet CLASS. + + The handling of DNS label case is not CLASS dependent. + + + + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS Case Insensitivity + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, [STD 13] says + case MUST be preserved on output, and preserved when convenient on + input. However, this means less than it would appear since the + preservation of case on output is NOT required when output is + optimized by the use of indirect labels, as explained below. + + + +4.1 DNS Output Case Preservation + + [STD 13] views the DNS namespace as a node tree. ASCII output is as + if a name was marshaled by taking the label on the node whose name is + to be output, converting it to a typographically encoded ASCII + string, walking up the tree outputting each label encountered, and + preceding all labels but the first with a period ("."). Wire output + follows the same sequence but each label is wire encoded and no + periods inserted. No "case conversion" or "case folding" is done + during such output operations, thus "preserving" case. However, to + optimize output, indirect labels may be used to point to names + elsewhere in the DNS answer. In determining whether the name to be + pointed to, for example the QNAME, is the "same" as the remainder of + the name being optimized, the case insensitive comparison specified + above is done. Thus such optimization MAY easily destroy the output + preservation of case. This type of optimization is commonly called + "name compression". + + + +4.2 DNS Input Case Preservation + + Originally, DNS input came from an ASCII Master File as defined in + [STD 13] or a zone transfer. DNS Dynamic update and incremental zone + transfers [RFC 1995] have been added as a source of DNS data [RFC + 2136, 3007]. When a node in the DNS name tree is created by any of + such inputs, no case conversion is done. Thus the case of ASCII + labels is preserved if they are for nodes being created. However, + when a name label is input for a node that already exist in DNS data + being held, the situation is more complex. Implementations may retain + the case first input for such a label or allow new input to override + the old case or even maintain separate copies preserving the input + case. + + For example, if data with owner name "foo.bar.example" is input and + then later data with owner name "xyz.BAR.example" is input, the name + of the label on the "bar.example" node, i.e. "bar", might or might + not be changed to "BAR" or the actual input case could be preserved. + Thus later retrieval of data stored under "xyz.bar.example" in this + case can easily return data with "xyz.BAR.example". The same + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS Case Insensitivity + + + considerations apply when inputting multiple data records with owner + names differing only in case. For example, if an "A" record is stored + as the first resourced record under owner name "xyz.BAR.example" and + then a second "A" record is stored under "XYZ.BAR.example", the + second MAY be stored with the first (lower case initial label) name + or the second MAY override the first so that only an upper case + initial label is retained or both capitalizations MAY be kept. + + Note that the order of insertion into a server database of the DNS + name tree nodes that appear in a Master File is not defined so that + the results of inconsistent capitalization in a Master File are + unpredictable output capitalization. + + + +5. Internationalized Domain Names + + A scheme has been adopted for "internationalized domain names" and + "internationalized labels" as described in [RFC 3490, 3454, 3491, and + 3492]. It makes most of [UNICODE] available through a separate + application level transformation from internationalized domain name + to DNS domain name and from DNS domain name to internationalized + domain name. Any case insensitivity that internationalized domain + names and labels have varies depending on the script and is handled + entirely as part of the transformation described in [RFC 3454] and + [RFC 3491] which should be seen for further details. This is not a + part of the DNS as standardized in STD 13. + + + +6. Security Considerations + + The equivalence of certain DNS label types with case differences, as + clarified in this document, can lead to security problems. For + example, a user could be confused by believing two domain names + differing only in case were actually different names. + + Furthermore, a domain name may be used in contexts other than the + DNS. It could be used as a case sensitive index into some data base + system. Or it could be interpreted as binary data by some integrity + or authentication code system. These problems can usually be handled + by using a standardized or "canonical" form of the DNS ASCII type + labels, that is, always mapping the ASCII letter value octets in + ASCII labels to some specific pre-chosen case, either upper case or + lower case. An example of a canonical form for domain names (and also + a canonical ordering for them) appears in Section 8 of [RFC 2535]. + See also [RFC 3597]. + + Finally, a non-DNS name may be stored into DNS with the false + expectation that case will always be preserved. For example, although + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS Case Insensitivity + + + this would be quite rare, on a system with case sensitive email + address local parts, an attempt to store two "RP" records that + differed only in case would probably produce unexpected results that + might have security implications. That is because the entire email + address, including the possibly case sensitive local or left hand + part, is encoded into a DNS name in a readable fashion where the case + of some letters might be changed on output as described above. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Copyright and Disclaimer + + Copyright (C) The Internet Society 2004. This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Normative References + + [ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + [RFC 1034, 1035] - See [STD 13]. + + [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August + 1996. + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. + + [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", November 2000. + + [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", + draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. + + [STD 13] + - P. Mockapetris, "Domain names - concepts and facilities", RFC + 1034, November 1987. + - P. Mockapetris, "Domain names - implementation and + specification", RFC 1035, November 1987. + + + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Informative References + + [RFC 1591] - J. Postel, "Domain Name System Structure and + Delegation", March 1994. + + [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain + Name System (DNS) IANA Considerations", September 2000. + + [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August + 1999. + + [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", + August 1999. + + [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of + Foo", 1 April 2001. + + [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of + Internationalized String ("stringprep")", December 2002. + + [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", March 2003. + + [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile + for Internationalized Domain Names (IDN)", March 2003. + + [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications (IDNA)", March + 2003. + + [UNICODE] - The Unicode Consortium, "The Unicode Standard", + . + + + +-02 to -03 Changes + + The following changes were made between draft version -02 and -03: + + 1. Add internationalized domain name section and references. + + 2. Change to indicate that later input of a label for an existing DNS + name tree node may or may not be normalized to the earlier input or + override it or both may be preserved. + + 3. Numerous minor wording changes. + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS Case Insensitivity + + +-03 to -04 Changes + + The following changes were made between draft version -03 and -04: + + 1. Change to conform to the new IPR, Copyright, etc., notice + requirements. + + 2. Change in some section headers for clarity. + + 3. Drop section on wildcards. + + 4. Add emphasis on loss of case preservation due to name compression. + + 5. Add references to RFCs 1995 and 3092. + + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + +1 508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires December 2004. + + Its file name is draft-ietf-dnsext-insensitive-04.txt. + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 11] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-32.txt b/doc/draft/draft-ietf-dnsext-mdns-33.txt similarity index 93% rename from doc/draft/draft-ietf-dnsext-mdns-32.txt rename to doc/draft/draft-ietf-dnsext-mdns-33.txt index 50c54bcb39..8dcacc8bb9 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-32.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-33.txt @@ -7,8 +7,8 @@ DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -25 June 2004 + Microsoft +18 July 2004 Linklocal Multicast Name Resolution (LLMNR) @@ -16,28 +16,29 @@ Category: Standards Track Dave Thaler By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with - RFC 3667. + 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. + 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 + 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 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 November 22, 2004. + This Internet-Draft will expire on January 2, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society 2004. All rights reserved. Abstract @@ -54,14 +55,13 @@ Abstract - Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 Table of Contents @@ -96,6 +96,7 @@ Table of Contents Acknowledgments .............................................. 24 Authors' Addresses ........................................... 25 Intellectual Property Statement .............................. 25 +Disclaimer of Validity ....................................... 26 Full Copyright Statement ..................................... 26 @@ -114,14 +115,13 @@ Full Copyright Statement ..................................... 26 - Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 1. Introduction @@ -181,7 +181,7 @@ Esibov, Aboba & Thaler Standards Track [Page 3] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 1.1. Requirements @@ -241,7 +241,7 @@ Esibov, Aboba & Thaler Standards Track [Page 4] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 This may occur via any mechanism, including DHCPv4 [RFC2131] or @@ -301,7 +301,7 @@ Esibov, Aboba & Thaler Standards Track [Page 5] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 2.1. LLMNR packet format @@ -361,7 +361,7 @@ Esibov, Aboba & Thaler Standards Track [Page 6] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 LLMNR senders and responders MUST support standard queries (opcode @@ -421,7 +421,7 @@ Esibov, Aboba & Thaler Standards Track [Page 7] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 question section of an LLMNR query. LLMNR responders MUST silently @@ -481,7 +481,7 @@ Esibov, Aboba & Thaler Standards Track [Page 8] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 responder has another RR as well; the SOA RR MUST NOT be the only RR @@ -541,7 +541,7 @@ Esibov, Aboba & Thaler Standards Track [Page 9] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 [e] Responders MUST NOT respond using cached data. @@ -601,7 +601,7 @@ Esibov, Aboba & Thaler Standards Track [Page 10] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 significantly complicates implementation of LLMNR and would not be @@ -661,7 +661,7 @@ Esibov, Aboba & Thaler Standards Track [Page 11] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 Section 2.4 discusses use of TCP for LLMNR queries and responses. In @@ -721,7 +721,7 @@ Esibov, Aboba & Thaler Standards Track [Page 12] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 2.7. Retransmission and jitter @@ -781,7 +781,7 @@ Esibov, Aboba & Thaler Standards Track [Page 13] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 Due to the TTL minimalization necessary when caching an RRset, all @@ -841,7 +841,7 @@ Esibov, Aboba & Thaler Standards Track [Page 14] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 round trip estimates, with exponential backoff. [RFC1536] Section 4 @@ -901,7 +901,7 @@ Esibov, Aboba & Thaler Standards Track [Page 15] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no @@ -961,7 +961,7 @@ Esibov, Aboba & Thaler Standards Track [Page 16] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 There are some scenarios when multiple responders MAY respond to the @@ -1021,7 +1021,7 @@ Esibov, Aboba & Thaler Standards Track [Page 17] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 it MUST check whether the response arrived on an interface different @@ -1081,7 +1081,7 @@ Esibov, Aboba & Thaler Standards Track [Page 18] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 multiple interfaces, and receives replies from more than one, the @@ -1141,7 +1141,7 @@ Esibov, Aboba & Thaler Standards Track [Page 19] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 of both hosts responding to the name 'A'. Link-local addresses will @@ -1201,7 +1201,7 @@ Esibov, Aboba & Thaler Standards Track [Page 20] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 possible for an attacker to spoof a response to a frequent query @@ -1261,7 +1261,7 @@ Esibov, Aboba & Thaler Standards Track [Page 21] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 eliminating the benefits of cache separation. As a result, LLMNR is @@ -1321,7 +1321,7 @@ Esibov, Aboba & Thaler Standards Track [Page 22] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1381,7 +1381,7 @@ Esibov, Aboba & Thaler Standards Track [Page 23] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC @@ -1441,7 +1441,7 @@ Esibov, Aboba & Thaler Standards Track [Page 24] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 Authors' Addresses @@ -1478,7 +1478,7 @@ Intellectual Property Statement 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 + 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 @@ -1501,34 +1501,25 @@ Esibov, Aboba & Thaler Standards Track [Page 25] -INTERNET-DRAFT LLMNR 25 June 2004 +INTERNET-DRAFT LLMNR 18 July 2004 -Full Copyright Statement +Disclaimer of Validity - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. The limited permissions granted above are perpetual and - will not be revoked by the Internet Society or its successors or - assigns. This document and the information contained herein is - provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + Open Issues Open issues with this specification are tracked on the following web @@ -1536,10 +1527,19 @@ Open Issues http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html -Expiration Date - This memo is filed as , and expires - December 22, 2004. + + + + + + + + + + + +