Network Working Group                                           M. Stapp
Request for Comments: 4702                                       B. Volz
Category: Standards Track                            Cisco Systems, Inc.
                                                              Y. Rekhter
                                                        Juniper Networks
                                                            October 2006
        
Network Working Group                                           M. Stapp
Request for Comments: 4702                                       B. Volz
Category: Standards Track                            Cisco Systems, Inc.
                                                              Y. Rekhter
                                                        Juniper Networks
                                                            October 2006
        

The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option

动态主机配置协议(DHCP)客户端完全限定域名(FQDN)选项

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

摘要

This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment.

本文档描述了IPv4的动态主机配置协议(DHCPv4)选项,该选项可用于交换有关DHCPv4客户端完全限定域名的信息,以及有关更新与客户端地址分配相关的DNS RR的责任的信息。

Table of Contents

目录

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
      1.2. Models of Operation ........................................3
   2. The Client FQDN Option ..........................................4
      2.1. The Flags Field ............................................5
      2.2. The RCODE Fields ...........................................6
      2.3. The Domain Name Field ......................................6
           2.3.1. Deprecated ASCII Encoding ...........................7
   3. DHCP Client Behavior ............................................7
      3.1. Interaction with Other Options .............................7
      3.2. Client Desires to Update A RRs .............................8
      3.3. Client Desires Server to Do DNS Updates ....................8
      3.4. Client Desires No Server DNS Updates .......................8
      3.5. Domain Name and DNS Update Issues ..........................9
   4. DHCP Server Behavior ...........................................10
      4.1. When to Perform DNS Updates ...............................11
   5. DNS RR TTLs ....................................................12
   6. DNS Update Conflicts ...........................................12
   7. IANA Considerations ............................................13
   8. Security Considerations ........................................13
   9. Acknowledgements ...............................................14
   10. References ....................................................14
      10.1. Normative References .....................................14
      10.2. Informative References ...................................15
        
   1. Introduction ....................................................3
      1.1. Terminology ................................................3
      1.2. Models of Operation ........................................3
   2. The Client FQDN Option ..........................................4
      2.1. The Flags Field ............................................5
      2.2. The RCODE Fields ...........................................6
      2.3. The Domain Name Field ......................................6
           2.3.1. Deprecated ASCII Encoding ...........................7
   3. DHCP Client Behavior ............................................7
      3.1. Interaction with Other Options .............................7
      3.2. Client Desires to Update A RRs .............................8
      3.3. Client Desires Server to Do DNS Updates ....................8
      3.4. Client Desires No Server DNS Updates .......................8
      3.5. Domain Name and DNS Update Issues ..........................9
   4. DHCP Server Behavior ...........................................10
      4.1. When to Perform DNS Updates ...............................11
   5. DNS RR TTLs ....................................................12
   6. DNS Update Conflicts ...........................................12
   7. IANA Considerations ............................................13
   8. Security Considerations ........................................13
   9. Acknowledgements ...............................................14
   10. References ....................................................14
      10.1. Normative References .....................................14
      10.2. Informative References ...................................15
        
1. Introduction
1. 介绍

DNS ([2], [3]) maintains (among other things) the information about the mapping between hosts' Fully Qualified Domain Names (FQDNs) [11] and IP addresses assigned to the hosts. The information is maintained in two types of Resource Records (RRs): A and PTR. The DNS update specification ([4]) describes a mechanism that enables DNS information to be updated over a network.

DNS([2]、[3])维护(除其他外)主机的完全限定域名(FQDN)[11]与分配给主机的IP地址之间的映射信息。信息保存在两种类型的资源记录(RRs)中:A和PTR。DNS更新规范([4])描述了一种能够通过网络更新DNS信息的机制。

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4 or just DHCP in this document) [5] provides a mechanism by which a host (a DHCP client) can acquire certain configuration information, along with its address. This document specifies a DHCP option, the Client FQDN option, which can be used by DHCP clients and servers to exchange information about the client's fully qualified domain name for an address and who has the responsibility for updating the DNS with the associated A and PTR RRs.

IPv4的动态主机配置协议(DHCPv4或本文档中的DHCP)[5]提供了一种机制,主机(DHCP客户端)可以通过该机制获取某些配置信息及其地址。本文档指定了一个DHCP选项,即客户端FQDN选项,DHCP客户端和服务器可以使用该选项交换有关客户端地址的完全限定域名的信息,以及谁负责使用关联的a和PTR RRs更新DNS。

1.1. Terminology
1.1. 术语

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 [1].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。

1.2. Models of Operation
1.2. 运作模式

When a DHCP client acquires a new address, a site's administrator may desire that one or both of the A RR for the client's FQDN and the PTR RR for the acquired address be updated. Therefore, two separate DNS update transactions may occur. Acquiring an address via DHCP involves two entities: a DHCP client and a DHCP server. In principle, each of these entities could perform none, one, or both of the transactions. However, in practice, not all permutations make sense. The DHCP Client FQDN option is primarily intended to operate in the following two cases:

当DHCP客户端获取新地址时,站点管理员可能希望更新客户端FQDN的RR和获取的地址的PTR RR中的一个或两个。因此,可能会发生两个单独的DNS更新事务。通过DHCP获取地址涉及两个实体:DHCP客户端和DHCP服务器。原则上,这些实体中的每一个都可以不执行、执行一项或同时执行两项交易。然而,在实践中,并非所有排列都有意义。DHCP客户端FQDN选项主要用于以下两种情况:

1. DHCP client updates the A RR, DHCP server updates the PTR RR.

1. DHCP客户端更新A RR,DHCP服务器更新PTR RR。

2. DHCP server updates both the A and the PTR RRs.

2. DHCP服务器同时更新A和PTR RRs。

The only difference between these two cases is whether the FQDN-to-IP-address mapping is updated by a DHCP client or by a DHCP server. The IP-address-to-FQDN mapping is updated by a DHCP server in both cases.

