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
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.
この文書では、DHCPv4のクライアントの完全修飾ドメイン名について、クライアントのアドレス割り当てに関連するDNSのRRを更新するための責任についての情報を交換するために使用することができ、IPv4の動的ホスト構成プロトコル（DHCPv4の）オプションを説明します。
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
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アドレスの間のマッピングに関する情報を維持します。 AおよびPTR：情報は、リソースレコード（RR）の二種類に維持されます。 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オプションを指定し、アドレスをクライアントの完全修飾ドメイン名に関する情報を交換し、関連するA RRとPTR RRとDNSを更新する責任を負っている人には、DHCPクライアントとサーバで使用することができ、クライアントFQDNオプション、 。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
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クライアントが新しいアドレスを取得すると、サイトの管理者が取得したアドレスのための1つまたはクライアントのFQDNのためのA RRとPTR RRの両方を更新することを望むかもしれません。したがって、2つの別々のDNS更新のトランザクションが発生する可能性があります。 DHCPクライアントとDHCPサーバー：DHCP経由でアドレスを取得するには2つのエンティティが含まれます。原則として、これらの各エンティティはどれも、1、またはトランザクションの両方を行うことができませんでした。しかし、実際には、すべての順列は意味を成しません。 DHCPクライアントFQDNオプションは、主に以下の2つの場合に動作することが意図されています。
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.
これら2例の唯一の違いは、FQDNとIPアドレスのマッピングは、DHCPクライアントまたはDHCPサーバーによって更新されているかどうかです。 IPアドレスツーFQDNマッピングはどちらの場合も、DHCPサーバーによって更新されます。
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 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.
他の人がそうしている間、これら二つは、重要な理由は、それぞれのDNSドメイン名に対する権限に関係しています。 DHCPクライアントは、独自のA RRをマッピングする上で権限を与えられてもよいし、その権威は任意のアドレスをリストアップしたり、任意のドメイン名とそのアドレスを関連付けることからクライアントを防ぐために、サーバーに制限することができます。すべての場合において、アドレスに関連付けられたPTR RRを超える権威のための唯一の合理的な場所は、アドレスを割り当て、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.
これは、ゾーンにDNSアップデートを実行するためにDHCPクライアントとサーバを許可するローカルポリシーと考えられています。このドキュメントは、特定の管理ポリシーを必要とせず、1を提案していません。さらに、この仕様は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サーバを行うことができますかどうかを決定します。
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を伝えるためにできるようにするには、この文書では、「クライアントのFQDN」と呼ばれる新しいDHCPオプションを定義します。クライアントFQDNオプションは、DHCPサーバがクライアントにDNSの更新に関する情報を伝えるために使用することができますフラグ、および2つの非推奨RCODEsが含まれています。
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.
それは複数のオプションとしてメッセージでインスタンス化することができるものの、1つのクライアントのみ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 | | | | ...
+------+------+------+------+------+------+--
The above figure follows the conventions of [12].
上記の図は、[12]の規則に従います。
The format of the 1-octet Flags field is:
1オクテットのFlagsフィールドの形式は次のとおりです。
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更新を実行すべきでないかどうかを示します。クライアントが更新を実行する必要があるサーバーを示すために、更新を実行するべきではありませんサーバーと1を示すために、ビットを0に設定します。サーバからの応答内のビットの状態はサーバがとるべきアクションを示します。 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」ビットのクライアントの好みをオーバーライドしているかどうかを示します。クライアントは、クライアントへの返信に「S」ビットがクライアントから受信した「S」ビットが一致しない場合は、サーバーがこのビットを1に設定しなければならない0にこのビットを設定しなければなりません。
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アップデートを実行するべきではありませんかどうかを示します。クライアントは、サーバがアップデート（PTR RRおよび「S」ビットに基づいて、おそらくA RR）またはサーバがDNS更新を実行しないことを要求する1を実行すべきことを要求するために、このビットを0に設定します。サーバは、サーバが（0）または（1）DNS更新を行うものとないものかどうかを示すために「N」ビットをセットします。 「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]、セクション3.1で説明したように、圧縮することなく、正規のワイヤフォーマットを示しています。このエンコーディングは、クライアントが使用する必要があり、サーバでサポートしなければなりません。 0（2.3.1項を参照してください）現在では非推奨ASCIIエンコーディングを示します。サーバは、同じ符号を使用しなければなりません
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ビットをクリアしなければならない、と彼らはこれらのビットを無視しなければなりません。
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.
2 1オクテット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.
これらのフィールドで、このオプションが広いすでに使用されているとおり、フィールドが保持されます。これらのフィールドは、もともとそれが行われた、または255の値は、その更新を示すために使用された任意のA（RCODE1）またはPTR（RCODE2）RRのDNSアップデートからDHCPクライアント応答コードに示すために、DHCPサーバが使用するために定義されていました開始されていましたが、まだ完了していませんでした。これらの各フィールドは1つのオクテットの長さです。これらのフィールドは、それらを廃止する別の理由がある、12ビットのDNS RCODEの長さを拡張するためのメカニズムについて説明EDNS0 [13]、前に定義しました。
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に最新の状態にあることが判明していない場合は、権限サーバは、更新やゾーン転送を完了していない可能性があります、またはキャッシュリゾルバは、まだそれらのキャッシュを更新している可能性があります。
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で指定されるようにDomain Nameフィールドのデータが正規ワイヤ形式に表示されます。 DHCPクライアントは、標準的なワイヤフォーマットを使用している場合、それはFQDNは、メッセージ交換の間で変化しているかどうかを判断するためには1にフラグ欄に「E」ビットを設定しなければなりません、クライアントとサーバーは、ドメイン名のフィールドの内容を変更してはなりません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.
それは名前を提供するために、サーバーを希望する場合、クライアントはまた、空のドメイン名フィールドを離れることができます。
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エンコーディングを許可され、この仕様の以前のドラフトを実装しました。サーバ実装は0に設定された「E」ビットを持つクライアントFQDNオプションを送信するクライアントは、ドメイン名フィールドのASCIIエンコーディングを使用していることに注意してください。サーバは、クライアントにドメイン名フィールドのASCIIでエンコードされたバージョンを返すように調製することができます。 「E」ビットは、このオプションではASCIIエンコーディングの使用は非推奨と見なされるべきである0の場合、ASCIIでエンコードされたバージョンを返すように準備されていないサーバーは、クライアントFQDNオプションを無視しなければなりません。
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.
[7]、セクション2.1で変更されるクライアントとサーバは、[6]、第4のセクション（「前提条件」）、第5の文の文字セットの規則に従うべきです。しかし、実装者はまた、いくつかのクライアントソフトウェアが他の文字セットであることを意図したデータを送信することを認識する必要があります。この仕様は、他の文字セットのサポートを必要としません。
The following describes the behavior of a DHCP client that implements the Client FQDN option.
以下は、クライアントFQDNオプションを実装DHCPクライアントの動作を説明します。
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 prefer Client FQDN option data. Section 4 instructs servers to ignore the Host Name option in client messages that include the Client FQDN option.
その他のDHCPオプションは、クライアントFQDNオプションのドメイン名フィールドに関連したデータを搬送することができます。ホスト名オプション[12]は、例えば、クライアントのホスト名のASCII文字列表現が含まれています。一般的には、クライアントは、冗長データを送信する必要がないため、そのメッセージにクライアントFQDNオプションを送信するクライアントは、ホスト名オプションを送ってはいけません。ホスト名オプションおよびサーバーからクライアントFQDNオプションの両方を受信するクライアントは、クライアントFQDNオプションデータを好むべきです。第4節では、クライアントFQDNオプションを含めるクライアントのメッセージにホスト名オプションを無視するようにサーバーに指示します。
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とアドレス（複数可）のためのFQDNとIPアドレスのマッピングを更新するための責任になりたい維持した場合、クライアントは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メッセージを受信して、成功したメッセージで渡されたパラメータの最終チェックを完了した）サーバは持っていない限り、クライアントが（クライアントのFQDNに関連付けられている）A RRのアップデートを生じ得ます「S」は1である場合は1に、「S」ビットを設定し、DHCPクライアントがサーバーの返却クライアントFQDNオプションドメイン名]フィールドに名前のための更新を開始すべきではありません。サーバの返された名前は、クライアントの構成名と一致する場合は、明示的にFQDNで構成されているDHCPクライアントは「S」ビットの状態を無視するかもしれません。
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でなければなりません。
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 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.
クライアントのDHCP構成が（クライアントがDHCPACKメッセージを受信して、成功したメッセージで渡されたパラメータの最終チェックを完了）完了すると、クライアントは生じ得るそのDNSの更新は、サーバーの「N」ビットを提供し、サーバーの「場合1です。 N」ビットが0である、PTR RRアップデートを実行するかもしれサーバー。 「S」ビットが1であれば、それはまた、A RRアップデートを実行してもよいです。
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メッセージに異なるドメイン名のデータを返した場合、クライアントは自身の最終的なA RRアップデートを実行中、またはそれはそのDHCPREQUESTメッセージで送信するクライアントFQDNオプションを形成する際にそのデータを使用することができます。クライアントがDHCPDISCOVERとDHCPREQUESTメッセージで、同一のクライアントFQDNオプションデータを送信する必要はありません。クライアントがサーバーへのクライアントFQDNオプション、およびクライアントの設定が変更を送信した場合、それが通信する際に、特に、そのドメイン名の変更のその概念は、それがクライアントFQDNオプションに新しい名前のデータを送信できるように、サーバーを再び。これは、DHCPサーバがそのレコードを削除して、クライアントの現在のドメイン名の更新を試行すると、サーバーがクライアントを代表するAレコードを更新した場合、PTRレコードに関連付けられた名前を更新し、することがあります。
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アドレスのマッピングを更新するための責任。クライアントは、（2.2節を参照）のマッピングが最新であるかどうかを確認するためにDNSクエリを使用するかもしれません。
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を削除しようとすべきです。 （それはそのDHCP IPアドレスの使用を失ったために）、それは追加のA RRを削除することができなかったDHCPクライアントは、おそらくログメッセージを発することで、その管理者に通知することを試みるべきです。
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].
クライアントのアドレスがプライベートアドレス[8]である場合のRRにDNSの更新を行いたいクライアントは、そうすべきではありません。
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.
クライアントの「E」ビットが0で、サーバはASCIIエンコーディング（2.3.1項）をサポートしていない場合は、O、サーバーは、クライアント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.
0へのサーバー・セット「S」、「O」、およびオプションのコピーで「N」ビットoをそれがクライアントに戻ります。サーバーコピークライアントの「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.
クライアントの「N」ビットが1で、サーバの設定は、それが無いサーバが開始DNSの更新のためのクライアントの要求を尊重することを可能にする場合は、O、サーバが1に「N」ビットをセットします。
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.
クライアントの「S」ビットが1であると、サーバーの構成が、それはRRのDNSアップデートを開始するサーバーのクライアントの要求を尊重することを可能にする場合は、サーバーの「S」ビット場合はOそれ以外の場合は、サーバが1に「S」を設定しますクライアントの「S」ビットが一致しない、サーバが1に「O」ビットをセットします。
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バイナリエンコーディング）を使用しなければならない、そしてそれに応じて、オプションのフラグフィールドに「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メッセージを送信する前に255にRCODE1とRCODE2フィールドを設定する必要があります。
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.
「N」ビットがDHCPACKメッセージにおけるクライアントFQDNオプションのフラグ欄に1であれば、サーバーは任意のDNSアップデートを実行するべきではありませんクライアントに送信される（べき）。ただし、サーバーは、クライアントのためにDNSアップデートを経由して、それが以前に追加された任意のRRを削除する必要があります。
The server MAY perform the PTR RR DNS update (unless the "N" bit is 1).
（「N」ビットが1である場合を除く）サーバはPTR RR DNSアップデートを実行することができます。
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.
「S」ビットがDHCPACKメッセージ内のクライアントFQDNオプションのフラグ欄に1であれば、サーバがA 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.
サーバは、サーバがDHCPクライアントに答えた後まで完了しないRRのDNSアップデートだ場合は、DNSサーバとサーバの相互作用は、DHCPサーバがクライアントに関連付けられているドメイン名を変更することがあります。サーバは、ドメイン名の競合[10]を検出して解決する場合、これは、例えば、起こり得ます。このような場合には、サーバはDHCPクライアントに返すことのドメイン名は、2台の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を削除する必要があります。サーバがA RRの責任を取った場合また、サーバーは、そのRRを削除する必要があります。
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クライアントに関連したRRは静的に設定されたRRよりも揮発性であってもよいです。動的更新を実行するDHCPクライアントとサーバは、DNSクエリに対する回答の期限が切れているか、解放され、DHCP IPアドレスの割り当てを参照して、レコードを返すこと可能性を最小限に抑えるために、この変動性を反映して、リソース・レコードのTTLを指定しようとすべきです。
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の設計の基本的な部分です。この緩みは不可能リゾルバの有効期限が切れているか解放され、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アドレス割り当て活性の結果として追加のRRのための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システムに追加の負荷をかけるように、彼らはそうする必要は、ありません。
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 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.
この作品の実装者は、名前の衝突を防止する方法を検討する必要があります。 DNSアップデータが正常に特定の名前の上にDNS更新を実行するために、セキュリティトークンを必要とする場合、複数のアップデータは、その名のセキュリティ・トークンを与えられている場合は、名前の衝突にのみ発生する可能性があります。完全修飾ドメインがクライアントにバインドされた特定のアドレスに基づいている場合や、競合は発生しません。または、名前競合解決技法「名前解決の競合」に記載されているように[10]使用されるべきです。
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はすでにクライアントFQDNオプションにDHCPオプション81を割り当てています。この文書は、オプションの使用について説明したよう、IANAは、オプション81のために、このドキュメントを参照するように要求されています。
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を更新に加えて）FQDNとIPアドレスのマッピングを更新する責任があるかどうかにかかわらず、個々の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プロトコル自体からエンティティ認証の不在与えられ、そのクライアントのアイデンティティで自信を開発するために、現在、それは困難です。そこクライアントに使用するDNS名を開発するためにDHCPサーバのための多くの方法があるが、唯一の特定の比較的珍しい状況で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 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.
DHCPクライアントは、マルチメディアケーブルネットワークシステム（MCNS）ケーブルモデムを介してネットワークに接続されている場合、いくつかの余分な保証を提供しています状況の一例であり、ケーブルモデム終端システム（CMTS）、すなわち、ヘッドエンドは、ことを保証しますMACアドレスのスプーフィングは、単に発生しません。信頼されるかもしれない他の構成例は、クライアントがPPPを使用してネットワークアクセスサーバを介してネットワークへのアクセスを得るものです。 NAS自体は、DHCPクライアント-idオプションにクライアント識別をコードする、DHCP経由でIPアドレスを取得することがあります。この場合には、ネットワーク・アクセス・サーバだけでなく、DHCPサーバがDHCPサーバは、リモートアクセスサーバーのユーザー認証と承認手続きが十分であったことを信頼するように設定することができた場合には、信頼できる環境内で動作するかもしれない、と希望そのためのDHCPクライアントID内にコードクライアント識別を信頼しています。
It is critical to implement proper conflict resolution, and the security considerations of conflict resolution apply [10].
適切な紛争解決を実装するために重要であり、そして紛争解決のセキュリティの考慮事項は、[10]を適用します。
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.
バウンドマーク・ベイヤー、ジム、ラルフDroms、ロバート・エルツ、ピーター・フォード、オラフルグドムンソン、イーディギュンター、アンドレアス・グスタフソン、デビッドW. Hankinsさん、R.バールヒッブス、キム・キニア、スチュアート・クワン、テッド・レモン、エド・ルイス、マイケルに感謝彼らのレビューとコメントのためのルイス、ジョッシュリトルフィールド、マイケル・パットン、ペッカSavola、ユルキSoini、グレン・スタンプ。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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 1035、1987年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] RFC 2136 "ドメインネームシステム（DNS更新）における動的更新" いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、4月1997。
[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.、スタール、M.、およびE. Feinler、 "DoDのインターネットホストテーブル仕様"、RFC 952、1985年10月。
[7] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[7]ブレーデン、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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]レモン、T.とS.チェシャー、 "動的ホスト構成プロトコル（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.
、RFC 4703、2006年10月[10]スタップ、M.とB.フォルツ、 "動的ホスト構成プロトコル（DHCP）クライアントの間で完全修飾ドメイン名（FQDN）紛争の解決"。
[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.
"FYI質問と回答について - 回答よく寄せられるために "[11]マリン、A.、レイノルズ、J.、およびG.マルキン、新しいインターネットユーザー" 質問"、FYI 4、RFC 1594、1994年3月。
[12] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[12]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年3月。
[13] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[13]いるVixie、P.、 "DNS用拡張メカニズム（EDNS0）"、RFC 2671、1999年8月。
[14] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[14]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[15] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[16] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[16]太田、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.、RFC 1996、1996年8月 "ゾーンの変更（DNSがNOTIFY）のプロンプト通知のメカニズム"。
Authors' Addresses
著者のアドレス
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
マーク・スタップシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
Phone: 978.936.1535 EMail: mjs@cisco.com
電話：978.936.1535 Eメール：mjs@cisco.com
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
バーニーフォルツシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
Phone: 978.936.0382 EMail: volz@cisco.com
電話：978.936.0382 Eメール：volz@cisco.com
Yakov Rekhter Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
ヤコフ・レックタージュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089 USA
Phone: 408.745.2000 EMail: yakov@juniper.net
電話：408.745.2000 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。