[要約] RFC 3397は、DHCPドメイン検索オプションに関する仕様であり、クライアントがDNSドメインを検索するための情報を提供します。このRFCの目的は、DHCPクライアントが正確なドメイン検索情報を取得できるようにすることです。
Network Working Group B. Aboba
Request for Comments: 3397 Microsoft
Category: Standards Track S. Cheshire
Apple Computer, Inc.
November 2002
Dynamic Host Configuration Protocol (DHCP) Domain Search Option
動的ホスト構成プロトコル（DHCP）ドメイン検索オプション
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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames using DNS.
このドキュメントでは、DHCPサーバーからDHCPクライアントに渡される新しい動的ホスト構成プロトコル（DHCP）オプションを定義して、DNSを使用してホスト名を解決するときに使用されるドメイン検索リストを指定します。
Table of Contents
目次
1. Introduction ................................................ 2
1.1 Terminology ............................................ 2
1.2 Requirements Language .................................. 2
2. Domain Search Option Format ................................. 2
3. Example ..................................................... 3
4. Security Considerations ..................................... 4
5. Normative References ........................................ 5
6. Informative References ...................................... 5
7. IANA Considerations ......................................... 6
8. Acknowledgments ............................................. 6
9. Intellectual Property Statement ............................. 6
10. Authors' Addresses .......................................... 7
11. Full Copyright Statement .................................... 8
The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a mechanism for host configuration. [RFC2132] and [RFC2937] allow DHCP servers to pass name service configuration information to DHCP clients. In some circumstances, it is useful for the DHCP client to be configured with the domain search list. This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames with DNS. This option applies only to DNS and does not apply to other name resolution mechanisms.
動的ホスト構成プロトコル（DHCP）[RFC2131]は、ホスト構成のメカニズムを提供します。[RFC2132]および[RFC2937]により、DHCPサーバーは名前のサービス構成情報をDHCPクライアントに渡すことができます。状況によっては、DHCPクライアントがドメイン検索リストで構成されるのに役立ちます。このドキュメントでは、DHCPサーバーからDHCPクライアントに渡される新しいDHCPオプションを定義して、DNSでホスト名を解決するときに使用されるドメイン検索リストを指定します。このオプションはDNSにのみ適用され、他の名前解決メカニズムには適用されません。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
DHCP client A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address.
DHCPクライアントDHCPクライアントまたは「クライアント」は、DHCPを使用してネットワークアドレスなどの構成パラメーターを取得するインターネットホストです。
DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
DHCPサーバーDHCPサーバーまたは「サーバー」は、構成パラメーターをDHCPクライアントに返すインターネットホストです。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、「要件レベルを示すためにRFCで使用するためのキーワード」[RFC2119]に記載されているように解釈される。
The code for this option is 119.
このオプションのコードは119です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 119 | Len | Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above diagram, Searchstring is a string specifying the searchlist. If the length of the searchlist exceeds the maximum permissible within a single option (255 octets), then multiple options MAY be used, as described in "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396].
上記の図では、SearchStringは検索リストを指定する文字列です。検索リストの長さが単一のオプション（255オクテット）内で最大許容値を超える場合、「動的ホスト構成プロトコル（DHCPV4）の長いオプションをエンコードする」[RFC3396]で説明されているように、複数のオプションを使用できます。
To enable the searchlist to be encoded compactly, searchstrings in the searchlist MUST be concatenated and encoded using the technique described in section 4.1.4 of "Domain Names - Implementation And Specification" [RFC1035]. In this scheme, an entire domain name or a list of labels at the end of a domain name is replaced with a pointer to a prior occurrence of the same name. Despite its complexity, this technique is valuable since the space available for encoding DHCP options is limited, and it is likely that a domain searchstring will contain repeated instances of the same domain name. Thus the DNS name compression is both useful and likely to be effective.
検索リストをコンパクトにエンコードできるようにするには、「ドメイン名 - 実装と仕様」[RFC1035]のセクション4.1.4で説明されている手法を使用して、検索リストの検索ストリングを連結およびエンコードする必要があります。このスキームでは、ドメイン名全体のドメイン名またはドメイン名の最後にあるラベルのリストは、同じ名前の事前に発生するポインターに置き換えられます。その複雑さにもかかわらず、この手法はDHCPオプションのエンコードに利用できるスペースが限られているため価値があり、ドメイン検索ストリングには同じドメイン名の繰り返しインスタンスが含まれる可能性があります。したがって、DNS名圧縮は有用であり、効果的である可能性があります。
For use in this specification, the pointer refers to the offset within the data portion of the DHCP option (not including the preceding DHCP option code byte or DHCP option length byte).
この仕様で使用するために、ポインターは、DHCPオプションのデータ部分内のオフセットを指します（前のDHCPオプションコードバイトまたはDHCPオプション長バイトを含まない）。
If multiple Domain Search Options are present, then the data portions of all the Domain Search Options are concatenated together as specified in "Encoding Long DHCP Options in the Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396] and the pointer indicates an offset within the complete aggregate block of data.
複数のドメイン検索オプションが存在する場合、すべてのドメイン検索オプションのデータ部分は、「ダイナミックホスト構成プロトコル（DHCPV4）の長いDHCPオプションをエンコードする」[RFC3396]で指定されているように連結され、ポインターは、ポインターがオフセットを示しています。データの完全な集約ブロック。
Below is an example encoding of a search list consisting of "eng.apple.com." and "marketing.apple.com.":
以下は、「eng.apple.com」で構成される検索リストのエンコードの例です。および "Market.Apple.com。"：
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 | 3 |'e'|'n'|'g'| 5 |'a'|'p'|'p'|'l'|
+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 |'e'| 3 |'c'|'o'|'m'| 0 | 9 |'m'|'a'|
+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+
|119| 9 |'r'|'k'|'e'|'t'|'i'|'n'|'g'|xC0|x04|
+---+---+---+---+---+---+---+---+---+---+---+
Note:
注記：
i. The encoding has been split (for this example) into three Domain Search Options. All Domain Search Options are logically concatenated into one block of data before being interpreted by the client.
i. エンコーディングは（この例では）3つのドメイン検索オプションに分割されています。すべてのドメイン検索オプションは、クライアントによって解釈される前に、データの1つのブロックに論理的に連結されます。
ii. The encoding of "eng.apple.com." ends with a zero, the null root label, to mark the end of the name, as required by RFC 1035.
ii。「eng.apple.com」のエンコード。RFC 1035で要求されるように、名前の最後をマークするゼロ、nullルートラベルで終わります。
iii. The encoding of "marketing" (for "marketing.apple.com.") ends with the two-octet compression pointer C004 (hex), which points to offset 4 in the complete aggregated block of Domain Search Option data, where another validly encoded domain name can be found to complete the name ("apple.com.").
iii。「マーケティング」のエンコード（「Marketing.Apple.com。」）は、2オクテットの圧縮ポインターC004（HEX）で終わります。ドメイン名は、名前（ "Apple.com。"）を完成させることができます。
Every search domain name must end either with a zero or with a two-octet compression pointer. If the receiver is part-way through decoding a search domain name when it reaches the end of the complete aggregated block of the searchlist option data, without finding a zero or a valid two-octet compression pointer, then the partially read name MUST be discarded as invalid.
すべての検索ドメイン名は、ゼロまたは2オクテットの圧縮ポインターで終了する必要があります。受信機が検索ドメイン名のデコードを介して部門である場合は、ゼロまたは有効な2オクテットの圧縮ポインターを見つけることなく、検索リストオプションデータの完全な集計ブロックの終了に到達したときに、部分的に読み取られた名前を破棄する必要があります。無効として。
Potential attacks on DHCP are discussed in section 7 of the DHCP protocol specification [RFC2131], as well as in the DHCP authentication specification [RFC3118]. In particular, using the domain search option, a rogue DHCP server might be able to redirect traffic to another site.
DHCPに対する潜在的な攻撃については、DHCPプロトコル仕様[RFC2131]のセクション7、およびDHCP認証仕様[RFC3118]で説明されています。特に、ドメイン検索オプションを使用して、Rogue DHCPサーバーはトラフィックを別のサイトにリダイレクトできる場合があります。
For example, a user requesting a connection to "myhost", expecting to reach "myhost.bigco.com" might instead be directed to "myhost.roguedomain.com". Note that support for DNSSEC [RFC2535] will not avert this attack, since the resource records for "myhost.roguedomain.com" might be legitimately signed. This makes the domain search option a more fruitful avenue of attack for a rogue DHCP server than providing an illegitimate DNS server option (described in [RFC2132]).
たとえば、「myhost」に「myhost.bigco.com」に到達することを期待する「myhost」への接続を要求するユーザーは、代わりに「myhost.roguedomain.com」に向けられる場合があります。「myhost.roguedomain.com」のリソースレコードが合法的に署名される可能性があるため、DNSSEC [RFC2535]のサポートはこの攻撃を回避しないことに注意してください。これにより、ドメイン検索オプションは、違法なDNSサーバーオプション（[RFC2132]で説明）を提供するよりも、不正なDHCPサーバーの攻撃のより実り多い手段になります。
The degree to which a host is vulnerable to attack via an invalid domain search option is determined in part by DNS resolver behavior. [RFC1535] discusses security weaknesses related to implicit as well as explicit domain searchlists, and provides recommendations relating to resolver searchlist processing. [RFC1536] section 6 also addresses this vulnerability, and recommends that resolvers:
ホストが無効なドメイン検索オプションを介して攻撃に対して脆弱である程度は、DNSリゾルバーの動作によって部分的に決定されます。[RFC1535]は、暗黙的および明示的なドメイン検索リストに関連するセキュリティの弱点について説明し、Resolver SearchList処理に関連する推奨事項を提供します。[RFC1536]セクション6では、この脆弱性についても対処し、そのリゾルバーを推奨しています。
[1] Use searchlists only when explicitly specified; no implicit searchlists should be used.
[1] SearchListsを使用して、明示的に指定した場合にのみ使用します。暗黙の検索リストを使用する必要はありません。
[2] Resolve a name that contains any dots by first trying it as an FQDN and if that fails, with the local domain name (or searchlist if specified) appended.
[2] 最初にFQDNとして試してみることでドットを含む名前を解決し、それが失敗した場合、ローカルドメイン名（または指定されている場合は検索リスト）が追加されます。
[3] Resolve a name containing no dots by appending with the searchlist right away, but once again, no implicit searchlists should be used.
[3] SeartListにすぐに追加することにより、ドットを含む名前を含む名前を解決しますが、もう一度、暗黙の検索リストを使用する必要はありません。
In order to minimize potential vulnerabilities it is recommended that:
潜在的な脆弱性を最小限に抑えるために、次のことをお勧めします。
[a] Hosts implementing the domain search option SHOULD also implement the searchlist recommendations of [RFC1536], section 6.
[a] ドメイン検索オプションを実装するホストは、[RFC1536]、セクション6の検索リストの推奨事項も実装する必要があります。
[b] Where DNS parameters such as the domain searchlist or DNS servers have been manually configured, these parameters SHOULD NOT be overridden by DHCP.
[b] ドメイン検索リストやDNSサーバーなどのDNSパラメーターが手動で構成されている場合、これらのパラメーターはDHCPによって無効にされるべきではありません。
[c] Domain search option implementations MAY require DHCP authentication [RFC3118] prior to accepting a domain search option.
[c] ドメイン検索オプションの実装には、ドメイン検索オプションを受け入れる前に、DHCP認証[RFC3118]が必要になる場合があります。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P. and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993.
[RFC1536] Kumar、A.、Postel、J.、Neuman、C.、Danzig、P。and S. Miller、「一般的なDNS実装エラーと提案された修正」、RFC 1536、1993年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] DROMS、R。およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3396] Lemon、T。およびS. Cheshire、「ダイナミックホスト構成プロトコル（DHCPV4）の長いオプションをコードする」、RFC 3396、2002年11月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535] Gavron、E。、「セキュリティ問題と広く展開されたDNSソフトウェアによる修正の提案」、RFC 1535、1993年10月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, September 2000.
[RFC2937]スミス、C。、「DHCPの名前サービス検索オプション」、RFC 2937、2000年9月。
The IANA has assigned DHCP option code 119 to the Domain Search Option.
IANAは、DHCPオプションコード119をドメイン検索オプションに割り当てました。
The authors would like to thank Michael Patton, Erik Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, Erik Nordmark, Myron Hattig, Keith Moore, and Bill Manning for comments on this memo.
著者は、マイケル・パットン、エリック・ガットマン、オラファー・グドムンドソン、トーマス・ナルテン、マーク・アンドリュース、エリック・ノードマーク、マイロン・ハッティグ、キース・ムーア、ビル・マニングにこのメモに関するコメントをしてくれたことに感謝したいと思います。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスに基づく免許にある範囲に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA
Stuart Cheshire Apple Computer、Inc。1 Infinite Loop Cupertino California 95014 USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。