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
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)
用于编码动态主机配置协议（DHCP）信息（DHCID RR）的DNS资源记录（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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
动态主机配置协议（DHCP）客户端可以尝试更新相同的DNS完全限定域名（FQDN），或者在获取DHCP租约时更新已添加到DNS中用于其他目的的DNS FQDN。无论是DHCP服务器还是客户端本身执行DNS更新，都可能发生冲突。为了解决此类冲突，RFC 4703建议在DNS中存储客户端标识符，以明确地将域名与它们所引用的DHCP客户端相关联。此备忘录为此目的定义了一种独特的资源记录（RR）类型，供DHCP客户端和服务器使用：“DHCID”RR。
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
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
A set of procedures to allow DHCP [7] [11] clients and servers to automatically update the DNS ([3], [4]) is proposed in [1].
[1]中提出了一套允许DHCP[7][11]客户端和服务器自动更新DNS（[3]、[4]）的过程。
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.
如果多个DHCP客户端希望使用相同的DNS名称，或者一个DHCP客户端试图使用为其他目的添加的名称，则可能会发生冲突。为了解决此类冲突，[1]建议在DNS中存储客户端标识符，以明确地将域名与使用它们的DHCP客户端相关联。为了清楚起见，该DHCP信息优选使用不同的RR类型。此备忘录为此目的定义了一个独特的RR，供DHCP客户端或服务器使用：“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.
为了隐藏潜在的敏感客户机标识信息，存储的数据是单向SHA-256哈希计算的结果。哈希包括来自DHCP客户端消息以及域名本身的信息，因此存储在DHCID RR中的数据将取决于DHCP协议交互中使用的客户端标识和域名。这意味着，如果单个客户机随时间与多个名称关联，DHCID RDATA将有所不同。这使得“跟踪”客户机变得困难，因为它与各种域名相关联。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[2]中所述进行解释。
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.
DHCID RR由助记DHCID和类型代码49定义。DHCID RR仅在in类中定义。DHCID RRs不会导致额外的节处理。
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.
传输中DHCID RR的RDATA部分包含二进制数据的RDLENGTH八位字节。该数据的格式以及DHCP服务器和客户端对其的解释如下所述。
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,
DNS软件应该考虑RDATA部分是不透明的。DHCP客户端或服务器使用DHCID RR将DHCP客户端的标识与DNS名称关联，以便多个DHCP客户端和服务器可以确定地对同一区域执行动态DNS更新。从更新程序的角度来看，DHCID资源记录RDATA由一个2-octet标识符类型组成，按网络字节顺序排列，
followed by a 1-octet digest type, followed by one or more octets representing the actual identifier:
后跟1个八位字节摘要类型，后跟表示实际标识符的一个或多个八位字节：
< 2 octets > Identifier type code
< 1 octet > Digest type code
< n octets > Digest (length depends on digest type)
< 2 octets > Identifier type code
< 1 octet > Digest type code
< n octets > Digest (length depends on digest type)
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.
在DNS主文件中，RDATA以base-64编码表示为单个块，与[8]第3节中用于表示二进制数据的块相同。数据可以被分成任意数量的空格分隔的子字符串，下至单个base-64位，这些子字符串连接起来形成完整的RDATA。这些子字符串可以使用标准括号跨行。
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:
DHCID RR标识符类型代码指定DHCP客户端请求中的哪些数据用作哈希函数的输入。标识符类型代码在IANA维护的注册表中定义，如第7节所述。标识符类型代码和该类型标识符的初始赋值列表为：
+------------------+------------------------------------------------+
| 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. |
+------------------+------------------------------------------------+
+------------------+------------------------------------------------+
| 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. |
+------------------+------------------------------------------------+
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.
DHCID RR摘要类型代码是所用摘要算法的标识符。根据标识符和规范FQDN计算摘要，如下一节所述。
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.
摘要类型代码在IANA维护的注册表中定义，如第7节所述。摘要类型代码的初始赋值列表为：保留值0，值1为SHA-256。保留其他类型需要IETF标准操作。定义新值还需要IETF标准行动来记录DNS更新程序如何处理多个摘要类型。
The DHCID RDATA is formed by concatenating the 2-octet identifier type code with variable-length data.
DHCID RDATA是通过将2-octet标识符类型代码与可变长度数据串联而形成的。
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).
除0xffff以外的所有类型代码的RDATA（保留用于将来扩展）是通过连接2个八位标识符类型代码、1个八位摘要类型代码和摘要值（SHA-256为32个八位字节）形成的。
< identifier-type > < digest-type > < digest >
< identifier-type > < digest-type > < digest >
The input to the digest hash function is defined to be:
摘要哈希函数的输入定义为：
digest = SHA-256(< identifier > < FQDN >)
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.
FQDN在缓冲区中以[9]第6.2节所述的标准导线格式表示。标识符类型代码和标识符相关，如第3.3节所述：标识符类型代码描述标识符的来源。
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.
如果DHCPv4消息中存在客户端标识符选项，并且按照[6]中的规定对其进行编码，则DHCPv4更新程序将使用0x0002类型代码。否则，如果存在客户端标识符选项，则更新程序使用0x0001，如果不存在，则使用0x0000。
A DHCPv6 updater always uses the 0x0002 type code.
DHCPv6更新程序始终使用0x0002类型代码。
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.
当更新程序使用客户机的DUID（来自DHCPv6客户机标识符选项或根据[6]中指定编码的DHCPv4客户机标识符选项的一部分）时，DHCID RR的前两个八位字节必须为0x0002，以网络字节顺序排列。第三个八位组是摘要类型代码（SHA-256为1）。DHCID RR的其余部分必须包含跨DUID的八位字节（后跟FQDN）计算SHA-256哈希的结果。
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.
当更新程序使用由客户端在其DHCPREQUEST消息中发送的DHCPv4客户端标识符选项时，DHCID RR的前两个八位字节必须为0x0001（按网络字节顺序）。第三个八位组是摘要类型代码（SHA-256为1）。DHCID RR的其余部分必须包含跨选项的数据八位字节（即类型和客户端标识符字段）计算SHA-256哈希的结果，然后是FQDN。
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.
当更新程序使用客户端的链接层地址作为标识符时，DHCID RDATA的前两个八位字节必须为零。第三个八位组是摘要类型代码（SHA-256为1）。为了生成剩余的资源记录，更新程序使用SHA-256算法在包含客户端网络硬件类型、链路层地址和FQDN数据的缓冲区中计算单向散列。具体来说，缓冲区的第一个八位字节包含网络硬件类型，它出现在客户端DHCPREQUEST消息的DHCP“htype”字段中。客户端的DHCPREQUEST消息中“chaddr”字段的所有有效八位字节都将按照八位字节在DHCPREQUEST消息中出现的相同顺序显示。“chaddr”字段中的有效八位字节数在DHCPREQUEST消息的“hlen”字段中指定。如上所述，FQDN数据如下所示。
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).
DHCP服务器将IPv6地址2001:DB8:：1234:5678分配给在其DHCPv6请求中包含DHCPv6客户端标识符选项数据00:01:00:06:41:2d:f1:66:01:02:03:04:05:06的客户端。服务器代表客户端更新名称“chi6.example.com”，并使用DHCP客户端标识符选项数据作为形成DHCID RR的输入。DHCID RDATA是通过将两个类型的八位字节设置为值0x0002，将SHA-256的1-八位字节摘要类型设置为1，并在包含来自客户端id选项的14个八位字节和FQDN（如第3.5节所述）的缓冲区中执行SHA-256哈希计算而形成的。
chi6.example.com. AAAA 2001:DB8::1234:5678
chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
OjxfNuVAA2kjEA= )
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:
如果不支持DHCID RR类型，RDATA将被编码为[13]：
\# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd b95000da48c40 )
\#35（000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd b95000da48c40）
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).
DHCP服务器将IPv4地址192.0.2.2分配给在其DHCP请求中包含DHCP客户端标识符选项数据01:07:08:09:0a:0b:0c的客户端。服务器代表客户端更新名称“chi.example.com”，并使用DHCP客户端标识符选项数据作为形成DHCID RR的输入。DHCID RDATA是通过将两个类型的八位字节设置为值0x0001，将SHA-256的1-八位字节摘要类型设置为1，并在包含来自客户端id选项和FQDN（如第3.5节所述）的七个八位字节的缓冲区中执行SHA-256哈希计算而形成的。
chi.example.com. A 192.0.2.2 chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW L3b/NaiUDlW2No= )
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:
如果不支持DHCID RR类型，RDATA将被编码为[13]：
\# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd 6a2503956d8da )
\#35（0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd 6a2503956d8da）
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”将IPv4地址192.0.2.3分配给以太网MAC地址为01:02:03:04:05:06的客户端的DHCP服务器使用客户端的链路层地址来标识客户端。DHCID RDATA是通过将两个类型的八位字节设置为零，将SHA-256的1-八位字节摘要类型设置为1，并在包含以太网的1-八位字节“htype”值0x01的缓冲区中执行SHA-256哈希计算，后跟以太网MAC地址的六个八位字节和域名（如第3.5节所述）。
client.example.com. A 192.0.2.3 client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V ytcKD//7es/deY= )
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:
如果不支持DHCID RR类型，RDATA将被编码为[13]：
\# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283 fffedeb3f75e6 )
\#35（00000 1C4B9A5B24951343158DDE7BC77169841F7A4243A572B5C283 fffedeb3f75e6）
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].
除[1]中详述的用途外，不得将该RR用于任何其他用途。尽管此RR包含对DNS服务器不透明的数据，但更新和解释此记录的所有实体的数据必须一致。因此，由于修订[1]，新的数据格式只能通过DHC工作组的行动来定义。
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.
DHCID RR中的数据允许更新程序确定是否有多个DHCP客户端希望使用特定FQDN。这允许站点管理员建立有关DNS更新的策略。DHCID RR本身不建立任何策略。
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.
更新程序使用来自DHCP客户端请求的数据和客户端希望用于计算客户端标识哈希的域名，然后将该哈希与他们希望与客户端IP地址关联的名称上的任何DHCID RRs中的数据进行比较。如果更新程序发现其RDATA与其计算的客户机标识不匹配的DHCID RRs，则更新程序应得出结论，即不同的客户机当前与所讨论的名称相关联。然后，更新程序应根据站点的管理策略进行操作。该策略可能要求选择不同的名称，或者允许更新程序继续。
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.
DHCID记录本身不会给DNS带来任何新的安全问题。为了隐藏客户端的身份信息，使用了单向散列。此外，为了通过检查与特定散列值相关联的名称使“跟踪”客户机变得困难，在散列计算中包括FQDN。因此，RDATA既依赖于DHCP客户端标识数据，也依赖于与客户端关联的每个FQDN。
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.
但是，应注意，具有一些知识（例如DHCP客户端标识数据中常用的MAC地址）的攻击者可能能够通过使用蛮力攻击来发现客户端的DHCP标识。即使没有任何额外的知识，在计算散列中使用的未知比特数通常也只有48到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.
管理员应警惕允许对区域进行不安全的DNS更新，无论它们是否暴露于全球互联网。在执行DNS更新时，DHCP客户端和服务器都应该使用某种形式的更新身份验证（例如，[12]）。
IANA has allocated a DNS RR type number for the DHCID record type.
IANA已为DHCID记录类型分配了DNS RR类型号。
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].
本规范为与DHCID RR相关联的2个八位标识符类型代码定义了一个新的数字空间。IANA已经为这个数字空间建立了一个值的注册表。第3.3节中指定了三个初始值，值0xFFFF保留供将来使用。根据[5]中的定义，通过标准行动分配新的DHCID RR标识符类型代码。
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].
本规范为与DHCID RR相关的1-octet摘要类型代码定义了一个新的数字空间。IANA已经为这个数字空间建立了一个值的注册表。第3.4节中指定了两个初始值。新的DHCID RR摘要类型代码通过标准行动分配，如[5]中所定义。
Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson, Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie Volz for their review and suggestions.
Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson, Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie Volz for their review and suggestions.translate error, please retry
[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.
[1] Stapp，M.和B.Volz，“解决动态主机配置协议（DHCP）客户端之间的完全限定域名（FQDN）冲突”，RFC 4703，2006年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[3] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[4] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[4] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[6] Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（DHCPv4）的节点特定客户端标识符”，RFC 4361，2006年2月。
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[7] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[8] Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[9] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[10] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[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.
[11] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[12] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[12] Vixie，P.，Gudmundsson，O.，Eastlake，D.，和B.Wellington，“DNS的密钥交易认证（TSIG）”，RFC 28452000年5月。
[13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[13] Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
Authors' Addresses
作者地址
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Mark Stapp Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Phone: 978.936.1535 EMail: mjs@cisco.com
电话：978.936.1535电子邮件：mjs@cisco.com
Ted Lemon Nominum, Inc. 950 Charter St. Redwood City, CA 94063 USA
Ted Lemon Nominum，Inc.美国加利福尼亚州红杉市特许街950号，邮编94063
EMail: mellon@nominum.com
EMail: mellon@nominum.com
Andreas Gustafsson Araneus Information Systems Oy Ulappakatu 1 02320 Espoo Finland
Andreas Gustafsson Araneus信息系统Oy Ulappakatu芬兰埃斯波102320
EMail: gson@araneus.fi
EMail: gson@araneus.fi
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。