+++ /dev/null
-
-
-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)
- <draft-ietf-dnsext-dhcid-rr-07.txt>
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
--- /dev/null
+
+
+DNSEXT M. Stapp
+Internet-Draft Cisco Systems, Inc.
+Expires: January 14, 2005 T. Lemon
+ A. Gustafsson
+ Nominum, Inc.
+ July 16, 2004
+
+
+ A DNS RR for Encoding DHCP Information (DHCID RR)
+ <draft-ietf-dnsext-dhcid-rr-08.txt>
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at http://
+ www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 14, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ It is possible for multiple DHCP clients to attempt to update the
+ same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
+ the clients themselves perform the DNS updates, conflicts can arise.
+ To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
+ proposes storing client identifiers in the DNS to unambiguously
+
+
+
+Stapp, et al. Expires January 14, 2005 [Page 1]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+
--- /dev/null
+
+INTERNET-DRAFT Donald E. Eastlake 3rd
+Clarifies STD0013 Motorola Laboratories
+Expires December 2004 July 2004
+
+
+
+ Domain Name System (DNS) Case Insensitivity Clarification
+ ------ ---- ------ ----- ---- ------------- -------------
+ <draft-ietf-dnsext-insensitive-04.txt>
+
+ Donald E. Eastlake 3rd
+
+
+
+Status of This Document
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the DNSEXT working group at namedroppers@ops.ietf.org.
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC 2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
+ Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+
+Abstract
+
+ Domain Name System (DNS) names are "case insensitive". This document
+ explains exactly what that means and provides a clear specification
+ of the rules. This clarification should not have any interoperability
+ consequences.
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 1]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+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]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Informative References
+
+ [RFC 1591] - J. Postel, "Domain Name System Structure and
+ Delegation", March 1994.
+
+ [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
+ June 1999.
+
+ [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
+ Name System (DNS) IANA Considerations", September 2000.
+
+ [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
+ 1999.
+
+ [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
+ August 1999.
+
+ [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
+ Foo", 1 April 2001.
+
+ [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
+ Internationalized String ("stringprep")", December 2002.
+
+ [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)", March 2003.
+
+ [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
+ for Internationalized Domain Names (IDN)", March 2003.
+
+ [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
+ for Internationalized Domain Names in Applications (IDNA)", March
+ 2003.
+
+ [UNICODE] - The Unicode Consortium, "The Unicode Standard",
+ <http://www.unicode.org/unicode/standard/standard.html>.
+
+
+
+-02 to -03 Changes
+
+ The following changes were made between draft version -02 and -03:
+
+ 1. Add internationalized domain name section and references.
+
+ 2. Change to indicate that later input of a label for an existing DNS
+ name tree node may or may not be normalized to the earlier input or
+ override it or both may be preserved.
+
+ 3. Numerous minor wording changes.
+
+
+
+D. Eastlake 3rd [Page 10]
+\f
+
+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]
+\f
+
DNSEXT Working Group Levon Esibov
INTERNET-DRAFT Bernard Aboba
Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-32.txt> Microsoft
-25 June 2004
+<draft-ietf-dnsext-mdns-33.txt> Microsoft
+18 July 2004
Linklocal Multicast Name Resolution (LLMNR)
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
- RFC 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
-
Esibov, Aboba & Thaler Standards Track [Page 1]
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
Table of Contents
Acknowledgments .............................................. 24
Authors' Addresses ........................................... 25
Intellectual Property Statement .............................. 25
+Disclaimer of Validity ....................................... 26
Full Copyright Statement ..................................... 26
-
Esibov, Aboba & Thaler Standards Track [Page 2]
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
1. Introduction
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
1.1. Requirements
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
This may occur via any mechanism, including DHCPv4 [RFC2131] or
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
2.1. LLMNR packet format
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
LLMNR senders and responders MUST support standard queries (opcode
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
question section of an LLMNR query. LLMNR responders MUST silently
-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
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
[e] Responders MUST NOT respond using cached data.
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
significantly complicates implementation of LLMNR and would not be
-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
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
2.7. Retransmission and jitter
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
Due to the TTL minimalization necessary when caching an RRset, all
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
round trip estimates, with exponential backoff. [RFC1536] Section 4
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
There are some scenarios when multiple responders MAY respond to the
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
it MUST check whether the response arrived on an interface different
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
multiple interfaces, and receives replies from more than one, the
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
of both hosts responding to the name 'A'. Link-local addresses will
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
possible for an attacker to spoof a response to a frequent query
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
eliminating the benefits of cache separation. As a result, LLMNR is
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
-INTERNET-DRAFT LLMNR 25 June 2004
+INTERNET-DRAFT LLMNR 18 July 2004
Authors' Addresses
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
-INTERNET-DRAFT LLMNR 25 June 2004
-
+INTERNET-DRAFT LLMNR 18 July 2004
-Full Copyright Statement
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+Disclaimer of Validity
- 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
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-Expiration Date
- This memo is filed as <draft-ietf-dnsext-mdns-32.txt>, and expires
- December 22, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
projects / thirdparty / bind9.git / commitdiff
