diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc4701.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4701.txt | 675 |
1 files changed, 0 insertions, 675 deletions
diff --git a/contrib/bind9/doc/rfc/rfc4701.txt b/contrib/bind9/doc/rfc/rfc4701.txt deleted file mode 100644 index 03e3c54..0000000 --- a/contrib/bind9/doc/rfc/rfc4701.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group M. Stapp -Request for Comments: 4701 Cisco Systems, Inc. -Category: Standards Track T. Lemon - Nominum, Inc. - A. Gustafsson - Araneus Information Systems Oy - October 2006 - - - A DNS Resource Record (RR) for Encoding - Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - It is possible for Dynamic Host Configuration Protocol (DHCP) clients - to attempt to update the same DNS Fully Qualified Domain Name (FQDN) - or to update a DNS FQDN that has been added to the DNS for another - purpose as they obtain DHCP leases. Whether the DHCP server or the - clients themselves perform the DNS updates, conflicts can arise. To - resolve such conflicts, RFC 4703 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 Resource - Record (RR) type for this purpose for use by DHCP clients and - servers: the "DHCID" RR. - - - - - - - - - - - - - - - -Stapp, et al. Standards Track [Page 1] - -RFC 4701 The DHCID RR October 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 2. Terminology .....................................................3 - 3. The DHCID RR ....................................................3 - 3.1. DHCID RDATA Format .........................................3 - 3.2. DHCID Presentation Format ..................................4 - 3.3. The DHCID RR Identifier Type Codes .........................4 - 3.4. The DHCID RR Digest Type Code ..............................4 - 3.5. Computation of the RDATA ...................................5 - 3.5.1. Using the Client's DUID .............................5 - 3.5.2. Using the Client Identifier Option ..................6 - 3.5.3. Using the Client's htype and chaddr .................6 - 3.6. Examples ...................................................6 - 3.6.1. Example 1 ...........................................6 - 3.6.2. Example 2 ...........................................7 - 3.6.3. Example 3 ...........................................7 - 4. Use of the DHCID RR .............................................8 - 5. Updater Behavior ................................................8 - 6. Security Considerations .........................................8 - 7. IANA Considerations .............................................9 - 8. Acknowledgements ................................................9 - 9. References ......................................................9 - 9.1. Normative References .......................................9 - 9.2. Informative References ....................................10 - - - - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Standards Track [Page 2] - -RFC 4701 The DHCID RR October 2006 - - -1. Introduction - - A set of procedures to allow DHCP [7] [11] clients and servers to - automatically update the DNS ([3], [4]) is proposed in [1]. - - Conflicts can arise if multiple DHCP clients wish to use the same DNS - name or a DHCP client attempts to use a name added for another - purpose. To resolve such 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 obscure potentially sensitive client identifying - information, the data stored is the result of a one-way SHA-256 hash - computation. The hash includes information from the DHCP client's - 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. - -2. 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 [2]. - -3. The DHCID RR - - The DHCID RR is defined with mnemonic DHCID and type code 49. The - DHCID RR is only defined in the IN class. DHCID RRs cause no - additional section processing. - -3.1. DHCID RDATA Format - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - octets 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 2-octet identifier type, in network byte order, - - - -Stapp, et al. Standards Track [Page 3] - -RFC 4701 The DHCID RR October 2006 - - - followed by a 1-octet digest type, followed by one or more octets - representing the actual identifier: - - < 2 octets > Identifier type code - < 1 octet > Digest type code - < n octets > Digest (length depends on digest type) - -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 [8], Section 3. 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 Identifier Type Codes - - The DHCID RR Identifier Type Code specifies what data from the DHCP - client's request was used as input into the hash function. The - identifier type codes are defined in a registry maintained by IANA, - as specified in Section 7. The initial list of assigned values for - the identifier type code and that type's identifier is: - - - +------------------+------------------------------------------------+ - | Identifier Type | Identifier | - | Code | | - +------------------+------------------------------------------------+ - | 0x0000 | The 1-octet 'htype' followed by 'hlen' octets | - | | of 'chaddr' from a DHCPv4 client's DHCPREQUEST | - | | [7]. | - | 0x0001 | The data octets (i.e., the Type and | - | | Client-Identifier fields) from a DHCPv4 | - | | client's Client Identifier option [10]. | - | 0x0002 | The client's DUID (i.e., the data octets of a | - | | DHCPv6 client's Client Identifier option [11] | - | | or the DUID field from a DHCPv4 client's | - | | Client Identifier option [6]). | - | 0x0003 - 0xfffe | Undefined; available to be assigned by IANA. | - | 0xffff | Undefined; RESERVED. | - +------------------+------------------------------------------------+ - -3.4. The DHCID RR Digest Type Code - - The DHCID RR Digest Type Code is an identifier for the digest - algorithm used. The digest is calculated over an identifier and the - canonical FQDN as described in the next section. - - - -Stapp, et al. Standards Track [Page 4] - -RFC 4701 The DHCID RR October 2006 - - - The digest type codes are defined in a registry maintained by IANA, - as specified in Section 7. The initial list of assigned values for - the digest type codes is: value 0 is reserved, and value 1 is - SHA-256. Reserving other types requires IETF standards action. - Defining new values will also require IETF standards action to - document how DNS updaters are to deal with multiple digest types. - -3.5. Computation of the RDATA - - The DHCID RDATA is formed by concatenating the 2-octet identifier - type code with variable-length data. - - The RDATA for all type codes other than 0xffff, which is reserved for - future expansion, is formed by concatenating the 2-octet identifier - type code, the 1-octet digest type code, and the digest value (32 - octets for SHA-256). - - < identifier-type > < digest-type > < digest > - - The input to the digest hash function is defined to be: - - digest = SHA-256(< identifier > < FQDN >) - - The FQDN is represented in the buffer in the canonical wire format as - described in [9], Section 6.2. The identifier type code and the - identifier are related as specified in Section 3.3: the identifier - type code describes the source of the identifier. - - A DHCPv4 updater uses the 0x0002 type code if a Client Identifier - option is present in the DHCPv4 messages and it is encoded as - specified in [6]. Otherwise, the updater uses 0x0001 if a Client - Identifier option is present, and 0x0000 if not. - - A DHCPv6 updater always uses the 0x0002 type code. - -3.5.1. Using the Client's DUID - - When the updater is using the Client's DUID (either from a DHCPv6 - Client Identifier option or from a portion of the DHCPv4 Client - Identifier option encoded as specified in [6]), the first two octets - of the DHCID RR MUST be 0x0002, in network byte order. The third - octet is the digest type code (1 for SHA-256). The rest of the DHCID - RR MUST contain the results of computing the SHA-256 hash across the - octets of the DUID followed by the FQDN. - - - - - - - -Stapp, et al. Standards Track [Page 5] - -RFC 4701 The DHCID RR October 2006 - - -3.5.2. Using the Client Identifier Option - - When the updater is using the DHCPv4 Client Identifier option sent by - the client in its DHCPREQUEST message, the first two octets of the - DHCID RR MUST be 0x0001, in network byte order. The third octet is - the digest type code (1 for SHA-256). The rest of the DHCID RR MUST - contain the results of computing the SHA-256 hash across the data - octets (i.e., the Type and Client-Identifier fields) of the option, - followed by the FQDN. - -3.5.3. Using the Client's htype and chaddr - - When the updater is using the client's link-layer address as the - identifier, the first two octets of the DHCID RDATA MUST be zero. - The third octet is the digest type code (1 for SHA-256). To generate - the rest of the resource record, the updater computes a one-way hash - using the SHA-256 algorithm across a buffer containing the client's - network hardware type, link-layer address, and the FQDN data. - Specifically, the first octet 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 octets of the - 'chaddr' field in the client's DHCPREQUEST message follow, in the - same order in which the octets appear in the DHCPREQUEST message. - The number of significant octets in the 'chaddr' field is specified - in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as - specified above, follows. - -3.6. Examples - -3.6.1. Example 1 - - A DHCP server allocates the IPv6 address 2001:DB8::1234:5678 to a - client that included the DHCPv6 client-identifier option data 00:01: - 00:06:41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The - server updates the name "chi6.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 octets - to the value 0x0002, the 1-octet digest type to 1 for SHA-256, and - performing a SHA-256 hash computation across a buffer containing the - 14 octets from the client-id option and the FQDN (represented as - specified in Section 3.5). - - chi6.example.com. AAAA 2001:DB8::1234:5678 - chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l - OjxfNuVAA2kjEA= ) - - If the DHCID RR type is not supported, the RDATA would be encoded - [13] as: - - - -Stapp, et al. Standards Track [Page 6] - -RFC 4701 The DHCID RR October 2006 - - - \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd - b95000da48c40 ) - -3.6.2. Example 2 - - A DHCP server allocates the IPv4 address 192.0.2.2 to a client that - 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 octets to the value 0x0001, the 1-octet digest - type to 1 for SHA-256, and performing a SHA-256 hash computation - across a buffer containing the seven octets from the client-id option - and the FQDN (represented as specified in Section 3.5). - - chi.example.com. A 192.0.2.2 - chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW - L3b/NaiUDlW2No= ) - - If the DHCID RR type is not supported, the RDATA would be encoded - [13] as: - - \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd - 6a2503956d8da ) - -3.6.3. Example 3 - - A DHCP server allocating the IPv4 address 192.0.2.3 to a client with - the 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 - octets to zero, the 1-octet digest type to 1 for SHA-256, and - performing an SHA-256 hash computation across a buffer containing the - 1-octet 'htype' value for Ethernet, 0x01, followed by the six octets - of the Ethernet MAC address, and the domain name (represented as - specified in Section 3.5). - - client.example.com. A 192.0.2.3 - client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V - ytcKD//7es/deY= ) - - If the DHCID RR type is not supported, the RDATA would be encoded - [13] as: - - \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283 - fffedeb3f75e6 ) - - - - - -Stapp, et al. Standards Track [Page 7] - -RFC 4701 The DHCID RR October 2006 - - -4. Use of the DHCID RR - - This RR MUST NOT be used for any purpose other than that detailed in - [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, 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 obscure the client's identity information, - a one-way hash is used. Further, 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. - - However, it should be noted that an attacker that has some knowledge, - such as of MAC addresses commonly used in DHCP client identification - data, may be able to discover the client's DHCP identify by using a - brute-force attack. Even without any additional knowledge, the - number of unknown bits used in computing the hash is typically only - 48 to 80. - - Administrators should be wary of permitting unsecured DNS updates to - zones, whether or not they are exposed to the global Internet. Both - DHCP clients and servers SHOULD use some form of update - authentication (e.g., [12]) when performing DNS updates. - - - -Stapp, et al. Standards Track [Page 8] - -RFC 4701 The DHCID RR October 2006 - - -7. IANA Considerations - - IANA has allocated a DNS RR type number for the DHCID record type. - - This specification defines a new number-space for the 2-octet - identifier type codes associated with the DHCID RR. IANA has - established 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 identifier type codes are - assigned through Standards Action, as defined in [5]. - - This specification defines a new number-space for the 1-octet digest - type codes associated with the DHCID RR. IANA has established a - registry of the values for this number-space. Two initial values are - assigned in Section 3.4. New DHCID RR digest type codes are assigned - through Standards Action, as defined in [5]. - -8. Acknowledgements - - Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson, - Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie - Volz for their review and suggestions. - -9. References - -9.1. Normative References - - [1] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain - Name (FQDN) Conflicts among Dynamic Host Configuration Protocol - (DHCP) Clients", RFC 4703, October 2006. - - [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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers - for Dynamic Host Configuration Protocol Version Four (DHCPv4)", - RFC 4361, February 2006. - - - - - -Stapp, et al. Standards Track [Page 9] - -RFC 4701 The DHCID RR October 2006 - - -9.2. Informative References - - [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - - [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - - [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [12] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Standards Track [Page 10] - -RFC 4701 The DHCID RR October 2006 - - -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 - Araneus Information Systems Oy - Ulappakatu 1 - 02320 Espoo - Finland - - EMail: gson@araneus.fi - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Standards Track [Page 11] - -RFC 4701 The DHCID RR October 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Stapp, et al. Standards Track [Page 12] - |
