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
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服务器。本文档描述了DHCPv4和DHCPv6选项，这些选项可用于配置节点，并提供执行知情递归DNS服务器选择决策所需的信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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的答案一样有用。当节点的私有名称空间可见时，某些RDN具有其他RDN不具有的信息。节点应该能够查询能够解析查询的RDNS，而不管答案是来自公共DNS还是私有名称空间。
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浏览器，它通常访问多个不同的目的地，每个目的地仅在一个网络上可用。因此，浏览器需要能够通过不同的网络接口进行通信，这取决于它试图到达的目的地。
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,
附录A描述了本文档之前的工具可能采用的最佳当前实践，以及在不支持本文档中所述解决方案的网络上可能采用的最佳实践。附录B讨论了一种可能验证多个答案的情况，
but with different trust anchors. Appendix C illustrates with pseudocode the functionality described in Section 4.
但是有不同的信任锚。附录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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.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.
多接口节点可以连接到使用专用名称空间的一个或多个网络。例如，节点可以同时打开到公共因特网的无线LAN（WLAN）连接、到运营商网络的蜂窝连接以及到企业网络的虚拟专用网络（VPN）连接。当应用程序启动与完全限定域名（FQDN）的连接建立时，节点需要能够选择正确的RDN以进行成功的DNS查询。这如图1所示。公用名称的FQDN可以使用任何RDN解析，但对于企业或运营商服务的专用名称的FQDN，节点需要能够正确选择用于DNS解析的正确RDN，即，在已知目标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 | |
+---------------+
+---------------+
| 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.
在第二个问题中，FQDN是有效的，可以通过不同的网络接口解析，但是可以解析到不同的IP地址，不一定是全局可访问的IP地址，如图2所示。节点的路由、源和目标地址选择机制必须确保目标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
+--------------------+ |
+--------------------| |
+------+ 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地址通过RDNSSA和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 |
+-------------------+ +-------+
+-------------------| +-------+
+------+ 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:AAAA合成网络接口特定IPv6地址的结果
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，它除了可能解析为网络接口特定的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.
本文档在编写时考虑了三种特定的部署场景。第一种是具有两个或更多上行链路虚拟局域网（VLAN）连接的客户场所设备（CPE）。第二个场景涉及一个具有两个上行互联网连接的蜂窝设备：WLAN和蜂窝。第三种情况是VPN，出于延迟原因，可能首选使用本地RDNS，但必须使用企业的RDNS来解析企业使用的私有名称。
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节中定义的RDNSPreference值。这样做的目的是说明管理员何时可以选择使用不同的首选项值。
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.
家庭网关可以有两个通向不同网络的上行链路连接，如[With-IPV6NAT]中所述。在两个上行链路场景中，只有一个上行链路连接通向Internet，而另一个上行链路连接通向使用专用名称空间的专用网络。
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只需要向通向因特网的接口的rdns发送默认查询，并向专用网络的rdns发送与专用名称空间相关的查询。这可以通过将专用网络的RDNS设置为了解列出的域和网络，而不是默认RDNS来配置。
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的RDN的正确RDN通信。是否将更新的主机指向DNS代理或实际的RDNSE是部署决策。
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
蜂窝设备可以同时具有WLAN和蜂窝网络接口。在这种情况下，通常希望在默认情况下使用WLAN，除了蜂窝网络运营商希望通过蜂窝接口进行的连接之外。使用WLAN进行DNS查询
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.
可能会提高蜂窝设备的功耗，并通常提供较低的延迟。蜂窝网络可以利用私有名称；因此，蜂窝设备需要通过蜂窝接口请求这些请求。这可以通过将蜂窝网络的rdns设置为低优先级，并将与蜂窝网络的私有名称空间相关的域和网络列为通过蜂窝网络的rdns可用来配置。这将导致节点在默认情况下向WLAN接口的RDNS发送DNS查询（即，在默认情况下，被视为中等首选），并向蜂窝接口的RDNS发送与私有名称空间相关的查询。
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发送到企业的RDNS，而默认情况下，本地接入网络的RDNS可能用于所有其他流量。这可以通过将VPN接口的RDNS设置为低优先级，并列出与企业网络私有名称空间相关的域和网络，这些域和网络可通过VPN接口的RDNS使用。这将导致节点在默认情况下直接向WLAN接口的RDNS发送DNS查询（即，在默认情况下，视为中等首选），并将与私有名称空间相关的查询发送到VPN接口的RDNS。
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.
在这三种情况下，一个或多个连接的网络可以同时支持IPv4和IPv6。在这种情况下，可以使用DHCPv4和DHCPv6两者或其中一者来学习RDNS选择信息。
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选项和（存根/代理）解析器在面对专用名称空间和多个同时活动的网络接口时可用于改进RDNS选择的过程。本程序受第4.5节所述的使用限制。附录C中的伪代码说明了改进的RDNS选择是如何工作的。
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的首选项列表。为了以最佳方式构建列表，在需要进行任何DNS查询之前，节点应使用第4.2节和第4.3节中定义的DHCP选项请求RDNS选择信息。借助于接收到的rdns选择信息，节点可以确定任何可用rdns是否具有关于前向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).
缺少更具体信息的解析器可以假设所有信息都可以从任何网络接口的任何RDN获得。通过其他RDNSS地址配置方法学习的RDNSE可被视为默认RDNSE，但就偏好而言，它们必须作为中等偏好RDNSE处理（另请参见第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查询时，解析程序必须为明确已知的RDNSE提供最高优先级，以服务于匹配的域或网络。解析程序必须考虑到接收到的RDNS选择信息的信任级别差异（参见第8.2节）。解析程序必须首选受信任接口的RDNSE。只有当受信任接口专门配置了低优先权RDNSE时，非受信任接口的RDNSE才能具有最高优先权。图4中的非详尽案例列表说明了接收到的RDNS选择信息的不同信任级别如何影响RDNS选择逻辑。在图4中，“中”、“高”和“低”表示显式配置的RDN优先于其他RDN。“中等”首选项也用于没有明确首选项配置信息的RDNSE。图4中的“特定域”表示特定RDNS具有的显式配置的“域和网络”私有名称空间信息。
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选项首选项字段的帮助下，在同等受信任的RDN之间确定优先级。冲突解决程序不得将不受信任的RDNs的优先级高于受信任的RDNs，即使在不受信任的RDNs显然具有附加信息的情况下也是如此。在所有其他条件相同的情况下，冲突解决程序可以根据其内部偏好做出优先级决策。
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
--------------------------+------------------------+-----------------
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：不同信任级别情况下的RDNS选择
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下是否有效。第一个是执行DNSSEC验证本身。第二种方法是与经过身份验证的RDNS建立安全连接，并依靠该RDNS执行DNSSEC验证（使用AD位发出已完成验证的信号）。DNSSEC是检测伪造响应所必需的，没有它，任何DNS响应都可能被伪造或更改。除非DNS响应已通过DNSSEC验证，否则节点无法做出选择来自任何接口的数据的决定。
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
节点应按照首选项列表定义的顺序向RDNSE发送请求，直到收到可接受的回复、收到所有回复或出现超时。如果请求的名称与从任何接口接受的特定域或网络规则相匹配，DNSSEC感知解析程序不得继续进行无法使用DNSSEC验证的回复，直到已联系首选项列表上的所有RDNS或超时。这可以防止可能的重定向攻击。在请求的名称与任何特定域或网络不匹配的情况下，可以认为从任何RDN接收到的第一个响应是可接受的。DNSSEC感知节点可能始终联系所有RDNSE，以尝试接收可验证的响应，但联系所有RDNSE则不是
mandated for the default case as that would consume excess resources in some deployments.
强制用于默认情况，因为这将在某些部署中消耗多余的资源。
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).
如果从能够为查询名称提供答案的RDNS接收到经过验证的NXDOMAIN响应，则节点不得接受来自其他RDNS的未经验证的响应（有关多个信任锚点的注意事项，请参见附录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查找过程时可以联系哪些RDNS。此选项与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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
选项代码：选项选择（74）
option-len: Length of the option in octets
选项len：选项的长度（以八位字节为单位）
DNS-recursive-name-server: An IPv6 address of RDNSS
DNS递归名称服务器：RDNS的IPv6地址
Reserved: Field reserved for the future. MUST be set to zero and MUST be ignored on receipt.
保留：为将来保留的字段。必须设置为零，并且在收到时必须忽略。
prf: RDNSS preference:
prf:RDNS首选项：
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）。收到时，保留值必须视为中等首选项（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].
域和网络：用于正向DNS查找的域和用于反向DNS查找的网络的列表，RDNS对此有专门知识。字段必须按照[RFC3315]第8节的规定进行编码。“.”的特殊域用于表示解析全局名称和充当默认RDNS的能力。列表中缺少“.”域表示RDNS仅包含与列出的域和网络相关的信息。反向映射网络按照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.
节点应在DHCPv6请求中包含选项请求选项（选项ORO[RFC3315]），并带有选项RDNSS选择选项代码，以通知DHCPv6服务器对改进的RDNSS选择逻辑的支持。然后，接收此信息的DHCPv6服务器可以选择仅使用选项_rdss_选择来提供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.
选项_rdss_选择包含一个或多个相关rdss具有特定知识的域。如果要配置多个RDNSE，则该选项可以在单个DHCPv6消息中多次出现。例如，如果出于可靠性目的，网络链路具有多个RDNSE，则可能出现这种情况。
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服务器接收的选项发生潜在冲突。对重叠网络进行解释，以便解析器可以使用任何RDNSE进行与网络匹配的查询。
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
如果选项_rdss_选择包含已从同一网络的其他DHCPv6服务器学习到的rdss地址，并且包含新的域或网络，则节点应将该信息附加到先前接收到的信息中。以前不能删除该节点
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.
获得的信息。但是，节点也不应延长早期信息的生存期。当从信任度较低的接口获取冲突的RDNS地址时，节点必须忽略该选项。
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选项一样，选项RDNSS选项不得出现在除以下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.
客户应定期更新通过选项选择了解到的信息。当链路状态发生变化时（如节点移动性引起的变化），以及当更新配置了DHCPv6的IPv6地址的生存期时，应刷新信息。此外，[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查找过程时可以联系哪些RDN。此选项与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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
选项代码：RDNSselection（146）
option-len: Length of the option in octets
选项len：选项的长度（以八位字节为单位）
Reserved: Field reserved for the future. MUST be set to zero and MUST be ignored on receipt.
保留：为将来保留的字段。必须设置为零，并且在收到时必须忽略。
prf: RDNSS preference:
prf:RDNS首选项：
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）。收到时，保留值必须视为中等首选项（00）。
Primary DNS-recursive-name-server's IPv4 address: Address of a primary RDNSS
主DNS递归名称服务器的IPv4地址：主RDNS的地址
Secondary DNS-recursive-name-server's IPv4 address: Address of a secondary RDNSS or 0.0.0.0 if not configured
辅助DNS递归名称服务器的IPv4地址：辅助RDNS或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].
域和网络：用于正向DNS查找的域和用于反向DNS查找的网络的列表，RDNSs对此有专门知识。字段必须按照[RFC3315]第8节的规定进行编码。“.”的特殊域用于表示解析全局名称并充当默认RDN的能力。列表中缺少“.”域表示RDNSE仅包含与列出的域和网络相关的信息。反向映射网络按照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.
RDNSselection选项包含一个或多个主要和次要RDNSS具有特定知识的域。如果域和网络字段的长度导致选项长度超过单个选项（255个八位字节）允许的最大值，则可以使用多个选项，如“动态主机配置协议（DHCPv4）中的编码长选项”所述[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服务器接收的选项发生潜在冲突。对重叠网络进行解释，以便解析器可以使用任何RDNSE进行与网络匹配的查询。
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地址，并且包含新的域或网络，则节点应将该信息附加到先前接收到的信息中。节点不得删除以前获得的信息。但是，节点也不应延长早期信息的生存期。当从信任度较低的接口获取冲突的RDNS地址时，节点必须忽略该选项。
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.
客户应定期刷新通过RDNS选择选项了解到的信息。当链路状态发生变化时（如节点移动性引起的变化），以及在延长使用DHCPv4配置的IPv4地址租约时，应刷新信息。
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消息的一般大小限制限制了这些RDNS选择选项中可以承载的域和网络的数量。用于RDNS选择的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:
默认情况下不应启用RDNS选择选项。（在本节中，“RDNSselection option”指的是DHCPv4 RDNSselection option和DHCPv6 option_rdnsu 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. 在RDNS选择选项中推荐的RDNS的IP地址是已知的，并且受客户端信任；也就是说，RDNSselection选项的作用不是将客户机引入新的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 RDNSSELECTION选项和DHCPv6选项RDNSSELECTION旨在彼此共存，并与用于RDNSAddress配置的其他工具共存。
For RDNSS selection purposes, information received from all tools MUST be combined together into a single list, as discussed in Section 4.1.
出于RDNS选择目的，从所有工具收到的信息必须合并到一个列表中，如第4.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可能在相同或同等受信任的接口上提供冲突的RDNS选择信息。在这种情况下，除非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).
在构建要对话的RDNs列表时，通过DHCPv4 RDNs选择选项和DHCPv6选项RDNs选择以外的工具学习的RDNs必须作为默认RDNs处理，具有中等优先权（参见第4.1节）。
The non-exhaustive list of possible other sources for RDNSS address configuration are:
RDNS地址配置可能的其他源的非详尽列表包括：
(1) DHCPv6 OPTION_DNS_SERVERS defined in [RFC3646].
(1) [RFC3646]中定义的DHCPv6选项\u DNS\u服务器。
(2) DHCPv4 Domain Server option defined in [RFC2132].
(2) [RFC2132]中定义的DHCPv4域服务器选项。
(3) IPv6 Router Advertisement RDNSS Option defined in [RFC6106].
(3) [RFC6106]中定义的IPv6路由器播发RDNS选项。
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首选项字段值决定首选哪一个。如果RDNS选择选项定义了介质首选项，则应从RDNS选择选项中选择RDNS。
If multiple sources are providing same RDNSS(es) IP address(es), each address MUST be added to the RDNSS list only once.
如果多个源提供相同的RDNS（es）IP地址，则每个地址只能添加到RDNS列表中一次。
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请求中指示支持选项_rdns_选择，则DHCPv6服务器可能会忽略选项_DNS_服务器的发送。这允许在网络管理员希望只公布低首选默认RDNSE的情况下卸载用例。
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.
根据在接口上接收到的答案执行的任何后续查询必须继续使用同一接口，而与任何其他接口上的RDNS选择设置无关。例如，如果节点接收到具有规范名称（CNAME）或委派名称（DNAME）的回复，则后续查询必须发送到同一接口的RDN，或发送到同一RDN，而不考虑接收到的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节）或打开改变RDNS选择首选项的新并行网络接口后，与专用名称空间相关的缓存信息可能会过时。实现应确保这些事件中不会保留过时的信息。避免来自本地缓存的不必要/过时响应的一种实现方法是管理每个接口的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说明了节点初始化两个网络接口以供并行使用并从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 | | |
| +----------+ | |
| | | |
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。
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. 该节点从DHCPv6服务器获取新接口2的域'domain2.example.com'和IPv6网络信息，例如'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-| | |
| | | |
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. 节点创建要联系的RDNs列表，并使用配置的RDNs选择信息和存储的关于优先级决策的域信息。
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. 节点选择了接口2，正如前面从DHCPv6了解到的，接口2具有域“domain2.example.com”。然后，节点使用接口2的RDNS将请求的名称解析为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.
部署专用名称空间的网络管理员可以通过提供本文档中描述的信息，在高级节点的RDNS选择过程中提供帮助。
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提供SOA记录时，example.com的子域才允许位于运营商的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分配了两个新的选项代码。
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）参数”组中的“引导供应商扩展和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)".
请求从“IPv6动态主机配置协议（DHCPv6）”组中的“DHCP选项代码”注册表为DHCPv6选项选择（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 RDNS选择选项或DHCPv6选项_rdss_选择选项将解析程序发送的部分或所有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.
攻击者可能试图通过从非常小到非常大范围的广告域和网络来吸引特定流量，或者只是试图将攻击者的RDN作为最高首选默认RDN。
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感知的解析器。只有当节点信任RDNS并且可以使用DNS消息的安全通道时，才有可能信任RDNS进行的验证。
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节使用规范语言描述节点的内部行为，以确保节点不会因意外使用RDNS选择选项而打开新的攻击向量。在标准工作期间，大家一致认为，默认情况下不总是启用此选项更安全，但只有在认为有用和安全时才启用。
[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 21321997年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，“无类别地址ARPA委托”，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.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3396]Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，2002年11月。
[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，“支持IP版本6的DNS扩展”，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，“动态主机配置协议（DHCP）域搜索选项”，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]Lemon，T.，Cheshire，S.，和B.Volz，“动态主机配置协议（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 36462003年12月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年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 61062010年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：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418]Blanchet，M.和P.Seite，“多接口和供应域问题声明”，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.
[With-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.
在某些专用命名空间部署上，RDNS选择的显式策略不可用。本节介绍节点通过发送广泛的查询和利用可能存在的间接信息元素作为提示来缓解问题的方法。
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，以便能够拒绝无法验证的响应。合法答案之间的选择是特定于实现的，但首选来自受信任RDNSE的回复。
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查询，则功耗会增加，而DNS查询本可以通过更便宜的接口来解决。此外，RDNSS上的负载也会增加。但是，结果的本地缓存可以缓解这些问题，并且节点还可以学习一些接口，这些接口似乎能够提供比其他接口更好的响应，并且更喜欢这些接口，而不会忘记当节点使用专用名称空间连接到多个网络时，需要回退。
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节中的示例非常相似。虽然这些选项不打算用于RDNS选择，但节点可以将它们用作更智能的RDNS优先级排序提示，以提高快速和成功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]定义如何为节点提供更具体的路由。此信息不打算用于RDNS选择，但是，节点可以使用此信息作为提示，提示首先尝试反向查找过程的接口。与其他接口的RDNS相比，通过与更具体路由相同的接口配置的RDNS更有可能正确回答反向查找问题。如果在与更具体的路由信息相同的RA[RFC6106]中接收到rdss地址，则成功的可能性可能更高。
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).
节点可以利用最长匹配前缀方法来决定要联系哪些RDN进行反向查找。也就是说，节点可以通过具有与被查询地址最长匹配前缀的接口向RDNS发送DNS查询。在使用唯一本地寻址（ULA）[RFC4193]地址的情况下，以及当查询的地址属于同一网络（例如，intranet）中的节点或服务器时，这种方法会有所帮助。
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根的信任锚点，并且还有一个特殊用途的信任锚点，例如.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风格伪代码中的RDNS选择逻辑。该代码不打算作为此类代码使用；此处仅用于说明目的。
The beginning of the whole procedure is a call to "dns_query" function with a query and list of RDNSSes given as parameters.
整个过程的开始是调用“dns_query”函数，并以查询和rdnse列表作为参数。
/* 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. */
};
/* 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. */
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. */
/* The implementation of this matching function
is left for reader, or rather writer. */
/* return TRUE if query matches rdnss->d_and_n, otherwise FALSE. */
}
/* 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. */
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;
}
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. */
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 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;
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. */
/* 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;
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;
}
/* 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. */
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;
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 );
/* 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 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;
/* 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 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;
{
/* 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;
}
}
/* 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. */
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;
int i;
int swapped = 0;
struct rdnss rdnss_swap;
do
{
/* Clear swapped-indicator. */
swapped = FALSE;
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)
/* 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);
{
/* 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. */
}
/* 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;
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 );
/* 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++)
{
/* 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);
/* 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);
/* 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 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;
}
/* If acceptable response has been found, return it. */
if (response) return response;
}
return NULL;
}
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诺基亚Hermiankatu 12 D坦佩雷FI-33720芬兰
EMail: teemu.savolainen@nokia.com
EMail: teemu.savolainen@nokia.com
Jun-ya Kato NTT 9-11, Midori-Cho 3-Chome Musashino-Shi Tokyo 180-8585 Japan
Jun ya Kato NTT 9-11，Midori Cho 3-Chome Musashino Shi东京180-8585
EMail: kato@syce.net
EMail: kato@syce.net
Ted Lemon Nominum, Inc. 2000 Seaport Boulevard Redwood City, CA 94063 USA
Ted Lemon Nominum，Inc.美国加利福尼亚州红木市海港大道2000号，邮编94063
Phone: +1 650 381 6000
EMail: Ted.Lemon@nominum.com
Phone: +1 650 381 6000
EMail: Ted.Lemon@nominum.com