这两种情况之间的唯一区别是FQDN到IP地址的映射是由DHCP客户端还是由DHCP服务器更新的。在这两种情况下,DHCP服务器都会更新IP地址到FQDN的映射。

The reason these two are important, while others are unlikely, has to do with authority over the respective DNS domain names. A DHCP client may be given authority over mapping its own A RRs, or that

这两个原因很重要,而其他原因则不太可能,这与对各自DNS域名的权限有关。DHCP客户端可以被授予映射其自己的RRs的权限,或者

authority may be restricted to a server to prevent the client from listing arbitrary addresses or associating its address with arbitrary domain names. In all cases, the only reasonable place for the authority over the PTR RRs associated with the address is in the DHCP server that allocates the address.

权限可能仅限于服务器,以防止客户端列出任意地址或将其地址与任意域名关联。在所有情况下,对与该地址相关的PTR RRs的权限的唯一合理位置是在分配该地址的DHCP服务器中。

Note: A third case is supported: the client requests that the server perform no updates. However, this case is presumed to be rare because of the authority issues.

注意:支持第三种情况:客户端请求服务器不执行更新。然而,由于当局的问题,这种情况被认为是罕见的。

It is considered local policy to permit DHCP clients and servers to perform DNS updates to zones. This document does not require any specific administrative policy and does not propose one. Furthermore, this specification applies only to DHCP client and server processes; it does not apply to other processes that initiate DNS updates.

允许DHCP客户端和服务器对区域执行DNS更新被视为本地策略。本文件不要求任何具体的行政政策,也不提出任何具体的行政政策。此外,本规范仅适用于DHCP客户端和服务器进程;它不适用于启动DNS更新的其他进程。

This document describes a DHCP option which a client can use to convey all or part of its domain name to a DHCP server. Site-specific policy determines whether DHCP servers use the names that clients offer or not, and what DHCP servers may do in cases where clients do not supply domain names.

本文档描述了一个DHCP选项,客户端可以使用该选项将其全部或部分域名传送到DHCP服务器。特定于站点的策略确定DHCP服务器是否使用客户端提供的名称,以及在客户端不提供域名的情况下DHCP服务器可以执行的操作。

2. The Client FQDN Option
2. 客户端FQDN选项

To update the IP-address-to-FQDN mapping, a DHCP server needs to know the FQDN of the client to which the server leases the address. To allow the client to convey its FQDN to the server, this document defines a new DHCP option, called "Client FQDN". The Client FQDN option also contains Flags, which DHCP servers can use to convey information about DNS updates to clients, and two deprecated RCODEs.

要将IP地址更新为FQDN映射,DHCP服务器需要知道服务器租用地址的客户端的FQDN。为了允许客户端将其FQDN传送到服务器,本文档定义了一个新的DHCP选项,称为“客户端FQDN”。客户端FQDN选项还包含标志(DHCP服务器可以使用这些标志向客户端传递有关DNS更新的信息)和两个不推荐使用的RCODE。

Clients MAY send the Client FQDN option, setting appropriate Flags values, in both their DHCPDISCOVER and DHCPREQUEST messages. If a client sends the Client FQDN option in its DHCPDISCOVER message, it MUST send the option in subsequent DHCPREQUEST messages though the contents of the option MAY change.

客户端可以在其DHCPDISCOVER和DHCPREQUEST消息中发送客户端FQDN选项,设置适当的标志值。如果客户端在其DHCPDISCOVER消息中发送客户端FQDN选项,则它必须在后续DHCPREQUEST消息中发送该选项,尽管该选项的内容可能会更改。

Only one Client FQDN option MAY appear in a message, though it may be instantiated in a message as multiple options [9]. DHCP clients and servers supporting this option MUST implement DHCP option concatenation [9]. In the terminology of [9], the Client FQDN option is a concatenation-requiring option.

一条消息中只能显示一个客户端FQDN选项,尽管它可能在消息中被实例化为多个选项[9]。支持此选项的DHCP客户端和服务器必须实现DHCP选项连接[9]。在[9]的术语中,客户机FQDN选项是一个需要连接的选项。

The code for this option is 81. Len contains the number of octets that follow the Len field, and the minimum value is 3 (octets).

此选项的代码为81。Len包含Len字段后面的八位字节数,最小值为3(八位字节)。

The format of the Client FQDN option is:

客户端FQDN选项的格式为:

        Code   Len    Flags  RCODE1 RCODE2   Domain Name
       +------+------+------+------+------+------+--
       |  81  |   n  |      |      |      |       ...
       +------+------+------+------+------+------+--
        
        Code   Len    Flags  RCODE1 RCODE2   Domain Name
       +------+------+------+------+------+------+--
       |  81  |   n  |      |      |      |       ...
       +------+------+------+------+------+------+--
        

The above figure follows the conventions of [12].

上图遵循[12]的惯例。

2.1. The Flags Field
2.1. 旗帜区

The format of the 1-octet Flags field is:

1-octet标志字段的格式为:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |  MBZ  |N|E|O|S|
       +-+-+-+-+-+-+-+-+
        
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |  MBZ  |N|E|O|S|
       +-+-+-+-+-+-+-+-+
        

The "S" bit indicates whether the server SHOULD or SHOULD NOT perform the A RR (FQDN-to-address) DNS updates. A client sets the bit to 0 to indicate the server SHOULD NOT perform the updates and 1 to indicate the server SHOULD perform the updates. The state of the bit in the reply from the server indicates the action to be taken by the server; if 1, the server has taken responsibility for A RR updates for the FQDN.

“S”位指示服务器是否应该执行A RR(FQDN到地址)DNS更新。客户端将位设置为0表示服务器不应执行更新,将位设置为1表示服务器应执行更新。来自服务器的回复中位的状态指示服务器要采取的操作;如果为1,则服务器负责FQDN的RR更新。

The "O" bit indicates whether the server has overridden the client's preference for the "S" bit. A client MUST set this bit to 0. A server MUST set this bit to 1 if the "S" bit in its reply to the client does not match the "S" bit received from the client.

