Network Working Group M. Stapp
Request for Comments: 4703 B. Volz
Category: Standards Track Cisco Systems, Inc.
October 2006
Resolution of Fully Qualified Domain Name (FQDN) Conflicts
among Dynamic Host Configuration Protocol (DHCP) Clients
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
抽象
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts.
DHCP（Dynamic Host Configuration Protocol）は、IPアドレスの動的な割り当てと完全修飾ドメイン名を含むホスト構成のためのメカニズムを提供します。 DNSで正確な名前とIPアドレスとIPアドレスと名前のマッピングを維持するために、これらの動的に割り当てられたアドレスと完全修飾ドメイン名（FQDN）がDNSに更新が必要です。この文書では、完全修飾ドメイン名の使用で競合がDHCPクライアントとサーバの間で発生する可能性がある状況を識別し、それは、これらの競合を解決するためのDHCID DNSリソースレコード（RR）を使用するための戦略を説明します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Issues with DNS Update in DHCP Environments .....................4
3.1. Client Misconfiguration ....................................4
3.2. Multiple DHCP Servers ......................................5
4. Use of the DHCID RR .............................................5
5. Procedures for Performing DNS Updates ...........................6
5.1. Error Return Codes .........................................6
5.2. Dual IPv4/IPv6 Client Considerations .......................6
5.3. Adding A and/or AAAA RRs to DNS ............................7
5.3.1. Initial DHCID RR Request ............................7
5.3.2. DNS UPDATE When FQDN in Use .........................7
5.3.3. FQDN in Use by Another Client .......................8
5.4. Adding PTR RR Entries to DNS ...............................8
5.5. Removing Entries from DNS ..................................9
5.6. Updating Other RRs ........................................10
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................11
"The Client FQDN Option" [8] includes a description of the operation of [4] clients and servers that use the DHCPv4 client FQDN option. "The DHCPv6 Client FQDN Option" [9] includes a description of the operation of [5] clients and servers that use the DHCPv6 client FQDN option. Through the use of the client FQDN option, DHCP clients and servers can negotiate the client's FQDN and the allocation of responsibility for updating the DHCP client's A and/or AAAA RRs. This document identifies situations in which conflicts in the use of FQDNs may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record [2] in resolving those conflicts.
「クライアントFQDNオプション」[8]のDHCPv4クライアントFQDNオプションを使用する[4]クライアントとサーバの動作の説明を含んでいます。 「DHCPv6のクライアントFQDNオプション」[9] DHCPv6クライアントFQDNオプションを使用する[5]クライアントとサーバの動作の説明を含んでいます。クライアントFQDNオプションを使用することにより、DHCPクライアントとサーバは、クライアントのFQDNとDHCPクライアントのAおよび/またはAAAA RRを更新するための責任の割り当てを交渉することができます。これらの競合を解決するには、[2]この文書では、FQDNでの使用で競合がDHCPクライアントとサーバの間で発生する可能性がある状況を識別し、それはDHCID DNSリソースレコードを使用するための戦略を説明します。
In any case, whether a site permits all, some, or no DHCP servers and clients to perform DNS updates ([3], [10]) into the zones that it controls is entirely a matter of local administrative policy. This document does not require any specific administrative policy, and does not propose one. The range of possible policies is very broad, from sites where only the DHCP servers have been given credentials that the DNS servers will accept, to sites where each individual DHCP client has been configured with credentials that allow the client to modify its own FQDN. Compliant implementations MAY support some or all of these possibilities. Furthermore, this specification applies only to DHCP client and server processes; it does not apply to other processes that initiate DNS updates.
いずれにしても、サイトはそれが制御するゾーンにすべて、いくつか、または全くDHCPサーバおよびクライアントのDNS更新を実行する（[3]、[10]）を許可するかどうかは、完全にローカル管理ポリシーの問題です。このドキュメントは、特定の管理ポリシーを必要とせず、1を提案していません。可能な政策の範囲が唯一のDHCPサーバは、DNSサーバが受け入れる資格情報を与えられているサイトから、個々のDHCPクライアントは、クライアントが独自のFQDNを変更できるようにする資格情報を使用して構成されているサイトに、非常に広いです。標準に準拠した実装は、これらの可能性の一部またはすべてをサポートするかもしれません。さらに、この仕様はDHCPクライアントとサーバプロセスに適用されます。それはDNSの更新を開始し、他のプロセスには適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
This document assumes familiarity with DNS terminology defined in [6] and DHCP terminology defined in [4] and [5].
この文書では、[6]、で定義されたDHCPの用語で定義されたDNSの用語に精通している前提とし[4]、[5]。
FQDN, or Fully Qualified Domain Name, is the full name of a system, rather than just its hostname. For example, "venera" is a hostname, and "venera.isi.edu" is an FQDN. See [7].
FQDN、または完全修飾ドメイン名は、完全なシステムの名前だけではなく、そのホスト名です。たとえば、「ベネラは」ホスト名で、「venera.isi.eduは」FQDNです。 [7]を参照してください。
DOCSIS, or Data-Over-Cable Service Interface Specifications, is defined by CableLabs.
DOCSIS、またはデータオーバーケーブルサービスインターフェース仕様は、CableLabsので定義されています。
There are two DNS update situations that require special consideration in DHCP environments: cases where more than one DHCP client has been configured with the same FQDN, and cases where more than one DHCP server has been given authority to perform DNS updates in a zone. In these cases, it is possible for DNS records to be modified in inconsistent ways unless the updaters have a mechanism that allows them to detect anomalous situations. If DNS updaters can detect these situations, site administrators can configure the updaters' behavior so that the site's policies can be enforced. This specification describes a mechanism designed to allow updaters to detect these situations and suggests that DHCP implementations use this mechanism by default.
複数のDHCPクライアントが同じFQDNで構成されている場合、および複数のDHCPサーバがゾーンでDNS更新を実行する権限を与えられている例：DHCP環境で特別な配慮を必要とする2つのDNSの更新状況があります。 DNSレコードは、一貫性のない方法で変更されるのアップデータは、それらが異常な状況を検出することを可能にするメカニズムを持っていない限り、これらの例では、それが可能です。 DNSアップデータは、このような状況を検出することができた場合は、サイトのポリシーを施行することができるように、サイト管理者はアップデータの行動を設定することができます。この仕様は、アップデータは、これらの状況を検出することを可能にするために設計されたメカニズムを説明し、DHCPの実装は、デフォルトでこのメカニズムを使用することを示唆しています。
Administrators may wish to maintain a one-to-one relationship between active DHCP clients and FQDNs, and to maintain consistency between a client's A, AAAA, and PTR RRs. Clients that are not represented in the DNS, or clients that inadvertently share an FQDN with another client may encounter inconsistent behavior or may not be able to obtain access to network resources. Whether each DHCP client is configured with an FQDN by its administrator or whether the DHCP server is configured to distribute the clients' FQDN, the consistency of the DNS data is entirely dependent on the accuracy of the configuration procedure. Sites that deploy [10] may configure credentials for each client and its assigned FQDN in a way that is more error-resistant, as both the FQDN and credentials must match.
管理者は、アクティブなDHCPクライアントとFQDNの間に1対1の関係を維持するために、クライアントのA、AAAA、およびPTR RRの間の一貫性を維持することを望むかもしれません。うっかり別のクライアントにFQDNを共有するDNSで表現されていないクライアント、またはクライアントが一貫性のない動作が発生する可能性がありますか、ネットワークリソースへのアクセスを取得することができない場合があります。各DHCPクライアントは、その管理者またはDHCPサーバがクライアントのFQDNを分配するように構成されているかどうかをFQDNで構成されているかどうか、DNSデータの一貫性は、設定手順の精度に完全に依存しています。 FQDNと資格情報の両方が一致しなければならないように展開部位[10]は、より誤り耐性があるように、各クライアントとその割り当てられたFQDNの資格情報を構成することができます。
Consider an example in which two DHCP clients in the "example.com" network are both configured with the hostname "foo". The clients are permitted to perform their own DNS updates. The first client, client A, is configured via DHCP. It adds an A RR to "foo.example.com", and its DHCP server adds a PTR RR corresponding to its assigned IP address. When the second client, client B, boots, it is also configured via DHCP, and it also begins to update "foo.example.com".
「example.com」ネットワーク内の2つのDHCPクライアントが両方のホスト名「foo」というで構成されている例を考えてみましょう。クライアントは、独自のDNS更新を実行することが許可されています。最初のクライアント、クライアントAは、DHCPを介して設定されます。それは「foo.example.com」にA RRを追加し、そのDHCPサーバは、割り当てられたIPアドレスに対応するPTR RRを追加します。また、第2のクライアントは、クライアントB、ブーツは、それはまた、DHCPを介して設定され、そしてそれはまた、「foo.example.com」を更新することから始まります。
At this point, the "example.com" administrators may wish to establish some policy about DHCP clients' FQDNs. If the policy is that each client that boots should replace any existing A RR that matches its FQDN, Client B can proceed, though Client A may encounter problems. In this example, Client B replaces the A RR associated with "foo.example.com". Client A must have some way to recognize that the RR associated with "foo.example.com" now contains information for Client B, so that it can avoid modifying the RR. When Client A's assigned IP address expires, for example, it should not remove an RR that reflects Client B's DHCP-assigned IP address.
この時点で、「example.com」の管理者は、DHCPクライアントのFQDNのに関するいくつかのポリシーを確立することを望むかもしれません。ポリシーは、ブーツはそのFQDNと一致する既存のRRを交換する必要があり、各クライアントは、クライアントBが進行できるということであれば、クライアントAは、問題が発生するかもしれません。この例では、クライアントBは、「foo.example.com」に関連付けられたA RRを置き換えます。クライアントAは、RRを修正することを避けることができるように、「foo.example.com」に関連したRRは現在、クライアントBのための情報が含まれていることを認識するためのいくつかの方法を持っている必要があります。クライアントAの割り当てられたIPアドレスの有効期限が切れると、例えば、それは、クライアントBのDHCPによって割り当てられたIPアドレスを反映したRRを削除するべきではありません。
If the policy is that the first DHCP client with a given FQDN should be the only client associated with that FQDN, Client B needs to be able to determine if it is not the client associated with "foo.example.com". It could be that Client A booted first, and that Client B should choose another FQDN. Or it could be that B has booted on a new subnet and received a new IP address assignment, in which case B should update the DNS with its new IP address. It must either retain persistent state about the last IP address it was assigned (in addition to its current IP address) or it must have some other way to detect that it was the last updater of "foo.example.com" in order to implement the site's policy.
ポリシーは特定のFQDNを持つ最初のDHCPクライアントがそのFQDNに関連付けられている唯一のクライアントであるべきということであれば、クライアントBは、それが「foo.example.com」に関連したクライアントではないかどうかを判断できるようにする必要があります。これは、クライアントAが最初に起動している可能性があり、かつそのクライアントBは、別のFQDNを選択する必要があります。それともBが新しいサブネット上で起動し、ケースBは、新しいIPアドレスとDNSを更新するべき新しいIPアドレスの割り当てを、受信したことが考えられます。それはそれは（現在のIPアドレスに加えて）割り当てられていた最後のIPアドレスに関する永続的な状態を保持しなければならないのいずれか、またはそれが実現するためには、それは「foo.example.com」の最後の更新者だったことを検出するためにいくつかの他の方法を持っている必要がありますサイトのポリシー。
It is possible to arrange for DHCP servers to perform A and/or AAAA RR updates on behalf of their clients. If a single DHCP server manages all of the DHCP clients at a site, it can maintain a database of the FQDNs in use and can check that database before assigning an FQDN to a client. Such a database is necessarily proprietary, however, and the approach does not work once more than one DHCP server is deployed.
彼らのクライアントに代わってAおよび/またはAAAA RRアップデートを実行するためにDHCPサーバを手配することが可能です。単一のDHCPサーバがサイトでDHCPクライアントのすべてを管理している場合、それは、使用中のFQDNのデータベースを維持することができ、クライアントにFQDNを割り当てる前に、そのデータベースを確認することができます。このようなデータベースは、しかし、必ずしも独自のものです、そしてアプローチは、複数のDHCPサーバーが展開され、一度は動作しません。
When multiple DHCP servers are deployed, the servers require a way to coordinate the identities of DHCP clients. Consider an example in which DHCPv4 Client A boots, obtains an IP address from Server S1, presenting the hostname "foo" in a Client FQDN option [8] in its DHCPREQUEST message. Server S1 updates the FQDN "foo.example.com", adding an A RR containing the IP address assigned to A. The client then moves to another subnet, served by Server S2. When Client A boots on the new subnet, Server S2 will assign it a new IP address and will attempt to add an A RR containing the newly assigned IP address to the FQDN "foo.example.com". At this point, without some communication mechanism that S2 can use to ask S1 (and every other DHCP server that updates the zone) about the client, S2 has no way to know whether Client A is currently associated with the FQDN, or whether A is a different client configured with the same FQDN. If the servers cannot distinguish between these situations, they cannot enforce the site's naming policies.
複数のDHCPサーバが展開されている場合、サーバーは、DHCPクライアントのアイデンティティを調整する方法が必要です。 DHCPv4のクライアントAのブーツは、そのDHCPREQUESTメッセージでクライアントFQDNオプション[8]でホスト名「foo」を提示し、サーバS1からIPアドレスを取得している例を考えてみましょう。サーバS1は、クライアントがサーバーS2によって提供される別のサブネットに移動A.に割り当てられたIPアドレスを含むA RRを追加し、「foo.example.com」FQDNを更新します。クライアントAのブーツは、新しいサブネット上で、サーバーS2はそれを新しいIPアドレスを割り当てますし、FQDN「foo.example.com」に新たに割り当てられたIPアドレスを含むA RRを追加しようとしたとき。この時点で、S2はS1（およびゾーンの更新を他のすべてのDHCPサーバ）クライアントについて尋ねるために使用できるいくつかの通信メカニズムせず、S2は、クライアントAが現在FQDNに関連付けられているかどうかを知る方法がない、またはAであるかどうか同じFQDNで構成された別のクライアント。サーバは、これらの状況を区別することができない場合は、サイトの名前付けポリシーを強制することはできません。
A solution to both of these problems is for the updater (a DHCP client or DHCP server) to be able to determine which DHCP client has been associated with an FQDN, in order to offer administrators the opportunity to configure updater behavior.
これらの問題の両方を解決するには、アップデータ（DHCPクライアントまたはDHCPサーバ）がDHCPクライアントは、管理者はアップデータの動作を設定する機会を提供するために、FQDNに関連付けられているかを判断できるようにするためです。
For this purpose, a DHCID RR, specified in [2], is used to associate client identification information with an FQDN and the A, AAAA, and PTR RRs associated with that FQDN. When either a client or server adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that specifies a unique client identity, based on data from the client's DHCP message. In this model, only one client is associated with a given FQDN at a time.
この目的のため、[2]で指定DHCID RRは、そのFQDNに関連付けられたFQDN及びA、AAAA、およびPTRのRRとクライアント識別情報を関連付けるために使用されます。クライアントまたはサーバのどちらかがクライアントのために、AAAA、またはPTR RRを追加すると、それはまた、クライアントのDHCPメッセージからのデータをもとに、独自のクライアントIDを指定するDHCID RRを追加します。このモデルでは、1つのクライアントのみが一度に与えられたFQDNに関連付けられています。
By associating this ownership information with each FQDN, cooperating DNS updaters may determine whether their client is currently associated with a particular FQDN and implement the appropriately configured administrative policy. In addition, DHCP clients that currently have FQDNs may move from one DHCP server to another without losing their FQDNs.
各FQDNこの所有者情報を関連付けることにより、DNSアップデータを協働して、クライアントが現在特定のFQDNに関連付けられているかどうかを判断し、適切に構成された管理ポリシーを実装することができます。また、現在のFQDNを持つDHCPクライアントは、FQDNのを失うことなく別のDHCPサーバから移動してもよいです。
The specific algorithm utilizing the DHCID RR to signal client ownership is explained below. The algorithm only works in the case where the updating entities all cooperate -- this approach is advisory only and is not a substitute for DNS security, nor is it replaced by DNS security.
クライアントの所有権を知らせるためにDHCID RRを利用し、特定のアルゴリズムを以下に説明します。このアプローチはあくまで参考で、DNSのセキュリティに代わるものではありません、またそれは、DNSセキュリティによって置き換えられる - アルゴリズムは、更新エンティティのすべてが協力した場合に動作します。
Certain RCODEs defined in [3] indicate that the destination DNS server cannot perform an update, i.e., FORMERR, SERVFAIL, REFUSED, NOTIMP. If one of these RCODEs is returned, the updater MUST terminate its update attempt. Other RCODEs [13] may indicate that there are problems with the key being used and may mean to try a different key, if available, or to terminate the operation. Because some errors may indicate a misconfiguration of the updater or the DNS server, the updater MAY attempt to signal to its administrator that an error has occurred, e.g., through a log message.
[3]で定義された特定のRCODEs宛先DNSサーバがアップデートを実行できないことを示し、すなわち、FORMERR、SERVFAILは、NOTIMP、拒否しました。これらRCODEsの1が返された場合、アップデータは、その更新の試みを終えなければなりません。他のRCODEs [13]使用されているキーに問題があることを示してもよいし、利用可能な場合、異なる鍵を試すために、または操作を終了することを意味してもよいです。多少の誤差が更新またはDNSサーバの設定ミスを示すことができるため、アップデータは、ログメッセージを介して、例えば、エラーが発生したことをその管理者に信号を試みることができます。
At the time of publication of this document, a small minority of DHCP clients support both IPv4 and IPv6. We anticipate, however, that a transition will take place over a period of time, and more sites will have dual-stack clients present. IPv6 clients require updates of AAAA RRs; IPv4 client require updates of A RRs. The administrators of mixed deployments will likely wish to permit a single FQDN to contain A and AAAA RRs from the same client.
このドキュメントの公開時点で、DHCPクライアントの少数は、IPv4とIPv6の両方をサポートしています。私たちは、遷移が、時間の期間にわたって行われ、多くのサイトが存在デュアルスタッククライアントを持っていること、しかし、期待しています。 IPv6のクライアントは、AAAAのRRの更新を必要とします。 IPv4のクライアントはRRの更新が必要です。混合展開の管理者は、おそらく同じクライアントからのAとAAAA RRを含むように、単一のFQDNを許可したくなります。
Sites that wish to permit a single FQDN to contain both A and AAAA RRs MUST make use of DHCPv4 clients and servers that support using the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such that this DUID is used in computing the RDATA of the DHCID RR by both DHCPv4 and DHCPv6 for the client; see [11]. Otherwise, a dual-stack client that uses older-style DHCPv4 client identifiers (see [4] and [12]) will only be able to have either its A or AAAA records in DNS under a single FQDN because of the DHCID RR conflicts that result.
AとAAAA RRの両方を含むように、単一のFQDNを許可したいサイトがこのDUIDはDHCIDのRDATAを計算するのに使用されているようなのDHCPv4クライアント識別子のためのDHCP一意識別子（DUID）を使用してサポートするのDHCPv4クライアントとサーバを利用する必要がありますクライアントのDHCPv4とDHCPv6の両方によってRR。 [11]を参照してください。それ以外の場合は、古いスタイルのDHCPv4クライアント識別子を使用してデュアルスタッククライアントは、（参照[4]と[12]）だけのためDHCID RRの競合の単一FQDNの下でDNSのいずれかでそのAまたはAAAAレコードを持つことができるようになりますこと結果。
When a DHCP client or server intends to update A and/or AAAA RRs, it starts with the UPDATE request in Section 5.3.1.
DHCPクライアントまたはサーバがAおよび/またはAAAA RRを更新しようとするときは、5.3.1項でUPDATE要求で始まります。
As the update sequence below can result in loops, implementers SHOULD limit the total number of attempts for a single transaction.
以下更新シーケンスは、ループをもたらすことができるように、実装は、単一のトランザクションの試行の合計数を制限する必要があります。
The updater prepares a DNS UPDATE request that includes as a prerequisite the assertion that the FQDN does not exist. The update section of the request attempts to add the new FQDN and its IP address mapping (A and/or AAAA RRs) and the DHCID RR with its unique client identity.
アップデータは、前提条件としてFQDNが存在しないという主張を含んでいるDNS更新要求を準備します。リクエストの更新部は、そのユニークなクライアントIDを使用して新しいFQDNとIPアドレスのマッピング（Aおよび/またはAAAAのRR）とDHCID RRを追加しようとします。
If the UPDATE request succeeds, the A and/or AAAA RR update is now complete (and a client updater is finished, while a server would then proceed to perform a PTR RR update).
UPDATE要求が成功した場合、Aおよび/またはAAAA RRの更新が完了しました（そしてサーバは、その後のPTR RRアップデートを実行するために進行する一方で、クライアントのアップデータは、終了します）。
If the response to the UPDATE returns YXDOMAIN, the updater can now conclude that the intended FQDN is in use and proceeds to Section 5.3.2.
UPDATEに対する応答がYXDOMAINを返した場合、アップデータは現在、意図FQDNは、セクション5.3.2に使用して進行中であることを結論付けることができます。
If any other status is returned, the updater SHOULD NOT attempt an update (see Section 5.1).
他のステータスが返された場合、アップデータは（セクション5.1を参照）の更新を試みるべきではありません。
The updater next attempts to confirm that the FQDN is not being used by some other client by preparing an UPDATE request in which there are two prerequisites. The first prerequisite is that the FQDN exists. The second is that the desired FQDN has attached to it a DHCID RR whose contents match the client identity. The update section of the UPDATE request contains:
アップデータは、次のFQDNは、2つの前提条件が存在する更新要求を調製することにより、いくつかの他のクライアントによって使用されていないことを確認しようと試みます。最初の前提条件は、FQDNが存在することです。第二は、所望のFQDNがそれに内容がクライアントIDと一致DHCID RRを取り付けたことです。 UPDATE要求の更新セクションが含まれています。
1. A delete of any existing A RRs on the FQDN if this is an A update or an AAAA update and the updater does not desire A records on the FQDN, or if this update is adding an A and the updater only desires a single IP address on the FQDN.
1. Aこれは、更新またはAAAAアップデートで、アップデータがFQDNでレコードを希望しない場合はFQDN上の既存のRRの削除、またはこの更新は、Aを加えていると、アップデータは、単一のIPを希望する場合FQDNに取り組みます。
2. A delete of the existing AAAA RRs on the FQDN if the updater does not desire AAAA records on the FQDN, or if this update is adding an AAAA and the updater only desires a single IP address on the FQDN.
アップデータは、FQDNにAAAAレコードを希望しない場合、またはこの更新はAAAAを追加され、アップデータが唯一のFQDN上の単一のIPアドレスを希望する場合2. A FQDN上の既存のAAAA RRを削除しますの。
3. An add (or adds) of the A RR that matches the DHCP binding if this is an A update.
3.アンこれはアップデートである場合にDHCPバインディングと一致するRRの追加（または追加します）。
4. Adds of the AAAA RRs that match the DHCP bindings if this is an AAAA update.
これはAAAAアップデートである場合、DHCPバインディングと一致するAAAAのRRの4を追加。
Whether A or AAAA RRs are deleted depends on the updater or updater's policy. For example, if the updater is the client or configured as the only DHCP server for the link on which the client is located, the updater may find it beneficial to delete all A and/or AAAA RRs and then add the current set of A and/or AAAA RRs, if any, for the client.
AまたはAAAAのRRが削除されているかどうかはアップデータやアップデータのポリシーに依存します。アップデータは、クライアントであるか、クライアントが配置されているリンクのための唯一のDHCPサーバとして設定された場合、アップデータは、すべてのAおよび/またはAAAA RRを削除することが有益見つけ、その後、Aの現在のセットを追加することができ、 /またはAAAA RRは、もしあれば、クライアントのために。
If the UPDATE request succeeds, the updater can conclude that the current client was the last client associated with the FQDN, and that the FQDN now contains the updated A and/or AAAA RRs. The update is now complete (and a client updater is finished, while a server would then proceed to perform a PTR RR update).
UPDATE要求が成功した場合、アップデータは、現在のクライアントは、FQDNに関連付けられている最後のクライアントで、FQDNは現在更新Aおよび/またはAAAA RRを含んでいることと結論付けることができます。更新が完了しました（そしてサーバは、その後のPTR RRアップデートを実行するために進行する一方で、クライアントのアップデータは、終了します）。
If the response to the UPDATE request returns NXDOMAIN, the FQDN is no longer in use, and the updater proceeds back to Section 5.3.1.
UPDATE要求に対する応答がNXDOMAINを返す場合、FQDNが使用されていません、とアップデータは、セクション5.3.1に戻って進みます。
If the response to the UPDATE request returns NXRRSET, there are two possibilities: there are no DHCID RRs for the FQDN, or the DHCID RR does not match. In either case, the updater proceeds to Section 5.3.3.
UPDATE要求に対する応答がNXRRSETを返した場合、2つの可能性がありますがFQDNのためのDHCID RRはありません、またはDHCID RRは一致していません。いずれの場合も、アップデータは、セクション5.3.3に移行します。
As the FQDN appears to be in use by another client or is not associated with any client, the updater SHOULD either choose another FQDN and restart the update process with this new FQDN or terminate the update with a failure.
FQDNは、別のクライアントで使用されているようですまたは任意のクライアントに関連付けられていない、アップデータは別のFQDNを選択して、この新しいFQDNで更新プロセスを再起動するか、失敗して更新を終了すべきであるのいずれかのよう。
Techniques that may be considered to disambiguate FQDNs include adding some suffix or prefix to the hostname portion of the FQDN or randomly generating a hostname.
FQDNを明確に考慮することができる技術は、FQDNのホスト名部分にいくつかの接尾辞もしくは接頭辞を追加またはランダムホスト名を生成することを含みます。
The DHCP server submits a DNS UPDATE request that deletes all of the PTR RRs associated with the client's assigned IP address and adds a PTR RR whose data is the client's (possibly disambiguated) FQDN. The server MAY also add a DHCID RR as specified in Section 4, in which case it would include a delete of all of the DHCID RRs associated with the client's assigned IP address and would add a DHCID RR for the client.
DHCPサーバは、クライアントの割り当てられたIPアドレスに関連付けられたPTR RRのすべてを削除し、そのデータがクライアントの（おそらく明確化）FQDNでPTR RRを追加するDNS更新要求を送信します。第4節で指定されたサーバーは、その場合には、クライアントの割り当てられたIPアドレスに関連付けられているDHCIDのRRのすべての削除が含まれるであろうし、クライアントのためのDHCID RRを追加し、DHCID RRを追加するかもしれません。
There is no need to validate the DHCID RR for PTR updates as the DHCP server (or servers) only assigns an address to a single client at a time.
DHCPサーバ（またはサーバ）としてPTRの更新のためのDHCID RRを検証する必要が一度に単一のクライアントにアドレスを割り当てるはありません。
The most important consideration in removing DNS entries is to be sure that an entity removing a DNS entry is only removing an entry that it added, or for which an administrator has explicitly assigned it responsibility.
DNSエントリを除去する際に最も重要な考慮事項は、DNSエントリを削除するエンティティが唯一それが追加されたエントリを削除するか、または管理者が明示的に責任を割り当てられているためにことを確認することです。
When an address' lease time or valid lifetime expires or a DHCP client issues a DHCPRELEASE [4] or Release [5] request, the DHCP server SHOULD delete the PTR RR that matches the DHCP binding, if one was successfully added. The server's UPDATE request SHOULD assert that the domain name (PTRDNAME field) in the PTR record matches the FQDN of the client whose address has expired or been released and should delete all RRs for the FQDN.
アドレスリース期間または有効期間が満了するか、DHCPクライアントはDHCPRELEASEを発行すると、[4]または[5]リクエストをリリース、DHCPサーバは、1が正常に追加された場合、DHCPバインディングに一致するPTR RRを削除する必要があります。サーバのUPDATE要求は、PTRレコードのドメイン名（PTRDNAMEフィールド）は、アドレスが有効期限が切れているか、リリースされてとFQDNのためのすべてのRRを削除する必要があり、クライアントのFQDNと一致していることを主張すべきです。
The entity chosen to handle the A or AAAA records for this client (either the client or the server) SHOULD delete the A or AAAA records that were added when the address was assigned to the client. However, the updater should only remove the DHCID RR if there are no A or AAAA RRs remaining for the client.
このクライアント（クライアントまたはサーバーのいずれか）のためのAまたはAAAAレコードを処理するために選ばれたエンティティは、アドレスがクライアントに割り当てられた時に追加されたAまたはAAAAレコードを削除する必要があります。クライアントのために残っていないAまたはAAAAのRRが存在しない場合は、アップデータはDHCID RRを削除する必要があります。
In order to perform this A or AAAA RR delete, the updater prepares an UPDATE request that contains a prerequisite that asserts that the DHCID RR exists whose data is the client identity described in Section 4 and contains an update section that deletes the client's specific A or AAAA RR.
このAを実行するか、またはAAAA RRを削除するために、更新は、データセクション4に記載のクライアントIDとクライアントの特定Aを削除または更新セクションを含んDHCID RRが存在することをアサート前提条件が含まれている更新要求を準備しますAAAAのRR。
If the UPDATE request succeeds, the updater prepares a second UPDATE request that contains three prerequisites and an update section that deletes all RRs for the FQDN. The first prerequisite asserts that the DHCID RR exists whose data is the client identity described in Section 4. The second prerequisite asserts that there are no A RRs. The third prerequisite asserts that there are no AAAA RRs.
UPDATE要求が成功した場合、アップデータは3つの前提条件とFQDNのためのすべてのRRを削除し、更新部分を含む第2の更新要求を準備します。最初の前提条件は、DHCID RRは、そのデータ項4に記載のクライアントIDである第二の前提条件無しA資源レコードが存在しないと主張が存在すると主張しています。第三の前提条件にはAAAA RRをがないことを主張します。
If either request fails, the updater MUST NOT delete the FQDN. It may be that the client whose address has expired has moved to another network and obtained an address from a different server, which has caused the client's A or AAAA RR to be replaced. Or, the DNS data may have been removed or altered by an administrator.
いずれかの要求が失敗した場合、アップデータはFQDNを削除してはなりません。それは、そのアドレスの有効期限が切れたクライアントが別のネットワークに移動し、クライアントのAまたはAAAA RRを交換する原因となった別のサーバーからアドレスを取得している可能性があります。または、DNSデータは、管理者によって削除または変更された可能性があります。
The procedures described in this document only cover updates to the A, AAAA, PTR, and DHCID RRs. Updating other types of RRs is outside the scope of this document.
この文書に記載された手順は、A、AAAA、PTR、およびDHCIDのRRの更新を覆います。 RRの他のタイプを更新すると、この文書の範囲外です。
Administrators should be wary of permitting unsecured DNS updates to zones, whether or not they are exposed to the global Internet. Both DHCP clients and servers SHOULD use some form of update request authentication (e.g., TSIG [13]) when performing DNS updates.
管理者は、彼らがグローバルインターネットに公開されているかどうかにかかわらず、ゾーンにセキュリティ保護されていないDNSの更新を許可するには慎重でなければなりません。 DNS更新を実行するときに、DHCPクライアントとサーバの両方が更新要求の認証（例えば、TSIG [13]）のいくつかのフォームを使用すべきです。
Whether a DHCP client may be 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 may be based on the security model that is used with the Dynamic 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 may be based on the security model that is being used with dynamic 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 FQDN to use for the client, and of the identity of the client.
DHCPサーバは常に（IPとFQDNのマッピングの更新に加えて）FQDNとIPアドレスのマッピングを更新する責任があるかどうかにかかわらず、個々のDHCPクライアントの希望の、また、サイトローカルの問題です。二つの選択肢間の選択は、ダイナミックDNSの更新に使用されているセキュリティモデルに基づくことができます。 DHCPサーバがクライアントに代わってDNSアップデートを実行している場合には、DHCPサーバはFQDNをクライアントに使用するのと、クライアントの身元を確認する必要があります。
Currently, it is difficult for DHCP servers to develop much confidence in the identities of their clients, given the absence of entity authentication from the DHCP protocol itself. There are many ways for a DHCP server to develop an FQDN to use for a client, but only in certain relatively rare circumstances will the DHCP server know for certain the identity of the client. If [14] becomes widely deployed, this may become more customary.
DHCPサーバがDHCPプロトコル自体からエンティティ認証の不在与え、彼らのクライアントのアイデンティティで自信を開発するために、現在、それは困難です。そこクライアントに使用するFQDNを開発するためにDHCPサーバのための多くの方法があるが、唯一の特定の比較的まれな状況でDHCPサーバは、クライアントの特定のアイデンティティのために知っているだろう。 [14]が広く展開になった場合、これは、より慣用なる可能性があります。
One example of a situation that offers some extra assurances is when the DHCP client is connected to a network through a DOCSIS cable modem, and the Cable Modem Termination System (head-end) of the cable modem ensures that MAC address spoofing simply does not occur. Another example of a configuration that might be trusted is when clients obtain network access via a network access server using PPP. The Network Access Server (NAS) itself might be obtaining IP addresses via DHCP, encoding client identification into the DHCP client-id option. In this case, the NAS as well as the DHCP server might be operating within a trusted environment, in which case the
DHCPクライアントは、DOCSISケーブルモデムを介してネットワークに接続されている場合、いくつかの余分な保証を提供しています状況の一例であり、ケーブルモデムのケーブルモデム終端システム（ヘッドエンド）は、MACアドレスのスプーフィングは、単に発生しないことを保証します。クライアントがPPPを使用してネットワークアクセスサーバを介してネットワークへのアクセスを得る際に、信頼されるかもしれない他の構成例です。ネットワークアクセスサーバー（NAS）自体は、DHCPクライアント-idオプションにクライアント識別をコードする、DHCP経由でIPアドレスを取得することがあります。この場合、NASだけでなく、DHCPサーバは、信頼できる環境内で動作する可能性がある場合、
DHCP server could be configured to trust that the user authentication and authorization processing of the NAS was sufficient, and would therefore trust the client identification encoded within the DHCP client-id.
DHCPサーバは、NASのユーザの認証および認可処理が十分であったことを信頼するように設定することができ、そのためのDHCPクライアントID内にエンコードされたクライアント識別を信頼することになります。
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, and Glenn Stump for their review and comments.
バウンドマーク・ベイヤー、ジム、ラルフDroms、ロバート・エルツ、ピーター・フォード、オラフルグドムンソン、イーディギュンター、アンドレアス・グスタフソン、デビッドW. Hankinsさん、R.バールヒッブス、キム・キニア、スチュアート・クワン、テッド・レモン、エド・ルイス、マイケルに感謝彼らのレビューとコメントのためのルイス、ジョッシュリトルフィールド、マイケル・パットン、ペッカSavola、およびグレン切り株。
[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] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR), RFC 4701, October 2006.
[2]スタップ、M.、レモン、T.、およびA.グスタフソン、「DNSリソースレコード（RR）を動的ホスト構成プロトコル（DHCP）の情報（DHCID RR）、RFC 4701、2006年10月を符号化するため。
[3] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[3]は、RFC 2136 "ドメインネームシステム（DNS更新）における動的更新" いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、4月1997。
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[4] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[5] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[6] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[6] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[7] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[7]マルキン、FYI 18 G.、 "インターネットユーザーの用語集"、RFC 1983、1996年8月。
[8] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, October 2006.
[8]スタップ、M.、フォルツ、B.、およびY. Rekhter、 "動的ホスト構成プロトコル（DHCP）クライアント完全修飾ドメイン名（FQDN）オプション"、RFC 4702、2006年10月。
[9] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[9]フォルツ、B.、 "IPv6の動的ホスト構成プロトコル（DHCPv6）クライアント完全修飾ドメイン名（FQDN）オプション"、RFC 4704、2006年10月に。
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[10]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[11] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[11]レモン、T.とB.ゾンマーフェルト、RFC 4361、2006年2月「動的ホスト構成プロトコルバージョン四つ（のDHCPv4）のためのノード固有のクライアント識別子」。
[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., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[13]いるVixie、P.、グドムンソン、O.、イーストレイク、D.、およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[14] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[14] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
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
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）によって提供されます。