DHCPv6のDNS設定オプション

広告

広告

原文

最終更新
2006-11-15T00:00:00+09:00
この記事のURI参照
http://www.7key.jp/rfc/rfc3646.html#source

DHCPv6のDNS設定オプション(和訳)

最終更新
2006-11-27T00:00:00+09:00
この記事のURI参照
http://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)のオプションについて記述するものである。

1. 序論

   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つのオプションについて記述する。

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].

当文書内で登場するMUSTMUST NOTREQUIREDSHALLSHALL NOTSHOULDSHOULD NOTRECOMMENDEDMAYOPTIONALの意味は、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固有の用語を用いる。

3. DNS再帰ネームサーバオプション

   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
option-code
OPTION_DNS_SERVERS (23)
option-len
DNS再帰ネームサーバリストの長さをオクテットで表す。16の倍数となる。
DNS-recursive-name-server
DNS再帰ネームサーバのIPv6アドレス。

4. ドメインサーチリストオプション

   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
option-code
OPTION_DOMAIN_LIST (24)
option-len
サーチリストフィールド長をオクテット単位で表す。
searchlist
ドメインサーチリストのドメイン名のリストの定義。
   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)。

5. これらのオプションの概観

   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)。

6. 安全性への配慮

   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章もまたこの弱点について扱い、リゾルバに以下を推薦している:

  1. 明示的に指定される際のみサーチリストを用い、暗黙のサーチリストを用いるべきではない。
  2. ドットを含む名前の解決にはFQDNとしてまず最初に試し、それが失敗したらサーチリストを付加した名前で解決を行う。
  3. サーチリストの右端にドットを含まない名前の解決には、暗黙のサーチリストを用いるべきではない。
   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.

脆弱性を最小とするために以下が推奨される:

  1. ドメインサーチオプションを実装しているホストは、RFC1536の6章で推薦されるサーチリストもまた実装すべきである(SHOULD)。
  2. ドメインサーチリストやDNSサーバのようなDNSパラメータが手動で設定された場合、これらのパラメータはDHCPによって無効にされるべきではない(SHOULD NOT)。
  3. ホストは、ドメインサーチオプションを受け入れるに先立ちDHCP認証(RFC3315の"DHCPメッセージの認証"を参照)を用いるべきである(SHOULD)。

7. IANAによる考察

   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)を割り当てた。

8. 謝辞

   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氏に謝辞を述べる。

9. 参照文献

9.1. 標準リファレンス

   [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.

9.2. 参考リファレンス

   [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編集者の職務に対する資金供給は、現在インターネット学会から提供されている。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年11月15日 最終更新:2006年11月15日