“O”位表示服务器是否已覆盖客户端对“s”位的首选项。客户端必须将此位设置为0。如果服务器对客户端的回复中的“S”位与从客户端接收到的“S”位不匹配,则服务器必须将该位设置为1。

The "N" bit indicates whether the server SHOULD NOT perform any DNS updates. A client sets this bit to 0 to request that the server SHOULD perform updates (the PTR RR and possibly the A RR based on the "S" bit) or to 1 to request that the server SHOULD NOT perform any DNS updates. A server sets the "N" bit to indicate whether the server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" bit is 1, the "S" bit MUST be 0.

“N”位指示服务器是否不应执行任何DNS更新。客户端将此位设置为0以请求服务器执行更新(PTR RR,可能还有基于“S”位的A RR),或将此位设置为1以请求服务器不执行任何DNS更新。服务器设置“N”位,以指示服务器应(0)还是不应(1)执行DNS更新。如果“N”位为1,“S”位必须为0。

The "E" bit indicates the encoding of the Domain Name field. 1 indicates canonical wire format, without compression, as described in [3], Section 3.1. This encoding SHOULD be used by clients and MUST be supported by servers. 0 indicates a now-deprecated ASCII encoding (see Section 2.3.1). A server MUST use the same encoding as that

“E”位表示域名字段的编码。1表示标准导线格式,无压缩,如第3.1节[3]所述。此编码应由客户端使用,并且必须由服务器支持。0表示现在已弃用的ASCII编码(参见第2.3.1节)。服务器必须使用与该服务器相同的编码

used by the client. A server that does not support the deprecated ASCII encoding MUST ignore Client FQDN options that use that encoding.

由客户端使用。不支持不推荐的ASCII编码的服务器必须忽略使用该编码的客户端FQDN选项。

The remaining bits in the Flags field are reserved for future assignment. DHCP clients and servers that send the Client FQDN option MUST clear the MBZ bits, and they MUST ignore these bits.

标志字段中的剩余位保留用于将来的分配。发送客户端FQDN选项的DHCP客户端和服务器必须清除MBZ位,并且必须忽略这些位。

2.2. The RCODE Fields
2.2. RCODE字段

The two 1-octet RCODE1 and RCODE2 fields are deprecated. A client SHOULD set these to 0 when sending the option and SHOULD ignore them on receipt. A server SHOULD set these to 255 when sending the option and MUST ignore them on receipt.

不推荐使用两个1-octet RCODE1和RCODE2字段。客户端在发送选项时应将这些设置为0,并在收到选项时忽略它们。服务器在发送选项时应将这些设置为255,并且在收到选项时必须忽略它们。

As this option with these fields is already in wide use, the fields are retained. These fields were originally defined for use by a DHCP server to indicate to a DHCP client the Response Code from any A (RCODE1) or PTR (RCODE2) RR DNS updates it has performed, or a value of 255 was used to indicate that an update had been initiated but had not yet completed. Each of these fields is one octet long. These fields were defined before EDNS0 [13], which describes a mechanism for extending the length of a DNS RCODE to 12 bits, which is another reason to deprecate them.

由于带有这些字段的此选项已被广泛使用,因此将保留这些字段。这些字段最初定义为供DHCP服务器使用,以向DHCP客户端指示其已执行的任何a(RCODE1)或PTR(RCODE2)RR DNS更新的响应代码,或者使用255值指示更新已启动但尚未完成。每个字段都有一个八位组长。这些字段是在EDNS0[13]之前定义的,EDNS0[13]描述了一种将DNS RCODE的长度扩展到12位的机制,这是不推荐这些字段的另一个原因。

If the client needs to confirm that the DNS update has been done, it MAY use a DNS query to check whether the mapping is up to date. However, depending on the load on the DHCP and DNS servers and the DNS propagation delays, the client can only infer success. If the information is not found to be up to date in DNS, the authoritative servers might not have completed the updates or zone transfers, or caching resolvers may yet have updated their caches.

如果客户端需要确认DNS更新已经完成,它可以使用DNS查询来检查映射是否是最新的。但是,根据DHCP和DNS服务器上的负载以及DNS传播延迟,客户端只能推断成功。如果在DNS中未找到最新信息,则权威服务器可能尚未完成更新或区域传输,或者缓存解析程序可能尚未更新其缓存。

2.3. The Domain Name Field
2.3. 域名字段

The Domain Name part of the option carries all or part of the FQDN of a DHCP client. The data in the Domain Name field SHOULD appear in canonical wire format as specified in [3], Section 3.1. If the DHCP client uses the canonical wire format, it MUST set the "E" bit in the Flags field to 1. In order to determine whether the FQDN has changed between message exchanges, the client and server MUST NOT alter the Domain Name field contents unless the FQDN has actually changed.

选项的域名部分包含DHCP客户端的全部或部分FQDN。域名字段中的数据应以[3]第3.1节中规定的标准导线格式显示。如果DHCP客户端使用规范的wire格式,则必须将Flags字段中的“E”位设置为1。为了确定FQDN在消息交换之间是否已更改,客户端和服务器不得更改域名字段内容,除非FQDN已实际更改。

A client MAY be configured with a fully qualified domain name or with a partial name that is not fully qualified. If a client knows only part of its name, it MAY send a name that is not fully qualified, indicating that it knows part of the name but does not necessarily know the zone in which the name is to be embedded.

可以使用完全限定的域名或不完全限定的部分名称配置客户端。如果客户机只知道其名称的一部分,它可能会发送一个不完全限定的名称,表示它知道名称的一部分,但不一定知道名称将嵌入的区域。

To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating zero-length label. To send a partial name, the Domain Name field is set to the DNS encoded domain name without the terminating zero-length label.

要发送完全限定的域名,域名字段设置为DNS编码的域名,包括终止的零长度标签。要发送部分名称,域名字段将设置为DNS编码的域名,而不带终止零长度标签。

A client MAY also leave the Domain Name field empty if it desires the server to provide a name.

如果客户机希望服务器提供名称,它也可以将域名字段留空。

