[要約] RFC 6731は、マルチインターフェースノードのための改良された逆引きDNSサーバーの選択に関するものです。その目的は、ノードが複数のインターフェースを持つ場合でも、最適な逆引きDNSサーバーを選択するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) T. Savolainen
Request for Comments: 6731 Nokia
Category: Standards Track J. Kato
ISSN: 2070-1721 NTT
T. Lemon
Nominum, Inc.
December 2012
Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
マルチインターフェースノードの再帰DNSサーバー選択の改善
Abstract
概要
A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions.
マルチインターフェースノードは複数のネットワークに接続されており、その一部はプライベートDNS名前空間を利用している可能性があります。ノードは通常、接続されているすべてのネットワークから再帰DNSサーバー構成情報を受信します。一部の再帰DNSサーバーには、他のサーバーにはない名前空間に関する情報がある場合があります。マルチインターフェースノードがDNSを利用する必要がある場合、ノードは使用する再帰DNSサーバーを選択する必要があります。このドキュメントでは、情報に基づいて再帰的なDNSサーバーの選択を決定するために必要な情報を使用してノードを構成するために使用できるDHCPv4およびDHCPv6オプションについて説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6731.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6731で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Private Namespaces and Problems for Multi-Interfaced Nodes . . 4
2.1. Fully Qualified Domain Names with Limited Scopes . . . . . 4
2.2. Network-Interface-Specific IP Addresses . . . . . . . . . 5
2.3. A Problem Not Fully Solved by the Described Solution . . . 6
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7
3.1. CPE Deployment Scenario . . . . . . . . . . . . . . . . . 7
3.2. Cellular Network Scenario . . . . . . . . . . . . . . . . 7
3.3. VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Dual-Stack Accesses . . . . . . . . . . . . . . . . . . . 8
4. Improved RDNSS Selection . . . . . . . . . . . . . . . . . . . 8
4.1. Procedure for Prioritizing RDNSSes and Handling
Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. RDNSS Selection DHCPv6 Option . . . . . . . . . . . . . . 11
4.3. RDNSS Selection DHCPv4 Option . . . . . . . . . . . . . . 13
4.4. Scalability Considerations . . . . . . . . . . . . . . . . 15
4.5. Limitations on Use . . . . . . . . . . . . . . . . . . . . 15
4.6. Coexistence of Various RDNSS Configuration Tools . . . . . 16
4.7. Considerations on Follow-Up Queries . . . . . . . . . . . 17
4.8. Closing Network Interfaces and Local Caches . . . . . . . 17
5. Example of a Node Behavior . . . . . . . . . . . . . . . . . . 17
6. Considerations for Network Administrators . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.1. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Trust Levels of Network Interfaces . . . . . . . . . . . . 21
8.3. Importance of Following the Algorithm . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Possible Alternative Practices for RDNSS Selection . 23
A.1. Sending Queries Out on Multiple Interfaces in Parallel . . 23
A.2. Search List Option for DNS Forward Lookup Decisions . . . 23
A.3. More-Specific Routes for Reverse Lookup Decisions . . . . 24
A.4. Longest Matching Prefix for Reverse Lookup Decisions . . . 24
Appendix B. DNSSEC and Multiple Answers Validating with
Different Trust Anchors . . . . . . . . . . . . . . . 24
Appendix C. Pseudocode for RDNSS Selection . . . . . . . . . . . 24
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29
A multi-interfaced node (MIF node) faces several problems a single-homed node does not encounter, as is described in [RFC6418]. This document studies in detail the problems private namespaces might cause for multi-interfaced nodes and provides a solution. The node might be implemented as a host or as a router.
[RFC6418]で説明されているように、マルチインターフェースノード（MIFノード）は、シングルホームノードが発生しないいくつかの問題に直面しています。このドキュメントでは、プライベートネームスペースがマルチインターフェースノードで発生する可能性がある問題を詳細に調査し、解決策を提供します。ノードは、ホストまたはルーターとして実装できます。
We start from the premise that network operators sometimes include private, but still globally unique, namespaces in the answers they provide from Recursive DNS Servers (RDNSSes) and that those private namespaces are at least as useful to nodes as the answers from the public DNS. When private namespaces are visible for a node, some RDNSSes have information other RDNSSes do not have. The node ought to be able to query the RDNSS that can resolve the query regardless of whether the answer comes from the public DNS or a private namespace.
ネットワークオペレーターは、再帰DNSサーバー（RDNSS）から提供される回答に、プライベートだがグローバルに一意の名前空間を含めることがあり、これらのプライベート名前空間はパブリックDNSからの回答と同じくらいノードにとって有用であるという前提から始めます。ノードのプライベート名前空間が表示される場合、一部のRDNSSには他のRDNSSにはない情報があります。ノードは、応答がパブリックDNSからのものかプライベート名前空間からのものかに関係なく、クエリを解決できるRDNSSをクエリできる必要があります。
An example of an application that benefits from multi-interfacing is a web browser that commonly accesses many different destinations, each of which is available on only one network. The browser therefore needs to be able to communicate over different network interfaces, depending on the destination it is trying to reach.
マルチインターフェイスのメリットを享受できるアプリケーションの例としては、多くの異なる宛先に一般的にアクセスするWebブラウザーがあり、それぞれが1つのネットワークでのみ利用可能です。したがって、ブラウザーは、到達しようとしている宛先に応じて、さまざまなネットワークインターフェイスを介して通信できる必要があります。
Selection of the correct interface and source address is often crucial in the networks using private namespaces. In such deployments, the destination's IP addresses might only be reachable on the network interface over which the destination's name was resolved. Henceforth, the solution described in this document is assumed to be commonly used in combination with tools for delivering additional routing and source and destination address selection policies (e.g., [RFC4191] and [RFC3442].
プライベートな名前空間を使用するネットワークでは、正しいインターフェイスと送信元アドレスの選択が重要になることがよくあります。このような配備では、宛先のIPアドレスは、宛先の名前が解決されたネットワークインターフェイスでのみ到達可能である可能性があります。今後、このドキュメントで説明するソリューションは、追加のルーティングおよび送信元と宛先のアドレス選択ポリシーを配信するためのツール（[RFC4191]や[RFC3442]など）と組み合わせて一般的に使用されることを想定しています。
This document is organized in the following manner. Background information about problem descriptions and example deployment scenarios are included in Sections 2 and 3. Section 4 contains all normative descriptions for DHCP options and node behavior. Informative Section 5 illustrates behavior of a node implementing functionality described in Section 4. Section 6 contains normative guidelines related to creation of private namespaces. The IANA considerations are in Section 7. Informational Section 8 summarizes identified security considerations.
このドキュメントは次のように構成されています。問題の説明と導入シナリオの例に関する背景情報は、セクション2と3に含まれています。セクション4には、DHCPオプションとノードの動作に関するすべての規範的な説明が含まれています。有益なセクション5は、セクション4で説明した機能を実装するノードの動作を示しています。セクション6には、プライベート名前空間の作成に関連する規範的なガイドラインが含まれています。 IANAの考慮事項はセクション7にあります。情報セクション8は、識別されたセキュリティの考慮事項を要約しています。
Appendix A describes best current practices that are possible with tools preceding this document and that are possibilities on networks not supporting the solution described in this document. Appendix B discusses a scenario where multiple answers are possible to validate, but with different trust anchors. Appendix C illustrates with pseudocode the functionality described in Section 4.
付録Aでは、このドキュメントの前にあるツールで可能であり、このドキュメントで説明されているソリューションをサポートしていないネットワークでの可能性がある現在のベストプラクティスについて説明します。付録Bでは、複数の回答を検証できるが、トラストアンカーが異なるシナリオについて説明します。付録Cは、セクション4で説明した機能を疑似コードで示しています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This section describes two private namespace scenarios related to node multi-interfacing for which the procedure described in Section 4 provides a solution. Additionally, Section 2.3 describes a problem for which this document provides only a partial solution.
このセクションでは、セクション4で説明した手順がソリューションを提供する、ノードのマルチインターフェイスに関連する2つのプライベート名前空間シナリオについて説明します。さらに、セクション2.3では、このドキュメントで部分的な解決策しか提供されていない問題について説明しています。
A multi-interfaced node can be connected to one or more networks that are using private namespaces. As an example, the node can simultaneously open a Wireless LAN (WLAN) connection to the public Internet, a cellular connection to an operator network, and a Virtual Private Network (VPN) connection to an enterprise network. When an application initiates a connection establishment to a Fully Qualified Domain Name (FQDN), the node needs to be able to choose the right RDNSS for making a successful DNS query. This is illustrated in Figure 1. An FQDN for a public name can be resolved with any RDNSS, but for an FQDN of the private name of an enterprise's or operator's service, the node needs to be able to correctly select the right RDNSS for the DNS resolution, i.e., do also network interface selection already before destination's IP address is known.
マルチインターフェースのノードは、プライベート名前空間を使用している1つ以上のネットワークに接続できます。例として、ノードは、パブリックインターネットへのワイヤレスLAN（WLAN）接続、オペレーターネットワークへのセルラー接続、およびエンタープライズネットワークへの仮想プライベートネットワーク（VPN）接続を同時に開くことができます。アプリケーションが完全修飾ドメイン名（FQDN）への接続確立を開始すると、ノードはDNSクエリを正常に実行するために適切なRDNSSを選択できる必要があります。これを図1に示します。パブリック名のFQDNは任意のRDNSSで解決できますが、企業またはオペレーターのサービスのプライベート名のFQDNの場合、ノードはDNSに適切なRDNSSを正しく選択できる必要があります解決、つまり、宛先のIPアドレスがわかる前に、すでにネットワークインターフェイスの選択も行います。
+---------------+
| RDNSS with | | Enterprise
+------+ | public + |----| Intranet
| | | enterprise's | |
| |===== VPN =======| private names | |
| | +---------------+ +----+
| MIF | | FW |
| node | +----+
| | +---------------+ |
| |----- WLAN ------| RDNSS with |----| Public
| | | public names | | Internet
| | +---------------+ +----+
| | | FW |
| | +---------------+ +----+
| |---- cellular ---| RDNSS with | |
+------+ | public + | | Operator
| operator's |----| Intranet
| private names | |
+---------------+
Figure 1: Private DNS Namespaces Illustrated
図1：図解されたプライベートDNS名前空間
In the second problem, an FQDN is valid and resolvable via different network interfaces, but to different and not necessarily globally reachable IP addresses, as is illustrated in Figure 2. The node's routing, source, and destination address selection mechanism has to ensure the destination's IP address is only used in combination with source IP addresses of the network interface on which the name was resolved.
2番目の問題では、FQDNは有効であり、さまざまなネットワークインターフェイスを介して解決できますが、図2に示すように、必ずしもグローバルに到達可能なさまざまなIPアドレスに解決できます。ノードのルーティング、ソース、および宛先アドレス選択メカニズムは、宛先のアドレスを確認する必要がありますIPアドレスは、名前が解決されたネットワークインターフェイスの送信元IPアドレスとの組み合わせでのみ使用されます。
+--------------------| |
+------+ IPv6 | RDNSS A |------| IPv6
| |-- interface 1 --| saying Peer is | |
| | | at: 2001:0db8:0::1 | |
| MIF | +--------------------+ +------+
| node | | Peer |
| | +--------------------+ +------+
| | IPv6 | RDNSS B | |
| |-- interface 2 --| saying Peer is | |
+------+ | at: 2001:0db8:1::1 |------| IPv6
+--------------------+ |
Figure 2: Private DNS Namespaces and Different IP Addresses for an FQDN on Interfaces 1 and 2
図2：インターフェイス1と2のFQDNのプライベートDNS名前空間と異なるIPアドレス
A similar situation can happen with IPv6 protocol translation and AAAA record synthesis [RFC6147]. A synthetic AAAA record is guaranteed to be valid only on the network on which it was synthesized. Figure 3 illustrates a scenario where the peer's IPv4 address is synthesized into different IPv6 addresses by RDNSSes A and B.
IPv6プロトコル変換とAAAAレコード合成[RFC6147]でも同様の状況が発生する可能性があります。合成AAAAレコードは、合成されたネットワーク上でのみ有効であることが保証されています。図3は、ピアのIPv4アドレスがRDNSSのAとBによって異なるIPv6アドレスに合成されるシナリオを示しています。
+-------------------| +-------+
+------+ IPv6 | RDNSS A |----| NAT64 |
| |-- interface 1 --| saying Peer is | +-------+
| | | at: A_Pref96:IPv4 | |
| MIF | +-------------------+ | +------+
| node | IPv4 +---| Peer |
| | +-------------------+ | +------+
| | IPv6 | RDNSS B | |
| |-- interface 2 --| saying Peer is | +-------+
+------+ | at: B_Pref96:IPv4 |----| NAT64 |
+-------------------+ +-------+
Figure 3: AAAA Synthesis Results in Network-Interface-Specific IPv6 Addresses
図3：ネットワークインターフェース固有のIPv6アドレスでのAAAA合成結果
It is worth noting that network-specific IP addresses can also cause problems for a single-homed node, if the node retains DNS cache during movement from one network to another. After the network change, a node can have entries in its DNS cache that are no longer correct or appropriate for its new network position.
あるネットワークから別のネットワークへの移動中にノードがDNSキャッシュを保持している場合、ネットワーク固有のIPアドレスもシングルホームノードに問題を引き起こす可能性があることに注意してください。ネットワークの変更後、ノードのDNSキャッシュには、ネットワークの新しい位置に対して正しくない、または適切ではなくなったエントリが含まれる可能性があります。
A more complex scenario is an FQDN, which in addition to possibly resolving into network-interface-specific IP addresses, identifies on different network interfaces completely different peer entities with potentially different sets of service offerings. In an even more complex scenario, an FQDN identifies a unique peer entity, but one that provides different services on its different network interfaces. The solution described in this document is not able to tackle these higher-layer issues. In fact, these problems might be solvable only by manual user intervention.
より複雑なシナリオはFQDNです。FQDNは、ネットワークインターフェイス固有のIPアドレスに解決される可能性があるだけでなく、異なるネットワークインターフェイス上で、提供されるサービスセットが異なる可能性のある完全に異なるピアエンティティを識別します。さらに複雑なシナリオでは、FQDNは一意のピアエンティティを識別しますが、異なるネットワークインターフェイスで異なるサービスを提供します。このドキュメントで説明されているソリューションは、これらの上位層の問題に取り組むことができません。実際、これらの問題は手動のユーザー介入によってのみ解決できる場合があります。
However, when DNS Security (DNSSEC) is used, the DNSSEC validation procedure can provide assistance for selecting correct responses for some, but not all, use cases. A node might prefer to use the DNS answer that validates with the preferred trust anchor.
ただし、DNSセキュリティ（DNSSEC）が使用されている場合、DNSSEC検証手順は、一部ではなく一部のユースケースで正しい応答を選択するための支援を提供できます。ノードは、優先トラストアンカーで検証するDNS回答の使用を好む場合があります。
This document has been written with three particular deployment scenarios in mind. The first is a Customer Premises Equipment (CPE) with two or more uplink Virtual Local Area Network (VLAN) connections. The second scenario involves a cellular device with two uplink Internet connections: WLAN and cellular. The third scenario is for VPNs, where use of a local RDNSS might be preferred for latency reasons, but the enterprise's RDNSS has to be used to resolve private names used by the enterprise.
このドキュメントは、3つの特定の展開シナリオを念頭に置いて作成されています。 1つは、2つ以上のアップリンク仮想ローカルエリアネットワーク（VLAN）接続を備えた顧客宅内機器（CPE）です。 2番目のシナリオには、2つのアップリンクインターネット接続（WLANとセルラー）を備えたセルラーデバイスが含まれます。 3番目のシナリオはVPNで、レイテンシの理由でローカルRDNSSの使用が推奨される場合がありますが、企業のRDNSSを使用して、企業が使用するプライベート名を解決する必要があります。
In this section, we are referring to the RDNSS preference values defined in Section 4. The purpose of that is to illustrate when administrators might choose to utilize the different preference values.
このセクションでは、セクション4で定義されたRDNSS設定値を参照します。その目的は、管理者がさまざまな設定値を使用することを選択する場合を説明することです。
A home gateway can have two uplink connections leading to different networks, as described in [WITHOUT-IPV6NAT]. In the two-uplink scenario, only one uplink connection leads to the Internet, while the other uplink connection leads to a private network utilizing private namespaces.
[WITHOUT-IPV6NAT]で説明されているように、ホームゲートウェイは、異なるネットワークにつながる2つのアップリンク接続を持つことができます。 2つのアップリンクのシナリオでは、1つのアップリンク接続のみがインターネットにつながり、他のアップリンク接続はプライベート名前空間を利用するプライベートネットワークにつながります。
It is desirable that the CPE does not have to send DNS queries over both uplink connections, but instead, CPE need only send default queries to the RDNSS of the interface leading to the Internet and queries related to the private namespace to the RDNSS of the private network. This can be configured by setting the RDNSS of the private network to know about listed domains and networks, but not to be a default RDNSS.
CPEは両方のアップリンク接続を介してDNSクエリを送信する必要がないことが望ましいが、代わりに、CPEはデフォルトのクエリをインターネットにつながるインターフェイスのRDNSSに送信し、プライベートネームスペースに関連するクエリをプライベートのRDNSSに送信するだけでよい通信網。これは、プライベートネットワークのRDNSSを設定して、リストされたドメインとネットワークを認識するように設定できますが、デフォルトのRDNSSには設定できません。
In this scenario, the legacy hosts can be supported by deploying DNS proxy on the CPE and configuring hosts in the LAN to talk to the DNS proxy. However, updated hosts would be able to talk directly to the correct RDNSS of each uplink ISP's RDNSS. It is a deployment decision whether the updated hosts would be pointed to a DNS proxy or to actual RDNSSes.
このシナリオでは、CPEにDNSプロキシを展開し、LAN内のホストを構成してDNSプロキシと通信することにより、レガシーホストをサポートできます。ただし、更新されたホストは、各アップリンクISPのRDNSSの正しいRDNSSと直接通信できます。更新されたホストがDNSプロキシを指すのか、実際のRDNSSを指すのかは、デプロイメントの決定です。
Depending on actual deployments, all VLAN connections might be considered trusted.
実際の展開によっては、すべてのVLAN接続が信頼できると見なされる場合があります。
A cellular device can have both WLAN and cellular network interfaces up. In such a case, it is often desirable to use WLAN by default, except for the connections that the cellular network operator wants to go over the cellular interface. The use of WLAN for DNS queries likely improves the power consumption of cellular devices and often provides lower latency. The cellular network might utilize private names; hence, the cellular device needs to ask for those through the cellular interface. This can be configured by setting the RDNSS of the cellular network to be of low preference and listing the domains and networks related to the cellular network's private namespaces as being available via the cellular network's RDNSS. This will cause a node to send DNS queries by default to the RDNSS of the WLAN interface (that is, by default, considered to be of medium preference) and queries related to private namespaces to the RDNSS of the cellular interface.
セルラーデバイスは、WLANとセルラーネットワークの両方のインターフェイスをアップにすることができます。このような場合、セルラーネットワークオペレーターがセルラーインターフェイスを介して接続することを望む接続を除いて、デフォルトでWLANを使用することが望ましい場合がよくあります。 DNSクエリにWLANを使用すると、セルラーデバイスの電力消費が改善され、多くの場合、レイテンシが短縮されます。セルラーネットワークはプライベート名を利用する場合があります。したがって、セルラーデバイスは、セルラーインターフェイスを介してそれらを要求する必要があります。これは、セルラーネットワークのRDNSSを低い優先度に設定し、セルラーネットワークのプライベートネームスペースに関連するドメインとネットワークを、セルラーネットワークのRDNSSを介して利用できるものとしてリストすることで構成できます。これにより、ノードはデフォルトでWLANインターフェースのRDNSSにDNSクエリを送信し（つまり、デフォルトで中程度の優先度であると見なされます）、プライベート名前空間に関連するクエリをセルラーインターフェースのRDNSSに送信します。
In this scenario, the cellular interface can be considered trusted and WLAN oftentimes untrusted.
このシナリオでは、セルラーインターフェイスは信頼できると見なすことができ、WLANは信頼できないことがよくあります。
Depending on a deployment, there might be interest in using VPN only for the traffic destined to a enterprise network. The enterprise might be using private namespaces; hence, related DNS queries need to be sent over VPN to the enterprise's RDNSS, while by default, the RDNSS of a local access network might be used for all other traffic. This can be configured by setting the RDNSS of the VPN interface to be of low preference and listing the domains and networks related to an enterprise network's private namespaces being available via the RDNSS of the VPN interface. This will cause a node to send DNS queries by default directly to the RDNSS of the WLAN interface (that is, by default, considered to be of medium preference) and queries related to private namespaces to the RDNSS of the VPN interface.
展開によっては、企業ネットワーク宛てのトラフィックに対してのみVPNを使用することに関心がある場合があります。企業はプライベート名前空間を使用している可能性があります。したがって、関連するDNSクエリをVPN経由で企業のRDNSSに送信する必要がありますが、デフォルトでは、ローカルアクセスネットワークのRDNSSが他のすべてのトラフィックに使用される可能性があります。これは、VPNインターフェースのRDNSSを低い優先度に設定し、VPNインターフェースのRDNSSを介して利用できるエンタープライズネットワークのプライベート名前空間に関連するドメインとネットワークをリストすることで構成できます。これにより、ノードはデフォルトで直接WLANインターフェースのRDNSSにDNSクエリを送信します（つまり、デフォルトで中程度の優先度であると見なされます）。VPNインターフェースのRDNSSにプライベート名前空間に関連するクエリを送信します。
In this scenario, the VPN interface can be considered trusted and the local access network untrusted.
このシナリオでは、VPNインターフェイスは信頼されていると見なされ、ローカルアクセスネットワークは信頼されていません。
In all three scenarios, one or more of the connected networks can support both IPv4 and IPv6. In such a case, both or either of DHCPv4 and DHCPv6 can be used to learn RDNSS selection information.
3つのシナリオすべてで、1つ以上の接続されたネットワークがIPv4とIPv6の両方をサポートできます。そのような場合、DHCPv4とDHCPv6の両方またはいずれかを使用して、RDNSS選択情報を学習できます。
This section describes DHCP options and a procedure that a (stub/ proxy) resolver can utilize for improved RDNSS selection in the face of private namespaces and multiple simultaneously active network interfaces. The procedure is subject to limitations of use as described in Section 4.5. The pseudocode in Appendix C illustrates how the improved RDNSS selection works.
このセクションでは、DHCPオプションと、（スタブ/プロキシ）リゾルバーがプライベート名前空間と複数の同時にアクティブなネットワークインターフェイスに直面してRDNSS選択を改善するために利用できる手順について説明します。この手順は、セクション4.5で説明されているように、使用の制限を受けます。付録Cの疑似コードは、改良されたRDNSS選択がどのように機能するかを示しています。
A resolver SHALL build a preference list of RDNSSes it will contact depending on the query. To build the list in an optimal way, a node SHALL request for RDNSS selection information with the DHCP options defined in Sections 4.2 and 4.3 before any DNS queries need to be made. With help of the received RDNSS selection information, the node can determine if any of the available RDNSSes have special knowledge about specific domains needed for forward DNS lookups or network addresses (later referred as "network") needed for reverse DNS lookups.
リゾルバは、クエリに応じて接続するRDNSSの優先リストを作成する必要があります（SHALL）。リストを最適な方法で構築するには、DNSクエリを実行する前に、ノードはセクション4.2と4.3で定義されたDHCPオプションを使用してRDNSS選択情報を要求する必要があります（SHALL）。受信したRDNSS選択情報を利用して、ノードは、使用可能なRDNSSのいずれかに、DNSの前方参照に必要な特定のドメイン、またはDNSの後方参照に必要なネットワークアドレス（後で「ネットワーク」と呼ばれる）に関する特別な知識があるかどうかを判断できます。
A resolver lacking more specific information can assume that all information is available from any RDNSS of any network interface. The RDNSSes learned by other RDNSS address configuration methods can be considered as default RDNSSes, but preference-wise, they MUST be handled as medium preference RDNSSes (see also Section 4.6).
より具体的な情報がないリゾルバは、すべての情報が任意のネットワークインターフェイスの任意のRDNSSから利用可能であると想定できます。他のRDNSSアドレス構成方法によって学習されたRDNSSは、デフォルトのRDNSSと見なすことができますが、優先的には、中優先のRDNSSとして処理する必要があります（セクション4.6も参照）。
When a DNS query needs to be made, the resolver MUST give highest preference to the RDNSSes explicitly known to serve a matching domain or network. The resolver MUST take into account differences in trust levels (see Section 8.2) of pieces of received RDNSS selection information. The resolver MUST prefer RDNSSes of trusted interfaces. The RDNSSes of untrusted interfaces can be of highest preference only if the trusted interfaces specifically configures low preference RDNSSes. The non-exhaustive list of cases in Figure 4 illustrates how the different trust levels of received RDNSS selection information influence the RDNSS selection logic. In Figure 4, "Medium", "High", and "Low" indicate the explicitly configured RDNSS's preference over other RDNSSes. The "Medium" preference is also used with RDNSSes for which no explicit preference configuration information is available. The "Specific domains" in Figure 4 indicate the explicitly configured "Domains and networks" private namespace information that a particular RDNSS has.
DNSクエリを作成する必要がある場合、リゾルバーは、一致するドメインまたはネットワークにサービスを提供することが明示的にわかっているRDNSSを最も優先する必要があります。リゾルバーは、受信したRDNSS選択情報の断片の信頼レベル（8.2節を参照）の違いを考慮に入れなければなりません（MUST）。リゾルバーは、信頼できるインターフェースのRDNSSを優先する必要があります。信頼できないインターフェイスのRDNSSは、信頼できるインターフェイスが優先度の低いRDNSSを明確に構成している場合にのみ、優先度が最も高くなります。図4のケースの完全ではないリストは、受信したRDNSS選択情報のさまざまな信頼レベルがRDNSS選択ロジックにどのように影響するかを示しています。図4の「中」、「高」、「低」は、明示的に構成されたRDNSSが他のRDNSSよりも優先されていることを示しています。 「中」設定は、明示的な設定構成情報が使用できないRDNSSでも使用されます。図4の「特定のドメイン」は、特定のRDNSSが持つ明示的に構成された「ドメインとネットワーク」のプライベート名前空間情報を示しています。
A resolver MUST prioritize between equally trusted RDNSSes with the help of the DHCP option preference field. The resolver MUST NOT prioritize less trusted RDNSSes higher than trusted, even in the case when a less trusted RDNSS would apparently have additional information. In the case of all other things being equal, the resolver can make the prioritization decision based on its internal preferences.
リゾルバーは、DHCPオプション設定フィールドを使用して、同等に信頼されたRDNSS間で優先順位を付ける必要があります。リゾルバーは、信頼性の低いRDNSSが明らかに追加情報を持っている場合でも、信頼性の低いRDNSSを信頼性よりも優先してはなりません。他のすべてのものが等しい場合、リゾルバは内部の優先順位に基づいて優先順位付けの決定を行うことができます。
Information from | Information from | Resulting RDNSS
more trusted | less trusted | preference
interface A | interface B | selection
--------------------------+------------------------+-----------------
1. Medium preference | Medium preference | Default:
default | default | A, then B
--------------------------+------------------------+-----------------
2. Medium preference | High preference default| Default:
default | | A, then B
| Specific domains | Specific:
| | A, then B
--------------------------+------------------------+-----------------
3. Low preference default | Medium preference | Default:
| default | B, then A
--------------------------+------------------------+-----------------
4. Low preference default | Medium preference | Default:
| default | B, then A
Specific domains | | Specific:
| | A, then B
--------------------------+------------------------+-----------------
Figure 4: RDNSS Selection in the Case of Different Trust Levels
図4：信頼レベルが異なる場合のRDNSSの選択
Because DNSSEC provides cryptographic assurance of the integrity of DNS data, it is necessary to prefer data that can be validated under DNSSEC over data that cannot. There are two ways that a node can determine that data is valid under DNSSEC. The first is to perform DNSSEC validation itself. The second is to have a secure connection to an authenticated RDNSS and to rely on that RDNSS to perform DNSSEC validation (signaling that it has done so using the AD bit). DNSSEC is necessary to detect forged responses, and without it any DNS response could be forged or altered. Unless the DNS responses have been validated with DNSSEC, a node cannot make a decision to prefer data from any interface with any great assurance.
DNSSECはDNSデータの整合性を暗号で保証するため、DNSSECで検証できないデータよりも、検証できるデータを優先する必要があります。ノードがDNSSECでデータが有効であると判断できる方法は2つあります。 1つ目は、DNSSEC検証自体を実行することです。 2つ目は、認証されたRDNSSへの安全な接続を確立し、そのRDNSSに依存してDNSSEC検証を実行することです（ADビットを使用してそうしたことを通知する）。偽造された応答を検出するにはDNSSECが必要です。DNSSECがなければ、DNS応答は偽造または変更される可能性があります。 DNSSECでDNS応答が検証されていない限り、ノードは、あらゆるインターフェースからのデータを優先するという決定を下すことはできません。
A node SHALL send requests to RDNSSes in the order defined by the preference list until an acceptable reply is received, all replies are received, or a timeout occurs. In the case of a requested name matching to a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all RDNSSes on the preference list have been contacted or timed out. This protects against possible redirection attacks. In the case of the requested name not matching to any specific domain or network, the first received response from any RDNSS can be considered acceptable. A DNSSEC-aware node MAY always contact all RDNSSes in an attempt to receive a response that can be validated, but contacting all RDNSSes is not mandated for the default case as that would consume excess resources in some deployments.
ノードは、受け入れ可能な応答が受信されるか、すべての応答が受信されるか、タイムアウトが発生するまで、優先リストで定義された順序でRDNSSに要求を送信する必要があります（SHALL）。特定のドメインまたはネットワークルールに一致する要求された名前がインターフェイスから受け入れられた場合、DNSSEC対応のリゾルバーは、優先リストのすべてのRDNSSに接続またはタイムアウトするまで、DNSSECを使用して検証できない応答を処理してはなりません（MUST NOT）。 。これにより、リダイレクト攻撃の可能性から保護されます。要求された名前が特定のドメインまたはネットワークと一致しない場合、RDNSSから最初に受信した応答は許容できると見なすことができます。 DNSSEC対応ノードは、検証可能な応答を受信するために、常にすべてのRDNSSに接続できますが、一部の展開では過剰なリソースを消費するため、デフォルトの場合はすべてのRDNSSに接続する必要があります。
In the case of a validated NXDOMAIN response being received from an RDNSS that can provide answers for the queried name, a node MUST NOT accept non-validated replies from other RDNSSes (see Appendix B for considerations related to multiple trust anchors).
照会された名前の回答を提供できるRDNSSから受信された検証済みのNXDOMAIN応答の場合、ノードは他のRDNSSからの検証されていない応答を受け入れてはなりません（複数のトラストアンカーに関する考慮事項については、付録Bを参照してください）。
DHCPv6 option described below can be used to inform resolvers what RDNSS can be contacted when initiating forward or reverse DNS lookup procedures. This option is DNS record type agnostic and applies, for example, equally to both A and AAAA queries.
以下で説明するDHCPv6オプションを使用すると、フォワードまたはリバースDNSルックアップ手順を開始するときに、どのRDNSSにアクセスできるかをリゾルバーに通知できます。このオプションはDNSレコードタイプに依存せず、たとえば、AクエリとAAAAクエリの両方に等しく適用されます。
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_RDNSS_SELECTION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS-recursive-name-server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |prf| |
+-+-+-+-+-+-+-+-+ Domains and networks |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCPv6 Option for Explicit Domain Configuration
図5：明示的なドメイン構成のDHCPv6オプション
option-code: OPTION_RDNSS_SELECTION (74)
オプションコード：OPTION_RDNSS_SELECTION（74）
option-len: Length of the option in octets
option-len：オクテット単位のオプションの長さ
DNS-recursive-name-server: An IPv6 address of RDNSS
DNS-recursive-name-server：RDNSSのIPv6アドレス
Reserved: Field reserved for the future. MUST be set to zero and MUST be ignored on receipt.
予約済み：将来のために予約されたフィールド。ゼロに設定する必要があり、受信時に無視する必要があります。
prf: RDNSS preference:
prf：RDNSS設定：
01 High 00 Medium 11 Low 10 Reserved
01高00中11低10予約
Reserved preference value (10) MUST NOT be sent. On receipt, the Reserved value MUST be treated as Medium preference (00).
予約済みの設定値（10）は送信してはならない（MUST NOT）。受信すると、Reserved値は中優先度（00）として扱われる必要があります。
Domains and networks: The list of domains for forward DNS lookup and networks for reverse DNS lookup about which the RDNSS has special knowledge. Field MUST be encoded as specified in Section 8 of [RFC3315]. A special domain of "." is used to indicate capability to resolve global names and act as a default RDNSS. Lack of a "." domain on the list indicates that the RDNSS only has information related to listed domains and networks. Networks for reverse mapping are encoded as defined for IP6.ARPA [RFC3596] or IN-ADDR.ARPA [RFC2317].
ドメインとネットワーク：RDNSSが特別な知識を持っている、フォワードDNSルックアップ用のドメインとリバースDNSルックアップ用のネットワークのリスト。 [RFC3315]のセクション8で指定されているとおりにフィールドをエンコードする必要があります。 「。」の特別なドメイングローバル名を解決し、デフォルトのRDNSSとして機能する機能を示すために使用されます。 「。」の欠如リストのドメインは、RDNSSにリストされているドメインとネットワークに関する情報のみがあることを示します。リバースマッピングのネットワークは、IP6.ARPA [RFC3596]またはIN-ADDR.ARPA [RFC2317]の定義に従ってエンコードされます。
A node SHOULD include the Option Request Option (OPTION_ORO [RFC3315]) in a DHCPv6 request with the OPTION_RDNSS_SELECTION option code to inform the DHCPv6 server about the support for the improved RDNSS selection logic. The DHCPv6 server receiving this information can then choose to provision RDNSS addresses only with OPTION_RDNSS_SELECTION.
ノードは、改善されたRDNSS選択ロジックのサポートについてDHCPv6サーバーに通知するために、OPTION_RDNSS_SELECTIONオプションコードを使用してDHCPv6要求にオプション要求オプション（OPTION_ORO [RFC3315]）を含める必要があります（SHOULD）。この情報を受信するDHCPv6サーバーは、OPTION_RDNSS_SELECTIONでのみRDNSSアドレスをプロビジョニングすることを選択できます。
OPTION_RDNSS_SELECTION contains one or more domains of which the related RDNSS has particular knowledge. The option can occur multiple times in a single DHCPv6 message, if multiple RDNSSes are to be configured. This can be the case, for example, if a network link has multiple RDNSSes for reliability purposes.
OPTION_RDNSS_SELECTIONには、関連するRDNSSが特定の知識を持つ1つ以上のドメインが含まれています。複数のRDNSSを構成する場合、このオプションは単一のDHCPv6メッセージで複数回発生する可能性があります。これは、たとえば、信頼性の目的でネットワークリンクに複数のRDNSSがある場合などです。
The list of networks MUST cover all the domains configured in this option. The length of the included networks SHOULD be as long as possible to avoid potential collision with information received on other option instances or with options received from DHCP servers of other network interfaces. Overlapping networks are interpreted so that the resolver can use any of the RDNSSes for queries matching the networks.
ネットワークのリストは、このオプションで構成されたすべてのドメインをカバーする必要があります。含まれるネットワークの長さは、他のオプションインスタンスで受信した情報や他のネットワークインターフェイスのDHCPサーバーから受信したオプションとの潜在的な衝突を回避するために、可能な限り長くする必要があります。重複するネットワークが解釈されるため、リゾルバーはネットワークに一致するクエリに任意のRDNSSを使用できます。
If OPTION_RDNSS_SELECTION contains an RDNSS address already learned from other DHCPv6 servers of the same network and contains new domains or networks, the node SHOULD append the information to the information received earlier. The node MUST NOT remove previously obtained information. However, the node SHOULD NOT extend the lifetime of earlier information either. When a conflicting RDNSS address is learned from a less trusted interface, the node MUST ignore the option.
OPTION_RDNSS_SELECTIONに同じネットワークの他のDHCPv6サーバーから既に学習されたRDNSSアドレスが含まれ、新しいドメインまたはネットワークが含まれている場合、ノードは以前に受信した情報に情報を追加する必要があります（SHOULD）。ノードは以前に取得した情報を削除してはなりません（MUST NOT）。ただし、ノードは以前の情報の有効期間も延長してはなりません（SHOULD NOT）。信頼性の低いインターフェイスから競合するRDNSSアドレスが学習された場合、ノードはオプションを無視する必要があります。
Like the RDNSS options of [RFC3646], OPTION_RDNSS_SELECTION MUST NOT appear in any other than the following DHCPv6 messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
[RFC3646]のRDNSSオプションと同様に、OPTION_RDNSS_SELECTIONは、要請、アドバタイズ、リクエスト、更新、再バインド、情報リクエスト、および返信のDHCPv6メッセージ以外には表示されません。
The client SHALL periodically refresh information learned with OPTION_RDNSS_SELECTION. The information SHALL be refreshed on link-state changes, such as those caused by node mobility, and when renewing lifetimes of IPv6 addresses configured with DHCPv6. Additionally, the DHCPv6 Information Refresh Time Option, as specified in [RFC4242], can be used to control the update frequency.
クライアントは、OPTION_RDNSS_SELECTIONで学習した情報を定期的に更新する必要があります（SHALL）。情報は、ノードのモビリティによって引き起こされるものなどのリンク状態の変更時、およびDHCPv6で構成されたIPv6アドレスのライフタイムを更新するときに更新される必要があります（SHALL）。さらに、[RFC4242]で指定されているDHCPv6情報更新時間オプションを使用して、更新頻度を制御できます。
The DHCPv4 option described below can be used to inform resolvers which RDNSS can be contacted when initiating forward or reverse DNS lookup procedures. This option is DNS record type agnostic and applies, for example, equally to both A and AAAA queries.
以下で説明するDHCPv4オプションを使用して、フォワードまたはリバースDNSルックアップ手順を開始するときに、どのRDNSSに接続できるかをリゾルバーに通知できます。このオプションはDNSレコードタイプに依存せず、たとえば、AクエリとAAAAクエリの両方に等しく適用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CODE | Len | Reserved |prf| Primary .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. DNS-recursive-name-server's IPv4 address | Secondary .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. DNS-recursive-name-server's IPv4 address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+ Domains and networks |
| (variable length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: DHCPv4 Option for Explicit Domain Configuration
図6：明示的なドメイン構成のDHCPv4オプション
option-code: RDNSS Selection (146)
オプションコード：RDNSSの選択（146）
option-len: Length of the option in octets
option-len：オクテット単位のオプションの長さ
Reserved: Field reserved for the future. MUST be set to zero and MUST be ignored on receipt.
予約済み：将来のために予約されたフィールド。ゼロに設定する必要があり、受信時に無視する必要があります。
prf: RDNSS preference:
prf：RDNSS設定：
01 High 00 Medium 11 Low 10 Reserved
01高00中11低10予約
Reserved preference value (10) MUST NOT be sent. On receipt, the Reserved value MUST be treated as Medium preference (00).
予約済みの設定値（10）は送信してはならない（MUST NOT）。受信すると、Reserved値は中優先度（00）として扱われる必要があります。
Primary DNS-recursive-name-server's IPv4 address: Address of a primary RDNSS
プライマリDNS-recursive-name-serverのIPv4アドレス：プライマリRDNSSのアドレス
Secondary DNS-recursive-name-server's IPv4 address: Address of a secondary RDNSS or 0.0.0.0 if not configured
セカンダリDNS-recursive-name-serverのIPv4アドレス：セカンダリRDNSSのアドレス、または構成されていない場合は0.0.0.0
Domains and networks: The list of domains for forward DNS lookup and networks for reverse DNS lookup about which the RDNSSes have special knowledge. Field MUST be encoded as specified in Section 8 of [RFC3315]. A special domain of "." is used to indicate capability to resolve global names and act as the default RDNSS. Lack of a "." domain on the list indicates that RDNSSes only have information related to listed domains and networks. Networks for reverse mapping are encoded as defined for IP6.ARPA [RFC3596] or IN-ADDR.ARPA [RFC2317].
ドメインとネットワーク：RDNSSが特別な知識を持っている、フォワードDNSルックアップ用のドメインとリバースDNSルックアップ用のネットワークのリスト。 [RFC3315]のセクション8で指定されているとおりにフィールドをエンコードする必要があります。 「。」の特別なドメイングローバル名を解決し、デフォルトのRDNSSとして機能する機能を示すために使用されます。 「。」の欠如リストのドメインは、RDNSSにリストされているドメインとネットワークに関する情報のみがあることを示します。リバースマッピングのネットワークは、IP6.ARPA [RFC3596]またはIN-ADDR.ARPA [RFC2317]の定義に従ってエンコードされます。
The RDNSS Selection option contains one or more domains of which the primary and secondary RDNSSes have particular knowledge. If the length of the domains and networks field causes option length to exceed the maximum permissible for 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]. When multiple options are present, the data portions of all option instances are concatenated together.
RDNSS選択オプションには、プライマリおよびセカンダリRDNSSが特定の知識を持つ1つ以上のドメインが含まれます。ドメインとネットワークのフィールドの長さが原因でオプションの長さが単一オプションの許容最大長（255オクテット）を超える場合、「動的ホスト構成プロトコル（DHCPv4）での長いオプションのエンコード」で説明されているように、複数のオプションを使用できます（MAY）。 [RFC3396]。複数のオプションが存在する場合、すべてのオプションインスタンスのデータ部分が一緒に連結されます。
The list of networks MUST cover all the domains configured in this option. The length of the included networks SHOULD be as long as possible to avoid potential collision with information received on other option instances or with options received from DHCP servers of other network interfaces. Overlapping networks are interpreted so that the resolver can use any of the RDNSSes for queries matching the networks.
ネットワークのリストは、このオプションで構成されたすべてのドメインをカバーする必要があります。含まれるネットワークの長さは、他のオプションインスタンスで受信した情報や他のネットワークインターフェイスのDHCPサーバーから受信したオプションとの潜在的な衝突を回避するために、可能な限り長くする必要があります。重複するネットワークが解釈されるため、リゾルバーはネットワークに一致するクエリに任意のRDNSSを使用できます。
If the RDNSS Selection option contains an RDNSS address already learned from other DHCPv4 servers of the same network and contains new domains or networks, the node SHOULD append the information to the information received earlier. The node MUST NOT remove previously obtained information. However, the node SHOULD NOT extend the lifetime of earlier information either. When a conflicting RDNSS address is learned from a less trusted interface, the node MUST ignore the option.
RDNSS選択オプションに同じネットワークの他のDHCPv4サーバーから既に学習されたRDNSSアドレスが含まれ、新しいドメインまたはネットワークが含まれている場合、ノードは以前に受信した情報に情報を追加する必要があります（SHOULD）。ノードは以前に取得した情報を削除してはなりません（MUST NOT）。ただし、ノードは以前の情報の有効期間も延長してはなりません（SHOULD NOT）。信頼性の低いインターフェイスから競合するRDNSSアドレスが学習された場合、ノードはオプションを無視する必要があります。
The client SHALL periodically refresh information learned with the RDNSS Selection option. The information SHALL be refreshed on link-state changes, such as those caused by node mobility, and when extending the lease of IPv4 addresses configured with DHCPv4.
クライアントは、RDNSS選択オプションで学習した情報を定期的に更新する必要があります（SHALL）。情報は、ノードのモビリティによって引き起こされるものなどのリンク状態の変更時、およびDHCPv4で構成されたIPv4アドレスのリースを延長するときに更新される必要があります（SHALL）。
The general size limitations of the DHCP messages limit the number of domains and networks that can be carried inside of these RDNSS selection options. The DHCP options for RDNSS selection are best suited for those deployments where relatively few and carefully selected domains and networks are enough.
DHCPメッセージの一般的なサイズ制限により、これらのRDNSS選択オプション内で伝送できるドメインおよびネットワークの数が制限されます。 RDNSSを選択するためのDHCPオプションは、慎重に選択された比較的少数のドメインとネットワークで十分な展開に最適です。
The RDNSS selection option SHOULD NOT be enabled by default. (In this section, "RDNSS selection option" refers to the DHCPv4 RDNSS Selection option and the DHCPv6 OPTION_RDNSS_SELECTION.) The option can be used in the following environments:
RDNSS選択オプションはデフォルトで有効にすべきではありません（SHOULD NOT）。 （このセクションでは、「RDNSS選択オプション」とは、DHCPv4 RDNSS選択オプションとDHCPv6 OPTION_RDNSS_SELECTIONを指します。）このオプションは、次の環境で使用できます。
1. The RDNSS selection option is delivered across a secure, trusted channel.
1. RDNSS選択オプションは、安全で信頼できるチャネルを介して配信されます。
2. The RDNSS selection option is not secured, but the client on a node does DNSSEC validation.
2. RDNSS選択オプションは保護されていませんが、ノード上のクライアントはDNSSEC検証を行います。
3. The RDNSS selection option is not secured, the resolver does DNSSEC validation, and the client communicates with the resolver configured with the RDNSS selection option over a secure, trusted channel.
3. RDNSS選択オプションは保護されておらず、リゾルバーはDNSSEC検証を実行し、クライアントはRDNSS選択オプションで構成されたリゾルバーと安全な信頼できるチャネルを介して通信します。
4. The IP address of the RDNSS that is being recommended in the RDNSS selection option is known and trusted by the client; that is, the RDNSS selection option serves not to introduce the client to a new RDNSS, but rather to inform it that the RDNSS it has already been configured to trust is available to it for resolving certain domains.
4. RDNSS選択オプションで推奨されているRDNSSのIPアドレスは既知であり、クライアントによって信頼されています。つまり、RDNSS選択オプションは、クライアントに新しいRDNSSを導入するのではなく、信頼するようにすでに構成されているRDNSSが特定のドメインを解決するために使用できることをクライアントに通知します。
As the DHCP by itself cannot tell whether it is using a secure, trusted channel, or whether the client on a node is performing DNSSEC validation, this option cannot be used without being explicitly enabled. The functionality can be enabled for an interface via administrative means, such as by provisioning tools or manual configuration. Furthermore, the functionality can be automatically enabled by a client on a node that knows it is performing DNSSEC validation or by a node that is configured or hard-coded to trust certain interfaces (see Section 8.2).
DHCP自体は、安全で信頼できるチャネルを使用しているかどうか、またはノード上のクライアントがDNSSEC検証を実行しているかどうかを判別できないため、明示的に有効にしない限り、このオプションは使用できません。この機能は、プロビジョニングツールや手動構成などの管理手段を介してインターフェイスに対して有効にできます。さらに、DNSSEC検証を実行していることを知っているノード上のクライアント、または特定のインターフェースを信頼するように構成またはハードコーディングされたノードによって、機能を自動的に有効にすることができます（セクション8.2を参照）。
The DHCPv4 RDNSS Selection option and the DHCPv6 OPTION_RDNSS_SELECTION are designed to coexist with each other and with other tools used for RDNSS address configuration.
DHCPv4 RDNSS選択オプションとDHCPv6 OPTION_RDNSS_SELECTIONは、相互に、およびRDNSSアドレス構成に使用される他のツールと共存するように設計されています。
For RDNSS selection purposes, information received from all tools MUST be combined together into a single list, as discussed in Section 4.1.
セクション4.1で説明したように、RDNSSの選択のために、すべてのツールから受け取った情報を1つのリストにまとめる必要があります。
It can happen that DHCPv4 and DHCPv6 are providing conflicting RDNSS selection information on the same or on equally trusted interfaces. In such a case, DHCPv6 MUST be preferred unless DHCPv4 is utilizing additional security frameworks for protecting the messages.
DHCPv4とDHCPv6が、同じまたは同等に信頼されたインターフェイスで競合するRDNSS選択情報を提供している場合があります。そのような場合、DHCPv4がメッセージを保護するために追加のセキュリティフレームワークを利用していない限り、DHCPv6を優先する必要があります。
The RDNSSes learned via tools other than the DHCPv4 RDNSS Selection option and the DHCPv6 OPTION_RDNSS_SELECTION MUST be handled as default RDNSSes, with medium preference, when building a list of RDNSSes to talk to (see Section 4.1).
DHCPv4 RDNSS選択オプションとDHCPv6 OPTION_RDNSS_SELECTION以外のツールを介して学習したRDNSSは、通信するRDNSSのリストを作成するときに、中程度の優先度でデフォルトのRDNSSとして処理する必要があります（セクション4.1を参照）。
The non-exhaustive list of possible other sources for RDNSS address configuration are:
RDNSSアドレス構成の他の可能なソースの完全なリストは次のとおりです。
(1) DHCPv6 OPTION_DNS_SERVERS defined in [RFC3646].
（1）[RFC3646]で定義されているDHCPv6 OPTION_DNS_SERVERS。
(2) DHCPv4 Domain Server option defined in [RFC2132].
（2）[RFC2132]で定義されているDHCPv4ドメインサーバーオプション。
(3) IPv6 Router Advertisement RDNSS Option defined in [RFC6106].
（3）[RFC6106]で定義されているIPv6ルーターアドバタイズメントRDNSSオプション。
When the RDNSS selection option contains a default RDNSS address and other sources are providing RNDSS addresses, the resolver MUST make the decision about which one to prefer based on the RDNSS preference field value. If the RDNSS selection option defines medium preference, then the RDNSS from the RDNSS selection option SHALL be selected.
RDNSS選択オプションにデフォルトのRDNSSアドレスが含まれていて、他のソースがRNDSSアドレスを提供している場合、リゾルバーはRDNSS設定フィールド値に基づいてどちらを優先するかを決定する必要があります。 RDNSS選択オプションが中程度の優先度を定義している場合、RDNSS選択オプションからのRDNSSを選択する必要があります。
If multiple sources are providing same RDNSS(es) IP address(es), each address MUST be added to the RDNSS list only once.
複数のソースが同じRDNSS IPアドレスを提供している場合、各アドレスはRDNSSリストに1回だけ追加する必要があります。
If a node had indicated support for OPTION_RDNSS_SELECTION in a DHCPv6 request, the DHCPv6 server MAY omit sending of OPTION_DNS_SERVERS. This enables offloading use case where the network administrator wishes to only advertise low preference default RDNSSes.
ノードがDHCPv6要求でOPTION_RDNSS_SELECTIONのサポートを示していた場合、DHCPv6サーバーはOPTION_DNS_SERVERSの送信を省略してもよい（MAY）。これにより、ネットワーク管理者が優先度の低いデフォルトのRDNSSのみをアドバタイズする場合のオフロードの使用例が可能になります。
Any follow-up queries that are performed on the basis of an answer received on an interface MUST continue to use the same interface, irrespective of the RDNSS selection settings on any other interface. For example, if a node receives a reply with a canonical name (CNAME) or delegation name (DNAME), the follow-up queries MUST be sent to RDNSS(es) of the same interface, or to the same RDNSS, irrespectively of the FQDN received. Otherwise, referrals can fail.
インターフェイスで受信した回答に基づいて実行されるフォローアップクエリは、他のインターフェイスのRDNSS選択設定に関係なく、同じインターフェイスを引き続き使用する必要があります。たとえば、ノードが正規名（CNAME）または委任名（DNAME）の応答を受け取った場合、フォローアップクエリは、同じインターフェイスのRDNSS（複数可）、または同じRDNSSに送信する必要があります。受信したFQDN。そうしないと、紹介が失敗する可能性があります。
Cached information related to private namespaces can become obsolete after the network interface over which the information was learned is closed (Section 2.2) or a new parallel network interface is opened that alters RDNSS selection preferences. An implementation SHOULD ensure obsolete information is not retained in these events. One implementation approach to avoid unwanted/obsolete responses from the local cache is to manage per-interface DNS caches or have interface information stored in the DNS cache. An alternative approach is to perform, possibly selective, DNS cache flushing on interface change events.
プライベート名前空間に関連するキャッシュされた情報は、情報が学習されたネットワークインターフェースが閉じられた後（セクション2.2）、またはRDNSS選択設定を変更する新しいパラレルネットワークインターフェースが開かれた後に古くなる可能性があります。実装では、これらのイベントで古い情報が保持されないようにする必要があります。ローカルキャッシュからの不要な/古くなった応答を回避するための1つの実装アプローチは、インターフェイスごとのDNSキャッシュを管理するか、インターフェイス情報をDNSキャッシュに格納することです。代替のアプローチは、インターフェース変更イベントでDNSキャッシュのフラッシュを、場合によっては選択的に実行することです。
Figure 7 illustrates node behavior when it initializes two network interfaces for parallel usage and learns domain and network information from DHCPv6 servers.
図7は、並列使用のために2つのネットワークインターフェイスを初期化し、DHCPv6サーバーからドメインとネットワーク情報を学習するときのノードの動作を示しています。
Application Node DHCPv6 server DHCPv6 server
on interface 1 on interface 2
| | |
| +-----------+ |
(1) | | open | |
| | interface | |
| +-----------+ |
| | |
(2) | |---option REQ-->|
| |<--option RESP--|
| | |
| +-----------+ |
(3) | | store | |
| | domains | |
| +-----------+ |
| | |
| +-----------+ |
(4) | | open | |
| | interface | |
| +-----------+ |
| | | |
(5) | |---option REQ------------------->|
| |<--option RESP-------------------|
| | | |
| +----------+ | |
(6) | | store | | |
| | domains | | |
| +----------+ | |
| | | |
Figure 7: Illustration of Learning Domains
図7：ドメインの学習の図
Flow explanations:
フローの説明：
1. A node opens its first network interface.
1. ノードが最初のネットワークインターフェイスを開きます。
2. The node obtains domain 'domain1.example.com' and IPv6 network '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from the DHCPv6 server.
2. ノードは、DHCPv6サーバーから新しいインターフェース1のドメイン「domain1.example.com」とIPv6ネットワーク「0.8.b.d.0.1.0.0.2.ip6.arpa」を取得します。
3. The node stores the learned domains and IPv6 networks for later use.
3. ノードは学習したドメインとIPv6ネットワークを保存して、後で使用できるようにします。
4. The node opens its second network interface 2.
4. ノードは2番目のネットワークインターフェイスを開きます2。
5. The node obtains domain 'domain2.example.com' and IPv6 network information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 2 from the DHCPv6 server.
5. ノードは、ドメイン「domain2.example.com」とIPv6ネットワーク情報を取得します。たとえば、DHCPv6サーバーから新しいインターフェース2の「1.8.b.d.0.1.0.0.2.ip6.arpa」を取得します。
6. The node stores the learned domains and networks for later use.
6. ノードは学習したドメインとネットワークを保存して、後で使用できるようにします。
Figure 8 illustrates how a resolver uses the learned domain information. Network information use for reverse lookups is not illustrated, but that would be similar to the example in Figure 8.
図8は、リゾルバーが学習したドメイン情報をどのように使用するかを示しています。逆引きに使用するネットワーク情報は示していませんが、図8の例と同様です。
Application Node RDNSS RDNSS
on interface 1 on interface 2
| | | |
(1) |--Name REQ-->| | |
| | | |
| +----------------+ | |
(2) | | RDNSS | | |
| | prioritization | | |
| +----------------+ | |
| | | |
(3) | |------------DNS resolution------>|
| |<--------------------------------|
| | | |
(4) |<--Name resp-| | |
| | | |
Figure 8: Example on Choosing Interface Based on Domain
図8：ドメインに基づくインターフェースの選択の例
Flow explanations:
フローの説明：
1. An application makes a request for resolving an FQDN, e.g., 'private.domain2.example.com'.
1. アプリケーションがFQDNの解決を要求します（例： 'private.domain2.example.com'）。
2. A node creates list of RDNSSes to contact and uses configured RDNSS selection information and stored domain information on prioritization decisions.
2. ノードは、接続するRDNSSのリストを作成し、優先順位付けの決定について、構成済みのRDNSS選択情報と格納されているドメイン情報を使用します。
3. The node has chosen interface 2, as it was learned earlier from DHCPv6 that the interface 2 has domain 'domain2.example.com'. The node then resolves the requested name using interface 2's RDNSS to an IPv6 address.
3. DHCPv6からインターフェース2がドメイン「domain2.example.com」を持っていることが以前に学習されたので、ノードはインターフェース2を選択しました。次に、ノードはインターフェース2のRDNSSを使用して、要求された名前をIPv6アドレスに解決します。
4. The node replies to the application with the resolved IPv6 address.
4. ノードは解決されたIPv6アドレスでアプリケーションに応答します。
Network administrators deploying private namespaces can assist advanced nodes in their RDNSS selection process by providing the information described within this document.
プライベート名前空間を展開するネットワーク管理者は、このドキュメントで説明されている情報を提供することにより、RDNSS選択プロセスで高度なノードを支援できます。
Private namespaces MUST be globally unique in order to keep DNS unambiguous and henceforth avoid caching-related issues and destination selection problems (see Section 2.3). Exceptions to this rule are domains utilized for local name resolution (such as .local).
プライベート名前空間は、DNSを明確に保つためにグローバルに一意である必要があり、今後キャッシュ関連の問題と宛先選択の問題を回避する必要があります（セクション2.3を参照）。このルールの例外は、ローカルの名前解決に使用されるドメイン（.localなど）です。
Private namespaces MUST only consist of subdomains of domains for which the relevant operator provides authoritative name service. Thus, subdomains of example.com are permitted in the private namespace served by an operator's RDNSSes only if the same operator provides a SOA record for example.com.
プライベート名前空間は、関連するオペレーターが信頼できるネームサービスを提供するドメインのサブドメインのみで構成する必要があります。したがって、example.comのサブドメインは、同じオペレーターがexample.comのSOAレコードを提供する場合にのみ、オペレーターのRDNSSによって提供されるプライベート名前空間で許可されます。
It is RECOMMENDED for administrators utilizing this tool to deploy DNSSEC for their zone in order to counter attacks against private namespaces.
プライベート名前空間に対する攻撃に対抗するために、このツールを使用してゾーンにDNSSECを展開する管理者に推奨されます。
Per this memo, IANA has assigned two new option codes.
このメモに従って、IANAは2つの新しいオプションコードを割り当てました。
The first option code has been assigned for the DHCPv4 RDNSS Selection option (146) from the "BOOTP Vendor Extensions and DHCP Options" registry in the group "Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters".
最初のオプションコードは、「動的ホスト構成プロトコル（DHCP）およびブートストラッププロトコル（BOOTP）パラメータ」グループの「BOOTPベンダー拡張およびDHCPオプション」レジストリからDHCPv4 RDNSS選択オプション（146）に割り当てられています。
The second option code is requested to be assigned for the DHCPv6 OPTION_RDNSS_SELECTION (74) from the "DHCP Option Codes" registry in the group "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".
2番目のオプションコードは、グループ「Dynamic Host Configuration Protocol for IPv6（DHCPv6）」の「DHCP Option Codes」レジストリからDHCPv6 OPTION_RDNSS_SELECTION（74）に割り当てるように要求されます。
It is possible that attackers might try to utilize the DHCPv4 RDNSS Selection option or the DHCPv6 OPTION_RDNSS_SELECTION option to redirect some or all DNS queries sent by a resolver to undesired destinations. The purpose of an attack might be denial of service, preparation for man-in-the-middle attack, or something akin.
攻撃者がDHCPv4 RDNSS選択オプションまたはDHCPv6 OPTION_RDNSS_SELECTIONオプションを利用して、リゾルバーから送信された一部またはすべてのDNSクエリを望ましくない宛先にリダイレクトしようとする可能性があります。攻撃の目的は、サービス拒否、中間者攻撃の準備、または類似したものである可能性があります。
Attackers might try to lure specific traffic by advertising domains and networks from very small to very large scope or simply by trying to place the attacker's RDNSS as the highest preference default RDNSS.
攻撃者は、ドメインとネットワークを非常に小さい範囲から非常に大きい範囲にアドバタイズすることによって、または単に攻撃者のRDNSSを最も高い優先度のデフォルトRDNSSとして配置することによって、特定のトラフィックを誘導しようとする可能性があります。
The best countermeasure for nodes is to implement validating DNSSEC-aware resolvers. Trusting validation done by an RDNSS is a possibility only if a node trusts the RDNSS and can use a secure channel for DNS messages.
ノードの最良の対策は、検証DNSSEC対応リゾルバーを実装することです。 RDNSSによって行われる信頼検証は、ノードがRDNSSを信頼し、DNSメッセージに安全なチャネルを使用できる場合にのみ可能です。
Trustworthiness of an interface and configuration information received over the interface is implementation and/or node deployment dependent, and the details of determining that trust are beyond the scope of this specification. Trust might, for example, be based on the nature of the interface: an authenticated and encrypted VPN, or a layer 2 connection to a trusted home network or to a trusted cellular network, might be considered trusted, while an unauthenticated and unencrypted connection to an unknown visited network would likely be considered untrusted.
インターフェイスの信頼性とインターフェイスを介して受信した構成情報は、実装やノードの展開に依存します。信頼性を判断する詳細は、この仕様の範囲外です。信頼は、たとえば、インターフェイスの性質に基づいている場合があります。認証および暗号化されたVPN、または信頼されたホームネットワークまたは信頼されたセルラーネットワークへのレイヤー2接続は、信頼されていると見なされ、認証されていない暗号化されていない接続は未知の訪問ネットワークはおそらく信頼できないと考えられます。
In many cases, an implementation might not be able to determine trust levels without explicit configuration provided by the user or the node's administrator. Therefore, for example, an implementation might not by default trust configuration received even over VPN interfaces. In some occasions, standards defining organizations that are specific to access network technology might be able to define trust levels as part of the system design work.
多くの場合、実装では、ユーザーまたはノードの管理者から提供された明示的な構成なしに信頼レベルを決定できない場合があります。したがって、たとえば、VPNインターフェイスを介して受信した場合でも、実装はデフォルトで信頼設定を受信しない場合があります。場合によっては、アクセスネットワークテクノロジに固有の組織を定義する標準が、システム設計作業の一部として信頼レベルを定義できる場合があります。
Section 4 uses normative language for describing a node's internal behavior in order to ensure that nodes will not open up new attack vectors by accidental use of RDNSS selection options. During the standards work, consensus was that it is safer to not always enable this option by default, but only when deemed useful and safe.
セクション4では、ノードがRDNSS選択オプションを誤って使用して新しい攻撃ベクトルを開かないようにするために、ノードの内部動作を説明するために規範的な言語を使用しています。標準化作業の間、コンセンサスは、デフォルトでこのオプションを常に有効にするのではなく、有用で安全であると考えられる場合にのみ安全であるということでした。
[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月。
[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月。
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2317] Eidnes、H.、de Groot、G。、およびP. Vixie、「Classless IN-ADDR.ARPA delegation」、BCP 20、RFC 2317、1998年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[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、「Encoding Long Options in the Dynamic Host Configuration Protocol（DHCPv4）」、RFC 3396、2002年11月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V.、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、2003年10月。
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4242] Venaas、S.、Chown、T。、およびB. Volz、「IPv6の動的ホスト構成プロトコルの情報更新時間オプション（DHCPv6）」、RFC 4242、2005年11月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397] Aboba、B。およびS. Cheshire、「Dynamic Host Configuration Protocol（DHCP）Domain Search Option」、RFC 3397、2002年11月。
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC3442]レモン、T。、チェシャー、S。、およびB.ヴォルツ、「動的ホスト構成プロトコル（DHCP）バージョン4のクラスレス静的ルートオプション」、RFC 3442、2002年12月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R。、「IPv6の動的ホスト構成プロトコル（DHCPv6）のDNS構成オプション」、RFC 3646、2003年12月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、2005年11月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 6106、2010年11月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to IPv4 Servers」、RFC 6147、2011年4月。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418] Blanchet、M。およびP. Seite、「Multiple Interfaces and Provisioning Domains Problem Statement」、RFC 6418、2011年11月。
[WITHOUT-IPV6NAT] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, February 2012.
[WITHOUT-IPV6NAT] Troan、O.、Miles、D.、Matsushima、S.、Okimoto、T。、およびD. Wing、「ネットワークアドレス変換なしのIPv6マルチホーミング」、作業中、2012年2月。
On some private namespace deployments, explicit policies for RDNSS selection are not available. This section describes ways for nodes to mitigate the problem by sending wide-spread queries and by utilizing possibly existing indirect information elements as hints.
一部のプライベート名前空間の展開では、RDNSS選択の明示的なポリシーを使用できません。このセクションでは、ノードが広範囲にわたるクエリを送信し、ヒントとして既存の間接情報要素を利用することによって問題を軽減する方法について説明します。
A possible current practice is to send DNS queries out of multiple interfaces and pick up the best out of the received responses. A node can implement DNSSEC in order to be able to reject responses that cannot be validated. Selection between legitimate answers is implementation specific, but replies from trusted RDNSSes are preferred.
現在可能なプラクティスは、複数のインターフェースからDNSクエリを送信し、受信した応答から最良のものを取得することです。ノードはDNSSECを実装して、検証できない応答を拒否できるようにすることができます。正当な回答からの選択は実装固有ですが、信頼できるRDNSSからの応答が優先されます。
A downside of this approach is increased consumption of resources, namely, power consumption if an interface, e.g., wireless, has to be brought up just for the DNS query that could have been resolved via a cheaper interface. Also, load on RDNSSes is increased. However, local caching of results mitigates these problems, and a node might also learn interfaces that seem to be able to provide 'better' responses than others and prefer those, without forgetting that fallback is required for cases when the node is connected to more than one network using private namespaces.
このアプローチの欠点は、リソースの消費量の増加です。つまり、ワイヤレスなどのインターフェースを、より安価なインターフェースを介して解決できるDNSクエリのためだけに起動する必要がある場合の電力消費です。また、RDNSSの負荷が増加します。ただし、結果のローカルキャッシュはこれらの問題を軽減し、ノードは他よりも「より良い」応答を提供できると思われるインターフェイスを学習し、ノードがより多くに接続されている場合にフォールバックが必要であることを忘れずにそれらを優先する可能性があります。プライベート名前空間を使用する1つのネットワーク。
A node can learn the special domains of attached network interfaces from IPv6 Router Advertisement DNS Search List Option [RFC6106] or DHCP search list options -- DHCPv4 Domain Search Option number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. The node behavior is very similar to that illustrated in the example in Section 5. While these options are not intended to be used in RDNSS selection, they can be used by the nodes as hints for smarter RDNSS prioritization purposes in order to increase likelihood of fast and successful DNS queries.
ノードは、IPv6ルーターアドバタイズメントDNS検索リストオプション[RFC6106]またはDHCP検索リストオプション-DHCPv4ドメイン検索オプション番号119 [RFC3397]およびDHCPv6ドメイン検索リストオプション番号24 [RFC3646]から、接続されたネットワークインターフェイスの特別なドメインを学習できます。ノードの動作は、セクション5の例に示されている動作と非常に似ています。これらのオプションはRDNSSの選択で使用することを意図していませんが、高速の可能性を高めるために、よりスマートなRDNSS優先順位付けのヒントとしてノードで使用できます。そして成功したDNSクエリ。
Overloading of existing DNS search list options is not without problems: resolvers would obviously use the domains learned from search lists for name resolution purposes. This might not be a problem in deployments where DNS search list options contain few domains like 'example.com, private.example.com' but can become a problem if many domains are configured.
既存のDNS検索リストオプションのオーバーロードに問題がないわけではありません。リゾルバーは、名前解決の目的で検索リストから学習したドメインを使用することは明らかです。これは、DNS検索リストオプションに 'example.com、private.example.com'のような少数のドメインが含まれている展開では問題にならない場合がありますが、多くのドメインが構成されている場合は問題になる可能性があります。
[RFC4191] defines how more-specific routes can be provisioned for nodes. This information is not intended to be used in RDNSS selection, but nevertheless, a node can use this information as a hint about which interface would be best to try first for reverse lookup procedures. An RDNSS configured via the same interface as more-specific routes is more likely capable to answer reverse lookup questions correctly than an RDNSS of another interface. The likelihood of success is possibly higher if an RDNSS address is received in the same RA [RFC6106] as the more-specific route information.
[RFC4191]は、より具体的なルートをノードにプロビジョニングする方法を定義しています。この情報はRDNSSの選択で使用するためのものではありませんが、ノードはこの情報を使用して、逆引き参照手順で最初に試行するのに最適なインターフェイスに関するヒントを得ることができます。より具体的なルートと同じインターフェイスを介して構成されたRDNSSは、別のインターフェイスのRDNSSよりも逆引きの質問に正しく回答できる可能性が高くなります。 RDNSSアドレスがより具体的なルート情報と同じRA [RFC6106]で受信された場合、成功の可能性はおそらく高くなります。
A node can utilize the longest matching prefix approach when deciding which RDNSS to contact for reverse lookup purposes. Namely, the node can send a DNS query to an RDNSS learned over an interface having a longest matching prefix to the address being queried. This approach can help in cases where Unique Local Addressing (ULA) [RFC4193] addresses are used and when the queried address belongs to a node or server within the same network (for example, intranet).
ノードは、逆ルックアップの目的で接続するRDNSSを決定するときに、最長一致プレフィックスアプローチを利用できます。すなわち、ノードはDNSクエリを、照会されているアドレスに一致する最長のプレフィックスを持つインターフェイスを介して学習されたRDNSSに送信できます。このアプローチは、Unique Local Addressing（ULA）[RFC4193]アドレスが使用されている場合、および照会されたアドレスが同じネットワーク（イントラネットなど）内のノードまたはサーバーに属している場合に役立ちます。
Appendix B. DNSSEC and Multiple Answers Validating with Different Trust Anchors
付録B.異なるトラストアンカーで検証するDNSSECおよび複数の回答
When validating DNS answers with DNSSEC, a validator might order the list of trust anchors it uses to start validation chains, in the order of the node's preferences for those trust anchors. A node could use this ability in order to select among alternative DNS results from different interfaces. Suppose that a node has a trust anchor for the public DNS root and also has a special-purpose trust anchor for example.com. An answer is received on interface i1 for www.example.com, and the validation for that succeeds by using the public trust anchor. Also, an answer is received on interface i2 for www.example.com, and the validation for that succeeds by using the trust anchor for example.com. In this case, the node has evidence for relying on i2 for answers in the example.com zone.
DNSSECを使用してDNS応答を検証する場合、検証ツールは、検証チェーンを開始するために使用するトラストアンカーのリストを、それらのトラストアンカーに対するノードの優先順位の順に並べます。ノードはこの機能を使用して、異なるインターフェースからの代替DNS結果の中から選択できます。ノードにパブリックDNSルートのトラストアンカーがあり、example.comなどの専用トラストアンカーもあるとします。 www.example.comのインターフェイスi1で回答が受信され、パブリックトラストアンカーを使用してその検証が成功します。また、www.example.comのインターフェースi2で応答が受信され、example.comのトラストアンカーを使用してその検証が成功します。この場合、ノードには、example.comゾーンの回答をi2に依存する証拠があります。
This section illustrates the RDNSS selection logic in C-style pseudocode. The code is not intended to be usable as such; it is only here for illustration purposes.
このセクションでは、Cスタイルの疑似コードでのRDNSS選択ロジックを示します。コードはそのように使用できるようには意図されていません。説明のためにのみここにあります。
The beginning of the whole procedure is a call to "dns_query" function with a query and list of RDNSSes given as parameters.
手順全体の最初は、クエリとパラメータとして指定されたRDNSSのリストを使用した「dns_query」関数の呼び出しです。
/* This is a structure that holds all information related to an RDNSS.*/
/* Here we include only the information related for this illustration.*/
struct rdnss
{
int prf; /* Preference of an RDNSS. */
int interface; /* Type of an interface RDNSS was learned over. */
struct d_and_n; /* Domains and networks information for this RDNSS. */
};
int has_special_knowledge( const struct rdnss *rdnss,
const char *query)
{
/* This function matches the query to the domains and networks
information of the given RDNSS. The function returns TRUE
if the query matches the domains and networks; otherwise, FALSE. */
/* The implementation of this matching function
is left for reader, or rather writer. */
/* return TRUE if query matches rdnss->d_and_n, otherwise FALSE. */
}
const struct rdnss* compare_rdnss_prf( const struct rdnss *rdnss_1,
const struct rdnss *rdnss_2 )
{
/* This function compares preference values of two RDNSSes and
returns the more preferred RDNSS. The function prefers rdnss_1
in the case of equal preference values. */
if (rdnss_1->prf == HIGH_PRF) return rdnss_1;
if (rdnss_2->prf == HIGH_PRF) return rdnss_2;
if (rdnss_1->prf == MED_PRF) return rdnss_1;
if (rdnss_2->prf == MED_PRF) return rdnss_2;
return rdnss_1;
}
const struct rdnss* compare_rdnss_trust( const struct rdnss *rdnss_1,
const struct rdnss *rdnss_2 )
{
/* This function compares trust of the two given RDNSSes. The trust
is based on the trust on the interface RDNSS was learned on. */
/* If the interface is the same, the trust is also the same,
and hence, function will return NULL to indicate lack of
difference in trust. */
if (rdnss_1->interface == rdnss_2->interface) return NULL;
/* Otherwise, implementation-specific rules define which interface
is considered more secure than the other. The rules shown here
are only for illustrative purposes and must be overwritten by
real implementations. */
if (rdnss_1->interface == IF_VPN) return rdnss_1;
if (rdnss_2->interface == IF_VPN) return rdnss_2;
if (rdnss_1->interface == IF_CELLULAR) return rdnss_1;
if (rdnss_2->interface == IF_CELLULAR) return rdnss_2;
if (rdnss_1->interface == IF_WLAN) return rdnss_1;
if (rdnss_2->interface == IF_WLAN) return rdnss_2;
/* Both RDNSSes are from unknown interfaces, so return NULL as
trust-based comparison is impossible. */
return NULL;
}
int compare_rdnsses ( const struct rdnss *rdnss_1,
const struct rdnss *rdnss_2,
const char *query)
{
/* This function compares two RDNSSes and decides which one is more
preferred for resolving the query. If the rdnss_1 is more
preferred, the function returns TRUE; otherwise, FALSE. */
const struct rdnss *more_trusted_rdnss = NULL;
const struct rdnss *less_trusted_rdnss = NULL;
/* Find out if either RDNSS is more trusted. */
more_trusted_rdnss = compare_rdnss_trust( rdnss_1, rdnss_2 );
/* Check if either was more trusted. */
if (more_trusted_rdnss)
{
/* Check which RDNSS was less trusted. */
less_trusted_rdnss =
more_trusted_rdnss == rdnss_1 ? rdnss_2 : rdnss_1;
/* If the more trusted interface is not of low preference
or has special knowledge about the query, or the more
trusted is more preferred and the less trusted has no special
information, prefer more trusted. Otherwise, prefer less trusted. */
if (more_trusted_rdnss->prf != LOW_PRF ||
has_special_knowledge( more_trusted_rdnss, query ) ||
(compare_rdnss_prf( more_trusted_rdnss, less_trusted_rdnss)
== more_trusted_rdnss &&
!has_special_knowledge( less_trusted_rdnss, query)))
{
/* If the more_trusted_rdnss was rdnss_1, return TRUE. */
return more_trusted_rdnss == rdnss_1 ? TRUE : FALSE;
}
else
{
/* If the more_trusted_rdnss was rdnss_1, return TRUE. */
return less_trusted_rdnss == rdnss_1 ? TRUE : FALSE;
}
}
else
{
/* There is no trust difference between RDNSSes; therefore, prefer the
RDNSS that has special knowledge. If both have specific knowledge,
then prefer the rdnss_1. */
if (has_special_knowledge( rdnss_1, query )) return TRUE;
if (has_special_knowledge( rdnss_2, query )) return FALSE;
/* Neither had special knowledge. Therefore, return TRUE if
rdnss_1 is more preferred; otherwise, return FALSE */
return compare_rdnss_prf( rdnss_1 , rdnss_2 )
== rdnss_1 ? TRUE : FALSE;
}
}
void bubble_sort_rdnsses( struct rdnss rdnss_list[],
const int rdnsses,
const char* query)
{
/* This function implements a bubble sort to arrange
RDNSSes in rdnss_list into preference order. */
int i;
int swapped = 0;
struct rdnss rdnss_swap;
do
{
/* Clear swapped-indicator. */
swapped = FALSE;
/* Go through the RDNSS list. */
for (i = 0; i < rdnsses-1; i++)
{
/* Check if the next two items are in the right order, i.e.,
more preferred before less preferred. */
if (compare_rdnsses( &rdnss_list[i],
&rdnss_list[i+1], query) == FALSE)
{
/* The order between two was not right, so swap these two RDNSSes. */
rdnss_swap = rdnss_list[i];
rdnss_list[i] = rdnss_list[i+1];
rdnss_list[i+1] = rdnss_swap;
swapped = TRUE;
}
}
} while (swapped);
/* No more swaps, which means the rdnss_list is now sorted
into preference order. */
}
struct hostent *dns_query( struct rdnss rdnss_list[],
const int rdnsses,
const char* query )
{
/* Perform address resolution for the query. */
int i;
struct hostent response;
/* Sort the RDNSSes into preference order. */
/* This is the function with which this pseudocode starts. */
bubble_sort_rdnsses( &rdnss_list[0], rdnsses, query );
/* Go thourgh all RDNSSes or until valid response is found. */
for (i = 0; i < rdnsses; i++)
{
/* Use the highest preference RDNSS first. */
response = send_and_validate_dns_query( rndss_list[i], query);
/* Check if DNSSEC validation is in use, and if so, validate the
received response. */
if (dnssec_in_use)
{
response = dnssec_validate(response);
/* If response is validated, use that. Otherwise, proceed to next
RDNSS. */
if (response) return response;
else continue;
}
/* If acceptable response has been found, return it. */
if (response) return response;
}
return NULL;
}
The authors would like to thank the following people for their valuable feedback and improvement ideas: Mark Andrews, Jari Arkko, Marcelo Bagnulo, Brian Carpenter, Stuart Cheshire, Lars Eggert, Stephan Farrell, Tomohiro Fujisaki, Brian Haberman, Peter Koch, Suresh Krishnan, Murray Kucherawy, Barry Leiba, Edward Lewis, Kurtis Lindqvist, Arifumi Matsumoto, Erik Nordmark, Steve Padgett, Fabien Rapin, Matthew Ryan, Robert Sparks, Dave Thaler, Sean Turner, Margaret Wasserman, Dan Wing, and Dec Wojciech. Ted Lemon and Julien Laganier receive special thanks for their contributions to security considerations.
著者は、貴重なフィードバックと改善のアイデアを提供してくれた次の人々に感謝したいと思います：マークアンドリュース、ヤリアルコ、マルセロバニュロ、ブライアンカーペンター、スチュアートチェシャー、ラースエガート、ステファンファレル、藤崎トモヒロ、ブライアンハーバーマン、ピーターコッホ、スレッシュクリシュナン、マレー・クチェラウィ、バリー・レイバ、エドワード・ルイス、クルティス・リンドクビスト、松本有史、エリック・ノードマーク、スティーブ・パジェット、ファビアン・ラピン、マシュー・ライアン、ロバート・スパークス、デイブ・ターラー、ショーン・ターナー、マーガレット・ワッサーマン、ダン・ウィング、そしてデック・ウォイチェッチ。 Ted Lemon氏とJulien Laganier氏は、セキュリティへの配慮への貢献に対して特別な感謝の意を表します。
Authors' Addresses
著者のアドレス
Teemu Savolainen Nokia Hermiankatu 12 D Tampere FI-33720 Finland
Teemu Savolainen Nokia Hermiankatu 12 DタンペレFI-33720フィンランド
EMail: teemu.savolainen@nokia.com
Jun-ya Kato NTT 9-11, Midori-Cho 3-Chome Musashino-Shi Tokyo 180-8585 Japan
じゅんーや かと んっｔ ９ー１１、 みどりーちょ ３ーちょめ むさしのーし ときょ １８０ー８５８５ じゃぱん
EMail: kato@syce.net
Ted Lemon Nominum, Inc. 2000 Seaport Boulevard Redwood City, CA 94063 USA
Ted Lemon Nominum、Inc. 2000 Seaport Boulevard Redwood City、CA 94063 USA
Phone: +1 650 381 6000
EMail: Ted.Lemon@nominum.com