Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6147 UC3M
Category: Standards Track A. Sullivan
ISSN: 2070-1721 Shinkuro
P. Matthews
Alcatel-Lucent
I. van Beijnum
IMDEA Networks
April 2011
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6147 UC3M
Category: Standards Track A. Sullivan
ISSN: 2070-1721 Shinkuro
P. Matthews
Alcatel-Lucent
I. van Beijnum
IMDEA Networks
April 2011
DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
DNS64:用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展
Abstract
摘要
DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators.
DNS64是从记录合成AAAA记录的机制。DNS64与IPv6/IPv4转换器一起使用，用于为通过NAT工作的应用程序类启用仅IPv6客户端和仅IPv4服务器之间的客户端-服务器通信，而无需对IPv6或IPv4节点进行任何更改。本文档指定了DNS64，并就如何将其与IPv6/IPv4转换器一起部署提供了建议。
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/rfc6147.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6147.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Overview ........................................................5
3. Background to DNS64-DNSSEC Interaction ..........................7
4. Terminology .....................................................9
5. DNS64 Normative Specification ..................................10
5.1. Resolving AAAA Queries and the Answer Section .............11
5.1.1. The Answer when There is AAAA Data Available .......11
5.1.2. The Answer when There is an Error ..................11
5.1.3. Dealing with Timeouts ..............................12
5.1.4. Special Exclusion Set for AAAA Records .............12
5.1.5. Dealing with CNAME and DNAME .......................12
5.1.6. Data for the Answer when Performing Synthesis ......13
5.1.7. Performing the Synthesis ...........................13
5.1.8. Querying in Parallel ...............................14
5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14
5.3. Handling Other Resource Records and the Additional
Section ...................................................15
5.3.1. PTR Resource Record ................................15
5.3.2. Handling the Additional Section ....................16
5.3.3. Other Resource Records .............................17
5.4. Assembling a Synthesized Response to a AAAA Query .........17
5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17
6. Deployment Notes ...............................................19
6.1. DNS Resolvers and DNS64 ...................................19
6.2. DNSSEC Validators and DNS64 ...............................19
6.3. DNS64 and Multihomed and Dual-Stack Hosts .................19
6.3.1. IPv6 Multihomed Hosts ..............................19
6.3.2. Accidental Dual-Stack DNS64 Use ....................20
6.3.3. Intentional Dual-Stack DNS64 Use ...................21
7. Deployment Scenarios and Examples ..............................21
7.1. Example of "an IPv6 Network to the IPv4 Internet"
Setup with DNS64 in DNS Server Mode .......................22
7.2. Example of "an IPv6 Network to the IPv4 Internet"
Setup with DNS64 in Stub-Resolver Mode ....................23
7.3. Example of "the IPv6 Internet to an IPv4 Network"
Setup with DNS64 in DNS Server Mode .......................24
8. Security Considerations ........................................27
9. Contributors ...................................................27
10. Acknowledgements ..............................................27
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................28
Appendix A. Motivations and Implications of Synthesizing AAAA
Resource Records when Real AAAA Resource Records
Exist ................................................30
1. Introduction ....................................................4
2. Overview ........................................................5
3. Background to DNS64-DNSSEC Interaction ..........................7
4. Terminology .....................................................9
5. DNS64 Normative Specification ..................................10
5.1. Resolving AAAA Queries and the Answer Section .............11
5.1.1. The Answer when There is AAAA Data Available .......11
5.1.2. The Answer when There is an Error ..................11
5.1.3. Dealing with Timeouts ..............................12
5.1.4. Special Exclusion Set for AAAA Records .............12
5.1.5. Dealing with CNAME and DNAME .......................12
5.1.6. Data for the Answer when Performing Synthesis ......13
5.1.7. Performing the Synthesis ...........................13
5.1.8. Querying in Parallel ...............................14
5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14
5.3. Handling Other Resource Records and the Additional
Section ...................................................15
5.3.1. PTR Resource Record ................................15
5.3.2. Handling the Additional Section ....................16
5.3.3. Other Resource Records .............................17
5.4. Assembling a Synthesized Response to a AAAA Query .........17
5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17
6. Deployment Notes ...............................................19
6.1. DNS Resolvers and DNS64 ...................................19
6.2. DNSSEC Validators and DNS64 ...............................19
6.3. DNS64 and Multihomed and Dual-Stack Hosts .................19
6.3.1. IPv6 Multihomed Hosts ..............................19
6.3.2. Accidental Dual-Stack DNS64 Use ....................20
6.3.3. Intentional Dual-Stack DNS64 Use ...................21
7. Deployment Scenarios and Examples ..............................21
7.1. Example of "an IPv6 Network to the IPv4 Internet"
Setup with DNS64 in DNS Server Mode .......................22
7.2. Example of "an IPv6 Network to the IPv4 Internet"
Setup with DNS64 in Stub-Resolver Mode ....................23
7.3. Example of "the IPv6 Internet to an IPv4 Network"
Setup with DNS64 in DNS Server Mode .......................24
8. Security Considerations ........................................27
9. Contributors ...................................................27
10. Acknowledgements ..............................................27
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................28
Appendix A. Motivations and Implications of Synthesizing AAAA
Resource Records when Real AAAA Resource Records
Exist ................................................30
This document specifies DNS64, a mechanism that is part of the toolbox for IPv4-IPv6 transition and coexistence. DNS64, used together with an IPv6/IPv4 translator such as stateful NAT64 [RFC6146], allows an IPv6-only client to initiate communications by name to an IPv4-only server.
本文档指定了DNS64，这是IPv4-IPv6转换和共存工具箱的一部分。DNS64与IPv6/IPv4转换器（如有状态NAT64[RFC6146]）一起使用，允许仅限IPv6的客户端按名称启动与仅限IPv4的服务器的通信。
DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. A synthetic AAAA RR created by the DNS64 from an original A RR contains the same owner name of the original A RR, but it contains an IPv6 address instead of an IPv4 address. The IPv6 address is an IPv6 representation of the IPv4 address contained in the original A RR. The IPv6 representation of the IPv4 address is algorithmically generated from the IPv4 address returned in the A RR and a set of parameters configured in the DNS64 (typically, an IPv6 prefix used by IPv6 representations of IPv4 addresses and, optionally, other parameters).
DNS64是从RRs合成AAAA资源记录（RRs）的机制。DNS64从原始A RR创建的合成AAAA RR包含与原始A RR相同的所有者名称，但它包含IPv6地址而不是IPv4地址。IPv6地址是原始A RR中包含的IPv4地址的IPv6表示形式。IPv4地址的IPv6表示通过算法从A RR中返回的IPv4地址和DNS64中配置的一组参数（通常，IPv4地址的IPv6表示使用的IPv6前缀和可选的其他参数）生成。
Together with an IPv6/IPv4 translator, these two mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server using the Fully Qualified Domain Name (FQDN) of the server.
与IPv6/IPv4转换器一起，这两种机制允许仅IPv6客户端使用服务器的完全限定域名（FQDN）启动与仅IPv4服务器的通信。
These mechanisms are expected to play a critical role in the IPv4- IPv6 transition and coexistence. Due to IPv4 address depletion, it is likely that in the future, many IPv6-only clients will want to connect to IPv4-only servers. In the typical case, the approach only requires the deployment of IPv6/IPv4 translators that connect an IPv6-only network to an IPv4-only network, along with the deployment of one or more DNS64-enabled name servers. However, some features require performing the DNS64 function directly in the end hosts themselves.
这些机制有望在IPv4-IPv6过渡和共存中发挥关键作用。由于IPv4地址耗尽，未来可能会有许多仅限IPv6的客户端希望连接到仅限IPv4的服务器。在典型情况下，该方法只需要部署将仅IPv6网络连接到仅IPv4网络的IPv6/IPv4转换器，以及部署一个或多个启用DNS64的名称服务器。但是，有些功能要求直接在终端主机中执行DNS64功能。
This document is structured as follows: Section 2 provides a non-normative overview of the behavior of DNS64. Section 3 provides a non-normative background required to understand the interaction between DNS64 and DNS Security Extensions (DNSSEC). The normative specification of DNS64 is provided in Sections 4, 5, and 6. Section 4 defines the terminology, Section 5 is the actual DNS64 specification, and Section 6 covers deployment issues. Section 7 is non-normative and provides a set of examples and typical deployment scenarios.
本文件结构如下：第2节提供了DNS64行为的非规范性概述。第3节提供了理解DNS64和DNS安全扩展（DNSSEC）之间交互所需的非规范性背景。DNS64的标准规范见第4、5和6节。第4节定义了术语，第5节是实际的DNS64规范，第6节讨论了部署问题。第7节是非规范性的，提供了一组示例和典型部署场景。
This section provides an introduction to the DNS64 mechanism.
本节介绍DNS64机制。
We assume that we have one or more IPv6/IPv4 translator boxes connecting an IPv4 network and an IPv6 network. The IPv6/IPv4 translator device provides translation services between the two networks, enabling communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By "IPv6-only hosts", we mean hosts running IPv6-only applications and hosts that can only use IPv6, as well as cases where only IPv6 connectivity is available to the client. By "IPv4-only servers", we mean servers running IPv4-only applications and servers that can only use IPv4, as well as cases where only IPv4 connectivity is available to the server). Each IPv6/IPv4 translator used in conjunction with DNS64 must allow communications initiated from the IPv6-only host to the IPv4-only host.
我们假设有一个或多个IPv6/IPv4转换器盒连接IPv4网络和IPv6网络。IPv6/IPv4转换器设备提供两个网络之间的转换服务，支持仅IPv4主机和仅IPv6主机之间的通信。（注意：“仅限IPv6主机”指运行仅限IPv6应用程序的主机和只能使用IPv6的主机，以及客户端只能使用IPv6连接的情况。通过“仅限IPv4服务器”，我们指的是运行仅IPv4应用程序的服务器和只能使用IPv4的服务器，以及仅IPv4连接可用于服务器的情况）。与DNS64一起使用的每个IPv6/IPv4转换器必须允许从仅限IPv6的主机到仅限IPv4的主机发起通信。
To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to learn the address of the responder, DNS64 is used to synthesize a AAAA record from an A record containing a real IPv4 address of the responder, whenever the DNS64 cannot retrieve a AAAA record for the queried name. The DNS64 service appears as a regular DNS server or resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query generated by the IPv6 initiator. It first attempts a resolution for the requested AAAA records. If there are no AAAA records available for the target node (which is the normal case when the target node is an IPv4-only node), DNS64 performs a query for A records. For each A record discovered, DNS64 creates a synthetic AAAA RR from the information retrieved in the A RR.
为了允许IPv6启动器执行标准AAAA RR DNS查找以了解响应程序的地址，当DNS64无法检索查询名称的AAAA记录时，使用DNS64从包含响应程序真实IPv4地址的a记录合成AAAA记录。DNS64服务显示为IPv6启动器的常规DNS服务器或解析程序。DNS64接收IPv6启动器生成的AAAA DNS查询。它首先尝试对请求的AAAA记录进行解析。如果目标节点没有可用的AAAA记录（这是目标节点为仅IPv4节点时的正常情况），DNS64将执行记录查询。对于发现的每个A记录，DNS64根据A RR中检索到的信息创建一个合成AAAA RR。
The owner name of a synthetic AAAA RR is the same as that of the original A RR, but an IPv6 representation of the IPv4 address contained in the original A RR is included in the AAAA RR. The IPv6 representation of the IPv4 address is algorithmically generated from the IPv4 address and additional parameters configured in the DNS64. Among those parameters configured in the DNS64, there is at least one IPv6 prefix. If not explicitly mentioned, all prefixes are treated equally, and the operations described in this document are performed using the prefixes available. So as to be general, we will call any of these prefixes Pref64::/n, and describe the operations made with the generic prefix Pref64::/n. The IPv6 addresses representing IPv4 addresses included in the AAAA RR synthesized by the DNS64 contain Pref64::/n, and they also embed the original IPv4 address.
合成AAAA RR的所有者名称与原始a RR的所有者名称相同，但原始a RR中包含的IPv4地址的IPv6表示形式包含在AAAA RR中。IPv4地址的IPv6表示是根据IPv4地址和DNS64中配置的其他参数通过算法生成的。在DNS64中配置的这些参数中，至少有一个IPv6前缀。如果没有明确提及，所有前缀都将被同等对待，本文档中描述的操作将使用可用的前缀执行。为了更一般，我们将调用这些前缀Pref64:：/n，并描述使用通用前缀Pref64:：/n进行的操作。表示由DNS64合成的AAAA RR中包含的IPv4地址的IPv6地址包含Pref64:：/n，并且它们还嵌入原始IPv4地址。
The same algorithm and the same Pref64::/n prefix(es) must be
configured both in the DNS64 device and the IPv6/IPv4 translator(s),
so that both can algorithmically generate the same IPv6
representation for a given IPv4 address. In addition, it is required
The same algorithm and the same Pref64::/n prefix(es) must be
configured both in the DNS64 device and the IPv6/IPv4 translator(s),
so that both can algorithmically generate the same IPv6
representation for a given IPv4 address. In addition, it is required
that IPv6 packets addressed to an IPv6 destination address that contains the Pref64::/n be delivered to an IPv6/IPv4 translator that has that particular Pref64::/n configured, so they can be translated into IPv4 packets.
将发往包含Pref64:：/n的IPv6目标地址的IPv6数据包传递到配置了特定Pref64:：/n的IPv6/IPv4转换器，以便将其转换为IPv4数据包。
Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs are passed back to the IPv6 initiator, which will initiate an IPv6 communication with the IPv6 address associated with the IPv4 receiver. The packet will be routed to an IPv6/IPv4 translator, which will forward it to the IPv4 network.
一旦DNS64合成了AAAA RRs，合成AAAA RRs将传回IPv6启动器，后者将启动与IPv4接收器关联的IPv6地址的IPv6通信。数据包将被路由到IPv6/IPv4转换器，后者将其转发到IPv4网络。
In general, the only shared state between the DNS64 and the IPv6/IPv4 translator is the Pref64::/n and an optional set of static parameters. The Pref64::/n and the set of static parameters must be configured to be the same on both; there is no communication between the DNS64 device and IPv6/IPv4 translator functions. The mechanism to be used for configuring the parameters of the DNS64 is beyond the scope of this memo.
通常，DNS64和IPv6/IPv4转换器之间的唯一共享状态是Pref64:：/n和一组可选的静态参数。Pref64:：/n和静态参数集必须配置为在这两者上相同；DNS64设备与IPv6/IPv4转换器功能之间没有通信。用于配置DNS64参数的机制超出了本备忘录的范围。
The prefixes to be used as Pref64::/n and their applicability are discussed in [RFC6052]. There are two types of prefixes that can be used as Pref64::/n.
[RFC6052]中讨论了用作Pref64:：/n的前缀及其适用性。有两种类型的前缀可以用作Pref64:：/n。
o The Pref64::/n can be the Well-Known Prefix 64:ff9b::/96 reserved by [RFC6052] for the purpose of representing IPv4 addresses in IPv6 address space.
o Pref64:：/n可以是[RFC6052]为表示IPv6地址空间中的IPv4地址而保留的众所周知的前缀64:ff9b:：/96。
o The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is an IPv6 prefix assigned by an organization to create IPv6 representations of IPv4 addresses.
o Pref64:：/n可以是网络特定前缀（NSP）。NSP是由组织分配的IPv6前缀，用于创建IPv4地址的IPv6表示形式。
The main difference in the nature of the two types of prefixes is that the NSP is a locally assigned prefix that is under control of the organization that is providing the translation services, while the Well-Known Prefix is a prefix that has a global meaning since it has been assigned for the specific purpose of representing IPv4 addresses in IPv6 address space.
这两种前缀性质的主要区别在于，NSP是本地分配的前缀，由提供翻译服务的组织控制，而众所周知的前缀是一个具有全局含义的前缀，因为它被分配用于在IPv6地址空间中表示IPv4地址的特定目的。
The DNS64 function can be performed in any of three places. The terms below are more formally defined in Section 4.
DNS64功能可以在三个位置中的任何一个执行。以下术语在第4节中有更正式的定义。
The first option is to locate the DNS64 function in authoritative servers for a zone. In this case, the authoritative server provides synthetic AAAA RRs for an IPv4-only host in its zone. This is one type of DNS64 server.
第一个选项是在区域的权威服务器中定位DNS64函数。在这种情况下，权威服务器为其区域中仅IPv4的主机提供合成AAAA RRs。这是DNS64服务器的一种类型。
Another option is to locate the DNS64 function in recursive name servers serving end hosts. In this case, when an IPv6-only host queries the name server for AAAA RRs for an IPv4-only host, the name server can perform the synthesis of AAAA RRs and pass them back to the IPv6-only initiator. The main advantage of this mode is that current IPv6 nodes can use this mechanism without requiring any modification. This mode is called "DNS64 in DNS recursive-resolver mode". This is a second type of DNS64 server, and it is also one type of DNS64 resolver.
另一个选项是在为终端主机服务的递归名称服务器中定位DNS64函数。在这种情况下，当仅IPv6主机向名称服务器查询仅IPv4主机的AAAA RRs时，名称服务器可以执行AAAA RRs的合成，并将其传递回仅IPv6的启动器。此模式的主要优点是当前IPv6节点可以使用此机制，而无需任何修改。此模式称为“DNS递归解析器模式下的DNS64”。这是第二种类型的DNS64服务器，也是一种类型的DNS64解析器。
The last option is to place the DNS64 function in the end hosts, coupled to the local (stub) resolver. In this case, the stub resolver will try to obtain (real) AAAA RRs, and in case they are not available, the DNS64 function will synthesize AAAA RRs for internal usage. This mode is compatible with some functions like DNSSEC validation in the end host. The main drawback of this mode is its deployability, since it requires changes in the end hosts. This mode is called "DNS64 in stub-resolver mode". This is the second type of DNS64 resolver.
最后一个选项是将DNS64函数放置在终端主机中，并与本地（存根）解析器耦合。在这种情况下，存根解析器将尝试获取（真实的）AAAA RRs，如果它们不可用，DNS64函数将合成AAAA RRs供内部使用。此模式与终端主机中的DNSSEC验证等功能兼容。这种模式的主要缺点是它的可部署性，因为它需要在终端主机中进行更改。此模式称为“存根解析器模式下的DNS64”。这是第二种类型的DNS64解析器。
DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge for DNS64, because DNSSEC is designed to detect changes to DNS answers, and DNS64 may alter answers coming from an authoritative server.
DNSSEC（[RFC4033]、[RFC4034]、[RFC4035]）对DNS64提出了特殊的挑战，因为DNSSEC设计用于检测DNS应答的更改，而DNS64可能会更改来自权威服务器的应答。
A recursive resolver can be security-aware or security-oblivious. Moreover, a security-aware recursive resolver can be validating or non-validating, according to operator policy. In the cases below, the recursive resolver is also performing DNS64, and has a local policy to validate. We call this general case vDNS64, but in all the cases below, the DNS64 functionality should be assumed to be needed.
递归解析器可以是安全感知的，也可以是不安全的。此外，根据操作员策略，安全感知递归解析器可以是验证的，也可以是非验证的。在以下情况下，递归解析器也在执行DNS64，并且有一个本地策略要验证。我们称之为一般情况下的vDNS64，但在以下所有情况下，应假定需要DNS64功能。
DNSSEC includes some signaling bits that offer some indicators of what the query originator understands.
DNSSEC包括一些信令位，这些信令位提供查询发起人理解的一些指标。
If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit set, the query originator is signaling that it understands DNSSEC. The DO bit does not indicate that the query originator will validate the response. It only means that the query originator can understand responses containing DNSSEC data. Conversely, if the DO bit is clear, that is evidence that the querying agent is not aware of DNSSEC.
如果查询到达设置了“DNSSEC OK”（DO）位的vDNS64设备，则查询发起人发出信号表示其理解DNSSEC。DO位并不表示查询发起人将验证响应。这只意味着查询发起人可以理解包含DNSSEC数据的响应。相反，如果DO位是清除的，则表明查询代理不知道DNSSEC。
If a query arrives at a vDNS64 device with the "Checking Disabled" (CD) bit set, it is an indication that the querying agent wants all the validation data so it can do checking itself. By local policy, vDNS64 could still validate, but it must return all data to the querying agent anyway.
如果查询到达vDNS64设备时设置了“Checking Disabled”（CD）位，则表示查询代理需要所有验证数据，以便自己进行检查。根据本地策略，vDNS64仍然可以进行验证，但它必须将所有数据返回到查询代理。
Here are the possible cases:
以下是可能的情况：
1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with the DO bit clear. In this case, DNSSEC is not a concern, because the querying agent does not understand DNSSEC responses. The DNS64 can do validation of the response, if dictated by its local policy.
1. DNS64（DNSSEC感知或DNSSEC不感知）接收DO位为clear的查询。在这种情况下，DNSSEC不是一个问题，因为查询代理不理解DNSSEC响应。DNS64可以根据其本地策略进行响应验证。
2. A security-oblivious DNS64 receives a query with the DO bit set, and the CD bit clear or set. This is just like the case of a non-DNS64 case: the server doesn't support it, so the querying agent is out of luck.
2. 不考虑安全性的DNS64接收设置了DO位和清除或设置了CD位的查询。这与非DNS64的情况类似：服务器不支持它，因此查询代理运气不佳。
3. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit clear. Such a resolver is not validating responses, likely due to local policy (see [RFC4035], Section 4.2). For that reason, this case amounts to the same as the previous case, and no validation happens.
3. 具有安全意识且未验证的DNS64接收设置了DO位且清除了CD位的查询。这种解析程序不验证响应，可能是由于本地策略（请参阅[RFC4035]，第4.2节）。因此，此案例与前一个案例相同，没有进行验证。
4. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit set. In this case, the DNS64 is supposed to pass on all the data it gets to the query initiator (see Section 3.2.2 of [RFC4035]). This case will not work with DNS64, unless the validating resolver is prepared to do DNS64 itself. If the DNS64 modifies the record, the client will get the data back and try to validate it, and the data will be invalid as far as the client is concerned.
4. 具有安全意识且未验证的DNS64接收具有DO位集和CD位集的查询。在这种情况下，DNS64应该将它获得的所有数据传递给查询启动器（请参见[RFC4035]的第3.2.2节）。除非验证冲突解决程序准备自行执行DNS64，否则此情况将不适用于DNS64。如果DNS64修改了记录，客户端将获取数据并尝试验证它，并且对于客户端而言，数据将无效。
5. A security-aware and validating DNS64 resolver receives a query with the DO bit clear and the CD bit clear. In this case, the resolver validates the data. If it fails, it returns RCODE 2 (Server failure); otherwise, it returns the answer. This is the ideal case for vDNS64. The resolver validates the data, and then synthesizes the new record and passes that to the client. The client, which is presumably not validating (else it should have set DO and CD), cannot tell that DNS64 is involved.
5. 安全感知和验证DNS64解析器接收DO位清除和CD位清除的查询。在这种情况下，解析器将验证数据。如果失败，则返回RCODE 2（服务器故障）；否则，它将返回答案。这是vDNS64的理想情况。解析器验证数据，然后合成新记录并将其传递给客户端。客户端可能没有进行验证（否则它应该设置DO和CD），无法判断是否涉及DNS64。
6. A security-aware and validating DNS64 resolver receives a query with the DO bit set and the CD bit clear. This works like the previous case, except that the resolver should also set the "Authentic Data" (AD) bit on the response.
6. 安全感知和验证DNS64解析器接收设置了DO位且清除了CD位的查询。这与前一种情况类似，只是解析器还应该在响应上设置“真实数据”（AD）位。
7. A security-aware and validating DNS64 resolver receives a query with the DO bit set and the CD bit set. This is effectively the same as the case where a security-aware and non-validating recursive resolver receives a similar query, and the same thing will happen: the downstream validator will mark the data as invalid if DNS64 has performed synthesis. The node needs to do DNS64 itself, or else communication will fail.
7. 安全感知和验证DNS64解析器接收具有DO位集和CD位集的查询。这实际上与安全感知和非验证递归解析器接收到类似查询的情况相同，并且会发生相同的情况：如果DNS64执行了合成，则下游验证器会将数据标记为无效。节点需要自己执行DNS64，否则通信将失败。
This section provides definitions for the special terms used in the document.
本节提供了本文件中使用的特殊术语的定义。
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]中所述进行解释。
Authoritative server: A DNS server that can answer authoritatively a given DNS request.
权威服务器：可以权威地响应给定DNS请求的DNS服务器。
DNS64: A logical function that synthesizes DNS resource records (e.g., AAAA records containing IPv6 addresses) from DNS resource records actually contained in the DNS (e.g., A records containing IPv4 addresses).
DNS64：从DNS中实际包含的DNS资源记录（例如，包含IPv4地址的记录）合成DNS资源记录（例如，包含IPv6地址的AAAA记录）的逻辑函数。
DNS64 recursive resolver: A recursive resolver that provides the DNS64 functionality as part of its operation. This is the same thing as "DNS64 in recursive-resolver mode".
DNS64递归解析器：一种递归解析器，提供DNS64功能作为其操作的一部分。这与“递归解析器模式下的DNS64”相同。
DNS64 resolver: Any resolver (stub resolver or recursive resolver) that provides the DNS64 function.
DNS64解析器：提供DNS64函数的任何解析器（存根解析器或递归解析器）。
DNS64 server: Any server providing the DNS64 function. This includes the server portion of a recursive resolver when it is providing the DNS64 function.
DNS64服务器：提供DNS64功能的任何服务器。这包括提供DNS64函数时递归解析器的服务器部分。
IPv4-only server: Servers running IPv4-only applications and servers that can only use IPv4, as well as cases where only IPv4 connectivity is available to the server.
仅IPv4服务器：运行仅IPv4应用程序的服务器和只能使用IPv4的服务器，以及仅IPv4连接可用于服务器的情况。
IPv6-only hosts: Hosts running IPv6-only applications and hosts that can only use IPv6, as well as cases where only IPv6 connectivity is available to the client.
仅限IPv6主机：运行仅限IPv6应用程序的主机和只能使用IPv6的主机，以及客户端只能使用IPv6连接的情况。
Recursive resolver: A DNS server that accepts requests from one resolver, and asks another server (of some description) for the answer on behalf of the first resolver. Full discussion of DNS recursion is beyond the scope of this document; see [RFC1034] and [RFC1035] for full details.
递归冲突解决程序：一个DNS服务器，它接受来自一个冲突解决程序的请求，并代表第一个冲突解决程序向另一个服务器（某些描述）请求答案。DNS递归的完整讨论超出了本文档的范围；有关详细信息，请参见[RFC1034]和[RFC1035]。
Synthetic RR: A DNS resource record (RR) that is not contained in the authoritative servers' zone data, but which is instead synthesized from other RRs in the same zone. An example is a synthetic AAAA record created from an A record.
合成RR：一种DNS资源记录（RR），它不包含在权威服务器的区域数据中，而是由同一区域中的其他RR合成。例如，从a记录创建的合成AAAA记录。
IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 packets and vice versa. It is only required that the communication initiated from the IPv6 side be supported.
IPv6/IPv4转换器：将IPv6数据包转换为IPv4数据包，反之亦然的设备。只需要支持从IPv6端发起的通信。
For a detailed understanding of this document, the reader should also be familiar with DNS terminology from [RFC1034] and [RFC1035] and with current NAT terminology from [RFC4787]. Some parts of this document assume familiarity with the terminology of the DNS security extensions outlined in [RFC4035]. It is worth emphasizing that while DNS64 is a logical function separate from the DNS, it is nevertheless closely associated with that protocol. It depends on the DNS protocol, and some behavior of DNS64 will interact with regular DNS responses.
为了详细了解本文档，读者还应熟悉[RFC1034]和[RFC1035]中的DNS术语以及[RFC4787]中的当前NAT术语。本文档的某些部分假定您熟悉[RFC4035]中概述的DNS安全扩展的术语。值得强调的是，尽管DNS64是与DNS分离的逻辑功能，但它与该协议密切相关。它取决于DNS协议，DNS64的某些行为将与常规DNS响应交互。
DNS64 is a logical function that synthesizes AAAA records from A records. The DNS64 function may be implemented in a stub resolver, in a recursive resolver, or in an authoritative name server. It works within those DNS functions, and appears on the network as though it were a "plain" DNS resolver or name server conforming to [RFC1034] and [RFC1035].
DNS64是一个逻辑函数，它从a记录合成AAAA记录。DNS64函数可以在存根解析器、递归解析器或权威名称服务器中实现。它在这些DNS功能中工作，并在网络上显示，就好像它是符合[RFC1034]和[RFC1035]的“普通”DNS解析程序或名称服务器一样。
The implementation SHOULD support mapping of separate IPv4 address ranges to separate IPv6 prefixes for AAAA record synthesis. This allows handling of special use IPv4 addresses [RFC5735].
该实现应支持将单独的IPv4地址范围映射到单独的IPv6前缀，以用于AAAA记录合成。这允许处理特殊用途的IPv4地址[RFC5735]。
DNS messages contain several sections. The portion of a DNS message that is altered by DNS64 is the answer section, which is discussed below in Section 5.1. The resulting synthetic answer is put together with other sections, and that creates the message that is actually returned as the response to the DNS query. Assembling that response is covered below in Section 5.4.
DNS消息包含几个部分。DNS消息中被DNS64更改的部分是应答部分，将在下面的第5.1节中讨论。生成的合成答案与其他部分放在一起，并创建实际作为DNS查询响应返回的消息。第5.4节将介绍该响应。
DNS64 also responds to PTR queries involving addresses containing any of the IPv6 prefixes it uses for synthesis of AAAA RRs.
DNS64还响应涉及地址的PTR查询，该地址包含它用于合成AAAA RRs的任何IPv6前缀。
When the DNS64 receives a query for RRs of type AAAA and class IN, it first attempts to retrieve non-synthetic RRs of this type and class, either by performing a query or, in the case of an authoritative server, by examining its own results. The query may be answered from a local cache, if one is available. DNS64 operation for classes other than IN is undefined, and a DNS64 MUST behave as though no DNS64 function is configured.
当DNS64接收到AAAA类型和类别的RRs查询时，它首先尝试通过执行查询或（对于权威服务器）检查自己的结果来检索此类型和类别的非合成RRs。如果本地缓存可用，则可以从本地缓存中回答查询。中以外的类的DNS64操作未定义，DNS64的行为必须如同未配置DNS64函数一样。
If the query results in one or more AAAA records in the answer section, the result is returned to the requesting client as per normal DNS semantics, except in the case where any of the AAAA records match a special exclusion set of prefixes, as considered in Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A for an analysis of the motivations for and the implications of not complying with this recommendation). By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs exist.
如果查询在应答部分中产生一个或多个AAAA记录，则根据正常DNS语义将结果返回给请求客户端，除非任何AAAA记录匹配特殊的前缀排除集，如第5.1.4节所述。如果有（非排除的）AAAA数据可用，DNS64不应在回复中包含合成AAAA RRs（有关不遵守本建议的动机和影响的分析，请参见附录A）。默认情况下，当存在真正的AAAA RRs时，DNS64实现不得合成AAAA RRs。
If the query results in a response with an RCODE other than 0 (No error condition), then there are two possibilities. A result with RCODE=3 (Name Error) is handled according to normal DNS operation (which is normally to return the error to the client). This stage is still prior to any synthesis having happened, so a response to be returned to the client does not need any special assembly other than what would usually happen in DNS operation.
如果查询结果的响应的RCODE不是0（无错误条件），则有两种可能性。RCODE=3（名称错误）的结果根据正常DNS操作（通常是将错误返回给客户端）进行处理。此阶段仍然在发生任何合成之前，因此要返回给客户机的响应不需要任何特殊的程序集，DNS操作中通常会发生的情况除外。
Any other RCODE is treated as though the RCODE were 0 (see Sections 5.1.6 and 5.1.7) and the answer section were empty. This is because of the large number of different responses from deployed name servers when they receive AAAA queries without a AAAA record being available (see [RFC4074]). Note that this means, for practical purposes, that several different classes of error in the DNS are all treated as though a AAAA record is not available for that owner name.
任何其他RCODE被视为RCODE为0（见第5.1.6节和第5.1.7节），答案部分为空。这是因为当部署的名称服务器在没有可用AAAA记录的情况下接收AAAA查询时，会有大量不同的响应（请参见[RFC4074]）。注意，这意味着，出于实际目的，DNS中的几个不同类别的错误都被视为AAAA记录不适用于该所有者名称。
It is important to note that, as of this writing, some servers respond with RCODE=3 to a AAAA query even if there is an A record available for that owner name. Those servers are in clear violation of the meaning of RCODE 3, and it is expected that they will decline in use as IPv6 deployment increases.
值得注意的是，在撰写本文时，有些服务器会以RCODE=3响应AAAA查询，即使该所有者名称有可用的a记录。这些服务器明显违反了RCODE 3的含义，预计随着IPv6部署的增加，它们的使用将减少。
If the query receives no answer before the timeout (which might be the timeout from every authoritative server, depending on whether the DNS64 is in recursive-resolver mode), it is treated as RCODE=2 (Server failure).
如果查询在超时之前没有收到响应（这可能是来自每个权威服务器的超时，具体取决于DNS64是否处于递归解析器模式），则将其视为RCODE=2（服务器故障）。
Some IPv6 addresses are not actually usable by IPv6-only hosts. If they are returned to IPv6-only querying agents as AAAA records, therefore, the goal of decreasing the number of failure modes will not be attained. Examples include AAAA records with addresses in the ::ffff:0:0/96 network, and possibly (depending on the context) AAAA records with the site's Pref64::/n or the Well-Known Prefix (see below for more about the Well-Known Prefix). A DNS64 implementation SHOULD provide a mechanism to specify IPv6 prefix ranges to be treated as though the AAAA containing them were an empty answer. An implementation SHOULD include the ::ffff/96 network in that range by default. Failure to provide this facility will mean that clients querying the DNS64 function may not be able to communicate with hosts that would be reachable from a dual-stack host.
某些IPv6地址实际上不可由仅限IPv6的主机使用。因此，如果将它们返回到IPv6，只查询作为AAAA记录的代理，则无法实现减少故障模式数量的目标。示例包括地址在：：ffff:0:0/96网络中的AAAA记录，以及可能（取决于上下文）具有站点的Pref64:：/n或已知前缀的AAAA记录（有关已知前缀的详细信息，请参阅下文）。DNS64实现应提供一种机制，指定IPv6前缀范围，将其视为包含它们的AAAA是空答案。默认情况下，实现应该包括该范围内的：：ffff/96网络。未能提供此功能将意味着查询DNS64功能的客户端可能无法与可从双堆栈主机访问的主机通信。
When the DNS64 performs its initial AAAA query, if it receives an answer with only AAAA records containing addresses in the excluded range(s), then it MUST treat the answer as though it were an empty answer, and proceed accordingly. If it receives an answer with at least one AAAA record containing an address outside any of the excluded range(s), then it by default SHOULD build an answer section for a response including only the AAAA record(s) that do not contain any of the addresses inside the excluded ranges. That answer section is used in the assembly of a response as detailed in Section 5.4. Alternatively, it MAY treat the answer as though it were an empty answer, and proceed accordingly. It MUST NOT return the offending AAAA records as part of a response.
当DNS64执行其初始AAAA查询时，如果它接收到只有AAAA记录包含排除范围内地址的答案，则它必须将该答案视为空答案，并相应地进行处理。如果它收到的应答中至少有一条AAAA记录包含排除范围以外的地址，则默认情况下，它应为仅包含不包含排除范围内任何地址的AAAA记录的应答构建应答节。该回答部分用于第5.4节详述的回答汇编。或者，它可以将答案视为一个空答案，并相应地进行处理。作为响应的一部分，它不得返回有问题的AAAA记录。
If the response contains a CNAME or a DNAME, then the CNAME or DNAME chain is followed until the first terminating A or AAAA record is reached. This may require the DNS64 to ask for an A record, in case the response to the original AAAA query is a CNAME or DNAME without a AAAA record to follow. The resulting AAAA or A record is treated like any other AAAA or A case, as appropriate.
如果响应包含CNAME或DNAME，则会跟随CNAME或DNAME链，直到到达第一个终止记录或AAAA记录为止。如果对原始AAAA查询的响应是CNAME或DNAME，而后面没有AAAA记录，则这可能需要DNS64请求A记录。产生的AAAA或记录被视为与任何其他AAAA或案例一样（视情况而定）。
When assembling the answer section, any chains of CNAME or DNAME RRs are included as part of the answer along with the synthetic AAAA (if appropriate).
组装答案部分时，任何CNAME或DNAME RRs链都与合成AAAA（如适用）一起作为答案的一部分。
If the query results in no error but an empty answer section in the response, the DNS64 attempts to retrieve A records for the name in question, either by performing another query or, in the case of an authoritative server, by examining its own results. If this new A RR query results in an empty answer or in an error, then the empty result or error is used as the basis for the answer returned to the querying client. If instead the query results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs according to the procedure outlined in Section 5.1.7. The DNS64 returns the synthesized AAAA records in the answer section, removing the A records that form the basis of the synthesis.
如果查询结果没有错误，但响应中有一个空的应答部分，则DNS64会尝试通过执行另一个查询或（对于权威服务器）检查其自身的结果来检索有关名称的记录。如果此新的A RR查询导致空答案或错误，则空结果或错误将用作返回到查询客户端的答案的基础。如果查询结果是一个或多个A RRs，则DNS64根据第5.1.7节中概述的程序基于A RRs合成AAAA RRs。DNS64在应答部分返回合成的AAAA记录，删除构成合成基础的A记录。
A synthetic AAAA record is created from an A record as follows:
合成AAAA记录由A记录创建，如下所示：
o The NAME field is set to the NAME field from the A record.
o 名称字段设置为A记录中的名称字段。
o The TYPE field is set to 28 (AAAA).
o 类型字段设置为28（AAAA）。
o The CLASS field is set to the original CLASS field, 1. Under this specification, DNS64 for any CLASS other than 1 is undefined.
o “类别”字段设置为原始类别字段1。根据本规范，除1以外的任何类别的DNS64均未定义。
o The Time to Live (TTL) field is set to the minimum of the TTL of the original A RR and the SOA RR for the queried domain. (Note that in order to obtain the TTL of the SOA RR, the DNS64 does not need to perform a new query, but it can remember the TTL from the SOA RR in the negative response to the AAAA query. If the SOA RR was not delivered with the negative response to the AAAA query, then the DNS64 SHOULD use the TTL of the original A RR or 600 seconds, whichever is shorter. It is possible instead to query explicitly for the SOA RR and use the result of that query, but this will increase query load and time to resolution for little additional benefit.) This is in keeping with the approach used in negative caching [RFC2308].
o 生存时间（TTL）字段设置为原始A RR的TTL和查询域的SOA RR的最小值。（注意，为了获得SOA RR的TTL，DNS64不需要执行新的查询，但它可以在对AAAA查询的否定响应中记住来自SOA RR的TTL。如果SOA RR没有与对AAAA查询的否定响应一起交付，则DNS64应该使用原始a RR的TTL或600秒，以相反，可以显式查询SOA RR并使用该查询的结果，但这将增加查询负载和解析时间，几乎没有额外的好处。）这与负缓存中使用的方法一致[RFC2308]。
o The RDLENGTH field is set to 16.
o RDLENGTH字段设置为16。
o The RDATA field is set to the IPv6 representation of the IPv4 address from the RDATA field of the A record. The DNS64 MUST check each A RR against configured IPv4 address ranges and select the corresponding IPv6 prefix to use in synthesizing the AAAA RR. See Section 5.2 for discussion of the algorithms to be used in effecting the transformation.
o RDATA字段设置为记录的RDATA字段中IPv4地址的IPv6表示形式。DNS64必须根据配置的IPv4地址范围检查每个A RR，并选择相应的IPv6前缀以用于合成AAAA RR。有关影响转换所用算法的讨论，请参见第5.2节。
The DNS64 MAY perform the query for the AAAA RR and for the A RR in parallel, in order to minimize the delay.
DNS64可并行执行AAAA RR和A RR查询，以最小化延迟。
NOTE: Querying in parallel will result in performing unnecessary A RR queries in the case where no AAAA RR synthesis is required. A possible trade-off would be to perform them sequentially but with a very short interval between them, so if we obtain a fast reply, we avoid doing the additional query. (Note that this discussion is relevant only if the DNS64 function needs to perform external queries to fetch the RR. If the needed RR information is available locally, as in the case of an authoritative server, the issue is no longer relevant.)
注意：如果不需要AAAA RR合成，并行查询将导致执行不必要的A RR查询。一个可能的折衷办法是按顺序执行它们，但它们之间的间隔很短，因此如果我们得到一个快速回复，我们就避免执行额外的查询。（请注意，仅当DNS64函数需要执行外部查询以获取RR时，此讨论才相关。如果所需的RR信息在本地可用，如权威服务器，则此问题不再相关。）
DNS64 supports multiple algorithms for the generation of the IPv6 representation of an IPv4 address. The constraints imposed on the generation algorithms are the following:
DNS64支持多种算法来生成IPv4地址的IPv6表示形式。对生成算法施加的约束如下：
o The same algorithm to create an IPv6 address from an IPv4 address MUST be used by both a DNS64 to create the IPv6 address to be returned in the synthetic AAAA RR from the IPv4 address contained in an original A RR, and by an IPv6/IPv4 translator to create the IPv6 address to be included in the source address field of the outgoing IPv6 packets from the IPv4 address included in the source address field of the incoming IPv4 packet.
o DNS64和DNS64必须使用相同的算法从IPv4地址创建IPv6地址，以从原始a RR中包含的IPv4地址创建要在合成AAAA RR中返回的IPv6地址，以及由IPv6/IPv4转换器从包括在传入IPv4分组的源地址字段中的IPv4地址创建要包括在传出IPv6分组的源地址字段中的IPv6地址。
o The algorithm MUST be reversible; i.e., it MUST be possible to derive the original IPv4 address from the IPv6 representation.
o 算法必须是可逆的；i、 例如，必须能够从IPv6表示中派生原始IPv4地址。
o The input for the algorithm MUST be limited to the IPv4 address; the IPv6 prefix (denoted Pref64::/n) used in the IPv6 representations; and, optionally, a set of stable parameters that are configured in the DNS64 and in the NAT64 (such as a fixed string to be used as a suffix).
o 算法的输入必须限于IPv4地址；IPv6表示中使用的IPv6前缀（表示为Pref64:：/n）；以及可选地，在DNS64和NAT64中配置的一组稳定参数（例如用作后缀的固定字符串）。
* For each prefix Pref64::/n, n MUST be less than or equal to 96. If one or more Pref64::/n are configured in the DNS64 through any means (such as manual configuration, or other automatic means not specified in this document), the default algorithm MUST use these prefixes (and not use the Well-Known Prefix). If no prefix is available, the algorithm MUST use the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to represent the IPv4 unicast address range.
* 对于每个前缀Pref64:：/n，n必须小于或等于96。如果在DNS64中通过任何方式（如手动配置或本文档中未指定的其他自动方式）配置了一个或多个Pref64:：/n，则默认算法必须使用这些前缀（而不是使用众所周知的前缀）。如果没有可用的前缀，则算法必须使用[RFC6052]中定义的众所周知的前缀64:ff9b:：/96来表示IPv4单播地址范围。
A DNS64 MUST support the algorithm for generating IPv6 representations of IPv4 addresses defined in Section 2 of [RFC6052]. Moreover, the aforementioned algorithm MUST be the default algorithm used by the DNS64. While the normative description of the algorithm is provided in [RFC6052], a sample description of the algorithm and its application to different scenarios are provided in Section 7 for illustration purposes.
DNS64必须支持生成[RFC6052]第2节中定义的IPv4地址的IPv6表示的算法。此外，上述算法必须是DNS64使用的默认算法。虽然[RFC6052]中提供了算法的规范性描述，但第7节中提供了算法的示例描述及其在不同场景中的应用，以供说明。
If a DNS64 server receives a PTR query for a record in the IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the address portion of the QNAME according to the encoding scheme outlined in Section 2.5 of [RFC3596], and examine the resulting address to see whether its prefix matches any of the locally configured Pref64::/n or the default Well-Known Prefix. There are two alternatives for a DNS64 server to respond to such PTR queries. A DNS64 server MUST provide one of these, and SHOULD NOT provide both at the same time unless different IP6.ARPA zones require answers of different sorts:
如果DNS64服务器收到IP6.ARPA域中记录的PTR查询，则必须从QNAME中去除IP6.ARPA标签，根据[RFC3596]第2.5节中概述的编码方案反转QNAME的地址部分，并检查生成的地址，以查看其前缀是否与任何本地配置的Pref64:：/n或默认的已知前缀匹配。DNS64服务器有两种选择来响应此类PTR查询。DNS64服务器必须提供其中一个，并且不应同时提供这两个，除非不同的IP6.ARPA区域需要不同类型的答案：
1. The first option is for the DNS64 server to respond authoritatively for its prefixes. If the address prefix matches any Pref64::/n used in the site, either a NSP or the Well-Known Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the query using locally appropriate RDATA. The DNS64 server MAY use the same RDATA for all answers. Note that the requirement is to match any Pref64::/n used at the site, and not merely the locally configured Pref64::/n. This is because end clients could ask for a PTR record matching an address received through a different (site-provided) DNS64, and if this strategy is in effect, those queries should never be sent to the global DNS. The advantage of this strategy is that it makes plain to the querying client that the prefix is one operated by the (DNS64) site, and that the answers the client is getting are generated by DNS64. The disadvantage is that any useful reverse-tree information that might be in the global DNS is unavailable to the clients querying the DNS64.
1. 第一个选项是DNS64服务器对其前缀进行授权响应。如果地址前缀与站点中使用的任何Pref64:：/n匹配，NSP或众所周知的前缀（即64:ff9b:：/96），则DNS64服务器可以使用本地适当的RDATA回答查询。DNS64服务器可以对所有答案使用相同的RDATA。请注意，要求匹配站点上使用的任何Pref64:：/n，而不仅仅是本地配置的Pref64:：/n。这是因为最终客户端可能会请求与通过不同（站点提供的）DNS64接收的地址匹配的PTR记录，如果此策略有效，则这些查询不应发送到全局DNS。此策略的优点是，它使查询客户端明白前缀是由（DNS64）站点操作的前缀，并且客户端得到的答案是由DNS64生成的。缺点是，查询DNS64的客户端无法使用全局DNS中可能存在的任何有用的反向树信息。
2. The second option is for the DNS64 name server to synthesize a CNAME mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA name. In this case, the DNS64 name server SHOULD ensure that there is RDATA at the PTR of the corresponding IN-ADDR.ARPA name, and that there is not an existing CNAME at that name. This is in order to avoid synthesizing a CNAME that makes a CNAME chain longer or that does not actually point to
2. 第二个选项是DNS64名称服务器合成一个CNAME，将IP6.ARPA名称空间映射到相应的IN-ADDR.ARPA名称。在这种情况下，DNS64名称服务器应确保相应In-ADDR.ARPA名称的PTR处存在RDATA，并且该名称处不存在CNAME。这是为了避免合成使CNAME链更长或实际上不指向的CNAME
anything. The rest of the response would be the normal DNS processing. The CNAME can be signed on the fly if need be. The advantage of this approach is that any useful information in the reverse tree is available to the querying client. The disadvantages are that it adds additional load to the DNS64 (because CNAMEs have to be synthesized for each PTR query that matches the Pref64::/n), and that it may require signing on the fly.
任何东西响应的其余部分将是正常的DNS处理。如果需要，可以动态签署CNAME。这种方法的优点是，查询客户机可以使用反向树中的任何有用信息。缺点是它给DNS64增加了额外的负载（因为必须为每个与Pref64:：/n匹配的PTR查询合成CNAMEs），并且可能需要动态签名。
If the address prefix does not match any Pref64::/n, then the DNS64 server MUST process the query as though it were any other query; i.e., a recursive name server MUST attempt to resolve the query as though it were any other (non-A/AAAA) query, and an authoritative server MUST respond authoritatively or with a referral, as appropriate.
如果地址前缀与任何Pref64:：/n不匹配，则DNS64服务器必须像处理任何其他查询一样处理该查询；i、 例如，递归名称服务器必须尝试解析该查询，就像解析任何其他（非a/AAAA）查询一样，并且权威服务器必须根据需要以权威方式或引用方式进行响应。
DNS64 synthesis MUST NOT be performed on any records in the additional section of synthesized answers. The DNS64 MUST pass the additional section unchanged.
不得对合成答案附加部分中的任何记录执行DNS64合成。DNS64必须以不变的方式通过附加部分。
NOTE: It may appear that adding synthetic records to the additional section is desirable, because clients sometimes use the data in the additional section to proceed without having to re-query. There is in general no promise, however, that the additional section will contain all the relevant records, so any client that depends on the additional section being able to satisfy its needs (i.e., without additional queries) is necessarily broken. An IPv6-only client that needs a AAAA record, therefore, will send a query for the necessary AAAA record if it is unable to find such a record in the additional section of an answer it is consuming. For a correctly functioning client, the effect would be no different if the additional section were empty. The alternative of removing the A records in the additional section and replacing them with synthetic AAAA records may cause a host behind a NAT64 to query directly a name server that is unaware of the NAT64 in question. The result in this case will be resolution failure anyway, but later in the resolution operation. The prohibition on synthetic data in the additional section reduces, but does not eliminate, the possibility of resolution failures due to cached DNS data from behind the DNS64. See Section 6.
注意：向附加部分添加合成记录似乎是可取的，因为客户端有时使用附加部分中的数据来继续操作，而无需重新查询。但是，一般来说，没有承诺附加部分将包含所有相关记录，因此任何依赖附加部分能够满足其需求（即无需附加查询）的客户都必然会被打破。因此，需要AAAA记录的仅限IPv6的客户端如果无法在其正在使用的应答的附加部分中找到所需的AAAA记录，则将发送对该记录的查询。对于功能正常的客户端，如果附加部分为空，效果也不会有什么不同。删除附加部分中的A记录并将其替换为合成AAAA记录的替代方案可能会导致NAT64后面的主机直接查询不知道有问题的NAT64的名称服务器。这种情况下的结果将是解析失败，但稍后将在解析操作中失败。附加部分中对合成数据的禁止减少但不能消除由于来自DNS64后面的缓存DNS数据而导致解析失败的可能性。见第6节。
If the DNS64 is in recursive-resolver mode, then considerations outlined in [DEFAULT-LOCAL-ZONES] may be relevant.
如果DNS64处于递归解析器模式，则[DEFAULT-LOCAL-ZONES]中列出的注意事项可能相关。
All other RRs MUST be returned unchanged. This includes responses to queries for A RRs.
所有其他RRs必须原封不动地返回。这包括对RRs查询的响应。
A DNS64 uses different pieces of data to build the response returned to the querying client.
DNS64使用不同的数据段构建返回给查询客户端的响应。
The query that is used as the basis for synthesis results either in an error, an answer that can be used as a basis for synthesis, or an empty (authoritative) answer. If there is an empty answer, then the DNS64 responds to the original querying client with the answer the DNS64 received to the original (initiator's) query. Otherwise, the response is assembled as follows.
用作合成基础的查询会导致错误、可用作合成基础的答案或空（权威）答案。如果存在空答案，则DNS64使用DNS64接收到的原始（发起方）查询的答案响应原始查询客户端。否则，响应的组装如下。
The header fields are set according to the usual rules for recursive or authoritative servers, depending on the role that the DNS64 is serving. The question section is copied from the original (initiator's) query. The answer section is populated according to the rules in Section 5.1.7. The authority and additional sections are copied from the response to the final query that the DNS64 performed, and used as the basis for synthesis.
根据递归或权威服务器的常规规则设置标头字段，具体取决于DNS64所服务的角色。问题部分是从原始（发起者的）查询中复制的。答案部分根据第5.1.7节中的规则填充。权限和附加部分从DNS64执行的最终查询的响应中复制，并用作合成的基础。
The final response from the DNS64 is subject to all the standard DNS rules, including truncation [RFC1035] and EDNS0 handling [RFC2671].
DNS64的最终响应受所有标准DNS规则的约束，包括截断[RFC1035]和EDNS0处理[RFC2671]。
We consider the case where a recursive resolver that is performing DNS64 also has a local policy to validate the answers according to the procedures outlined in [RFC4035], Section 5. We call this general case vDNS64.
我们考虑的情况下，执行DNS64的递归解析器也有一个本地策略来验证答案（根据[RCF4035]，第5节中所概述的过程）。我们称之为一般情况vDNS64。
The vDNS64 uses the presence of the DO and CD bits to make some decisions about what the query originator needs, and can react accordingly:
vDNS64使用DO和CD位的存在来决定查询发起人需要什么，并可以做出相应的反应：
1. If CD is not set and DO is not set, vDNS64 SHOULD perform validation and do synthesis as needed. See the next item for rules about how to do validation and synthesis. In this case, however, vDNS64 MUST NOT set the AD bit in any response.
1. 如果未设置CD且未设置DO，vDNS64应根据需要执行验证并进行合成。有关如何进行验证和合成的规则，请参见下一项。但是，在这种情况下，vDNS64不得在任何响应中设置AD位。
2. If CD is not set and DO is set, then vDNS64 SHOULD perform validation. Whenever vDNS64 performs validation, it MUST validate the negative answer for AAAA queries before proceeding to query for A records for the same name, in order to be sure that there is not a legitimate AAAA record on the Internet. Failing to observe this step would allow an attacker to use DNS64 as a mechanism to circumvent DNSSEC. If the negative response validates, and the response to the A query validates, then the vDNS64 MAY perform synthesis and SHOULD set the AD bit in the answer to the client. This is acceptable, because [RFC4035], Section 3.2.3 says that the AD bit is set by the name server side of a security-aware recursive name server if and only if it considers all the RRSets in the answer and authority sections to be authentic. In this case, the name server has reason to believe the RRSets are all authentic, so it SHOULD set the AD bit. If the data does not validate, the vDNS64 MUST respond with RCODE=2 (Server failure).
2. 如果未设置CD且已设置DO，则vDNS64应执行验证。每当vDNS64执行验证时，它必须验证AAAA查询的否定答案，然后再继续查询同名的记录，以确保Internet上没有合法的AAAA记录。如果不遵守此步骤，攻击者可以使用DNS64作为绕过DNSSEC的机制。如果否定响应验证，并且对A查询的响应验证，则vDNS64可以执行合成，并应在客户机的答案中设置AD位。这是可以接受的，因为[RFC4035]第3.2.3节规定，AD位由安全感知递归名称服务器的名称服务器端设置，当且仅当它认为应答和权限部分中的所有RRSET都是可信的时。在这种情况下，名称服务器有理由相信rrset都是可信的，因此它应该设置AD位。如果数据未验证，vDNS64必须响应RCODE=2（服务器故障）。
A security-aware end point might take the presence of the AD bit as an indication that the data is valid, and may pass the DNS (and DNSSEC) data to an application. If the application attempts to validate the synthesized data, of course, the validation will fail. One could argue therefore that this approach is not desirable, but security-aware stub resolvers must not place any reliance on data received from resolvers and validated on their behalf without certain criteria established by [RFC4035], Section 4.9.3. An application that wants to perform validation on its own should use the CD bit.
安全感知端点可以将AD位的存在作为数据有效的指示，并可以将DNS（和DNSSEC）数据传递给应用程序。当然，如果应用程序尝试验证合成数据，验证将失败。因此，有人可能会认为这种方法不可取，但在没有[RFC4035]第4.9.3节规定的特定标准的情况下，安全意识存根解析程序不得依赖从解析程序接收并代表解析程序验证的数据。要自行执行验证的应用程序应使用CD位。
3. If the CD bit is set and DO is set, then vDNS64 MAY perform validation, but MUST NOT perform synthesis. It MUST return the data to the query initiator, just like a regular recursive resolver, and depend on the client to do the validation and the synthesis itself.
3. 如果设置了CD位并设置了DO，则vDNS64可以执行验证，但不能执行合成。它必须将数据返回给查询发起程序，就像常规的递归解析器一样，并依靠客户机自己进行验证和合成。
The disadvantage to this approach is that an end point that is translation-oblivious but security-aware and validating will not be able to use the DNS64 functionality. In this case, the end point will not have the desired benefit of NAT64. In effect, this strategy means that any end point that wishes to do validation in a NAT64 context must be upgraded to be translation-aware as well.
这种方法的缺点是，不考虑翻译但具有安全意识和验证的端点将无法使用DNS64功能。在这种情况下，终点将不会有NAT64所期望的好处。实际上，这种策略意味着任何希望在NAT64上下文中进行验证的端点也必须升级为翻译感知。
While DNS64 is intended to be part of a strategy for aiding IPv6 deployment in an internetworking environment with some IPv4-only and IPv6-only networks, it is important to realize that it is incompatible with some things that may be deployed in an IPv4-only or dual-stack context.
虽然DNS64旨在成为帮助在具有某些仅IPv4和仅IPv6网络的互联环境中部署IPv6的策略的一部分，但必须认识到它与可能在仅IPv4或双堆栈上下文中部署的某些内容不兼容。
Full-service resolvers that are unaware of the DNS64 function can be (mis)configured to act as mixed-mode iterative and forwarding resolvers. In a native IPv4 context, this sort of configuration may appear to work. It is impossible to make it work properly without it being aware of the DNS64 function, because it will likely at some point obtain IPv4-only glue records and attempt to use them for resolution. The result that is returned will contain only A records, and without the ability to perform the DNS64 function the resolver will be unable to answer the necessary AAAA queries.
不知道DNS64功能的完整服务解析程序可以（mis）配置为充当混合模式迭代和转发解析程序。在本机IPv4上下文中，这种配置似乎可以工作。在不知道DNS64函数的情况下，要使其正常工作是不可能的，因为它可能会在某个时候获取仅IPv4的粘合记录，并尝试使用它们进行解析。返回的结果将只包含一条记录，如果无法执行DNS64函数，解析程序将无法回答必要的AAAA查询。
An existing DNSSEC validator (i.e., one that is unaware of DNS64) might reject all the data that comes from DNS64 as having been tampered with (even if it did not set CD when querying). If it is necessary to have validation behind the DNS64, then the validator must know how to perform the DNS64 function itself. Alternatively, the validating host may establish a trusted connection with a DNS64, and allow the DNS64 recursive resolver to do all validation on its behalf.
现有的DNSSEC验证器（即，不知道DNS64的验证器）可能会拒绝来自DNS64的所有数据，因为这些数据已被篡改（即使在查询时未设置CD）。如果需要在DNS64后面进行验证，则验证程序必须知道如何执行DNS64函数本身。或者，验证主机可以与DNS64建立可信连接，并允许DNS64递归解析器代表其执行所有验证。
Synthetic AAAA records may be constructed on the basis of the network context in which they were constructed. If a host sends DNS queries to resolvers in multiple networks, it is possible that some of them will receive answers from a DNS64 without all of them being connected via a NAT64. For instance, suppose a system has two interfaces, i1 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 has native IPv6 connectivity only. I1 might receive a AAAA answer from a DNS64 that is configured for a particular NAT64; the IPv6 address contained in that AAAA answer will not connect with anything via i2.
合成AAAA记录可以基于构建它们的网络上下文来构建。如果主机向多个网络中的解析程序发送DNS查询，则其中一些解析程序可能会收到来自DNS64的应答，而不会通过NAT64连接所有解析程序。例如，假设一个系统有两个接口，i1和i2。i1通过NAT64连接到IPv4 Internet，而i2仅具有本机IPv6连接。I1可以从为特定NAT64配置的DNS64接收AAAA应答；AAAA应答中包含的IPv6地址将不会通过i2与任何内容连接。
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv6)+-----------------+IPv6 Internet|
+---------------+ +-------------+
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv6)+-----------------+IPv6 Internet|
+---------------+ +-------------+
Figure 1: IPv6 Multihomed Hosts
图1:IPv6多宿主主机
This example illustrates why it is generally preferable that hosts treat DNS answers from one interface as local to that interface. The answer received on one interface will not work on the other interface. Hosts that attempt to use DNS answers globally may encounter surprising failures in these cases.
此示例说明了为什么主机通常更倾向于将一个接口的DNS应答视为该接口的本地应答。在一个接口上收到的答案在另一个接口上不起作用。在这些情况下，尝试全局使用DNS应答的主机可能会遇到意外的失败。
Note that the issue is not that there are two interfaces, but that there are two networks involved. The same results could be achieved with a single interface routed to two different networks.
请注意，问题不是有两个接口，而是涉及两个网络。同样的结果也可以通过将一个接口路由到两个不同的网络来实现。
Similarly, suppose that i1 has IPv6 connectivity and can connect to the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity. In this case, i1 could receive an IPv6 address from a synthetic AAAA that would better be reached via native IPv4. Again, it is worth emphasizing that this arises because there are two networks involved.
类似地，假设i1具有IPv6连接，并且可以通过NAT64连接到IPv4 Internet，但i2具有本机IPv4连接。在这种情况下，i1可以从合成AAAA接收IPv6地址，该地址最好通过本机IPv4到达。同样，值得强调的是，这是因为涉及到两个网络。
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv4)+-----------------+IPv4 Internet|
+---------------+ +-------------+
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv4)+-----------------+IPv4 Internet|
+---------------+ +-------------+
Figure 2: Accidental Dual-Stack DNS64 Use
图2：意外使用双堆栈DNS64
The default configuration of dual-stack hosts is that IPv6 is preferred over IPv4 ([RFC3484]). In that arrangement, the host will often use the NAT64 when native IPv4 would be more desirable. For this reason, hosts with IPv4 connectivity to the Internet should avoid using DNS64. This can be partly resolved by ISPs when providing DNS resolvers to clients, but that is not a guarantee that
双栈主机的默认配置是IPv6优先于IPv4（[RFC3484]）。在这种安排下，当本机IPv4更理想时，主机将经常使用NAT64。因此，与Internet具有IPv4连接的主机应避免使用DNS64。当向客户端提供DNS解析程序时，ISP可以部分解决这一问题，但这并不能保证
the NAT64 will never be used when a native IPv4 connection should be used. There is no general-purpose mechanism to ensure that native IPv4 transit will always be preferred, because to a DNS64-oblivious host, the DNS64 looks just like an ordinary DNS server. Operators of a NAT64 should expect traffic to pass through the NAT64 even when it is not necessary.
当应使用本机IPv4连接时，将永远不会使用NAT64。没有通用机制来确保本机IPv4传输始终是首选，因为对于DNS64不经意的主机，DNS64看起来就像普通的DNS服务器。NAT64的运营商应该期望流量通过NAT64，即使在没有必要的情况下。
Finally, consider the case where the IPv4 connectivity on i2 is only with a LAN, and not with the IPv4 Internet. The IPv4 Internet is only accessible using the NAT64. In this case, it is critical that the DNS64 not synthesize AAAA responses for hosts in the LAN, or else that the DNS64 be aware of hosts in the LAN and provide context-sensitive answers ("split view" DNS answers) for hosts inside the LAN. As with any split view DNS arrangement, operators must be prepared for data to leak from one context to another, and for failures to occur because nodes accessible from one context are not accessible from the other.
最后，考虑在IP2上的IPv4连接性仅使用LAN，而不与IPv4互联网连接的情况。IPv4 Internet只能使用NAT64访问。在这种情况下，至关重要的是DNS64不能为LAN中的主机合成AAAA响应，否则DNS64应该知道LAN中的主机，并为LAN中的主机提供上下文敏感的应答（“拆分视图”DNS应答）。与任何拆分视图DNS安排一样，运营商必须做好准备，以防数据从一个上下文泄漏到另一个上下文，并防止发生故障，因为从一个上下文访问的节点无法从另一个上下文访问。
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| |
| i2 (IPv4)+---(local LAN only)
+---------------+
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| |
| i2 (IPv4)+---(local LAN only)
+---------------+
Figure 3: Intentional Dual-Stack DNS64 Use
图3：有意使用双堆栈DNS64
It is important for deployers of DNS64 to realize that, in some circumstances, making the DNS64 available to a dual-stack host will cause the host to prefer to send packets via NAT64 instead of via native IPv4, with the associated loss of performance or functionality (or both) entailed by the NAT. At the same time, some hosts are not able to learn about DNS servers provisioned on IPv6 addresses, or simply cannot send DNS packets over IPv6.
DNS64的部署人员必须认识到，在某些情况下，使DNS64可用于双栈主机将导致主机倾向于通过NAT64而不是通过本机IPv4发送数据包，NAT会导致相关的性能或功能损失（或两者兼而有之）。同时，一些主机无法了解在IPv6地址上配置的DNS服务器，或者根本无法通过IPv6发送DNS数据包。
In this section, we illustrate how the DNS64 behaves in different scenarios that are expected to be common. In particular, we will consider the following scenarios defined in [RFC6144]: the "an IPv6 network to the IPv4 Internet" scenario (both with DNS64 in DNS server mode and in stub-resolver mode) and the "IPv6 Internet to an IPv4 network" setup (with DNS64 in DNS server mode only).
在本节中，我们将说明DNS64在不同场景中的行为，这些场景可能很常见。特别地，我们将考虑在[RCF6144]中定义的以下场景：“IPv4网络到IPv4 Internet”场景（既有DNS服务器在DNS服务器模式下，也有存根解析器模式）和“IPv6 Internet到IPv4网络”设置（只有DNS64在DNS服务器模式下）。
In all the examples below, there is an IPv6/IPv4 translator connecting the IPv6 domain to the IPv4 one. Also, there is a name server that is a dual-stack node, so it can communicate with IPv6 hosts using IPv6 and with IPv4 nodes using IPv4. In addition, we assume that in the examples, the DNS64 function learns which IPv6 prefix it needs to use to map the IPv4 address space through manual configuration.
在下面的所有示例中，有一个IPv6/IPv4转换器将IPv6域连接到IPv4域。此外，还有一个名称服务器是双堆栈节点，因此它可以使用IPv6与IPv6主机通信，也可以使用IPv4与IPv4节点通信。此外，我们假设在示例中，DNS64函数通过手动配置了解需要使用哪个IPv6前缀来映射IPv4地址空间。
7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode
7.1. 在DNS服务器模式下使用DNS64设置“到IPv4 Internet的IPv6网络”的示例
In this example, we consider an IPv6 node located in an IPv6-only site that initiates a communication to an IPv4 node located in the IPv4 Internet.
在这个例子中，我们考虑位于IPv6唯一站点的IPv6节点，该节点发起IPv4节点到IPv4 Internet的通信。
The scenario for this case is depicted in the following figure:
下图描述了这种情况的场景：
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | Internet |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +------------+ | 192.0.2.1 |
| |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | Internet |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +------------+ | 192.0.2.1 |
| |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
Figure 4: "An IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode
图4：DNS服务器模式下DNS64的“IPv6网络到IPv4 Internet”设置
The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
此图显示了IPv4地址为192.0.2.1和FQDN H2.example.com的IPv6节点H1和IPv4节点H2。
The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in the local name server.
IPv6/IPv4转换器将IPv4地址203.0.113.1分配给其IPv4接口，并使用众所周知的前缀64:ff9b:：/96创建IPv4地址的IPv6表示形式。本地名称服务器中的DNS64函数中配置了相同的前缀。
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs recursive lookups (henceforth called "the recursive name server").
对于本例，假设典型的DNS情况，其中IPv6主机只有存根解析程序，并且它们配置有名称服务器的IP地址，它们必须始终查询该名称服务器并执行递归查找（此后称为“递归名称服务器”）。
The steps by which H1 establishes communication with H2 are:
H1与H2建立通信的步骤如下：
1. H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2 to the recursive name server. The recursive name server implements DNS64 functionality.
1. H1对h2.example.com进行DNS查找。H1通过向递归名称服务器发送H2的AAAA记录的DNS查询来实现这一点。递归名称服务器实现DNS64功能。
2. The recursive name server resolves the query, and discovers that there are no AAAA records for H2.
2. 递归名称服务器解析查询，并发现H2没有AAAA记录。
3. The recursive name server performs an A-record query for H2 and gets back an RRSet containing a single A record with the IPv4 address 192.0.2.1. The name server then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits and the received IPv4 address in the lower 32 bits; i.e., the resulting IPv6 address is 64:ff9b::192.0.2.1.
3. 递归名称服务器对H2执行A-record查询，并获取包含单个A记录的RRSet，该A记录的IPv4地址为192.0.2.1。名称服务器然后合成AAAA记录。AAAA记录中的IPv6地址在高96位包含分配给IPv6/IPv4转换器的前缀，在低32位包含接收到的IPv4地址；i、 例如，生成的IPv6地址是64:ff9b:：192.0.2.1。
4. H1 receives the synthetic AAAA record and sends a packet towards H2. The packet is sent to the destination address 64:ff9b:: 192.0.2.1.
4. H1接收合成AAAA记录并向H2发送数据包。数据包被发送到目标地址64:ff9b:：192.0.2.1。
5. The packet is routed to the IPv6 interface of the IPv6/IPv4 translator, and the subsequent communication flows by means of the IPv6/IPv4 translator mechanisms.
5. 数据包被路由到IPv6/IPv4转换器的IPv6接口，随后的通信通过IPv6/IPv4转换器机制进行。
7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode
7.2. 在存根解析器模式下使用DNS64设置“到IPv4 Internet的IPv6网络”的示例
This case is depicted in the following figure:
下图描述了这种情况：
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +--------+ | Internet |
| |-----| Name |----| |
| +-----+ | | server | | +----+ |
| | H1 | | +--------+ | | H2 | |
| |with |---| | | +----+ |
| |DNS64| | +------------+ | 192.0.2.1 |
| +----+ |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +--------+ | Internet |
| |-----| Name |----| |
| +-----+ | | server | | +----+ |
| | H1 | | +--------+ | | H2 | |
| |with |---| | | +----+ |
| |DNS64| | +------------+ | 192.0.2.1 |
| +----+ |---| IPv6/IPv4 |--| |
| | | Translator | | |
| | +------------+ | |
| | | | |
+---------------------+ +---------------+
Figure 5: "An IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode
图5：“连接IPv4 Internet的IPv6网络”设置，DNS64处于存根解析器模式
The figure shows an IPv6 node H1 implementing the DNS64 function and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
此图显示了实现DNS64功能的IPv6节点H1和IPv4地址为192.0.2.1和FQDN H2.example.com的IPv4节点H2。
The IPv6/IPv4 translator has an IPv4 address 203.0.113.1 assigned to its IPv4 interface, and it is using the Well-Known Prefix 64:ff9b::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in H1.
IPv6/IPv4转换器将IPv4地址203.0.113.1分配给其IPv4接口，并使用众所周知的前缀64:ff9b:：/96创建IPv4地址的IPv6表示形式。在H1中的DNS64函数中配置了相同的前缀。
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and they are configured with the IP address of a name server that they always have to query and that performs recursive lookups (henceforth called "the recursive name server"). The recursive name server does not perform the DNS64 function.
对于本例，假设典型的DNS情况，其中IPv6主机只有存根解析程序，并且它们配置有名称服务器的IP地址，它们必须始终查询该名称服务器并执行递归查找（此后称为“递归名称服务器”）。递归名称服务器不执行DNS64功能。
The steps by which H1 establishes communication with H2 are:
H1与H2建立通信的步骤如下：
1. H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2 to the recursive name server.
1. H1对h2.example.com进行DNS查找。H1通过向递归名称服务器发送H2的AAAA记录的DNS查询来实现这一点。
2. The recursive DNS server resolves the query, and returns the answer to H1. Because there are no AAAA records in the global DNS for H2, the answer is empty.
2. 递归DNS服务器解析查询，并将答案返回到H1。由于H2的全局DNS中没有AAAA记录，因此答案为空。
3. The stub resolver at H1 then queries for an A record for H2 and gets back an A record containing the IPv4 address 192.0.2.1. The DNS64 function within H1 then synthesizes a AAAA record. The IPv6 address in the AAAA record contains the prefix assigned to the IPv6/IPv4 translator in the upper 96 bits, then the received IPv4 address in the lower 32 bits; the resulting IPv6 address is 64:ff9b::192.0.2.1.
3. H1的存根解析器然后查询H2的A记录，并返回包含IPv4地址192.0.2.1的A记录。H1中的DNS64函数然后合成AAAA记录。AAAA记录中的IPv6地址包含分配给IPv6/IPv4转换器的前缀（高96位），然后是接收到的IPv4地址（低32位）；生成的IPv6地址是64:ff9b:：192.0.2.1。
4. H1 sends a packet towards H2. The packet is sent to the destination address 64:ff9b::192.0.2.1.
4. H1向H2发送数据包。数据包被发送到目标地址64:ff9b:：192.0.2.1。
5. The packet is routed to the IPv6 interface of the IPv6/IPv4 translator and the subsequent communication flows using the IPv6/ IPv4 translator mechanisms.
5. 数据包被路由到IPv6/IPv4转换器的IPv6接口，随后的通信流使用IPv6/IPv4转换器机制。
7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode
7.3. 在DNS服务器模式下使用DNS64设置“IPv6 Internet到IPv4网络”的示例
In this example, we consider an IPv6 node located in the IPv6 Internet that initiates a communication to an IPv4 node located in the IPv4 site.
在这个例子中，我们考虑位于IPv6 Internet中的IPv6节点，该节点发起IPv4节点到IPv4站点的通信。
In some cases, this scenario can be addressed without using any form of DNS64 function. This is because it is possible to assign a fixed IPv6 address to each of the IPv4 nodes. Such an IPv6 address would be constructed using the address transformation algorithm defined in [RFC6052] that takes as input the Pref64::/96 and the IPv4 address of the IPv4 node. Note that the IPv4 address can be a public or a private address; the latter does not present any additional difficulty, since an NSP must be used as Pref64::/96 (in this scenario, the usage of the Well-Known Prefix is not supported as discussed in [RFC6052]). Once these IPv6 addresses have been assigned to represent the IPv4 nodes in the IPv6 Internet, real AAAA RRs containing these addresses can be published in the DNS under the site's domain. This is the recommended approach to handle this scenario, because it does not involve synthesizing AAAA records at the time of query.
在某些情况下，可以在不使用任何形式的DNS64函数的情况下解决此场景。这是因为可以为每个IPv4节点分配固定的IPv6地址。这种IPv6地址将使用[RFC6052]中定义的地址转换算法构造，该算法将Pref64:：/96和IPv4节点的IPv4地址作为输入。请注意，IPv4地址可以是公用地址或专用地址；后者不存在任何额外的困难，因为NSP必须用作Pref64:：/96（在这种情况下，不支持使用已知前缀，如[RFC6052]中所述）。一旦这些IPv6地址被分配代表IPv6 Internet中的IPv4节点，包含这些地址的真正AAAA RRs就可以在站点域下的DNS中发布。这是处理此场景的推荐方法，因为它不涉及在查询时合成AAAA记录。
However, there are some more dynamic scenarios, where synthesizing AAAA RRs in this setup may be needed. In particular, when DNS Update [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 nodes, there are two options. One option is to modify the DNS server that receives the dynamic DNS updates. That would normally be the authoritative server for the zone. So the authoritative zone would have normal AAAA RRs that are synthesized as dynamic updates occur. The other option is to modify all of the authoritative servers to generate synthetic AAAA records for a zone, possibly based on additional constraints, upon the receipt of a DNS query for the AAAA RR. The first option -- in which the AAAA is synthesized when the DNS update message is received, and the data published in the relevant zone -- is recommended over the second option (i.e., the synthesis upon receipt of the AAAA DNS query). This is because it is usually easier to solve problems of misconfiguration when the DNS responses are not being generated dynamically. However, it may be the case where the primary server (that receives all the updates) cannot be upgraded for whatever reason, but where a secondary can be upgraded in order to handle the (comparatively small amount of) AAAA queries. In such a case, it is possible to use the DNS64 as described next. The DNS64 behavior that we describe in this section covers the case of synthesizing the AAAA RR when the DNS query arrives.
但是，还有一些更动态的场景，可能需要在此设置中合成AAAA RRs。特别是，当在IPv4站点中使用DNS更新[RFC2136]来更新IPv4节点的RRs时，有两个选项。一个选项是修改接收动态DNS更新的DNS服务器。这通常是该区域的权威服务器。因此，在动态更新发生时，权威区域将具有正常的AAAA RRs。另一个选项是，在收到AAAA RR的DNS查询后，修改所有权威服务器以生成区域的合成AAAA记录（可能基于其他约束）。第一个选项——当收到DNS更新消息时合成AAAA，并在相关区域中发布数据——建议优于第二个选项（即，在收到AAAA DNS查询时合成）。这是因为当DNS响应不是动态生成时，通常更容易解决配置错误的问题。但是，在这种情况下，可能由于任何原因无法升级主服务器（接收所有更新），但可以升级辅助服务器以处理（相对较少的）AAAA查询。在这种情况下，可以如下面所述使用DNS64。我们在本节中描述的DNS64行为涵盖了在DNS查询到达时合成AAAA RR的情况。
The scenario for this case is depicted in the following figure:
下图描述了这种情况的场景：
+-----------+ +----------------------+
| | | IPv4 site |
| IPv6 | +------------+ | +----+ |
| Internet |----| IPv6/IPv4 |--|---| H2 | |
| | | Translator | | +----+ |
| | +------------+ | |
| | | | 192.0.2.1 |
| | +------------+ | |
| |----| Name server|--| |
| | | with DNS64 | | |
+-----------+ +------------+ | |
| | | |
+----+ | |
| H1 | +----------------------+
+----+
+-----------+ +----------------------+
| | | IPv4 site |
| IPv6 | +------------+ | +----+ |
| Internet |----| IPv6/IPv4 |--|---| H2 | |
| | | Translator | | +----+ |
| | +------------+ | |
| | | | 192.0.2.1 |
| | +------------+ | |
| |----| Name server|--| |
| | | with DNS64 | | |
+-----------+ +------------+ | |
| | | |
+----+ | |
| H1 | +----------------------+
+----+
Figure 6: "The IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode
图6：DNS服务器模式下DNS64的“IPv6 Internet到IPv4网络”设置
The figure shows an IPv6 node H1 and an IPv4 node H2 with the IPv4 address 192.0.2.1 and FQDN h2.example.com.
此图显示了IPv4地址为192.0.2.1和FQDN H2.example.com的IPv6节点H1和IPv4节点H2。
The IPv6/IPv4 translator is using an NSP 2001:db8::/96 to create IPv6 representations of IPv4 addresses. The same prefix is configured in the DNS64 function in the local name server. The name server that implements the DNS64 function is the authoritative name server for the local domain.
IPv6/IPv4转换器正在使用NSP 2001:db8:：/96创建IPv4地址的IPv6表示形式。本地名称服务器中的DNS64函数中配置了相同的前缀。实现DNS64功能的名称服务器是本地域的权威名称服务器。
The steps by which H1 establishes communication with H2 are:
H1与H2建立通信的步骤如下：
1. H1 does a DNS lookup for h2.example.com. H1 does this by sending a DNS query for a AAAA record for H2. The query is eventually forwarded to the server in the IPv4 site.
1. H1对h2.example.com进行DNS查找。H1通过发送H2的AAAA记录的DNS查询来实现这一点。查询最终被转发到IPv4站点中的服务器。
2. The local DNS server resolves the query (locally), and discovers that there are no AAAA records for H2.
2. 本地DNS服务器解析查询（本地），并发现H2没有AAAA记录。
3. The name server verifies that h2.example.com and its A RR are among those that the local policy defines as allowed to generate a AAAA RR. If that is the case, the name server synthesizes a AAAA record from the A RR and the prefix 2001:db8::/96. The IPv6 address in the AAAA record is 2001:db8::192.0.2.1.
3. 名称服务器验证h2.example.com及其A RR是否在本地策略定义为允许生成AAAA RR的范围内。如果是这种情况，名称服务器将根据a RR和前缀2001:db8:：/96合成AAAA记录。AAAA记录中的IPv6地址是2001:db8:：192.0.2.1。
4. H1 receives the synthetic AAAA record and sends a packet towards H2. The packet is sent to the destination address 2001:db8:: 192.0.2.1.
4. H1接收合成AAAA记录并向H2发送数据包。数据包被发送到目标地址2001:db8:：192.0.2.1。
5. The packet is routed through the IPv6 Internet to the IPv6 interface of the IPv6/IPv4 translator and the communication flows using the IPv6/IPv4 translator mechanisms.
5. 数据包通过IPv6 Internet路由到IPv6/IPv4转换器的IPv6接口，通信流使用IPv6/IPv4转换器机制。
DNS64 operates in combination with the DNS, and is therefore subject to whatever security considerations are appropriate to the DNS mode in which the DNS64 is operating (i.e., authoritative, recursive, or stub-resolver mode).
DNS64与DNS一起运行，因此需要考虑适合DNS64运行的DNS模式的任何安全因素（即，权威、递归或存根解析器模式）。
DNS64 has the potential to interfere with the functioning of DNSSEC, because DNS64 modifies DNS answers, and DNSSEC is designed to detect such modifications and to treat modified answers as bogus. See the discussion above in Sections 3, 5.5, and 6.2.
DNS64有可能干扰DNSSEC的功能，因为DNS64修改DNS应答，而DNSSEC旨在检测此类修改并将修改后的应答视为伪造应答。见上文第3、5.5和6.2节中的讨论。
Additionally, for the correct functioning of the translation services, the DNS64 and the NAT64 need to use the same Pref64. If an attacker manages to change the Pref64 used by the DNS64, the traffic generated by the host that receives the synthetic reply will be delivered to the altered Pref64. This can result in either a denial-of-service (DoS) attack (if the resulting IPv6 addresses are not assigned to any device), a flooding attack (if the resulting IPv6 addresses are assigned to devices that do not wish to receive the traffic), or an eavesdropping attack (in case the Pref64 is routed through the attacker).
此外，为了使翻译服务正常工作，DNS64和NAT64需要使用相同的Pref64。如果攻击者成功更改了DNS64使用的Pref64，则接收合成回复的主机生成的通信量将传送到更改后的Pref64。这可能导致拒绝服务（DoS）攻击（如果生成的IPv6地址未分配给任何设备）、泛洪攻击（如果生成的IPv6地址分配给不希望接收流量的设备）或窃听攻击（如果Pref64通过攻击者路由）。
Dave Thaler Microsoft dthaler@windows.microsoft.com
戴夫·泰勒微软公司dthaler@windows.microsoft.com
This document contains the result of discussions involving many people, including the participants of the IETF BEHAVE Working Group. The following IETF participants made specific contributions to parts of the text, and their help is gratefully acknowledged: Jaap Akkerhuis, Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao, Hui Deng, Francis Dupont, Patrik Faltstrom, David Harrington, Ed Jankiewicz, Peter Koch, Suresh Krishnan, Martti Kuparinen, Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Jeff Westhead, Florian Weimer, Dan Wing, Xu Xiaohu, and Xiangsong Cui.
本文件包含许多人参与的讨论结果，包括IETF工作组的参与者。以下IETF参与者对部分文本做出了具体贡献，感谢他们的帮助：雅普·阿克赫斯、马克·安德鲁斯、雅里·阿尔科、罗布·奥斯汀、蒂莫西·鲍德温、弗雷德·贝克、道格·巴顿、马克·布兰切特、卡梅隆·伯恩、布赖恩·卡彭特、曹震、邓晖、弗朗西斯·杜邦、帕特里克·法尔茨特罗姆、大卫·哈林顿、，Ed Jankiewicz、Peter Koch、Suresh Krishnan、Martti Kuparinen、Ed Lewis、Xing Li、Bill Manning、Matthijs Mekking、Hiroshi Miyata、Simon Perrault、Teemu Savolainen、Jyrki Soini、Dave Thaler、Mark Townsley、Rick van Rein、Stig Venaas、Magnus Westerlund、Jeff Westhead、Florian Weimer、Dan Wing、徐小虎和崔祥松。
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnulo和Iljitsch van Beijnum的部分资金来自Trilogy，该研究项目由欧盟委员会第七个框架计划支持。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[DEFAULT-LOCAL-ZONES] Andrews, M., "Locally-served DNS Zones", Work in Progress, March 2011.
[DEFAULT-LOCAL-ZONES]Andrews，M.，“本地服务DNS区域”，正在进行的工作，2011年3月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[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月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4074]Morishita，Y.和T.Jinmei，“针对IPv6地址的DNS查询的常见错误行为”，RFC 4074，2005年5月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist
附录A.真实AAAA资源记录存在时合成AAAA资源记录的动机和影响
The motivation for synthesizing AAAA RRs when real AAAA RRs exist is to support the following scenario:
当存在真正的AAAA RRs时，合成AAAA RRs的动机是支持以下场景：
o An IPv4-only server application (e.g., web server software) is running on a dual-stack host. There may also be dual-stack server applications running on the same host. That host has fully routable IPv4 and IPv6 addresses, and hence the authoritative DNS server has an A record and a AAAA record.
o 仅IPv4服务器应用程序（例如web服务器软件）正在双堆栈主机上运行。在同一主机上还可能运行双堆栈服务器应用程序。该主机具有完全可路由的IPv4和IPv6地址，因此权威DNS服务器具有A记录和AAAA记录。
o An IPv6-only client (regardless of whether the client application is IPv6-only, the client stack is IPv6-only, or it only has an IPv6 address) wants to access the above server.
o 仅限IPv6的客户端（无论客户端应用程序是否仅限IPv6，客户端堆栈是否仅限IPv6，或是否仅具有IPv6地址）希望访问上述服务器。
o The client issues a DNS query to a DNS64 resolver.
o 客户端向DNS64解析程序发出DNS查询。
If the DNS64 only generates a synthetic AAAA if there's no real AAAA, then the communication will fail. Even though there's a real AAAA, the only way for communication to succeed is with the translated address. So, in order to support this scenario, the administrator of a DNS64 service may want to enable the synthesis of AAAA RRs even when real AAAA RRs exist.
如果DNS64仅在没有真实AAAA的情况下生成合成AAAA，则通信将失败。即使有真正的AAAA，沟通成功的唯一途径就是翻译地址。因此，为了支持此场景，DNS64服务的管理员可能希望启用AAAA RRs的合成，即使存在真正的AAAA RRs。
The implication of including synthetic AAAA RRs when real AAAA RRs exist is that translated connectivity may be preferred over native connectivity in some cases where the DNS64 is operated in DNS server mode.
当存在真实AAAA RRs时，包括合成AAAA RRs的含义是，在DNS64在DNS服务器模式下运行的某些情况下，转换连接可能优于本机连接。
RFC 3484 [RFC3484] rules use "longest matching prefix" to select the preferred destination address to use. So, if the DNS64 resolver returns both the synthetic AAAA RRs and the real AAAA RRs, then if the DNS64 is operated by the same domain as the initiating host, and a global unicast prefix (referred to as a Network-Specific Prefix (NSP) in [RFC6052]) is used, then a synthetic AAAA RR is likely to be preferred.
RFC 3484[RFC3484]规则使用“最长匹配前缀”选择要使用的首选目标地址。因此，如果DNS64解析器返回合成AAAA RRs和真实AAAA RRs，那么如果DNS64由与发起主机相同的域操作，并且使用全局单播前缀（在[RFC6052]中称为网络特定前缀（NSP）），则合成AAAA RR可能是优选的。
This means that without further configuration:
这意味着无需进一步配置：
o In the "an IPv6 network to the IPv4 Internet" scenario, the host will prefer translated connectivity if an NSP is used. If the Well-Known Prefix defined in [RFC6052] is used, it will probably prefer native connectivity.
o 在“从IPv6网络到IPv4 Internet”的场景中，如果使用NSP，主机将更喜欢转换连接。如果使用[RFC6052]中定义的众所周知的前缀，它可能更喜欢本机连接。
o In the "IPv6 Internet to an IPv4 network" scenario, it is possible to bias the selection towards the real AAAA RR if the DNS64 resolver returns the real AAAA first in the DNS reply, when an NSP is used (the Well-Known Prefix usage is not supported in this case).
o 在“IPv6 Internet到IPv4网络”场景中，如果使用NSP时DNS64解析器在DNS应答中首先返回真实AAAA，则可能会使选择偏向真实AAAA RR（在这种情况下不支持众所周知的前缀用法）。
o In the "an IPv6 network to an IPv4 network" scenario, for local destinations (i.e., target hosts inside the local site), it is likely that the NSP and the destination prefix are the same, so we can use the order of RR in the DNS reply to bias the selection through native connectivity. If the Well-Known Prefix is used, the "longest matching prefix" rule will select native connectivity.
o 在“从IPv6网络到IPv4网络”的场景中，对于本地目的地（即本地站点内的目标主机），NSP和目的地前缀可能相同，因此我们可以使用DNS应答中的RR顺序通过本机连接偏向选择。如果使用已知前缀，“最长匹配前缀”规则将选择本机连接。
The problem can be solved by properly configuring the RFC 3484 [RFC3484] policy table.
通过正确配置RFC 3484[RFC3484]策略表，可以解决此问题。
Authors' Addresses
作者地址
Marcelo Bagnulo UC3M Av. Universidad 30 Leganes, Madrid 28911 Spain
马塞洛·巴格努洛UC3M Av。西班牙马德里勒加内斯30大学28911
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Andrew Sullivan Shinkuro 4922 Fairmont Avenue, Suite 250 Bethesda, MD 20814 USA
Andrew Sullivan Shinkuro美国马里兰州贝塞斯达费尔蒙特大道4922号250室20814
Phone: +1 301 961 3131
EMail: ajs@shinkuro.com
Phone: +1 301 961 3131
EMail: ajs@shinkuro.com
Philip Matthews Unaffiliated 600 March Road Ottawa, Ontario Canada
加拿大安大略省渥太华市3月路600号菲利普·马修斯非附属公司
Phone: +1 613-592-4343 x224
EMail: philip_matthews@magma.ca
Phone: +1 613-592-4343 x224
EMail: philip_matthews@magma.ca
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van Beijnum IMDEA Networks Avda。德尔马尔地中海，22勒加内斯，马德里28918西班牙
Phone: +34-91-6246245
EMail: iljitsch@muada.com
Phone: +34-91-6246245
EMail: iljitsch@muada.com