2.3.1. Deprecated ASCII Encoding
2.3.1. 不推荐的ASCII编码

A substantial population of clients implemented an earlier draft of this specification, which permitted an ASCII encoding of the Domain Name field. Server implementations SHOULD be aware that clients that send the Client FQDN option with the "E" bit set to 0 are using an ASCII encoding of the Domain Name field. Servers MAY be prepared to return an ASCII-encoded version of the Domain Name field to such clients. Servers that are not prepared to return an ASCII-encoded version MUST ignore the Client FQDN option if the "E" bit is 0. The use of ASCII encoding in this option SHOULD be considered deprecated.

大量客户机实现了本规范的早期草案,该草案允许对域名字段进行ASCII编码。服务器实现应该知道,发送“E”位设置为0的客户端FQDN选项的客户端使用的是域名字段的ASCII编码。服务器可能准备好向此类客户端返回域名字段的ASCII编码版本。如果“E”位为0,则不准备返回ASCII编码版本的服务器必须忽略客户端FQDN选项。此选项中使用ASCII编码应视为不推荐使用。

A DHCP client that used ASCII encoding was permitted to suggest a single label if it was not configured with a fully qualified name. Such clients send a single label as a series of ASCII characters in the Domain Name field, excluding the "." (dot) character.

如果使用ASCII编码的DHCP客户端未配置完全限定名称,则允许其建议单个标签。这类客户端在域名字段中以一系列ASCII字符的形式发送单个标签,不包括“.”(点)字符。

Clients and servers SHOULD follow the character set rules of [6], fourth section ("Assumptions"), first 5 sentences, as modified by [7], Section 2.1. However, implementers SHOULD also be aware that some client software may send data intended to be in other character sets. This specification does not require support for other character sets.

客户机和服务器应遵循[6]第四节(“假设”)前5句中的字符集规则,经[7]第2.1节修改。然而,实现者也应该意识到,一些客户端软件可能会发送预期在其他字符集中的数据。本规范不要求支持其他字符集。

3. DHCP Client Behavior
3. DHCP客户端行为

The following describes the behavior of a DHCP client that implements the Client FQDN option.

以下描述了实现客户端FQDN选项的DHCP客户端的行为。

3.1. Interaction with Other Options
3.1. 与其他选择的互动

Other DHCP options MAY carry data that is related to the Domain Name field of the Client FQDN option. The Host Name option [12], for example, contains an ASCII string representation of the client's host name. In general, a client does not need to send redundant data, and therefore clients that send the Client FQDN option in their messages MUST NOT also send the Host Name option. Clients that receive both the Host Name option and the Client FQDN option from a server SHOULD

其他DHCP选项可能包含与客户端FQDN选项的域名字段相关的数据。例如,主机名选项[12]包含客户端主机名的ASCII字符串表示形式。通常,客户端不需要发送冗余数据,因此在其消息中发送客户端FQDN选项的客户端也不得发送主机名选项。从服务器接收主机名选项和客户端FQDN选项的客户端应

prefer Client FQDN option data. Section 4 instructs servers to ignore the Host Name option in client messages that include the Client FQDN option.

首选客户端FQDN选项数据。第4节指示服务器忽略包含客户端FQDN选项的客户端消息中的主机名选项。

3.2. Client Desires to Update A RRs
3.2. 客户希望更新RRs

If a client that owns/maintains its own FQDN wants to be responsible for updating the FQDN-to-IP-address mapping for the FQDN and address(es) used by the client, the client MUST include the Client FQDN option in the DHCPREQUEST message originated by the client. A DHCP client MAY choose to include the Client FQDN option in its DHCPDISCOVER messages as well as its DHCPREQUEST messages. The "S", "O", and "N" bits in the Flags field in the option MUST be 0.

如果拥有/维护自己的FQDN的客户端希望负责更新FQDN到IP地址的映射,以供客户端使用FQDN和地址,则客户端必须在客户端发出的DHCPREQUEST消息中包含客户端FQDN选项。DHCP客户端可以选择在其DHCPDISCOVER消息以及DHCPREQUEST消息中包含客户端FQDN选项。选项中标志字段中的“S”、“O”和“N”位必须为0。

Once the client's DHCP configuration is completed (the client receives a DHCPACK message and successfully completes a final check on the parameters passed in the message), the client MAY originate an update for the A RR (associated with the client's FQDN) unless the server has set the "S" bit to 1. If the "S" is 1, the DHCP client SHOULD NOT initiate an update for the name in the server's returned Client FQDN option Domain Name field. However, a DHCP client that is explicitly configured with a FQDN MAY ignore the state of the "S" bit if the server's returned name matches the client's configured name.

一旦客户机的DHCP配置完成(客户机收到DHCPACK消息并成功完成对消息中传递的参数的最终检查),客户机可能会发起a RR(与客户机的FQDN关联)的更新,除非服务器已将“s”位设置为1。如果“S”为1,则DHCP客户端不应在服务器返回的客户端FQDN选项域名字段中启动名称更新。但是,如果服务器返回的名称与客户端配置的名称匹配,则显式配置了FQDN的DHCP客户端可能会忽略“S”位的状态。

3.3. Client Desires Server to Do DNS Updates
3.3. 客户端希望服务器进行DNS更新

A client can choose to delegate the responsibility for updating the FQDN-to-IP-address mapping for the FQDN and address(es) used by the client to the server. In order to inform the server of this choice, the client SHOULD include the Client FQDN option in its DHCPREQUEST message and MAY include the Client FQDN option in its DHCPDISCOVER. The "S" bit in the Flags field in the option MUST be 1, and the "O" and "N" bits MUST be 0.

客户机可以选择将客户机使用的FQDN和地址的FQDN到IP地址映射更新责任委托给服务器。为了将此选择通知服务器,客户机应在其DHCPREQUEST消息中包含客户机FQDN选项,并可在其DHCPDISCOVER中包含客户机FQDN选项。选项中标志字段中的“S”位必须为1,“O”和“N”位必须为0。

