広告
広告
https://www.7key.jp/rfc/rfc3646.html#source
https://www.7key.jp/rfc/rfc3646.html#translation
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.
当文書はインターネットコミュニティに役立つであろうインターネット標準プロトコルを提供するものであり、改良のための議論や提案を求めるものである。当プロトコル標準化の状況と現状については"Internet Official Protocol Standards"(STD1)の最新版を参照のこと。尚、当文書の配布に制限は設けていない。
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.
当文書は、利用可能なDNS再帰ネームサーバのリストとクライアントへのドメインサーチリストを伝えるIPv6用動的ホスト設定プロトコル(DHCPv6)のオプションについて記述するものである。
This document describes two options for passing configuration information related to Domain Name Service (DNS) (RFC 1034 [6] and RFC 1035 [1]) in DHCPv6 (RFC 3315 [2]).
当文書は、DHCPv6(RFC 3315[2])内のドメインネームサービス(DNS)(RFC 1034[6]及びRFC 1035[1])に関連する設定情報を伝えるための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 BCP 14, RFC 2119 [3].
当文書内で登場するMUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONALの意味は、BCP 14及びRFC 2119[3]の通り解釈するものとする。
Throughout this document, unless otherwise specified, the acronym DHCP refers to DHCP as specified in RFC 3315.
当文書では特に定義がなければ、頭字語DHCPはRFC 3315で定義されるDHCPv6を指すものとする。
This document uses terminology specific to IPv6 and DHCP as defined in section "Terminology" of RFC 3315.
当文書では、RFC 3315の"用語"章で定義されるIPv6及びDHCP固有の用語を用いる。
The DNS Recursive Name Server option provides a list of one or more IPv6 addresses of DNS recursive name servers to which a client's DNS resolver MAY send DNS queries [1]. The DNS servers are listed in the order of preference for use by the client resolver.
DNS再帰ネームサーバオプションは、クライアントのDNSリゾルバがDNSクエリを送信するかもしれない(MAY)DNS再帰ネームサーバの1つ以上のIPv6アドレスリストを提供する。DNSサーバは、クライアントリゾルバによって用いられる優先順位でリスト化される。
The format of the DNS Recursive Name Server option is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DNS_SERVERS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-recursive-name-server (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DNS-recursive-name-server (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNS再帰ネームサーバオプションのフォーマットは次の通り:(図省略/原文参照)
option-code: OPTION_DNS_SERVERS (23) option-len: Length of the list of DNS recursive name servers in octets; must be a multiple of 16 DNS-recursive-name-server: IPv6 address of DNS recursive name server
The Domain Search List option specifies the domain search list the client is to use when resolving hostnames with DNS. This option does not apply to other name resolution mechanisms.
ドメインサーチリストオプションは、クライアントがDNSでホスト名を解決する際に用いるドメイン検索リストを定義する。このオプションは、他の名前解決メカニズムには該当しない。
The format of the Domain Search List option is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DOMAIN_LIST | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | searchlist | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ドメインサーチリストオプションのフォーマットは次の通り:(図省略/原文参照)
option-code: OPTION_DOMAIN_LIST (24) option-len: Length of the 'searchlist' field in octets searchlist: The specification of the list of domain names in the Domain Search List
The list of domain names in the 'searchlist' MUST be encoded as specified in section "Representation and use of domain names" of RFC 3315.
サーチリストのドメイン名のリストは、RFC3315の"ドメイン名の表現と用い方"章で定義されるようにエンコードされなければならない(MUST)。
The DNS Recursive Name Server option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
DNS再帰ネームサーバオプションは、要請、アドバタイズ、リクエスト、更新、再結合、情報リクエスト、応答以外のメッセージで用いてはならない(MUST NOT)。
The Domain Search List option MUST NOT appear in any other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
ドメインサーチリストオプションは、要請、アドバタイズ、リクエスト、更新、再結合、情報リクエスト、応答以外のメッセージで用いてはならない(MUST NOT)。
The DNS Recursive Name Server option may be used by an intruder DHCP server to cause DHCP clients to send DNS queries to an intruder DNS recursive name server. The results of these misdirected DNS queries may be used to spoof DNS names.
DNS再帰ネームサーバオプションは、DHCPクライアントが侵入者DNS再帰ネームサーバにDNSクエリを送信することを引き起こすために侵入者DHCPサーバによって用いられるかもしれない。これらの誤ったDNSクエリの結果は、DNS名スプーフを引き起こすかもしれない。
To avoid attacks through the DNS Recursive Name Server option, the DHCP client SHOULD require DHCP authentication (see section "Authentication of DHCP messages" in RFC 3315) before installing a list of DNS recursive name servers obtained through authenticated DHCP.
DNS再帰ネームサーバオプションを用いての攻撃を避けるために、DHCPクライアントは認証済みのDHCPで得たDNS再帰ネームサーバのリストを導入する前に、DHCP認証(RFC3315の"DHCPメッセージの認証"を参照)を要求すべきである(SHOULD)。
The Domain Search List option may be used by an intruder DHCP server to cause DHCP clients to search through invalid domains for incompletely specified domain names. The results of these misdirected searches may be used to spoof DNS names. Note that support for DNSSEC [4] will not avert this attack, because the resource records in the invalid domains may be legitimately signed.
ドメインサーチリストオプションは、DHCPクライアントが不完全に指定したドメイン名について不正なドメインを検索させることを引き起こすために侵入者DHCPサーバによって用いられるかもしれない。これらの誤った検索の結果はDNS名スプーフに用いられるかもしれない。不正なドメインのリソースレコードは合法的に署名されるおそれがあるため、DNSSEC[4]のサポートはこの攻撃を避けないことに注意が必要である。
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 [7] contains a discussion of security weaknesses related to implicit as well as explicit domain searchlists, and provides recommendations relating to resolver searchlist processing. Section 6 of RFC1536 [5] also addresses this vulnerability, and recommends that resolvers: 1. Use searchlists only when explicitly specified; no implicit searchlists should be used. 2. Resolve a name that contains any dots by first trying it as an FQDN and if that fails, with the names in the searchlist appended. 3. Resolve a name containing no dots by appending with the searchlist right away, but once again, no implicit searchlists should be used.
ホストが無効なドメインサーチオプションによる攻撃で受けるダメージの度合いは、DNSリゾルバの処理によって決定する部分もある。RFC1535[7]は明示的若しくは暗黙的なドメインサーチに関するセキュリティの弱点の議論を含み、リゾルバ検索リスト処理に関する勧告を提供する。RFC1536[5]の6章もまたこの弱点について扱い、リゾルバに以下を推薦している:
In order to minimize potential vulnerabilities it is recommended that: 1. Hosts implementing the domain search option SHOULD also implement the searchlist recommendations of RFC1536, section 6. 2. Where DNS parameters such as the domain searchlist or DNS servers have been manually configured, these parameters SHOULD NOT be overridden by DHCP. 3. A host SHOULD require the use of DHCP authentication (see section "Authentication of DHCP messages" in RFC 3315) prior to accepting a domain search option.
脆弱性を最小とするために以下が推奨される:
IANA has assigned an option code to the DNS Recursive Name Server option (23) and to the Domain Search List option (24) from the DHCP option code space defined in section "IANA Considerations" of RFC 3315.
IANAは、RFC3315の"IANAによる考察"で定義したDHCPオプションコード空間からDNS再帰ネームサーバオプションコード(23)とドメインサーチリストオプションコード(24)を割り当てた。
This option was originally part of the DHCPv6 specification, written by Jim Bound, Mike Carney, Charlie Perkins, Ted Lemon, Bernie Volz and Ralph Droms.
このオプションは元々DHCPv6定義の一部であり、Jim Bound氏、Mike Carney氏、Charlie Perkins氏、Ted Lemon氏、Bernie Volz氏、Ralph Droms氏によって書かれたものである。
The analysis of the potential attack through the domain search list is taken from the specification of the DHCPv4 Domain Search option, RFC3397 [8].
ドメインサーチリストを用いての攻撃の可能性の分析は、DHCPv4ドメインサーチオプションの仕様書であるRFC3397[8]から流用した。
Thanks to Rob Austein, Alain Durand, Peter Koch, Tony Lindstrom and Pekka Savola for their contributions to this document.
当文書への貢献に伴い、Rob Austein氏、Alain Durand氏、Peter Koch氏、Tony Lindstrom氏、Pekka Savola氏に謝辞を述べる。
[1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, May 2003. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [5] Kumar, A., Postel, J., Neuman, C., Danzig, P. and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993.
[6] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [7] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993. [8] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
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.
当文書に記された実装や技術に関して主張される知的財産やその他の権利の有効性や範囲について、またこれらの権利の元でライセンスが利用可能か不可能化について、IETHはいかなる立場もとらない(そのような権利を確認する努力をしたわけではない)。IETFの標準手続きと標準関連文書での権利に関する手順はBCP11を参照のこと。出版に利用する権利やライセンス保証、この仕様書の実装者や利用者の所有権の一般的なライセンスや許可の取得については、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 Executive Directorまで情報を提供願う。
Ralph Droms, Editor Cisco Systems 1414 Massachusetts Ave. Boxboro, MA 01719 USA Phone: +1 978 936 1674 EMail: rdroms@cisco.com
Copyright (C) The Internet Society (2003).
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.
当文書及び文書内の情報は無保証で提供され、寄稿者、寄稿者が代表となる組織、もしあれば寄稿者を後援する組織、インターネット学会及びIETFは、当文書がいかなる権利も侵害していないという保証、商業利用や特定目的に対する適合性への保証、更にはこれらに限らずあらゆる保証について明示的にも暗黙的にも保証をしていない。
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC編集者の職務に対する資金供給は、現在インターネット学会から提供されている。
広告