RFC4701 日本語訳
4701 A DNS Resource Record (RR) for Encoding Dynamic HostConfiguration Protocol (DHCP) Information (DHCID RR). M. Stapp, T.Lemon, A. Gustafsson. October 2006. (Format: TXT=24570 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Stapp
Request for Comments: 4701 Cisco Systems, Inc.
Category: Standards Track T. Lemon
Nominum, Inc.
A. Gustafsson
Araneus Information Systems Oy
October 2006
コメントを求めるワーキンググループM.スタップ要求をネットワークでつないでください: 4701年のシスコシステムズInc.カテゴリ: 標準化過程T.レモンNominum Inc.A.グスタファソンAraneus情報システムOy2006年10月
A DNS Resource Record (RR) for Encoding
Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
Dynamic Host Configuration Protocol(DHCP)情報をコード化するためのDNSリソース記録(RR)(DHCID RR)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR.
Dynamic Host Configuration Protocol(DHCP)クライアントが、同じDNS Fully Qualified Domain Name(FQDN)をアップデートするか、または彼らがDHCPリースを得るとき別の目的のためにDNSに加えられるDNS FQDNをアップデートするのを試みるのは、可能です。 DHCPサーバかクライアント自身がDNSアップデートを実行するか否かに関係なく、闘争は起こることができます。 そのような闘争を解決するために、RFC4703は、彼らが参照するDHCPクライアントと共に明白にドメイン名を関連づけるためにDNSのクライアント識別子を保存するよう提案します。 このメモはDHCPクライアントとサーバでこのために使用のための異なったResource Record(RR)タイプを定義します: "DHCID"RR。
Stapp, et al. Standards Track [Page 1] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. The DHCID RR ....................................................3
3.1. DHCID RDATA Format .........................................3
3.2. DHCID Presentation Format ..................................4
3.3. The DHCID RR Identifier Type Codes .........................4
3.4. The DHCID RR Digest Type Code ..............................4
3.5. Computation of the RDATA ...................................5
3.5.1. Using the Client's DUID .............................5
3.5.2. Using the Client Identifier Option ..................6
3.5.3. Using the Client's htype and chaddr .................6
3.6. Examples ...................................................6
3.6.1. Example 1 ...........................................6
3.6.2. Example 2 ...........................................7
3.6.3. Example 3 ...........................................7
4. Use of the DHCID RR .............................................8
5. Updater Behavior ................................................8
6. Security Considerations .........................................8
7. IANA Considerations .............................................9
8. Acknowledgements ................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
1. 序論…3 2. 用語…3 3. DHCID RR…3 3.1. DHCID RDATA形式…3 3.2. DHCIDプレゼンテーション形式…4 3.3. DHCID RR識別子タイプコード…4 3.4. DHCID RRはタイプコードを読みこなします…4 3.5. RDATAの計算…5 3.5.1. クライアントのDUIDを使用します…5 3.5.2. クライアント識別子オプションを使用します…6 3.5.3. Clientのhtypeとchaddrを使用します…6 3.6. 例…6 3.6.1. 例1…6 3.6.2. 例2…7 3.6.3. 例3…7 4. DHCID RRの使用…8 5. Updaterの振舞い…8 6. セキュリティ問題…8 7. IANA問題…9 8. 承認…9 9. 参照…9 9.1. 標準の参照…9 9.2. 有益な参照…10
Stapp, et al. Standards Track [Page 2] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[2ページ]。
1. Introduction
1. 序論
A set of procedures to allow DHCP [7] [11] clients and servers to automatically update the DNS ([3], [4]) is proposed in [1].
DHCP[7][11]クライアントとサーバが自動的にDNS([3]をアップデートするのを許容する手順のセット、[4])は[1]で提案されます。
Conflicts can arise if multiple DHCP clients wish to use the same DNS name or a DHCP client attempts to use a name added for another purpose. To resolve such conflicts, [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients using them. In the interest of clarity, it is preferable for this DHCP information to use a distinct RR type. This memo defines a distinct RR for this purpose for use by DHCP clients or servers: the "DHCID" RR.
複数のDHCPクライアントが同じDNS名を使用したいと思うなら、闘争が起きることができますか、またはDHCPクライアントは、別の目的のために加えられた名前を使用するのを試みます。 そのような闘争を解決するために、DHCPクライアントが彼らを使用していて、[1]は、明白にドメイン名を関連づけるためにDNSのクライアント識別子を保存するよう提案します。 明快のために、このDHCP情報が異なったRRタイプを使用するのは、望ましいです。 このメモはこのために使用のためにDHCPクライアントかサーバで異なったRRを定義します: "DHCID"RR。
In order to obscure potentially sensitive client identifying information, the data stored is the result of a one-way SHA-256 hash computation. The hash includes information from the DHCP client's message as well as the domain name itself, so that the data stored in the DHCID RR will be dependent on both the client identification used in the DHCP protocol interaction and the domain name. This means that the DHCID RDATA will vary if a single client is associated over time with more than one name. This makes it difficult to 'track' a client as it is associated with various domain names.
潜在的に機密のクライアント身元が分かる情報をあいまいにするために、保存されたデータは一方向SHA-256ハッシュ計算の結果です。 ハッシュはドメイン名自体と同様にDHCPクライアントのメッセージからの情報を含んでいます、DHCID RRに保存されたデータがDHCPプロトコル相互作用に使用されるクライアント識別とドメイン名の両方に依存するようになるように。 これは、独身のクライアントが時間がたつにつれて1つ以上の名前に関連しているとDHCID RDATAが異なることを意味します。 これで、それが様々なドメイン名に関連しているのでクライアントが'追跡'であることは難しくなります。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[2]で説明されるように本書では解釈されることであるべきですか?
3. The DHCID RR
3. DHCID RR
The DHCID RR is defined with mnemonic DHCID and type code 49. The DHCID RR is only defined in the IN class. DHCID RRs cause no additional section processing.
DHCID RRはニーモニックDHCIDとタイプコード49で定義されます。 DHCID RRはINのクラスで定義されるだけです。 DHCID RRsはどんな追加セクション処理も引き起こしません。
3.1. DHCID RDATA Format
3.1. DHCID RDATA形式
The RDATA section of a DHCID RR in transmission contains RDLENGTH octets of binary data. The format of this data and its interpretation by DHCP servers and clients are described below.
トランスミッションにおけるDHCID RRのRDATA部はバイナリ・データのRDLENGTH八重奏を含みます。 このデータの形式とDHCPサーバとクライアントによるその解釈は以下で説明されます。
DNS software should consider the RDATA section to be opaque. DHCP clients or servers use the DHCID RR to associate a DHCP client's identity with a DNS name, so that multiple DHCP clients and servers may deterministically perform dynamic DNS updates to the same zone. From the updater's perspective, the DHCID resource record RDATA consists of a 2-octet identifier type, in network byte order,
DNSソフトウェアは、RDATA部が不伝導性であると考えるはずです。 DHCPクライアントかサーバがDHCPクライアントのアイデンティティをDNS名に関連づけるのにDHCID RRを使用します、複数のDHCPクライアントとサーバが決定論的にダイナミックなDNSアップデートを同じゾーンに実行できるように。 updaterの見解から、DHCIDリソースの記録的なRDATAはネットワークバイトオーダーで2八重奏の識別子タイプから成ります。
Stapp, et al. Standards Track [Page 3] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[3ページ]。
followed by a 1-octet digest type, followed by one or more octets representing the actual identifier:
実際の識別子を表す1つ以上の八重奏があとに続いた1八重奏のダイジェストタイプによって後をつけられています:
< 2 octets > Identifier type code
< 1 octet > Digest type code
< n octets > Digest (length depends on digest type)
1つの八重奏の<2八重奏>Identifierタイプコード<>Digestはコード<n八重奏>Digestをタイプします。(長さをダイジェストタイプに頼っています)
3.2. DHCID Presentation Format
3.2. DHCIDプレゼンテーション形式
In DNS master files, the RDATA is represented as a single block in base-64 encoding identical to that used for representing binary data in [8], Section 3. The data may be divided up into any number of white-space-separated substrings, down to single base-64 digits, which are concatenated to form the complete RDATA. These substrings can span lines using the standard parentheses.
DNS基本ファイルでは、RDATAは単滑車として[8](セクション3)にバイナリ・データを表すのに使用されるそれと同じベース-64コード化で表されます。 データはいろいろな切り離された白いスペースサブストリングに分割されるかもしれません、ただ一つのベース-64ケタまで。(ケタは、完全なRDATAを形成するために連結されます)。 標準の括弧を使用することでこれらのサブストリングは系列にかかることができます。
3.3. The DHCID RR Identifier Type Codes
3.3. DHCID RR識別子タイプコード
The DHCID RR Identifier Type Code specifies what data from the DHCP client's request was used as input into the hash function. The identifier type codes are defined in a registry maintained by IANA, as specified in Section 7. The initial list of assigned values for the identifier type code and that type's identifier is:
DHCID RR Identifier Type Codeは、DHCPクライアントの要求からのどんなデータがハッシュ関数に入力されるように使用されたかを指定します。 識別子タイプコードはセクション7で指定されるようにIANAによって維持された登録で定義されます。 識別子タイプコードとそのタイプの識別子のための割り当てられた値の初期のリストは以下の通りです。
+------------------+------------------------------------------------+ | Identifier Type | Identifier | | Code | | +------------------+------------------------------------------------+ | 0x0000 | The 1-octet 'htype' followed by 'hlen' octets | | | of 'chaddr' from a DHCPv4 client's DHCPREQUEST | | | [7]. | | 0x0001 | The data octets (i.e., the Type and | | | Client-Identifier fields) from a DHCPv4 | | | client's Client Identifier option [10]. | | 0x0002 | The client's DUID (i.e., the data octets of a | | | DHCPv6 client's Client Identifier option [11] | | | or the DUID field from a DHCPv4 client's | | | Client Identifier option [6]). | | 0x0003 - 0xfffe | Undefined; available to be assigned by IANA. | | 0xffff | Undefined; RESERVED. | +------------------+------------------------------------------------+
+------------------+------------------------------------------------+ | 識別子タイプ| 識別子| | コード| | +------------------+------------------------------------------------+ | 0×0000| 'hlen'八重奏があとに続いた1八重奏の'htype'| | | DHCPv4クライアントのDHCPREQUESTからの'chaddr'について| | | [7]. | | 0×0001| DHCPv4からのデータ八重奏(| | | すなわち、Typeとクライアント識別子分野)| | | クライアントのClient Identifierオプション[10]。 | | 0×0002| (のすなわち、aのデータ八重奏| | | DHCPv6クライアントClient Identifierが[11]をゆだねるクライアントのDUID| | | DUIDはクライアントのDHCPv4ものから|さばきます| | クライアントIdentifierオプション[6])。 | | 0×0003--0xfffe| 未定義。 IANAによって割り当てられるように、利用可能です。 | | 0xffff| 未定義。 予約にされる。 | +------------------+------------------------------------------------+
3.4. The DHCID RR Digest Type Code
3.4. DHCID RRダイジェストタイプコード
The DHCID RR Digest Type Code is an identifier for the digest algorithm used. The digest is calculated over an identifier and the canonical FQDN as described in the next section.
DHCID RR Digest Type Codeは使用されるダイジェストアルゴリズムのための識別子です。 ダイジェストは次のセクションで説明されるように識別子と正準なFQDNの上で計算されます。
Stapp, et al. Standards Track [Page 4] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[4ページ]。
The digest type codes are defined in a registry maintained by IANA, as specified in Section 7. The initial list of assigned values for the digest type codes is: value 0 is reserved, and value 1 is SHA-256. Reserving other types requires IETF standards action. Defining new values will also require IETF standards action to document how DNS updaters are to deal with multiple digest types.
ダイジェストタイプコードはセクション7で指定されるようにIANAによって維持された登録で定義されます。 ダイジェストタイプコードのための割り当てられた値の初期のリストは以下の通りです。 値0は予約されています、そして、値1はSHA-256です。 他のタイプを予約するのはIETF規格動作を必要とします。 また、新しい値を定義するのは、DNS updatersが複数のダイジェストタイプに対処することになっている方法を記録するためにIETF規格動作を必要とするでしょう。
3.5. Computation of the RDATA
3.5. RDATAの計算
The DHCID RDATA is formed by concatenating the 2-octet identifier type code with variable-length data.
DHCID RDATAは、可変長のデータで2八重奏の識別子タイプコードを連結することによって、形成されます。
The RDATA for all type codes other than 0xffff, which is reserved for future expansion, is formed by concatenating the 2-octet identifier type code, the 1-octet digest type code, and the digest value (32 octets for SHA-256).
0xffff以外のすべてのタイプコードのためのRDATAは、2八重奏の識別子タイプコード、1八重奏のダイジェストタイプコード、およびダイジェスト値(SHA-256のための32の八重奏)を連結することによって、形成されます。0xffffは今後の拡張のために予約されます。
< identifier-type > < digest-type > < digest >
<識別子タイプ><ダイジェストタイプ><ダイジェスト>。
The input to the digest hash function is defined to be:
ダイジェストハッシュ関数への入力は、である:なるように定義されます。
digest = SHA-256(< identifier > < FQDN >)
ダイジェスト=SHA-256(<識別子><FQDN>)
The FQDN is represented in the buffer in the canonical wire format as described in [9], Section 6.2. The identifier type code and the identifier are related as specified in Section 3.3: the identifier type code describes the source of the identifier.
FQDNは[9]、セクション6.2で説明されるようにバッファに正準なワイヤ形式で表されます。 識別子タイプコードと識別子はセクション3.3で指定されるように話されます: 識別子タイプコードは識別子の源について説明します。
A DHCPv4 updater uses the 0x0002 type code if a Client Identifier option is present in the DHCPv4 messages and it is encoded as specified in [6]. Otherwise, the updater uses 0x0001 if a Client Identifier option is present, and 0x0000 if not.
Client IdentifierオプションがDHCPv4メッセージに存在していて、それが[6]で指定されるようにコード化されるなら、DHCPv4 updaterは0×0002タイプコードを使用します。 さもなければ、updaterはまして、Client Identifierオプションがプレゼントと、0×0000であるなら0×0001を使用します。
A DHCPv6 updater always uses the 0x0002 type code.
DHCPv6 updaterはいつも0×0002タイプコードを使用します。
3.5.1. Using the Client's DUID
3.5.1. クライアントのDUIDを使用します。
When the updater is using the Client's DUID (either from a DHCPv6 Client Identifier option or from a portion of the DHCPv4 Client Identifier option encoded as specified in [6]), the first two octets of the DHCID RR MUST be 0x0002, in network byte order. The third octet is the digest type code (1 for SHA-256). The rest of the DHCID RR MUST contain the results of computing the SHA-256 hash across the octets of the DUID followed by the FQDN.
updaterであるときに、使用はClientのDUIDです。(DHCPv6 Client Identifierオプションか[6])、DHCID RR MUSTの最初の2つの八重奏で指定されるようにコード化されたDHCPv4 Client Identifierオプションの部分からの、0×0002になってください、ネットワークバイトオーダーで。 3番目の八重奏はダイジェストタイプコード(SHA-256のための1)です。 DHCID RR MUSTの残りはFQDNによって続かれたDUIDの八重奏の向こう側にSHA-256ハッシュを計算するという結果を含んでいます。
Stapp, et al. Standards Track [Page 5] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[5ページ]。
3.5.2. Using the Client Identifier Option
3.5.2. クライアント識別子オプションを使用します。
When the updater is using the DHCPv4 Client Identifier option sent by the client in its DHCPREQUEST message, the first two octets of the DHCID RR MUST be 0x0001, in network byte order. The third octet is the digest type code (1 for SHA-256). The rest of the DHCID RR MUST contain the results of computing the SHA-256 hash across the data octets (i.e., the Type and Client-Identifier fields) of the option, followed by the FQDN.
updaterがそうであるときにはDHCID RR MUSTでは、0×0001になってくださいオプションがクライアントでDHCPREQUESTメッセージ、最初の2つの八重奏で送ったDHCPv4 Client Identifierを使用して、ネットワークバイトオーダーで。 3番目の八重奏はダイジェストタイプコード(SHA-256のための1)です。 DHCID RR MUSTの残りはFQDNによって続かれたオプションのデータ八重奏(すなわち、TypeとClient-識別子分野)の向こう側にSHA-256ハッシュを計算するという結果を含んでいます。
3.5.3. Using the Client's htype and chaddr
3.5.3. Clientのhtypeとchaddrを使用します。
When the updater is using the client's link-layer address as the identifier, the first two octets of the DHCID RDATA MUST be zero. The third octet is the digest type code (1 for SHA-256). To generate the rest of the resource record, the updater computes a one-way hash using the SHA-256 algorithm across a buffer containing the client's network hardware type, link-layer address, and the FQDN data. Specifically, the first octet of the buffer contains the network hardware type as it appeared in the DHCP 'htype' field of the client's DHCPREQUEST message. All of the significant octets of the 'chaddr' field in the client's DHCPREQUEST message follow, in the same order in which the octets appear in the DHCPREQUEST message. The number of significant octets in the 'chaddr' field is specified in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified above, follows.
updaterがそうであるときにはDHCID RDATA MUSTでは、ゼロになってくださいリンクレイヤが識別子、最初の2つの八重奏として演説するクライアントのものを使用して。 3番目の八重奏はダイジェストタイプコード(SHA-256のための1)です。 リソース記録の残りを生成するために、updaterはクライアントのネットワークハードウェアタイプ、リンクレイヤアドレス、およびFQDNデータを含んでいて、バッファの向こう側にSHA-256アルゴリズムを使用することで一方向ハッシュを計算します。 明確に、バッファの最初の八重奏はクライアントのDHCPREQUESTメッセージのDHCP'htype'分野に現れたようにネットワークハードウェアタイプを含んでいます。 クライアントのDHCPREQUESTメッセージにおける、'chaddr'分野の重要な八重奏のすべてが続きます、八重奏がDHCPREQUESTメッセージに現れる同次で。 'chaddr'分野の重要な八重奏の数はDHCPREQUESTメッセージの'hlen'分野で指定されます。 上で指定されるとして、FQDNデータは従います。
3.6. Examples
3.6. 例
3.6.1. Example 1
3.6.1. 例1
A DHCP server allocates the IPv6 address 2001:DB8::1234:5678 to a client that included the DHCPv6 client-identifier option data 00:01: 00:06:41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server updates the name "chi6.example.com" on the client's behalf and uses the DHCP client identifier option data as input in forming a DHCID RR. The DHCID RDATA is formed by setting the two type octets to the value 0x0002, the 1-octet digest type to 1 for SHA-256, and performing a SHA-256 hash computation across a buffer containing the 14 octets from the client-id option and the FQDN (represented as specified in Section 3.5).
DHCPサーバはIPv6アドレス2001: DB8を割り当てます:、:1234:5678 クライアントに、それはDHCPv6クライアント識別子オプションデータ00:01を含めました: 00:06:41:2d:f1:、66:、01:02:03、:、04:05:06、DHCPv6要求で。 サーバは、クライアントに代わって"chi6.example.com"という名前をアップデートして、DHCID RRを形成する際に入力されるようにDHCPクライアント識別子オプションデータを使用します。 DHCID RDATAは、SHA-256のために値0x0002、1八重奏のダイジェストタイプへの2つのタイプ八重奏を1に設定して、クライアントイドオプションとFQDN(セクション3.5で指定されるように、表される)からの14の八重奏を含んでいて、バッファの向こう側にSHA-256ハッシュ計算を実行することによって、形成されます。
chi6.example.com. AAAA 2001:DB8::1234:5678
chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
OjxfNuVAA2kjEA= )
chi6.example.com。 AAAA2001: DB8:、:1234: 5678chi6.example.com。 DHCID(AAIBY2/AuCccgoJbsaxcQc9TUapptP69l OjxfNuVAA2kjEA=)
If the DHCID RR type is not supported, the RDATA would be encoded [13] as:
DHCID RRタイプがサポートされないなら、RDATAがコード化されるだろう、以下としての[13]
Stapp, et al. Standards Track [Page 6] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[6ページ]。
\# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
b95000da48c40 )
\# 35 (000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd b95000da48c40)
3.6.2. Example 2
3.6.2. 例2
A DHCP server allocates the IPv4 address 192.0.2.2 to a client that included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the name "chi.example.com" on the client's behalf and uses the DHCP client identifier option data as input in forming a DHCID RR. The DHCID RDATA is formed by setting the two type octets to the value 0x0001, the 1-octet digest type to 1 for SHA-256, and performing a SHA-256 hash computation across a buffer containing the seven octets from the client-id option and the FQDN (represented as specified in Section 3.5).
DHCPサーバがIPv4アドレスを割り当てる、192.0、.2、.2、DHCPクライアント識別子オプションデータを含んでいたクライアント、0a:0b:0c、08:09 01:07::DHCP要求で。 サーバは、クライアントに代わって"chi.example.com"という名前をアップデートして、DHCID RRを形成する際に入力されるようにDHCPクライアント識別子オプションデータを使用します。 DHCID RDATAは、SHA-256のために値0x0001、1八重奏のダイジェストタイプへの2つのタイプ八重奏を1に設定して、クライアントイドオプションとFQDN(セクション3.5で指定されるように、表される)からの7つの八重奏を含んでいて、バッファの向こう側にSHA-256ハッシュ計算を実行することによって、形成されます。
chi.example.com. A 192.0.2.2
chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
L3b/NaiUDlW2No= )
chi.example.com。 192.0 .2 .2 chi.example.com。 DHCID(AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW L3b/NaiUDlW2No=)
If the DHCID RR type is not supported, the RDATA would be encoded [13] as:
DHCID RRタイプがサポートされないなら、RDATAがコード化されるだろう、以下としての[13]
\# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
6a2503956d8da )
\# 35 (0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd 6a2503956d8da)
3.6.3. Example 3
3.6.3. 例3
A DHCP server allocating the IPv4 address 192.0.2.3 to a client with the Ethernet MAC address 01:02:03:04:05:06 using domain name "client.example.com" uses the client's link-layer address to identify the client. The DHCID RDATA is composed by setting the two type octets to zero, the 1-octet digest type to 1 for SHA-256, and performing an SHA-256 hash computation across a buffer containing the 1-octet 'htype' value for Ethernet, 0x01, followed by the six octets of the Ethernet MAC address, and the domain name (represented as specified in Section 3.5).
IPv4アドレスを割り当てるDHCPサーバ、192.0、.2、.3、イーサネットMACアドレスをもっているクライアント、01:02:03、:、04:05:06、ドメイン名"client.example.com"を使用すると、クライアントのリンクレイヤアドレスは、クライアントを特定するのに使用されます。 DHCID RDATAは、ゼロ、SHA-256のための1への1八重奏のダイジェストタイプ、イーサネット、0×01のためのイーサネットMACアドレスの6つの八重奏があとに続いた1八重奏の'htype'値を含んでいて、バッファの向こう側にSHA-256ハッシュ計算を実行して、およびドメイン名(セクション3.5で指定されるように、表される)に2つのタイプ八重奏を設定することによって、構成されます。
client.example.com. A 192.0.2.3
client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
ytcKD//7es/deY= )
client.example.com。 192.0 .2 .3 client.example.com。 DHCID(AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V ytcKD//7es/deY=)
If the DHCID RR type is not supported, the RDATA would be encoded [13] as:
DHCID RRタイプがサポートされないなら、RDATAがコード化されるだろう、以下としての[13]
\# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
fffedeb3f75e6 )
\# 35 (000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283 fffedeb3f75e6)
Stapp, et al. Standards Track [Page 7] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[7ページ]。
4. Use of the DHCID RR
4. DHCID RRの使用
This RR MUST NOT be used for any purpose other than that detailed in [1]. Although this RR contains data that is opaque to DNS servers, the data must be consistent across all entities that update and interpret this record. Therefore, new data formats may only be defined through actions of the DHC Working Group, as a result of revising [1].
このRR MUST NOT、あらゆる目的には、[1]で詳しく述べられるのを除いて、使用されてください。 このRRはDNSサーバに不明瞭なデータを含んでいますが、データはこの記録をアップデートして、解釈するすべての実体の向こう側に一貫しているに違いありません。 したがって、新しいデータ書式はDHC作業部会の動作で定義されるだけであるかもしれません、[1]を改訂することの結果、。
5. Updater Behavior
5. Updaterの振舞い
The data in the DHCID RR allows updaters to determine whether more than one DHCP client desires to use a particular FQDN. This allows site administrators to establish policy about DNS updates. The DHCID RR does not establish any policy itself.
DHCID RRのデータで、updatersは、1人以上のDHCPクライアントが、特定のFQDNを使用することを望んでいるかどうか決定できます。 これで、サイトの管理者はDNSアップデートに関する方針を確立できます。 DHCID RRはどんな方針自体も確立しません。
Updaters use data from a DHCP client's request and the domain name that the client desires to use to compute a client identity hash, and then compare that hash to the data in any DHCID RRs on the name that they wish to associate with the client's IP address. If an updater discovers DHCID RRs whose RDATA does not match the client identity that they have computed, the updater SHOULD conclude that a different client is currently associated with the name in question. The updater SHOULD then proceed according to the site's administrative policy. That policy might dictate that a different name be selected, or it might permit the updater to continue.
Updatersは彼らがクライアントのIPアドレスに関連づけたがっている名前のどんなDHCID RRsでもDHCPクライアントの要求とクライアントがクライアントアイデンティティハッシュを計算して、次に、そのハッシュを比較するのに使用することを望んでいるドメイン名からデータまでデータを使用します。 updaterがRDATAが彼らが計算したクライアントのアイデンティティに合っていないDHCID RRsを発見するなら、updater SHOULDは、名前がはっきりしていなく異なったクライアントが現在関連していると結論を下します。 そして、サイトの施政方針によると、updater SHOULDは続きます。 その方針が、異なった名前が選択されると決めるかもしれませんか、またはそれは、updaterが続くのを許容するかもしれません。
6. Security Considerations
6. セキュリティ問題
The DHCID record as such does not introduce any new security problems into the DNS. In order to obscure the client's identity information, a one-way hash is used. Further, in order to make it difficult to 'track' a client by examining the names associated with a particular hash value, the FQDN is included in the hash computation. Thus, the RDATA is dependent on both the DHCP client identification data and on each FQDN associated with the client.
そういうもののDHCID記録は少しの新しい警備上の問題もDNSに紹介しません。 クライアントのアイデンティティ情報をあいまいにするために、一方向ハッシュは使用されています。 さらに、FQDNは、クライアントが特定のハッシュ値に関連している名前を調べることによって'追跡'であることを難しくするようにハッシュ計算に含まれています。 したがって、RDATAは両方のDHCPクライアント識別情報と、そして、クライアントに関連しているそれぞれのFQDNに依存しています。
However, it should be noted that an attacker that has some knowledge, such as of MAC addresses commonly used in DHCP client identification data, may be able to discover the client's DHCP identify by using a brute-force attack. Even without any additional knowledge, the number of unknown bits used in computing the hash is typically only 48 to 80.
しかしながら、何らかの知識を持っている攻撃者が、DHCPクライアント識別情報で一般的に使用されるMACアドレスなどのようにクライアントのDHCPが使用するのによる全数探索法を特定すると発見できるかもしれないことに注意されるべきです。 少しも追加知識がなくても、通常、ハッシュを計算する際に使用される未知のビットの数は、48〜80にすぎません。
Administrators should be wary of permitting unsecured DNS updates to zones, whether or not they are exposed to the global Internet. Both DHCP clients and servers SHOULD use some form of update authentication (e.g., [12]) when performing DNS updates.
管理者はunsecured DNSがゾーンにアップデートする可能にするのに用心深いはずです、それらが世界的なインターネットに暴露されるか否かに関係なく。 DHCPクライアントとサーバSHOULDの両方が何らかの形式のアップデート認証を使用します。([12]) 例えば、DNSアップデートを実行するとき。
Stapp, et al. Standards Track [Page 8] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[8ページ]。
7. IANA Considerations
7. IANA問題
IANA has allocated a DNS RR type number for the DHCID record type.
IANAはDHCIDレコード種類のDNS RR形式数を割り当てました。
This specification defines a new number-space for the 2-octet identifier type codes associated with the DHCID RR. IANA has established a registry of the values for this number-space. Three initial values are assigned in Section 3.3, and the value 0xFFFF is reserved for future use. New DHCID RR identifier type codes are assigned through Standards Action, as defined in [5].
この仕様はDHCID RRに関連している2八重奏の識別子タイプコードのために新しい数スペースを定義します。 IANAはこの数スペースに値の登録を確立しました。 3つの初期の値がセクション3.3で割り当てられます、そして、値の0xFFFFは今後の使用のために予約されます。 新しいDHCID RR識別子タイプコードは[5]で定義されるようにStandards Actionを通して割り当てられます。
This specification defines a new number-space for the 1-octet digest type codes associated with the DHCID RR. IANA has established a registry of the values for this number-space. Two initial values are assigned in Section 3.4. New DHCID RR digest type codes are assigned through Standards Action, as defined in [5].
この仕様はDHCID RRに関連している1八重奏のダイジェストタイプコードのために新しい数スペースを定義します。 IANAはこの数スペースに値の登録を確立しました。 2つの初期の値がセクション3.4で割り当てられます。 新しいDHCID RRダイジェストタイプコードは[5]で定義されるようにStandards Actionを通して割り当てられます。
8. Acknowledgements
8. 承認
Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson, Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie Volz for their review and suggestions.
彼らのレビューと提案のためにハラルドAlvestrand、ラルフDroms、Olafurグドムンソン、サム・ハートマン、ジョッシュ・リトルフィールド、ペッカSavola、および特にバーニー・フォルツをありがとうございます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain
Name (FQDN) Conflicts among Dynamic Host Configuration Protocol
(DHCP) Clients", RFC 4703, October 2006.
[1] スタップ、M.、およびB.フォルツ、「完全修飾ドメイン名(FQDN)の解決はDynamic Host Configuration Protocol(DHCP)クライアントの中で闘争します」、RFC4703、2006年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[3]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[4]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[6] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
RFC 4361, February 2006.
[6] レモン、T.、およびB.ゾンマーフェルト、「ダイナミックなホスト構成のためのノード特有のクライアント識別子はバージョンFour(DHCPv4)について議定書の中で述べます」、RFC4361、2006年2月。
Stapp, et al. Standards Track [Page 9] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[9ページ]。
9.2. Informative References
9.2. 有益な参照
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[7]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[8]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[9] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
[10] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[10] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[11] Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[12] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
[12] Vixie(P.、グドムンソン、O.、イーストレーク、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
[13] グスタファソン、A.、「未知のDNSリソース記録(RR)タイプの取り扱い」、RFC3597、2003年9月。
Stapp, et al. Standards Track [Page 10] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[10ページ]。
Authors' Addresses
作者のアドレス
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
スタップシスコシステムズInc.1414マサチューセッツAveをマークしてください。 Boxborough、MA01719米国
Phone: 978.936.1535 EMail: mjs@cisco.com
以下に電話をしてください。 978.936.1535 メールしてください: mjs@cisco.com
Ted Lemon Nominum, Inc. 950 Charter St. Redwood City, CA 94063 USA
テッドレモンNominum Inc.950憲章聖カリフォルニア94063レッドウッドシティー(米国)
EMail: mellon@nominum.com
メール: mellon@nominum.com
Andreas Gustafsson Araneus Information Systems Oy Ulappakatu 1 02320 Espoo Finland
アンドレアス・グスタファソン・Araneus情報システムOy Ulappakatu1 02320エスポーフィンランド
EMail: gson@araneus.fi
メール: gson@araneus.fi
Stapp, et al. Standards Track [Page 11] RFC 4701 The DHCID RR October 2006
スタップ、他 規格はDHCID RR2006年10月にRFC4701を追跡します[11ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Stapp, et al. Standards Track [Page 12]
スタップ、他 標準化過程[12ページ]
一覧
スポンサーリンク