3.4. Client Desires No Server DNS Updates
3.4. 客户端不需要服务器DNS更新

A client can choose to request that the server perform no DNS updates on its behalf. In order to inform the server of this choice, the client SHOULD include the Client FQDN option in its DHCPREQUEST message and MAY include the Client FQDN option in its DHCPDISCOVER. The "N" bit in the Flags field in the option MUST be 1, and the "S" and "O" bits MUST be 0.

客户端可以选择请求服务器不代表其执行DNS更新。为了将此选择通知服务器,客户机应在其DHCPREQUEST消息中包含客户机FQDN选项,并可在其DHCPDISCOVER中包含客户机FQDN选项。选项中标志字段中的“N”位必须为1,“S”和“O”位必须为0。

Once the client's DHCP configuration is completed (the client receives a DHCPACK message and successfully completes a final check on the parameters passed in the message), the client MAY originate

一旦客户端的DHCP配置完成(客户端接收到DHCPACK消息并成功完成对消息中传递的参数的最终检查),客户端就可以发起

its DNS updates provided the server's "N" bit is 1. If the server's "N" bit is 0, the server MAY perform the PTR RR updates; it MAY also perform the A RR updates if the "S" bit is 1.

如果服务器的“N”位为1,则其DNS更新。如果服务器的“N”位为0,则服务器可以执行PTR-RR更新;如果“S”位为1,它还可以执行A RR更新。

3.5. Domain Name and DNS Update Issues
3.5. 域名和DNS更新问题

As there is a possibility that the DHCP server is configured to complete or replace a domain name that the client sends, the client MAY find it useful to send the Client FQDN option in its DHCPDISCOVER messages. If the DHCP server returns different Domain Name data in its DHCPOFFER message, the client could use that data in performing its own eventual A RR update, or in forming the Client FQDN option that it sends in its DHCPREQUEST message. There is no requirement that the client send identical Client FQDN option data in its DHCPDISCOVER and DHCPREQUEST messages. In particular, if a client has sent the Client FQDN option to its server, and the configuration of the client changes so that its notion of its domain name changes, it MAY send the new name data in a Client FQDN option when it communicates with the server again. This MAY cause the DHCP server to update the name associated with the PTR record and, if the server updated the A record representing the client, to delete that record and attempt an update for the client's current domain name.

由于DHCP服务器可能配置为完成或替换客户端发送的域名,因此客户端可能会发现在其DHCPDISCOVER消息中发送客户端FQDN选项很有用。如果DHCP服务器在其DHCPOFFER消息中返回不同的域名数据,则客户端可以使用该数据执行其自己的最终RR更新,或形成其在DHCPREQUEST消息中发送的客户端FQDN选项。不要求客户端在其DHCPDISCOVER和DHCPREQUEST消息中发送相同的客户端FQDN选项数据。特别是,如果客户机已将客户机FQDN选项发送到其服务器,并且客户机的配置发生了更改,因此其域名的概念发生了更改,则当其再次与服务器通信时,可能会在客户机FQDN选项中发送新的名称数据。这可能会导致DHCP服务器更新与PTR记录关联的名称,如果服务器更新了代表客户端的A记录,则会删除该记录并尝试更新客户端的当前域名。

A client that delegates the responsibility for updating the FQDN-to-IP-address mapping to a server will not receive any indication (either positive or negative) from the server as to whether the server was able to perform the update. The client MAY use a DNS query to check whether the mapping is up to date (see Section 2.2).

委托负责将FQDN到IP地址映射更新到服务器的客户端将不会从服务器接收到有关服务器是否能够执行更新的任何指示(正或负)。客户端可以使用DNS查询来检查映射是否是最新的(参见第2.2节)。

If a client releases its lease prior to the lease expiration time and is responsible for updating its A RR, the client SHOULD delete the A RR associated with the leased address before sending a DHCPRELEASE message. Similarly, if a client was responsible for updating its A RR, but is unable to renew its lease, the client SHOULD attempt to delete the A RR before its lease expires. A DHCP client that has not been able to delete an A RR that it added (because it has lost the use of its DHCP IP address) SHOULD attempt to notify its administrator, perhaps by emitting a log message.

如果客户机在租约到期之前解除租约并负责更新其a RR,则客户机应在发送DHCPRELEASE消息之前删除与租约地址关联的a RR。类似地,如果客户机负责更新其a RR,但无法续订其租约,则客户机应尝试在租约到期前删除a RR。无法删除其添加的RR的DHCP客户端(因为它已失去对其DHCP IP地址的使用)应尝试通知其管理员,可能是通过发出日志消息。

A client that desires to perform DNS updates to A RRs SHOULD NOT do so if the client's address is a private address [8].

如果希望对RRs执行DNS更新的客户端的地址是专用地址,则不应执行此操作[8]。

4. DHCP Server Behavior
4. DHCP服务器行为

The following describes the behavior of a DHCP server that implements the Client FQDN option when the client's message includes the Client FQDN option.

以下描述了当客户端消息包含客户端FQDN选项时,实现客户端FQDN选项的DHCP服务器的行为。

The server examines its configuration and the Flag bits in the client's Client FQDN option to determine how to respond:

服务器检查其配置和客户端的客户端FQDN选项中的标志位,以确定如何响应:

o If the client's "E" bit is 0 and the server does not support ASCII encoding (Section 2.3.1), the server SHOULD ignore the Client FQDN option.

o 如果客户端的“E”位为0,且服务器不支持ASCII编码(第2.3.1节),则服务器应忽略客户端FQDN选项。

o The server sets to 0 the "S", "O", and "N" bits in its copy of the option it will return to the client. The server copies the client's "E" bit.

o 服务器将返回给客户端的选项副本中的“S”、“O”和“N”位设置为0。服务器复制客户端的“E”位。

o If the client's "N" bit is 1 and the server's configuration allows it to honor the client's request for no server initiated DNS updates, the server sets the "N" bit to 1.

o 如果客户端的“N”位为1,并且服务器的配置允许它接受客户端的请求,不进行服务器启动的DNS更新,则服务器将“N”位设置为1。

o Otherwise, if the client's "S" bit is 1 and the server's configuration allows it to honor the client's request for the server to initiate A RR DNS updates, the server sets the "S" to 1. If the server's "S" bit does not match the client's "S" bit, the server sets the "O" bit to 1.

o 否则,如果客户机的“s”位为1,并且服务器的配置允许它接受客户机请求服务器启动RR DNS更新,则服务器将“s”设置为1。如果服务器的“s”位与客户端的“s”位不匹配,则服务器将“O”位设置为1。

The server MAY be configured to use the name supplied in the client's Client FQDN option, or it MAY be configured to modify the supplied name or to substitute a different name. The server SHOULD send its notion of the complete FQDN for the client in the Domain Name field. The server MAY simply copy the Domain Name field from the Client FQDN option that the client sent to the server. The server MUST use the same encoding format (ASCII or DNS binary encoding) that the client used in the Client FQDN option in its DHCPDISCOVER or DHCPREQUEST, and it MUST set the "E" bit in the option's Flags field accordingly.

服务器可以配置为使用客户端的客户端FQDN选项中提供的名称,也可以配置为修改提供的名称或替换其他名称。服务器应在“域名”字段中为客户端发送其完整FQDN的概念。服务器可以简单地从客户端发送到服务器的客户端FQDN选项复制域名字段。服务器必须使用与客户端在其DHCPDISCOVER或DHCPREQUEST中的客户端FQDN选项中使用的相同编码格式(ASCII或DNS二进制编码),并且必须相应地在选项的Flags字段中设置“E”位。

If a client sends both the Client FQDN and Host Name option, the server SHOULD ignore the Host Name option.

如果客户端同时发送客户端FQDN和主机名选项,则服务器应忽略主机名选项。

The server SHOULD set the RCODE1 and RCODE2 fields to 255 before sending the Client FQDN message to the client in a DHCPOFFER or DHCPACK.

在DHCPOFFER或DHCPACK中将客户端FQDN消息发送给客户端之前,服务器应将RCODE1和RCODE2字段设置为255。

4.1. When to Perform DNS Updates
4.1. 何时执行DNS更新

The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in the Flags field of the Client FQDN option in the DHCPACK messages (to be) sent to the client. However, the server SHOULD delete any RRs that it previously added via DNS updates for the client.

如果发送到客户端的DHCPACK消息(待发送)中客户端FQDN选项的标志字段中的“N”位为1,则服务器不应执行任何DNS更新。但是,服务器应该删除以前通过DNS更新为客户端添加的所有RRs。

The server MAY perform the PTR RR DNS update (unless the "N" bit is 1).

服务器可以执行PTR RR DNS更新(除非“N”位为1)。

The server MAY perform the A RR DNS update if the "S" bit is 1 in the Flags field of the Client FQDN option in the DHCPACK message (to be) sent to the client.

如果发送给客户端的DHCPACK消息(待发送)中客户端FQDN选项的标志字段中的“S”位为1,则服务器可以执行RR DNS更新。

The server MAY perform these updates even if the client's DHCPREQUEST did not carry the Client FQDN option. The server MUST NOT initiate DNS updates when responding to DHCPDISCOVER messages from a client.

即使客户端的DHCPREQUEST未包含客户端FQDN选项,服务器也可能执行这些更新。服务器在响应来自客户端的DHCPDISCOVER消息时不得启动DNS更新。

The server MAY perform its DNS updates (PTR RR or PTR and A RR) before or after sending the DHCPACK message to the client.

服务器可以在向客户端发送DHCPACK消息之前或之后执行其DNS更新(PTR RR或PTR和RR)。

If the server's A RR DNS update does not complete until after the server has replied to the DHCP client, the server's interaction with the DNS server MAY cause the DHCP server to change the domain name that it associates with the client. This can occur, for example, if the server detects and resolves a domain-name conflict [10]. In such cases, the domain name that the server returns to the DHCP client would change between two DHCP exchanges.

如果服务器的RR DNS更新在服务器回复DHCP客户端后才完成,则服务器与DNS服务器的交互可能会导致DHCP服务器更改其与客户端关联的域名。例如,如果服务器检测到并解决域名冲突[10],就会发生这种情况。在这种情况下,服务器返回给DHCP客户端的域名将在两次DHCP交换之间更改。

If the server previously performed DNS updates for the client and the client's information has not changed, the server MAY skip performing additional DNS updates.

如果服务器先前为客户端执行了DNS更新,并且客户端的信息没有更改,则服务器可能会跳过执行其他DNS更新。

When a server detects that a lease on an address that the server leases to a client has expired, the server SHOULD delete any PTR RR that it added via DNS update. In addition, if the server added an A RR on the client's behalf, the server SHOULD also delete the A RR.

当服务器检测到服务器租给客户端的地址上的租约已过期时,服务器应删除通过DNS更新添加的任何PTR RR。此外,如果服务器代表客户端添加了一个A RR,那么服务器还应该删除A RR。

When a server terminates a lease on an address prior to the lease's expiration time (for instance, by sending a DHCPNAK to a client), the server SHOULD delete any PTR RR that it associated with the address via DNS update. In addition, if the server took responsibility for an A RR, the server SHOULD also delete that A RR.

当服务器在租约到期之前终止对某个地址的租约时(例如,通过向客户端发送DHCPNAK),服务器应通过DNS更新删除与该地址关联的任何PTR RR。此外,如果服务器负责一个RR,那么服务器还应该删除该RR。

5. DNS RR TTLs
5. DNS RR TTLs

RRs associated with DHCP clients may be more volatile than statically configured RRs. DHCP clients and servers that perform dynamic updates should attempt to specify resource-record TTLs that reflect this volatility, in order to minimize the possibility that answers to DNS queries will return records that refer to DHCP IP address assignments that have expired or been released.

与DHCP客户端关联的RRs可能比静态配置的RRs更不稳定。执行动态更新的DHCP客户端和服务器应尝试指定反映此波动性的资源记录TTL,以最大限度地减少DNS查询的答案将返回指向已过期或已发布的DHCP IP地址分配的记录的可能性。

The coupling among primary, secondary, and caching DNS servers is 'loose'; that is a fundamental part of the design of the DNS. This looseness makes it impossible to prevent all possible situations in which a resolver may return a record reflecting a DHCP-assigned IP address that has expired or been released. In deployment, this rarely, if ever, represents a significant problem. Most DHCP-managed clients are infrequently looked up by name in the DNS, and the deployment of IXFR ([16]) and NOTIFY ([17]) can reduce the latency between updates and their visibility at secondary servers.

主DNS服务器、辅助DNS服务器和缓存DNS服务器之间的耦合“松散”;这是DNS设计的基本部分。这种松散性使得不可能防止冲突解决程序返回反映DHCP分配的IP地址已过期或已释放的记录的所有可能情况。在部署中,这很少(如果有的话)是一个重大问题。大多数DHCP管理的客户端很少在DNS中按名称查找,部署IXFR([16])和NOTIFY([17])可以减少更新之间的延迟以及它们在辅助服务器上的可见性。

We suggest these basic guidelines for implementers. In general, the TTLs for RRs added as a result of DHCP IP address assignment activity SHOULD be less than the initial lease time. The RR TTL on a DNS record added SHOULD NOT exceed 1/3 of the lease time, but SHOULD NOT be less than 10 minutes. We recognize that individual administrators will have varying requirements: DHCP servers and clients SHOULD allow administrators to configure TTLs and upper and lower bounds on the TTL values, either as an absolute time interval or as a percentage of the lease time.

我们向实施者建议这些基本准则。通常,由于DHCP IP地址分配活动而添加的RRs的TTL应小于初始租用时间。添加的DNS记录上的RR TTL不应超过租用时间的1/3,但不应少于10分钟。我们认识到,各个管理员将有不同的要求:DHCP服务器和客户端应允许管理员配置TTL以及TTL值的上限和下限,无论是作为绝对时间间隔还是作为租赁时间的百分比。

While clients and servers MAY update the TTL of the records as the lease is about to expire, there is no requirement that they do so, as this puts additional load on the DNS system with likely little benefit.

虽然客户机和服务器可能会在租约即将到期时更新记录的TTL,但不要求他们这样做,因为这会给DNS系统带来额外的负载,可能没有什么好处。

6. DNS Update Conflicts
6. DNS更新冲突

This document does not resolve how a DHCP client or server prevents name conflicts. This document addresses only how a DHCP client and server negotiate who will perform the DNS updates and the fully qualified domain name requested or used.

本文档不解决DHCP客户端或服务器如何防止名称冲突。本文档仅说明DHCP客户端和服务器如何协商谁将执行DNS更新以及请求或使用的完全限定域名。

Implementers of this work will need to consider how name conflicts will be prevented. If a DNS updater needs a security token in order to successfully perform DNS updates on a specific name, name conflicts can only occur if multiple updaters are given a security token for that name. Or, if the fully qualified domains are based on

这项工作的实现者需要考虑如何防止名称冲突。如果DNS更新程序需要安全令牌才能成功地对特定名称执行DNS更新,则只有在为多个更新程序提供该名称的安全令牌时,才会发生名称冲突。或者,如果完全限定的域基于

the specific address bound to a client, conflicts will not occur. Or, a name conflict resolution technique as described in "Resolving Name Conflicts" [10] SHOULD be used.

特定地址绑定到客户端,不会发生冲突。或者,应使用“解决名称冲突”[10]中所述的名称冲突解决技术。

7. IANA Considerations
7. IANA考虑

IANA has already assigned DHCP option 81 to the Client FQDN option. As this document describes the option's use, IANA is requested to reference this document for option 81.

IANA已将DHCP选项81分配给客户端FQDN选项。由于本文件描述了选项的使用,请IANA参考本文件了解选项81。

8. Security Considerations
8. 安全考虑

Unauthenticated updates to the DNS can lead to tremendous confusion, through malicious attack or through inadvertent misconfiguration. Administrators need to be wary of permitting unsecured DNS updates to zones that are exposed to the global Internet. Both DHCP clients and servers should use some form of update request origin authentication procedure (e.g., Secure DNS Dynamic Update [14]) when performing DNS updates.

未经验证的DNS更新可能会通过恶意攻击或无意的错误配置导致巨大的混乱。管理员需要警惕允许对暴露于全球互联网的区域进行不安全的DNS更新。在执行DNS更新时,DHCP客户端和服务器都应使用某种形式的更新请求源身份验证过程(例如,安全DNS动态更新[14])。

Whether a DHCP client is responsible for updating an FQDN-to-IP-address mapping or whether this is the responsibility of the DHCP server is a site-local matter. The choice between the two alternatives is likely based on the security model that is used with the DNS update protocol (e.g., only a client may have sufficient credentials to perform updates to the FQDN-to-IP-address mapping for its FQDN).

DHCP客户端是否负责更新FQDN到IP地址的映射,或者这是否是DHCP服务器的责任,这是一个站点本地问题。这两个备选方案之间的选择可能基于DNS更新协议使用的安全模型(例如,只有客户端可能具有足够的凭据来执行其FQDN的FQDN到IP地址映射的更新)。

Whether a DHCP server is always responsible for updating the FQDN-to-IP-address mapping (in addition to updating the IP to FQDN mapping), regardless of the wishes of an individual DHCP client, is also a site-local matter. The choice between the two alternatives is likely based on the security model that is being used with DNS updates. In cases where a DHCP server is performing DNS updates on behalf of a client, the DHCP server should be sure of the DNS name to use for the client, and of the identity of the client.

DHCP服务器是否总是负责更新FQDN到IP地址的映射(除了更新IP到FQDN的映射之外),而不管单个DHCP客户端的意愿如何,这也是站点本地的问题。这两个备选方案之间的选择可能基于DNS更新使用的安全模型。在DHCP服务器代表客户端执行DNS更新的情况下,DHCP服务器应确保客户端使用的DNS名称以及客户端的身份。

Currently, it is difficult for DHCP servers to develop much confidence in the identities of its clients, given the absence of entity authentication from the DHCP protocol itself. There are many ways for a DHCP server to develop a DNS name to use for a client, but only in certain relatively unusual circumstances will the DHCP server know for certain the identity of the client. If DHCP Authentication [15] becomes widely deployed, this may become more customary.

目前,由于DHCP协议本身没有实体身份验证,DHCP服务器很难对其客户端的身份建立信心。DHCP服务器有许多方法来开发用于客户端的DNS名称,但只有在某些相对不寻常的情况下,DHCP服务器才能确定客户端的身份。如果DHCP身份验证[15]得到广泛部署,这可能会变得更为常见。

One example of a situation that offers some extra assurances is when the DHCP client is connected to a network through an Multimedia Cable Network System (MCNS) cable modem, and the cable modem termination

提供一些额外保证的情况的一个示例是,当DHCP客户端通过多媒体电缆网络系统(MCNS)电缆调制解调器和电缆调制解调器终端连接到网络时

system (CMTS), i.e., head-end, ensures that MAC address spoofing simply does not occur. Another example of a configuration that might be trusted is one where clients obtain network access via a network access server using PPP. The NAS itself might be obtaining IP addresses via DHCP, encoding a client identification into the DHCP client-id option. In this case, the network access server as well as the DHCP server might be operating within a trusted environment, in which case the DHCP server could be configured to trust that the user authentication and authorization procedure of the remote access server was sufficient, and would therefore trust the client identification encoded within the DHCP client-id.

系统(CMTS),即前端,确保MAC地址欺骗不会发生。另一个可能受信任的配置示例是客户端通过使用PPP的网络访问服务器获得网络访问的配置。NAS本身可能通过DHCP获取IP地址,将客户端标识编码到DHCP客户端id选项中。在这种情况下,网络访问服务器以及DHCP服务器可能在受信任的环境中运行,在这种情况下,DHCP服务器可以配置为信任远程访问服务器的用户身份验证和授权过程是足够的,因此,将信任DHCP客户端id中编码的客户端标识。

It is critical to implement proper conflict resolution, and the security considerations of conflict resolution apply [10].

实施适当的冲突解决至关重要,冲突解决的安全考虑也适用[10]。

9. Acknowledgements
9. 致谢

Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W. Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Pekka Savola, Jyrki Soini, and Glenn Stump for their review and comments.

非常感谢马克·拜尔、吉姆·邦德、拉尔夫·德罗姆斯、罗伯特·埃尔兹、彼得·福特、奥拉弗尔·古德蒙德松、伊迪·冈特、安德烈亚斯·古斯塔夫松、大卫·W·汉金斯、R·巴尔·希布斯、金·金尼尔、斯图尔特·关、特德·莱蒙、埃德·刘易斯、迈克尔·刘易斯、乔什·利特菲尔德、迈克尔·巴顿、佩卡·萨沃拉、杰尔基·索尼和格伦·斯特普的评论。

10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[2] Mockapetris,P.,“域名-概念和设施”,STD 13,RFC 1034,1987年11月。

[3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[3] Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 10351987年11月。

[4] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.

[4] Vixie,P.,Thomson,S.,Rekhter,Y.,和J.Bound,“域名系统中的动态更新(DNS更新)”,RFC 21361997年4月。

[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[5] Droms,R.,“动态主机配置协议”,RFC 2131,1997年3月。

[6] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.

[6] Harrenstien,K.,Stahl,M.和E.Feinler,“国防部互联网主机表规范”,RFC 952,1985年10月。

[7] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

[7] Braden,R.,“互联网主机的要求-应用和支持”,STD 3,RFC 1123,1989年10月。

[8] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[8] Rekhter,Y.,Moskowitz,R.,Karrenberg,D.,Groot,G.,和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,1996年2月。

[9] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.

[9] Lemon,T.和S.Cheshire,“动态主机配置协议(DHCPv4)中的长选项编码”,RFC 3396,2002年11月。

[10] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients", RFC 4703, October 2006.

[10] Stapp,M.和B.Volz,“解决动态主机配置协议(DHCP)客户端之间的完全限定域名(FQDN)冲突”,RFC 4703,2006年10月。

10.2. Informative References
10.2. 资料性引用

[11] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", FYI 4, RFC 1594, March 1994.

[11] Marine,A.,Reynolds,J.,和G.Malkin,“供参考的问题和答案-常见问题“新互联网用户”问题的答案”,供参考第4期,RFC 1594,1994年3月。

[12] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.

[12] Alexander,S.和R.Droms,“DHCP选项和BOOTP供应商扩展”,RFC 21321997年3月。

[13] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.

[13] Vixie,P.,“DNS的扩展机制(EDNS0)”,RFC26711999年8月。

[14] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.

[14] 威灵顿,B.,“安全域名系统(DNS)动态更新”,RFC 3007,2000年11月。

[15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.

[15] Droms,R.和W.Arbaugh,“DHCP消息的身份验证”,RFC31182001年6月。

[16] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.

[16] Ohta,M.“DNS中的增量区域转移”,RFC 1995,1996年8月。

[17] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.

[17] Vixie,P.,“区域变更即时通知机制(DNS通知)”,RFC 1996,1996年8月。

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

Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA

伯尼·沃兹思科系统公司,美国马萨诸塞州伯斯堡马萨诸塞大道1414号,邮编01719

Phone: 978.936.0382 EMail: volz@cisco.com

电话:978.936.0382电子邮件:volz@cisco.com

Yakov Rekhter Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA

美国加利福尼亚州桑尼维尔市北马蒂尔达大道1194号亚科夫·雷克特·杜松网络公司,邮编94089

Phone: 408.745.2000 EMail: yakov@juniper.net

电话:408.745.2000电子邮件:yakov@juniper.net

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)提供。