Network Working Group A. Durand
Request for Comments: 4472 Comcast
Category: Informational J. Ihren
Autonomica
P. Savola
CSC/FUNET
April 2006
Network Working Group A. Durand
Request for Comments: 4472 Comcast
Category: Informational J. Ihren
Autonomica
P. Savola
CSC/FUNET
April 2006
Operational Considerations and Issues with IPv6 DNS
IPv6 DNS的操作注意事项和问题
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.
本备忘录介绍了IPv6域名系统（DNS）的操作注意事项和问题，包括特殊IPv6地址的摘要、已知DNS实施不当行为的文档、关于如何为服务提供和DNS解析程序IPv6支持执行DNS命名的建议和注意事项，正向树和反向树的DNS更新注意事项，以及其他问题。本备忘录旨在为有IPv4 DNS经验的用户提供有关IPv6 DNS注意事项的信息摘要。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Representing IPv6 Addresses in DNS Records .................3
1.2. Independence of DNS Transport and DNS Records ..............4
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
1.4. Query Type '*' and A/AAAA Records ..........................4
2. DNS Considerations about Special IPv6 Addresses .................5
2.1. Limited-Scope Addresses ....................................5
2.2. Temporary Addresses ........................................5
2.3. 6to4 Addresses .............................................5
2.4. Other Transition Mechanisms ................................5
3. Observed DNS Implementation Misbehavior .........................6
3.1. Misbehavior of DNS Servers and Load-balancers ..............6
3.2. Misbehavior of DNS Resolvers ...............................6
1. Introduction ....................................................3
1.1. Representing IPv6 Addresses in DNS Records .................3
1.2. Independence of DNS Transport and DNS Records ..............4
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
1.4. Query Type '*' and A/AAAA Records ..........................4
2. DNS Considerations about Special IPv6 Addresses .................5
2.1. Limited-Scope Addresses ....................................5
2.2. Temporary Addresses ........................................5
2.3. 6to4 Addresses .............................................5
2.4. Other Transition Mechanisms ................................5
3. Observed DNS Implementation Misbehavior .........................6
3.1. Misbehavior of DNS Servers and Load-balancers ..............6
3.2. Misbehavior of DNS Resolvers ...............................6
4. Recommendations for Service Provisioning Using DNS ..............7
4.1. Use of Service Names instead of Node Names .................7
4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
4.3. Adding the Records Only When Fully IPv6-enabled ............8
4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
4.4.1. TTL with Courtesy Additional Data ...................9
4.4.2. TTL with Critical Additional Data ..................10
4.5. IPv6 Transport Guidelines for DNS Servers .................10
5. Recommendations for DNS Resolver IPv6 Support ..................10
5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
5.2. Obtaining a List of DNS Recursive Resolvers ...............12
5.3. IPv6 Transport Guidelines for Resolvers ...................12
6. Considerations about Forward DNS Updating ......................13
6.1. Manual or Custom DNS Updates ..............................13
6.2. Dynamic DNS ...............................................13
7. Considerations about Reverse DNS Updating ......................14
7.1. Applicability of Reverse DNS ..............................14
7.2. Manual or Custom DNS Updates ..............................15
7.3. DDNS with Stateless Address Autoconfiguration .............16
7.4. DDNS with DHCP ............................................17
7.5. DDNS with Dynamic Prefix Delegation .......................17
8. Miscellaneous DNS Considerations ...............................18
8.1. NAT-PT with DNS-ALG .......................................18
8.2. Renumbering Procedures and Applications' Use of DNS .......18
9. Acknowledgements ...............................................19
10. Security Considerations .......................................19
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................22
Appendix A. Unique Local Addressing Considerations for DNS ........24
Appendix B. Behavior of Additional Data in IPv4/IPv6
Environments ..........................................24
B.1. Description of Additional Data Scenarios ..................24
B.2. Which Additional Data to Keep, If Any? ....................26
B.3. Discussion of the Potential Problems ......................27
4. Recommendations for Service Provisioning Using DNS ..............7
4.1. Use of Service Names instead of Node Names .................7
4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
4.3. Adding the Records Only When Fully IPv6-enabled ............8
4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
4.4.1. TTL with Courtesy Additional Data ...................9
4.4.2. TTL with Critical Additional Data ..................10
4.5. IPv6 Transport Guidelines for DNS Servers .................10
5. Recommendations for DNS Resolver IPv6 Support ..................10
5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
5.2. Obtaining a List of DNS Recursive Resolvers ...............12
5.3. IPv6 Transport Guidelines for Resolvers ...................12
6. Considerations about Forward DNS Updating ......................13
6.1. Manual or Custom DNS Updates ..............................13
6.2. Dynamic DNS ...............................................13
7. Considerations about Reverse DNS Updating ......................14
7.1. Applicability of Reverse DNS ..............................14
7.2. Manual or Custom DNS Updates ..............................15
7.3. DDNS with Stateless Address Autoconfiguration .............16
7.4. DDNS with DHCP ............................................17
7.5. DDNS with Dynamic Prefix Delegation .......................17
8. Miscellaneous DNS Considerations ...............................18
8.1. NAT-PT with DNS-ALG .......................................18
8.2. Renumbering Procedures and Applications' Use of DNS .......18
9. Acknowledgements ...............................................19
10. Security Considerations .......................................19
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................22
Appendix A. Unique Local Addressing Considerations for DNS ........24
Appendix B. Behavior of Additional Data in IPv4/IPv6
Environments ..........................................24
B.1. Description of Additional Data Scenarios ..................24
B.2. Which Additional Data to Keep, If Any? ....................26
B.3. Discussion of the Potential Problems ......................27
This memo presents operational considerations and issues with IPv6 DNS; it is meant to be an extensive summary and a list of pointers for more information about IPv6 DNS considerations for those with experience with IPv4 DNS.
本备忘录介绍了IPv6 DNS的操作注意事项和问题；它是一个广泛的摘要和一个指针列表，为那些有IPv4 DNS经验的人提供有关IPv6 DNS注意事项的更多信息。
The purpose of this document is to give information about various issues and considerations related to DNS operations with IPv6; it is not meant to be a normative specification or standard for IPv6 DNS.
本文档旨在提供与IPv6 DNS操作相关的各种问题和注意事项的信息；它不是IPv6 DNS的规范性规范或标准。
The first section gives a brief overview of how IPv6 addresses and names are represented in the DNS, how transport protocols and resource records (don't) relate, and what IPv4/IPv6 name space fragmentation means and how to avoid it; all of these are described at more length in other documents.
第一部分简要概述了IPv6地址和名称在DNS中的表示方式、传输协议和资源记录（不）的关系、IPv4/IPv6名称空间碎片的含义以及如何避免；所有这些在其他文件中都有更详细的描述。
The second section summarizes the special IPv6 address types and how they relate to DNS. The third section describes observed DNS implementation misbehaviors that have a varying effect on the use of IPv6 records with DNS. The fourth section lists recommendations and considerations for provisioning services with DNS. The fifth section in turn looks at recommendations and considerations about providing IPv6 support in the resolvers. The sixth and seventh sections describe considerations with forward and reverse DNS updates, respectively. The eighth section introduces several miscellaneous IPv6 issues relating to DNS for which no better place has been found in this memo. Appendix A looks briefly at the requirements for unique local addressing. Appendix B discusses additional data.
第二部分总结了特殊的IPv6地址类型及其与DNS的关系。第三部分描述了观察到的DNS实现错误行为，这些错误行为对DNS使用IPv6记录有不同的影响。第四部分列出了使用DNS提供服务的建议和注意事项。第五部分依次介绍有关在解析器中提供IPv6支持的建议和注意事项。第六节和第七节分别描述了正向和反向DNS更新的注意事项。第八部分介绍了与DNS相关的几个其他IPv6问题，在本备忘录中没有找到更好的位置。附录A简要介绍了唯一本地寻址的要求。附录B讨论了附加数据。
In the forward zones, IPv6 addresses are represented using AAAA records. In the reverse zones, IPv6 address are represented using PTR records in the nibble format under the ip6.arpa. tree. See [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] for background information.
在转发区域中，IPv6地址使用AAAA记录表示。在反向区域中，IPv6地址使用ip6.arpa下的半字节格式的PTR记录表示。树有关IPv6 DNS使用的更多信息，请参阅[RFC3596]，有关背景信息，请参阅[RFC3363]或[RFC3152]。
In particular, one should note that the use of A6 records in the forward tree or Bitlabels in the reverse tree is not recommended [RFC3363]. Using DNAME records is not recommended in the reverse tree in conjunction with A6 records; the document did not mean to take a stance on any other use of DNAME records [RFC3364].
特别值得注意的是，不建议在正向树中使用A6记录或在反向树中使用位标签[RFC3363]。不建议在反向树中与A6记录一起使用DNAME记录；该文件无意对DNAME记录的任何其他用途采取立场[RFC3364]。
DNS has been designed to present a single, globally unique name space [RFC2826]. This property should be maintained, as described here and in Section 1.3.
DNS被设计为提供一个单一的、全局唯一的名称空间[RFC2826]。应按照此处和第1.3节所述维护该财产。
The IP version used to transport the DNS queries and responses is independent of the records being queried: AAAA records can be queried over IPv4, and A records over IPv6. The DNS servers must not make any assumptions about what data to return for Answer and Authority sections based on the underlying transport used in a query.
用于传输DNS查询和响应的IP版本与所查询的记录无关：AAAA记录可以通过IPv4查询，而A记录可以通过IPv6查询。DNS服务器不得根据查询中使用的底层传输对应答和授权部分返回的数据进行任何假设。
However, there is some debate whether the addresses in Additional section could be selected or filtered using hints obtained from which transport was being used; this has some obvious problems because in many cases the transport protocol does not correlate with the requests, and because a "bad" answer is in a way worse than no answer at all (consider the case where the client is led to believe that a name received in the additional record does not have any AAAA records at all).
然而，对于是否可以使用从使用传输的地方获得的提示来选择或过滤附加部分中的地址存在一些争议；这有一些明显的问题，因为在许多情况下，传输协议与请求不相关，并且因为“坏”答案在某种程度上比根本没有答案更糟糕（考虑这样的情况，即客户机被引导认为在附加记录中收到的名称根本没有任何AAAA记录）。
As stated in [RFC3596]:
如[RFC3596]所述：
The IP protocol version used for querying resource records is independent of the protocol version of the resource records; e.g., IPv4 transport can be used to query IPv6 records and vice versa.
用于查询资源记录的IP协议版本独立于资源记录的协议版本；e、 例如，IPv4传输可用于查询IPv6记录，反之亦然。
To avoid the DNS name space from fragmenting into parts where some parts of DNS are only visible using IPv4 (or IPv6) transport, the recommendation is to always keep at least one authoritative server IPv4-enabled, and to ensure that recursive DNS servers support IPv4. See DNS IPv6 transport guidelines [RFC3901] for more information.
为了避免DNS名称空间被分割成仅使用IPv4（或IPv6）传输才能看到DNS某些部分的部分，建议始终至少启用一个权威服务器IPv4，并确保递归DNS服务器支持IPv4。有关更多信息，请参阅DNS IPv6传输指南[RFC3901]。
QTYPE=* is typically only used for debugging or management purposes; it is worth keeping in mind that QTYPE=* ("ANY" queries) only return any available RRsets, not *all* the RRsets, because the caches do not necessarily have all the RRsets and have no way of guaranteeing that they have all the RRsets. Therefore, to get both A and AAAA records reliably, two separate queries must be made.
QTYPE=*通常仅用于调试或管理目的；值得记住的是，QTYPE=*（“ANY”查询）只返回任何可用的RRSET，而不是*所有*RRSET，因为缓存不一定拥有所有RRSET，也无法保证它们拥有所有RRSET。因此，为了可靠地获取A和AAAA记录，必须进行两个单独的查询。
There are a couple of IPv6 address types that are somewhat special; these are considered here.
有几种IPv6地址类型有些特殊；这里考虑这些问题。
The IPv6 addressing architecture [RFC4291] includes two kinds of local-use addresses: link-local (fe80::/10) and site-local (fec0::/10). The site-local addresses have been deprecated [RFC3879] but are discussed with unique local addresses in Appendix A.
IPv6寻址体系结构[RFC4291]包括两种本地使用地址：链路本地（fe80:：/10）和站点本地（fec0:：/10）。站点本地地址已被弃用[RFC3879]，但在附录A中讨论了唯一的本地地址。
Link-local addresses should never be published in DNS (whether in forward or reverse tree), because they have only local (to the connected link) significance [WIP-DC2005].
链路本地地址不应在DNS中发布（无论是在正向树还是反向树中），因为它们只有本地（到连接的链路）意义[WIP-DC2005]。
Temporary addresses defined in RFC 3041 [RFC3041] (sometimes called "privacy addresses") use a random number as the interface identifier. Having DNS AAAA records that are updated to always contain the current value of a node's temporary address would defeat the purpose of the mechanism and is not recommended. However, it would still be possible to return a non-identifiable name (e.g., the IPv6 address in hexadecimal format), as described in [RFC3041].
RFC 3041[RFC3041]中定义的临时地址（有时称为“隐私地址”）使用随机数作为接口标识符。如果DNS AAAA记录被更新为始终包含节点临时地址的当前值，则会破坏该机制的用途，因此不建议这样做。但是，仍然可以返回不可识别的名称（例如十六进制格式的IPv6地址），如[RFC3041]中所述。
6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
6to4[RFC3056]指定一种自动隧道机制，该机制将公共IPv4地址V4ADDR映射到IPv6前缀2002:V4ADDR:：/48。
If the reverse DNS population would be desirable (see Section 7.1 for applicability), there are a number of possible ways to do so.
如果需要反向DNS填充（有关适用性，请参见第7.1节），则有多种可能的方法。
[WIP-H2005] aims to design an autonomous reverse-delegation system that anyone being capable of communicating using a specific 6to4 address would be able to set up a reverse delegation to the corresponding 6to4 prefix. This could be deployed by, e.g., Regional Internet Registries (RIRs). This is a practical solution, but may have some scalability concerns.
[WIP-H2005]旨在设计一个自主的反向委托系统，任何能够使用特定6to4地址进行通信的人都可以设置到相应6to4前缀的反向委托。这可以由区域互联网注册中心（RIR）等机构进行部署。这是一个实用的解决方案，但可能存在一些可伸缩性问题。
6to4 is mentioned as a case of an IPv6 transition mechanism requiring special considerations. In general, mechanisms that include a special prefix may need a custom solution; otherwise, for example, when IPv4 address is embedded as the suffix or not embedded at all, special solutions are likely not needed.
6to4是一种需要特别考虑的IPv6转换机制。通常，包含特殊前缀的机制可能需要自定义解决方案；否则，例如，当IPv4地址作为后缀嵌入或根本不嵌入时，可能不需要特殊的解决方案。
Note that it does not seem feasible to provide reverse DNS with another automatic tunneling mechanism, Teredo [RFC4380]; this is because the IPv6 address is based on the IPv4 address and UDP port of the current Network Address Translation (NAT) mapping, which is likely to be relatively short-lived.
注意，为反向DNS提供另一种自动隧道机制Teredo[RFC4380]似乎不可行；这是因为IPv6地址基于当前网络地址转换（NAT）映射的IPv4地址和UDP端口，这可能相对较短。
Several classes of misbehavior in DNS servers, load-balancers, and resolvers have been observed. Most of these are rather generic, not only applicable to IPv6 -- but in some cases, the consequences of this misbehavior are extremely severe in IPv6 environments and deserve to be mentioned.
已经观察到DNS服务器、负载平衡器和解析程序中存在几类错误行为。其中大多数都相当通用，不仅适用于IPv6，而且在某些情况下，这种错误行为的后果在IPv6环境中非常严重，值得一提。
There are several classes of misbehavior in certain DNS servers and load-balancers that have been noticed and documented [RFC4074]: some implementations silently drop queries for unimplemented DNS records types, or provide wrong answers to such queries (instead of a proper negative reply). While typically these issues are not limited to AAAA records, the problems are aggravated by the fact that AAAA records are being queried instead of (mainly) A records.
某些DNS服务器和负载平衡器中存在几类已经注意到并记录在案的错误行为[RFC4074]：一些实现会自动删除对未实现的DNS记录类型的查询，或者对此类查询提供错误的答案（而不是正确的否定回答）。虽然这些问题通常不限于AAAA记录，但由于查询的是AAAA记录，而不是（主要）A记录，因此问题更加严重。
The problems are serious because when looking up a DNS name, typical getaddrinfo() implementations, with AF_UNSPEC hint given, first try to query the AAAA records of the name, and after receiving a response, query the A records. This is done in a serial fashion -- if the first query is never responded to (instead of properly returning a negative answer), significant time-outs will occur.
问题很严重，因为在查找DNS名称时，典型的getaddrinfo（）实现在给出AF_unsec提示的情况下，首先尝试查询名称的AAAA记录，然后在收到响应后查询a记录。这是以串行方式完成的——如果第一个查询从未得到响应（而不是正确地返回否定答案），则将发生显著的超时。
In consequence, this is an enormous problem for IPv6 deployments, and in some cases, IPv6 support in the software has even been disabled due to these problems.
因此，这对于IPv6部署来说是一个巨大的问题，在某些情况下，软件中的IPv6支持甚至因为这些问题而被禁用。
The solution is to fix or retire those misbehaving implementations, but that is likely not going to be effective. There are some possible ways to mitigate the problem, e.g., by performing the lookups somewhat in parallel and reducing the time-out as long as at least one answer has been received, but such methods remain to be investigated; slightly more on this is included in Section 5.
解决方案是修复或淘汰那些行为不端的实现，但这可能不会有效。有一些可能的方法来缓解该问题，例如，通过在一定程度上并行执行查找，并且只要至少收到一个答案，就减少超时时间，但是这些方法仍有待研究；第5节对此作了详细介绍。
Several classes of misbehavior have also been noticed in DNS resolvers [WIP-LB2005]. However, these do not seem to directly impair IPv6 use, and are only referred to for completeness.
DNS解析程序[WIP-LB2005]中也注意到了几类不当行为。然而，这些似乎不会直接影响IPv6的使用，仅为完整性考虑。
When names are added in the DNS to facilitate a service, there are several general guidelines to consider to be able to do it as smoothly as possible.
当DNS中添加名称以便于服务时，考虑到可以尽可能顺利地执行它的几个一般准则。
It makes sense to keep information about separate services logically separate in the DNS by using a different DNS hostname for each service. There are several reasons for doing this, for example:
通过为每个服务使用不同的DNS主机名，在DNS中保持关于不同服务的信息在逻辑上是分开的是有意义的。这样做有几个原因，例如：
o It allows more flexibility and ease for migration of (only a part of) services from one node to another,
o 它使服务从一个节点迁移到另一个节点（仅部分）更加灵活和方便，
o It allows configuring different properties (e.g., Time to Live (TTL)) for each service, and
o 它允许为每个服务配置不同的属性（例如生存时间（TTL）），以及
o It allows deciding separately for each service whether or not to publish the IPv6 addresses (in cases where some services are more IPv6-ready than others).
o 它允许为每个服务分别决定是否发布IPv6地址（在某些服务比其他服务更适合IPv6的情况下）。
Using SRV records [RFC2782] would avoid these problems. Unfortunately, those are not sufficiently widely used to be applicable in most cases. Hence an operation technique is to use service names instead of node names (or "hostnames"). This operational technique is not specific to IPv6, but required to understand the considerations described in Section 4.2 and Section 4.3.
使用SRV记录[RFC2782]可以避免这些问题。不幸的是，这些标准没有得到足够广泛的应用，无法在大多数情况下适用。因此，一种操作技术是使用服务名而不是节点名（或“主机名”）。此操作技术并非特定于IPv6，但需要了解第4.2节和第4.3节中描述的注意事项。
For example, assume a node named "pobox.example.com" provides both SMTP and IMAP service. Instead of configuring the MX records to point at "pobox.example.com", and configuring the mail clients to look up the mail via IMAP from "pobox.example.com", one could use, e.g., "smtp.example.com" for SMTP (for both message submission and mail relaying between SMTP servers) and "imap.example.com" for IMAP. Note that in the specific case of SMTP relaying, the server itself must typically also be configured to know all its names to ensure that loops do not occur. DNS can provide a layer of indirection between service names and where the service actually is, and using which addresses. (Obviously, when wanting to reach a specific node, one should use the hostname rather than a service name.)
例如，假设名为“pobox.example.com”的节点同时提供SMTP和IMAP服务。不必将MX记录配置为指向“pobox.example.com”，也不必将邮件客户端配置为通过IMAP从“pobox.example.com”查找邮件，例如，可以将“smtp.example.com”用于smtp（用于smtp服务器之间的邮件提交和邮件中继），将“IMAP.example.com”用于IMAP。请注意，在SMTP中继的特定情况下，服务器本身通常也必须配置为知道其所有名称，以确保不会发生循环。DNS可以在服务名称和服务的实际位置以及使用哪个地址之间提供一层间接寻址。（显然，当想要到达特定节点时，应该使用主机名而不是服务名。）
The service naming can be achieved in basically two ways: when a service is named "service.example.com" for IPv4, the IPv6-enabled service could either be added to "service.example.com" or added separately under a different name, e.g., in a sub-domain like "service.ipv6.example.com".
服务命名基本上可以通过两种方式实现：当一个服务被命名为IPv4的“service.example.com”时，启用IPv6的服务可以添加到“service.example.com”中，或者以不同的名称单独添加，例如，在“service.IPv6.example.com”这样的子域中。
These two methods have different characteristics. Using a different name allows for easier service piloting, minimizing the disturbance to the "regular" users of IPv4 service; however, the service would not be used transparently, without the user/application explicitly finding it and asking for it -- which would be a disadvantage in most cases. When the different name is under a sub-domain, if the services are deployed within a restricted network (e.g., inside an enterprise), it's possible to prefer them transparently, at least to a degree, by modifying the DNS search path; however, this is a suboptimal solution. Using the same service name is the "long-term" solution, but may degrade performance for those clients whose IPv6 performance is lower than IPv4, or does not work as well (see Section 4.3 for more).
这两种方法具有不同的特点。使用不同的名称可以更容易地引导服务，最大限度地减少对IPv4服务的“常规”用户的干扰；但是，如果用户/应用程序没有显式地找到并请求服务，服务的使用就不会透明，这在大多数情况下都是一个缺点。当不同名称位于子域下时，如果服务部署在受限网络内（例如，在企业内），则可以通过修改DNS搜索路径透明地（至少在一定程度上）选择它们；然而，这是一个次优的解决方案。使用相同的服务名称是“长期”解决方案，但可能会降低IPv6性能低于IPv4或无法正常工作的客户端的性能（有关更多信息，请参阅第4.3节）。
In most cases, it makes sense to pilot or test a service using separate service names, and move to the use of the same name when confident enough that the service level will not degrade for the users unaware of IPv6.
在大多数情况下，使用单独的服务名称引导或测试服务是有意义的，并且在确信服务级别不会因不知道IPv6的用户而降低时，可以使用相同的名称。
The recommendation is that AAAA records for a service should not be added to the DNS until all of following are true:
建议在满足以下所有条件之前，不应将服务的AAAA记录添加到DNS：
1. The address is assigned to the interface on the node.
1. 地址分配给节点上的接口。
2. The address is configured on the interface.
2. 该地址在接口上配置。
3. The interface is on a link that is connected to the IPv6 infrastructure.
3. 接口位于连接到IPv6基础结构的链路上。
In addition, if the AAAA record is added for the node, instead of service as recommended, all the services of the node should be IPv6- enabled prior to adding the resource record.
此外，如果为节点添加AAAA记录，而不是推荐的服务，则在添加资源记录之前，节点的所有服务都应启用IPv6。
For example, if an IPv6 node is isolated from an IPv6 perspective (e.g., it is not connected to IPv6 Internet) constraint #3 would mean that it should not have an address in the DNS.
例如，如果IPv6节点从IPv6角度隔离（例如，它未连接到IPv6 Internet），则约束#3将意味着它在DNS中不应有地址。
Consider the case of two dual-stack nodes, which both are IPv6- enabled, but the server does not have (global) IPv6 connectivity. As the client looks up the server's name, only A records are returned (if the recommendations above are followed), and no IPv6 communication, which would have been unsuccessful, is even attempted.
考虑两个双栈节点的情况，这两个节点都是IPv6启用的，但是服务器没有（全局）IPv6连接。当客户端查找服务器名称时，只会返回一条记录（如果遵循上述建议），并且甚至不会尝试进行IPv6通信，这可能是不成功的。
The issues are not always so black-and-white. Usually, it's important that the service offered using both protocols is of roughly equal quality, using the appropriate metrics for the service (e.g., latency, throughput, low packet loss, general reliability, etc.). This is typically very important especially for interactive or real-time services. In many cases, the quality of IPv6 connectivity may not yet be equal to that of IPv4, at least globally; this has to be taken into consideration when enabling services.
这些问题并不总是那么黑白分明。通常，重要的是，使用两种协议提供的服务质量大致相同，使用服务的适当指标（例如，延迟、吞吐量、低数据包丢失、一般可靠性等）。这通常非常重要，尤其是对于交互式或实时服务。在许多情况下，IPv6连接的质量可能还不如IPv4，至少在全球范围内是如此；启用服务时必须考虑这一点。
The behavior of DNS caching when different TTL values are used for different RRsets of the same name calls for explicit discussion. For example, let's consider two unrelated zone fragments:
当不同的TTL值用于相同名称的不同RRSET时，DNS缓存的行为需要进行显式讨论。例如，让我们考虑两个不相关的区域碎片：
example.com. 300 IN MX foo.example.com. foo.example.com. 300 IN A 192.0.2.1 foo.example.com. 100 IN AAAA 2001:db8::1
example.com。300在MX foo.example.com。foo.example.com。在192.0.2.1 foo.example.com中显示300。AAAA 2001中的100:db8:：1
...
...
child.example.com. 300 IN NS ns.child.example.com. ns.child.example.com. 300 IN A 192.0.2.1 ns.child.example.com. 100 IN AAAA 2001:db8::1
child.example.com。300在NS.child.example.com。ns.child.example.com。192.0.2.1 ns.child.example.com中的300。AAAA 2001中的100:db8:：1
In the former case, we have "courtesy" additional data; in the latter, we have "critical" additional data. See more extensive background discussion of additional data handling in Appendix B.
在前一种情况下，我们有“礼貌”的额外数据；在后者中，我们有“关键”的额外数据。更多关于附加数据处理的背景讨论，请参见附录B。
When a caching resolver asks for the MX record of example.com, it gets back "foo.example.com". It may also get back either one or both of the A and AAAA records in the additional section. The resolver must explicitly query for both A and AAAA records [RFC2821].
当缓存解析器请求example.com的MX记录时，它返回“foo.example.com”。它还可以在附加部分中获取一个或两个A和AAAA记录。解析程序必须显式查询A和AAAA记录[RFC2821]。
After 100 seconds, the AAAA record is removed from the cache(s) because its TTL expired. It could be argued to be useful for the caching resolvers to discard the A record when the shorter TTL (in this case, for the AAAA record) expires; this would avoid the situation where there would be a window of 200 seconds when incomplete information is returned from the cache. Further argument
100秒后，AAAA记录将从缓存中删除，因为其TTL已过期。当较短的TTL（在本例中，对于AAAA记录）过期时，缓存解析程序丢弃A记录可能会很有用；这将避免在从缓存返回不完整信息时出现200秒窗口的情况。进一步论证
for discarding is that in the normal operation, the TTL values are so high that very likely the incurred additional queries would not be noticeable, compared to the obtained performance optimization. The behavior in this scenario is unspecified.
因为丢弃是指在正常操作中，TTL值非常高，与获得的性能优化相比，产生的额外查询很可能不明显。此场景中的行为未指定。
The difference to courtesy additional data is that the A/AAAA records served by the parent zone cannot be queried explicitly. Therefore, after 100 seconds the AAAA record is removed from the cache(s), but the A record remains. Queries for the remaining 200 seconds (provided that there are no further queries from the parent that could refresh the caches) only return the A record, leading to a potential operational situation with unreachable servers.
与其他数据不同的是，无法明确查询父区域提供的A/AAAA记录。因此，100秒后，AAAA记录将从缓存中删除，但A记录仍保留。剩余200秒的查询（前提是没有来自父级的进一步查询可以刷新缓存）只返回A记录，从而导致无法访问服务器的潜在操作情况。
Similar cache flushing strategies apply in this scenario; the behavior is likewise unspecified.
类似的缓存刷新策略也适用于此场景；该行为同样未指明。
As described in Section 1.3 and [RFC3901], there should continue to be at least one authoritative IPv4 DNS server for every zone, even if the zone has only IPv6 records. (Note that obviously, having more servers with robust connectivity would be preferable, but this is the minimum recommendation; also see [RFC2182].)
如第1.3节和[RFC3901]所述，每个区域应至少有一个权威IPv4 DNS服务器，即使该区域只有IPv6记录。（请注意，显然，拥有更多具有健壮连接的服务器更可取，但这是最低建议；另请参见[RFC2182]。）
When IPv6 is enabled on a node, there are several things to consider to ensure that the process is as smooth as possible.
当在一个节点上启用IPv6时，有几个事情需要考虑，以确保过程尽可能平滑。
The system library that implements the getaddrinfo() function for looking up names is a critical piece when considering the robustness of enabling IPv6; it may come in basically three flavors:
在考虑启用IPv6的稳健性时，实现用于查找名称的getaddrinfo（）函数的系统库是一个关键部分；基本上有三种口味：
1. The system library does not know whether IPv6 has been enabled in the kernel of the operating system: it may start looking up AAAA records with getaddrinfo() and AF_UNSPEC hint when the system is upgraded to a system library version that supports IPv6.
1. 系统库不知道是否在操作系统内核中启用了IPv6：当系统升级到支持IPv6的系统库版本时，它可能会使用getaddrinfo（）和AF_unsec提示开始查找AAAA记录。
2. The system library might start to perform IPv6 queries with getaddrinfo() only when IPv6 has been enabled in the kernel. However, this does not guarantee that there exists any useful IPv6 connectivity (e.g., the node could be isolated from the other IPv6 networks, only having link-local addresses).
2. 只有在内核中启用了IPv6时，系统库才可能开始使用getaddrinfo（）执行IPv6查询。但是，这并不保证存在任何有用的IPv6连接（例如，节点可以与其他IPv6网络隔离，仅具有链路本地地址）。
3. The system library might implement a toggle that would apply some heuristics to the "IPv6-readiness" of the node before starting to perform queries; for example, it could check whether only link-local IPv6 address(es) exists, or if at least one global IPv6 address exists.
3. 系统库可能会实现一个切换，在开始执行查询之前对节点的“IPv6就绪性”应用一些试探法；例如，它可以检查是否只存在链路本地IPv6地址，或者是否至少存在一个全局IPv6地址。
First, let us consider generic implications of unnecessary queries for AAAA records: when looking up all the records in the DNS, AAAA records are typically tried first, and then A records. These are done in serial, and the A query is not performed until a response is received to the AAAA query. Considering the misbehavior of DNS servers and load-balancers, as described in Section 3.1, the lookup delay for AAAA may incur additional unnecessary latency, and introduce a component of unreliability.
首先，让我们考虑不必要的查询对AAAA记录的一般含义：当查找DNS中的所有记录时，通常首先尝试AAAA记录，然后记录。这些都是以串行方式完成的，在收到AAAA查询的响应之前，不会执行A查询。考虑到DNS服务器和负载平衡器的不当行为，如第3.1节所述，AAAA的查找延迟可能会导致额外的不必要延迟，并引入不可靠性组件。
One option here could be to do the queries partially in parallel; for example, if the final response to the AAAA query is not received in 0.5 seconds, start performing the A query while waiting for the result. (Immediate parallelism might not be optimal, at least without information-sharing between the lookup threads, as that would probably lead to duplicate non-cached delegation chain lookups.)
这里的一个选择是部分并行地执行查询；例如，如果在0.5秒内未收到AAAA查询的最终响应，则在等待结果的同时开始执行A查询。（即时并行性可能不是最佳的，至少在查找线程之间没有信息共享的情况下是如此，因为这可能会导致重复的非缓存委派链查找。）
An additional concern is the address selection, which may, in some circumstances, prefer AAAA records over A records even when the node does not have any IPv6 connectivity [WIP-RDP2004]. In some cases, the implementation may attempt to connect or send a datagram on a physical link [WIP-R2006], incurring very long protocol time-outs, instead of quickly falling back to IPv4.
另一个问题是地址选择，在某些情况下，即使节点没有任何IPv6连接[WIP-RDP2004]，地址选择也可能会优先选择AAAA记录而不是A记录。在某些情况下，实现可能会尝试在物理链路[WIP-R2006]上连接或发送数据报，从而导致很长的协议超时，而不是迅速退回到IPv4。
Now, we can consider the issues specific to each of the three possibilities:
现在，我们可以考虑三个可能性中的每一个问题：
In the first case, the node performs a number of completely useless DNS lookups as it will not be able to use the returned AAAA records anyway. (The only exception is where the application desires to know what's in the DNS, but not use the result for communication.) One should be able to disable these unnecessary queries, for both latency and reliability reasons. However, as IPv6 has not been enabled, the connections to IPv6 addresses fail immediately, and if the application is programmed properly, the application can fall gracefully back to IPv4 [RFC4038].
在第一种情况下，节点执行许多完全无用的DNS查找，因为它无论如何都不能使用返回的AAAA记录。（唯一的例外是应用程序希望知道DNS中的内容，但不使用结果进行通信。）出于延迟和可靠性原因，应该能够禁用这些不必要的查询。但是，由于尚未启用IPv6，与IPv6地址的连接会立即失败，如果应用程序编程正确，应用程序可以正常返回IPv4[RFC4038]。
The second case is similar to the first, except it happens to a smaller set of nodes when IPv6 has been enabled but connectivity has not been provided yet. Similar considerations apply, with the exception that IPv6 records, when returned, will be actually tried first, which may typically lead to long time-outs.
第二种情况与第一种情况类似，只是当启用了IPv6但尚未提供连接时，会发生在较小的一组节点上。类似的考虑也适用，但IPv6记录在返回时实际上会首先尝试，这通常会导致长时间超时。
The third case is a bit more complex: optimizing away the DNS lookups with only link-locals is probably safe (but may be desirable with different lookup services that getaddrinfo() may support), as the link-locals are typically automatically generated when IPv6 is enabled, and do not indicate any form of IPv6 connectivity. That is, performing DNS lookups only when a non-link-local address has been configured on any interface could be beneficial -- this would be an indication that the address has been configured either from a router advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], or manually. Each would indicate at least some form of IPv6 connectivity, even though there would not be guarantees of it.
第三种情况有点复杂：仅使用链接局部变量优化DNS查找可能是安全的（但对于getaddrinfo（）可能支持的不同查找服务可能是可取的），因为链接局部变量通常在启用IPv6时自动生成，并且不表示任何形式的IPv6连接。也就是说，仅当在任何接口上配置了非链路本地地址时才执行DNS查找可能是有益的——这表明该地址已从路由器公告、IPv6动态主机配置协议（DHCPv6）[RFC3315]或手动配置。每一个都至少表示某种形式的IPv6连接，即使没有保证。
These issues should be analyzed at more depth, and the fixes found consensus on, perhaps in a separate document.
应该更深入地分析这些问题，并在一份单独的文件中达成一致意见。
In scenarios where DHCPv6 is available, a host can discover a list of DNS recursive resolvers through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. This option can be passed to a host through a subset of DHCPv6 [RFC3736].
在DHCPv6可用的场景中，主机可以通过DHCPv6“DNS递归名称服务器”选项[RFC3646]发现DNS递归解析程序列表。此选项可以通过DHCPv6[RFC3736]的子集传递给主机。
The IETF is considering the development of alternative mechanisms for obtaining the list of DNS recursive name servers when DHCPv6 is unavailable or inappropriate. No decision about taking on this development work has been reached as of this writing [RFC4339].
IETF正在考虑开发替代机制，用于在DHCPv6不可用或不合适时获取DNS递归名称服务器列表。截至撰写本文[RFC4339]时，尚未就开展这项开发工作做出任何决定。
In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms under consideration for development include the use of [WIP-O2004] and the use of Router Advertisements to convey the information [WIP-J2006].
在DHCPv6不可用或不合适的情况下，考虑开发的机制包括使用[WIP-O2004]和使用路由器广告来传达信息[WIP-J2006]。
Note that even though IPv6 DNS resolver discovery is a recommended procedure, it is not required for dual-stack nodes in dual-stack networks as IPv6 DNS records can be queried over IPv4 as well as IPv6. Obviously, nodes that are meant to function without manual configuration in IPv6-only networks must implement the DNS resolver discovery function.
请注意，尽管建议使用IPv6 DNS解析器发现过程，但双堆栈网络中的双堆栈节点不需要此过程，因为可以通过IPv4和IPv6查询IPv6 DNS记录。显然，在纯IPv6网络中不需要手动配置即可运行的节点必须实现DNS解析器发现功能。
As described in Section 1.3 and [RFC3901], the recursive resolvers should be IPv4-only or dual-stack to be able to reach any IPv4-only DNS server. Note that this requirement is also fulfilled by an IPv6- only stub resolver pointing to a dual-stack recursive DNS resolver.
如第1.3节和[RFC3901]所述，递归解析程序应为仅IPv4或双堆栈，以便能够访问任何仅IPv4的DNS服务器。请注意，指向双堆栈递归DNS解析器的仅IPv6存根解析器也满足了此要求。
While the topic of how to enable updating the forward DNS, i.e., the mapping from names to the correct new addresses, is not specific to IPv6, it should be considered especially due to the advent of Stateless Address Autoconfiguration [RFC2462].
虽然如何更新转发DNS（即从名称到正确新地址的映射）的主题并不特定于IPv6，但由于无状态地址自动配置[RFC2462]的出现，应特别考虑该主题。
Typically, forward DNS updates are more manageable than doing them in the reverse DNS, because the updater can often be assumed to "own" a certain DNS name -- and we can create a form of security relationship with the DNS name and the node that is allowed to update it to point to a new address.
通常，正向DNS更新比反向DNS更新更易于管理，因为更新程序通常可以被假定为“拥有”某个DNS名称——并且我们可以与DNS名称和允许更新它以指向新地址的节点创建一种形式的安全关系。
A more complex form of DNS updates -- adding a whole new name into a DNS zone, instead of updating an existing name -- is considered out of scope for this memo as it could require zone-wide authentication. Adding a new name in the forward zone is a problem that is still being explored with IPv4, and IPv6 does not seem to add much new in that area.
一种更复杂的DNS更新形式——在DNS区域中添加一个全新的名称，而不是更新现有名称——被认为超出了本备忘录的范围，因为它可能需要区域范围的身份验证。在转发区域中添加新名称是一个仍在使用IPv4探索的问题，而IPv6似乎并没有在该领域添加太多新名称。
The DNS mappings can also be maintained by hand, in a semi-automatic fashion or by running non-standardized protocols. These are not considered at more length in this memo.
DNS映射也可以手动、半自动或通过运行非标准化协议来维护。本备忘录未对这些问题进行详细考虑。
Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized mechanism for dynamically updating the DNS. It works equally well with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual address configuration. It is important to consider how each of these behave if IP address-based authentication, instead of stronger mechanisms [RFC3007], was used in the updates.
动态DNS更新（DDN）[RFC2136][RFC3007]是用于动态更新DNS的标准化机制。它同样适用于无状态地址自动配置（SLAAC）、DHCPv6或手动地址配置。重要的是要考虑这些行为中的每一个，如果在更新中使用了基于IP地址的身份验证，而不是更强大的机制[RCF300 7]。
1. Manual addresses are static and can be configured.
1. 手动地址是静态的，可以配置。
2. DHCPv6 addresses could be reasonably static or dynamic, depending on the deployment, and could or could not be configured on the DNS server for the long term.
2. DHCPv6地址可以是静态的，也可以是动态的，具体取决于部署情况，并且可以在DNS服务器上长期配置，也可以不配置。
3. SLAAC addresses are typically stable for a long time, but could require work to be configured and maintained.
3. SLAAC地址通常长时间稳定，但可能需要配置和维护工作。
As relying on IP addresses for Dynamic DNS is rather insecure at best, stronger authentication should always be used; however, this requires that the authorization keying will be explicitly configured using unspecified operational methods.
由于依赖IP地址进行动态DNS充其量是相当不安全的，因此应始终使用更强的身份验证；但是，这需要使用未指定的操作方法显式配置授权密钥。
Note that with DHCP it is also possible that the DHCP server updates the DNS, not the host. The host might only indicate in the DHCP exchange which hostname it would prefer, and the DHCP server would make the appropriate updates. Nonetheless, while this makes setting up a secure channel between the updater and the DNS server easier, it does not help much with "content" security, i.e., whether the hostname was acceptable -- if the DNS server does not include policies, they must be included in the DHCP server (e.g., a regular host should not be able to state that its name is "www.example.com"). DHCP-initiated DDNS updates have been extensively described in [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b].
请注意，使用DHCP时，DHCP服务器也可能更新DNS，而不是主机。主机可能只在DHCP交换中指明它喜欢哪个主机名，DHCP服务器将进行适当的更新。尽管如此，尽管这使得在更新程序和DNS服务器之间建立安全通道变得更容易，但对于“内容”安全性（即主机名是否可接受）并没有多大帮助——如果DNS服务器不包含策略，则必须将其包含在DHCP服务器中（例如，普通主机不应声明其名称为“www.example.com”）。DHCP启动的DDNS更新已在[WIP-SV2005]、[WIP-S2005a]和[WIP-S2005b]中进行了详细描述。
The nodes must somehow be configured with the information about the servers where they will attempt to update their addresses, sufficient security material for authenticating themselves to the server, and the hostname they will be updating. Unless otherwise configured, the first could be obtained by looking up the authoritative name servers for the hostname; the second must be configured explicitly unless one chooses to trust the IP address-based authentication (not a good idea); and lastly, the nodename is typically pre-configured somehow on the node, e.g., at install time.
节点必须以某种方式配置有关其将尝试更新其地址的服务器的信息、用于向服务器验证自身的足够安全材料，以及它们将要更新的主机名。除非另外配置，第一个可以通过查找主机名的权威名称服务器来获得；第二个必须显式配置，除非选择信任基于IP地址的身份验证（这不是一个好主意）；最后，节点名通常在节点上以某种方式预先配置，例如在安装时。
Care should be observed when updating the addresses not to use longer TTLs for addresses than are preferred lifetimes for the addresses, so that if the node is renumbered in a managed fashion, the amount of stale DNS information is kept to the minimum. That is, if the preferred lifetime of an address expires, the TTL of the record needs to be modified unless it was already done before the expiration. For better flexibility, the DNS TTL should be much shorter (e.g., a half or a third) than the lifetime of an address; that way, the node can start lowering the DNS TTL if it seems like the address has not been renewed/refreshed in a while. Some discussion on how an administrator could manage the DNS TTL is included in [RFC4192]; this could be applied to (smart) hosts as well.
更新地址时应注意不要对地址使用比地址首选生存期更长的TTL，这样，如果节点以托管方式重新编号，过时DNS信息的数量将保持在最小。也就是说，如果地址的首选生存期到期，则需要修改记录的TTL，除非它在到期之前已经完成。为了获得更好的灵活性，DNS TTL应该比地址的生存期短得多（例如，一半或三分之一）；这样，如果该地址似乎在一段时间内没有更新/刷新，则节点可以开始降低DNS TTL。[RFC4192]中包含了一些关于管理员如何管理DNS TTL的讨论；这也适用于（智能）主机。
Updating the reverse DNS zone may be difficult because of the split authority over an address. However, first we have to consider the applicability of reverse DNS in the first place.
更新反向DNS区域可能很困难，因为地址上的权限被分割。然而，首先我们必须考虑反向DNS的适用性。
Today, some applications use reverse DNS either to look up some hints about the topological information associated with an address (e.g., resolving web server access logs) or (as a weak form of a security check) to get a feel whether the user's network administrator has
如今，一些应用程序使用反向DNS来查找与地址相关的拓扑信息的提示（例如，解析web服务器访问日志），或者（作为安全检查的一种弱形式）来了解用户的网络管理员是否
"authorized" the use of the address (on the premise that adding a reverse record for an address would signal some form of authorization).
“授权”地址的使用（前提是为地址添加反向记录将表示某种形式的授权）。
One additional, maybe slightly more useful usage is ensuring that the reverse and forward DNS contents match (by looking up the pointer to the name by the IP address from the reverse tree, and ensuring that a record under the name in the forward tree points to the IP address) and correspond to a configured name or domain. As a security check, it is typically accompanied by other mechanisms, such as a user/ password login; the main purpose of the reverse+forward DNS check is to weed out the majority of unauthorized users, and if someone managed to bypass the checks, he would still need to authenticate "properly".
另一个可能稍微有用的用法是确保反向和正向DNS内容匹配（通过反向树中的IP地址查找指向名称的指针，并确保正向树中的名称下的记录指向IP地址），并与配置的名称或域相对应。作为安全检查，它通常伴随着其他机制，例如用户/密码登录；反向+正向DNS检查的主要目的是清除大多数未经授权的用户，如果有人设法绕过检查，他仍然需要“正确”进行身份验证。
It may also be desirable to store IPsec keying material corresponding to an IP address in the reverse DNS, as justified and described in [RFC4025].
还可能需要在反向DNS中存储与IP地址对应的IPsec密钥材料，如[RFC4025]中所述。
It is not clear whether it makes sense to require or recommend that reverse DNS records be updated. In many cases, it would just make more sense to use proper mechanisms for security (or topological information lookup) in the first place. At minimum, the applications that use it as a generic authorization (in the sense that a record exists at all) should be modified as soon as possible to avoid such lookups completely.
目前尚不清楚要求或建议更新反向DNS记录是否有意义。在许多情况下，首先使用适当的安全机制（或拓扑信息查找）更有意义。至少，应该尽快修改将其用作一般授权（在记录存在的意义上）的应用程序，以完全避免此类查找。
The applicability is discussed at more length in [WIP-S2005c].
[WIP-S2005c]详细讨论了适用性。
Reverse DNS can of course be updated using manual or custom methods. These are not further described here, except for one special case.
当然，可以使用手动或自定义方法更新反向DNS。除一种特殊情况外，此处不再进一步描述这些情况。
One way to deploy reverse DNS would be to use wildcard records, for example, by configuring one name for a subnet (/64) or a site (/48). As a concrete example, a site (or the site's ISP) could configure the reverses of the prefix 2001:db8:f00::/48 to point to one name using a wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR site.example.com.". Naturally, such a name could not be verified from the forward DNS, but would at least provide some form of "topological information" or "weak authorization" if that is really considered to be useful. Note that this is not actually updating the DNS as such, as the whole point is to avoid DNS updates completely by manually configuring a generic name.
部署反向DNS的一种方法是使用通配符记录，例如，为子网（/64）或站点（/48）配置一个名称。作为一个具体的例子，站点（或站点的ISP）可以配置前缀2001:db8:f00:：/48的反转，以使用通配符记录指向一个名称，如PTR site.example.com中的“*.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.”。当然，这样的名称无法从前向DNS进行验证，但至少会提供某种形式的“拓扑信息”或“弱授权”，如果这真的被认为是有用的话。请注意，这实际上并不是更新DNS本身，因为整个要点是通过手动配置通用名称来完全避免DNS更新。
Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in some regard, while being more difficult in another, as described below.
在某些方面，使用SLAAC的动态反向DNS比正向DNS更新更简单，而在另一方面则更困难，如下所述。
The address space administrator decides whether or not the hosts are trusted to update their reverse DNS records. If they are trusted and deployed at the same site (e.g., not across the Internet), a simple address-based authorization is typically sufficient (i.e., check that the DNS update is done from the same IP address as the record being updated); stronger security can also be used [RFC3007]. If they aren't allowed to update the reverses, no update can occur. However, such address-based update authorization operationally requires that ingress filtering [RFC3704] has been set up at the border of the site where the updates occur, and as close to the updater as possible.
地址空间管理员决定是否信任主机更新其反向DNS记录。如果它们受信任并部署在同一站点（例如，不跨互联网），则简单的基于地址的授权通常就足够了（即，检查DNS更新是否从与正在更新的记录相同的IP地址完成）；也可以使用更强的安全性[RFC3007]。如果不允许他们更新反转，则无法进行更新。然而，这种基于地址的更新授权在操作上要求入口过滤[RFC3704]设置在发生更新的站点边界，并尽可能靠近更新程序。
Address-based authorization is simpler with reverse DNS (as there is a connection between the record and the address) than with forward DNS. However, when a stronger form of security is used, forward DNS updates are simpler to manage because the host can be assumed to have an association with the domain. Note that the user may roam to different networks and does not necessarily have any association with the owner of that address space. So, assuming a stronger form of authorization for reverse DNS updates than an address association is generally infeasible.
基于地址的授权使用反向DNS比使用正向DNS更简单（因为记录和地址之间存在连接）。但是，当使用更强大的安全形式时，前向DNS更新更易于管理，因为可以假定主机与域有关联。注意，用户可以漫游到不同的网络，并且不一定与该地址空间的所有者有任何关联。因此，假设反向DNS更新的授权形式比地址关联更强，通常是不可行的。
Moreover, the reverse zones must be cleaned up by an unspecified janitorial process: the node does not typically know a priori that it will be disconnected, and it cannot send a DNS update using the correct source address to remove a record.
此外，反向区域必须通过未指定的清理过程进行清理：节点通常事先不知道它将断开连接，并且无法使用正确的源地址发送DNS更新以删除记录。
A problem with defining the clean-up process is that it is difficult to ensure that a specific IP address and the corresponding record are no longer being used. Considering the huge address space, and the unlikelihood of collision within 64 bits of the interface identifiers, a process that would remove the record after no traffic has been seen from a node in a long period of time (e.g., a month or year) might be one possible approach.
定义清理过程的一个问题是，很难确保不再使用特定的IP地址和相应的记录。考虑到巨大的地址空间，以及接口标识符的64位内不太可能发生冲突，一种可能的方法是在长时间（例如，一个月或一年）没有从节点看到通信量后删除记录。
To insert or update the record, the node must discover the DNS server to send the update to somehow, similar to as discussed in Section 6.2. One way to automate this is looking up the DNS server authoritative (e.g., through SOA record) for the IP address being updated, but the security material (unless the IP address-based authorization is trusted) must also be established by some other means.
要插入或更新记录，节点必须以某种方式发现要向其发送更新的DNS服务器，如第6.2节所述。自动化此操作的一种方法是查找DNS服务器权威（例如，通过SOA记录）以查找正在更新的IP地址，但还必须通过其他方式建立安全材料（除非基于IP地址的授权是可信的）。
One should note that Cryptographically Generated Addresses (CGAs) [RFC3972] may require a slightly different kind of treatment. CGAs are addresses where the interface identifier is calculated from a public key, a modifier (used as a nonce), the subnet prefix, and other data. Depending on the usage profile, CGAs might or might not be changed periodically due to, e.g., privacy reasons. As the CGA address is not predictable, a reverse record can only reasonably be inserted in the DNS by the node that generates the address.
需要注意的是，加密生成地址（CGA）[RFC3972]可能需要稍微不同的处理方式。CGA是根据公钥、修饰符（用作nonce）、子网前缀和其他数据计算接口标识符的地址。根据使用情况，由于（例如）隐私原因，CGA可能会或可能不会定期更改。由于CGA地址不可预测，因此只能由生成地址的节点合理地将反向记录插入DNS中。
With DHCPv4, the reverse DNS name is typically already inserted to the DNS that reflects the name (e.g., "dhcp-67.example.com"). One can assume similar practice may become commonplace with DHCPv6 as well; all such mappings would be pre-configured and would require no updating.
对于DHCPv4，反向DNS名称通常已经插入到反映名称的DNS中（例如，“dhcp-67.example.com”）。我们可以假设类似的做法在DHCPv6中也很常见；所有这些映射都将预先配置，不需要更新。
If a more explicit control is required, similar considerations as with SLAAC apply, except for the fact that typically one must update a reverse DNS record instead of inserting one (if an address assignment policy that reassigns disused addresses is adopted) and updating a record seems like a slightly more difficult thing to secure. However, it is yet uncertain how DHCPv6 is going to be used for address assignment.
如果需要更明确的控制，与SLAAC类似的考虑也适用，除了通常必须更新反向DNS记录而不是插入一个（如果采用了重新分配废弃地址的地址分配策略），并且更新记录似乎是一件更难确保的事情。然而，DHCPv6将如何用于地址分配尚不确定。
Note that when using DHCP, either the host or the DHCP server could perform the DNS updates; see the implications in Section 6.2.
请注意，当使用DHCP时，主机或DHCP服务器都可以执行DNS更新；参见第6.2节中的含义。
If disused addresses were to be reassigned, host-based DDNS reverse updates would need policy considerations for DNS record modification, as noted above. On the other hand, if disused address were not to be assigned, host-based DNS reverse updates would have similar considerations as SLAAC in Section 7.3. Server-based updates have similar properties except that the janitorial process could be integrated with DHCP address assignment.
如上文所述，如果要重新分配废弃的地址，基于主机的DDN反向更新将需要考虑修改DNS记录的策略。另一方面，如果不分配废弃地址，则基于主机的DNS反向更新的考虑事项与第7.3节中的SLAAC类似。基于服务器的更新具有类似的属性，只是看门人进程可以与DHCP地址分配集成。
In cases where a prefix, instead of an address, is being used and updated, one should consider what is the location of the server where DDNS updates are made. That is, where the DNS server is located:
在前缀，而不是地址，正在使用和更新的情况下，人们应该考虑什么是服务器的位置，其中DDNS更新作出。即，DNS服务器所在的位置：
1. At the same organization as the prefix delegator.
1. 与前缀委托人位于同一组织。
2. At the site where the prefixes are delegated to. In this case, the authority of the DNS reverse zone corresponding to the delegated prefix is also delegated to the site.
2. 在将前缀委派给的站点。在这种情况下，与委派前缀对应的DNS反向区域的权限也委派给站点。
3. Elsewhere; this implies a relationship between the site and where the DNS server is located, and such a relationship should be rather straightforward to secure as well. Like in the previous case, the authority of the DNS reverse zone is also delegated.
3. 在别处这意味着站点和DNS服务器所在地之间存在一种关系，而且这种关系也应该非常容易保护。与前一种情况一样，DNS反向区域的权限也被授予。
In the first case, managing the reverse DNS (delegation) is simpler as the DNS server and the prefix delegator are in the same administrative domain (as there is no need to delegate anything at all); alternatively, the prefix delegator might forgo DDNS reverse capability altogether, and use, e.g., wildcard records (as described in Section 7.2). In the other cases, it can be slightly more difficult, particularly as the site will have to configure the DNS server to be authoritative for the delegated reverse zone, implying automatic configuration of the DNS server -- as the prefix may be dynamic.
在第一种情况下，管理反向DNS（委派）更简单，因为DNS服务器和前缀委派者位于同一管理域中（因为根本不需要委派任何内容）；或者，前缀委托人可能完全放弃DDNS反向功能，并使用通配符记录（如第7.2节所述）。在其他情况下，这可能会稍微困难一些，特别是因为站点必须将DNS服务器配置为授权的反向区域，这意味着DNS服务器的自动配置——因为前缀可能是动态的。
Managing the DDNS reverse updates is typically simple in the second case, as the updated server is located at the local site, and arguably IP address-based authentication could be sufficient (or if not, setting up security relationships would be simpler). As there is an explicit (security) relationship between the parties in the third case, setting up the security relationships to allow reverse DDNS updates should be rather straightforward as well (but IP address-based authentication might not be acceptable). In the first case, however, setting up and managing such relationships might be a lot more difficult.
在第二种情况下，管理DDNS反向更新通常很简单，因为更新后的服务器位于本地站点，可以说基于IP地址的身份验证就足够了（或者，如果没有，则设置安全关系会更简单）。由于在第三种情况下双方之间存在明确的（安全）关系，因此设置安全关系以允许反向DDNS更新也应该相当简单（但基于IP地址的身份验证可能不可接受）。然而，在第一种情况下，建立和管理这种关系可能要困难得多。
This section describes miscellaneous considerations about DNS that seem related to IPv6, for which no better place has been found in this document.
本节介绍有关DNS的其他注意事项，这些注意事项似乎与IPv6有关，在本文档中找不到更好的位置。
The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look like AAAA records to the IPv6-only nodes. Numerous problems have been identified with [WIP-AD2005]. This is a strong reason not to use NAT-PT in the first place.
NAT-PT[RFC2766]的DNS-ALG组件会将一个记录弄乱，使其在仅IPv6的节点上看起来像AAAA记录。[WIP-AD2005]发现了许多问题。这是一个强有力的理由，不使用NAT-PT放在首位。
One of the most difficult problems of systematic IP address renumbering procedures [RFC4192] is that an application that looks up a DNS name disregards information such as TTL, and uses the result obtained from DNS as long as it happens to be stored in the memory of the application. For applications that run for a long time, this
系统IP地址重新编号过程[RFC4192]最困难的问题之一是，查找DNS名称的应用程序忽略了TTL等信息，只要从DNS获得的结果恰好存储在应用程序的内存中，就会使用该结果。对于运行时间较长的应用程序，此
could be days, weeks, or even months. Some applications may be clever enough to organize the data structures and functions in such a manner that lookups get refreshed now and then.
可能是几天、几周甚至几个月。有些应用程序可能足够聪明，能够以这样的方式组织数据结构和函数，以便不时刷新查找。
While the issue appears to have a clear solution, "fix the applications", practically, this is not reasonable immediate advice. The TTL information is not typically available in the APIs and libraries (so, the advice becomes "fix the applications, APIs, and libraries"), and a lot more analysis is needed on how to practically go about to achieve the ultimate goal of avoiding using the names longer than expected.
虽然这个问题似乎有一个明确的解决方案，“修复应用程序”，但实际上，这并不是一个合理的即时建议。TTL信息通常在API和库中不可用（因此，建议变成“修复应用程序、API和库”），并且需要更多的分析，以实际实现避免使用超过预期时间的名称的最终目标。
Some recommendations (Section 4.3, Section 5.1) about IPv6 service provisioning were moved here from [RFC4213] by Erik Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided useful feedback and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark Andrews helped in clarifying the issues regarding additional data and the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided useful feedback during the WG last call. Thomas Narten provided extensive feedback during the IESG evaluation.
Erik Nordmark和Bob Gilligan将有关IPv6服务供应的一些建议（第4.3节和第5.1节）从[RFC4213]移到这里。迈克尔·帕特恩斯提供了有用的反馈和改进。Scott Rose、Rob Austein、Masataka Ohta和Mark Andrews帮助澄清了有关附加数据和TTL使用的问题。Jefsey Morfin、Ralph Droms、Peter Koch、Jinmei Tatuya、Iljitsch van Beijnum、Edward Lewis和Rob Austein在工作组上次通话中提供了有用的反馈。Thomas Narten在IESG评估期间提供了广泛的反馈。
This document reviews the operational procedures for IPv6 DNS operations and does not have security considerations in itself.
本文档回顾了IPv6 DNS操作的操作过程，本身没有安全考虑因素。
However, it is worth noting that in particular with Dynamic DNS updates, security models based on the source address validation are very weak and cannot be recommended -- they could only be considered in the environments where ingress filtering [RFC3704] has been deployed. On the other hand, it should be noted that setting up an authorization mechanism (e.g., a shared secret, or public-private keys) between a node and the DNS server has to be done manually, and may require quite a bit of time and expertise.
但是，值得注意的是，特别是在动态DNS更新中，基于源地址验证的安全模型非常薄弱，因此不能推荐使用——它们只能在部署了入口过滤[RFC3704]的环境中使用。另一方面，应当注意，在节点和DNS服务器之间设置授权机制（例如，共享密钥或公共-私钥）必须手动完成，并且可能需要相当多的时间和专业知识。
To re-emphasize what was already stated, the reverse+forward DNS check provides very weak security at best, and the only (questionable) security-related use for them may be in conjunction with other mechanisms when authenticating a user.
为了再次强调已经说过的内容，反向+正向DNS检查最多只能提供非常弱的安全性，并且它们唯一（有问题的）与安全相关的用途可能是在验证用户时与其他机制结合使用。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[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月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, July 1997.
[RFC2182]Elz，R.，Bush，R.，Bradner，S.，和M.Patton，“辅助DNS服务器的选择和操作”，BCP 16，RFC 2182，1997年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC3152]Bush，R.，“IP6.ARPA的授权”，BCP 49，RFC 3152，2001年8月。
[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月。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363]Bush，R.，Durand，A.，Fink，B.，Gudmundsson，O.，和T.Hain，“代表域名系统（DNS）中的互联网协议版本6（IPv6）地址”，RFC 33632002年8月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364]Austein，R.，“互联网协议版本6（IPv6）的域名系统（DNS）支持权衡”，RFC 3364，2002年8月。
[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月。
[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月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879]Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 3879，2004年9月。
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, September 2004.
[RFC3901]Durand，A.和J.Ihren，“DNS IPv6传输操作指南”，BCP 91，RFC 3901，2004年9月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038]Shin，M-K.，Hong，Y-G.，Hagino，J.，Savola，P.，和E.Castro，“IPv6过渡的应用方面”，RFC 4038，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月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339]Jeong，J.，Ed.，“DNS服务器信息方法的IPv6主机配置”，RFC 4339，2006年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]互联网体系结构委员会，“IAB关于唯一DNS根的技术评论”，RFC 2826，2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 4025，2005年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215]Wiljakka，J.，“第三代合作伙伴计划（3GPP）网络中IPv6过渡的分析”，RFC 4215，2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit handling and additional data" on DNSEXT mailing list, Message-Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August 1, 2005, <http://ops.ietf.org/lists/namedroppers/ namedroppers.2005/msg01102.html>.
[TC-TEST]金梅，T.，“线程”RFC2181第9.1节：DNSEXT邮件列表上的“TC位处理和附加数据”，消息Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp“，2005年8月1日<http://ops.ietf.org/lists/namedroppers/ namedroppers.2005/msg0102.html>。
[WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", Work in Progress, October 2005.
[WIP-AD2005]Aoun，C.和E.Davies，“将NAT-PT移到实验阶段的原因”，正在进行的工作，2005年10月。
[WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to publish, that is the question", Work in Progress, October 2005.
[WIP-DC2005]Durand，A.和T.Chown，“出版还是不出版，这是一个问题”，正在进行的工作，2005年10月。
[WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation Specification", Work in Progress, November 2005.
[WIP-H2005]Huston，G.，“6to4反向DNS委托规范”，正在进行的工作，2005年11月。
[WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS Configuration", Work in Progress, January 2006.
[WIP-J2006]Jeong，J.，“DNS配置的IPv6路由器广告选项”，正在进行的工作，2006年1月。
[WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution Misbehavior", Work in Progress, February 2006.
[WIP-LB2005]Larson，M.和P.Barber，“观察到的DNS解析错误行为”，正在进行的工作，2006年2月。
[WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in Progress, February 2004.
[WIP-O2004]Ohta，M.，“预配置DNS服务器地址”，正在进行的工作，2004年2月。
[WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Work in Progress, January 2006.
[WIP-R2006]Roy，S.，“基于链路假设的IPv6邻居发现被认为是有害的”，正在进行的工作，2006年1月。
[WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6 on by Default", Work in Progress, July 2004.
[WIP-RDP2004]Roy，S.，Durand，A.，和J.Paugh，“双栈IPv6默认开启的问题”，正在进行的工作，2004年7月。
[WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in Progress, March 2006.
[WIP-S2005a]Stapp，M.，“DHCP客户端FQDN选项”，正在进行的工作，2006年3月。
[WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information (DHCID RR)", Work in Progress, March 2006.
[WIP-S2005b]Stapp，M.，“用于编码DHCP信息的DNS RR（DHCID RR）”，正在进行的工作，2006年3月。
[WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", Work in Progress, August 2005.
[WIP-S2005c]Senie，D.，“鼓励使用DNS地址映射”，正在进行的工作，2005年8月。
[WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among DHCP Clients", Work in Progress, March 2006.
[WIP-SV2005]Stapp，M.和B.Volz，“DHCP客户端之间FQDN冲突的解决”，正在进行的工作，2006年3月。
Unique local addresses [RFC4193] have replaced the now-deprecated site-local addresses [RFC3879]. From the perspective of the DNS, the locally generated unique local addresses (LUL) and site-local addresses have similar properties.
唯一本地地址[RFC4193]已取代现在已弃用的站点本地地址[RFC3879]。从DNS的角度来看，本地生成的唯一本地地址（LUL）和站点本地地址具有相似的属性。
The interactions with DNS come in two flavors: forward and reverse DNS.
与DNS的交互有两种：正向DNS和反向DNS。
To actually use local addresses within a site, this implies the deployment of a "split-faced" or a fragmented DNS name space, for the zones internal to the site, and the outsiders' view to it. The procedures to achieve this are not elaborated here. The implication is that local addresses must not be published in the public DNS.
要在站点内实际使用本地地址，这意味着为站点内部的区域和外部人员对其的看法部署“分割面”或分段DNS名称空间。实现这一点的程序在此不作详细说明。这意味着本地地址不得在公共DNS中发布。
To facilitate reverse DNS (if desired) with local addresses, the stub resolvers must look for DNS information from the local DNS servers, not, e.g., starting from the root servers, so that the local information may be provided locally. Note that the experience of private addresses in IPv4 has shown that the root servers get loaded for requests for private address lookups in any case. This requirement is discussed in [RFC4193].
为了便于使用本地地址进行反向DNS（如果需要），存根解析程序必须从本地DNS服务器查找DNS信息，而不是（例如）从根服务器开始，以便本地提供本地信息。请注意，IPv4中私有地址的经验表明，在任何情况下，根服务器都会加载用于私有地址查找的请求。[RFC4193]中讨论了该要求。
Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments
附录B.IPv4/IPv6环境中附加数据的行为
DNS responses do not always fit in a single UDP packet. We'll examine the cases that happen when this is due to too much data in the Additional section.
DNS响应并不总是适合单个UDP数据包。我们将在附加部分中分析由于数据过多而导致的情况。
There are two kinds of additional data:
有两种附加数据：
1. "critical" additional data; this must be included in all scenarios, with all the RRsets, and
1. “关键”附加数据；这必须包括在所有场景中，包括所有RRSET，以及
2. "courtesy" additional data; this could be sent in full, with only a few RRsets, or with no RRsets, and can be fetched separately as well, but at the cost of additional queries.
2. “礼貌”附加数据；这可以完全发送，只有几个RRSET，或者没有RRSET，也可以单独获取，但需要额外的查询。
The responding server can algorithmically determine which type the additional data is by checking whether it's at or below a zone cut.
响应服务器可以通过检查附加数据是在分区切割处还是在分区切割以下，通过算法确定附加数据的类型。
Only those additional data records (even if sometimes carelessly termed "glue") are considered "critical" or real "glue" if and only if they meet the above-mentioned condition, as specified in Section 4.2.1 of [RFC1034].
只有当且仅当这些附加数据记录满足[RFC1034]第4.2.1节规定的上述条件时，才将其视为“关键”或真正的“粘合”。
Remember that resource record sets (RRsets) are never "broken up", so if a name has 4 A records and 5 AAAA records, you can either return all 9, all 4 A records, all 5 AAAA records, or nothing. In particular, notice that for the "critical" additional data getting all the RRsets can be critical.
请记住，资源记录集（RRSET）永远不会被“分解”，因此，如果一个名称有4个a记录和5个AAAA记录，则可以返回全部9个、全部4个a记录、全部5个AAAA记录，或者什么都不返回。特别要注意的是，对于“关键”的额外数据，获取所有RRSET可能是关键的。
In particular, [RFC2181] specifies (in Section 9) that:
具体而言，[RFC2181]规定（在第9节中）：
a. if all the "critical" RRsets do not fit, the sender should set the TC bit, and the recipient should discard the whole response and retry using mechanism allowing larger responses such as TCP.
a. 如果所有“关键”RRSET都不适合，发送方应设置TC位，接收方应放弃整个响应，并使用允许更大响应（如TCP）的机制重试。
b. "courtesy" additional data should not cause the setting of the TC bit, but instead all the non-fitting additional data RRsets should be removed.
b. “礼节性”附加数据不应导致TC位的设置，而是应删除所有不适合的附加数据集。
An example of the "courtesy" additional data is A/AAAA records in conjunction with MX records as shown in Section 4.4; an example of the "critical" additional data is shown below (where getting both the A and AAAA RRsets is critical with respect to the NS RR):
“礼节性”附加数据的一个例子是A/AAAA记录和MX记录，如第4.4节所示；“关键”附加数据的示例如下所示（其中，获取A和AAAA RRSET对于NS RR而言至关重要）：
child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN AAAA 2001:db8::1
child.example.com。在NS.child.example.com中。ns.child.example.com。在192.0.2.1 ns.child.example.com中。在AAAA 2001中：db8:：1
When there is too much "courtesy" additional data, at least the non-fitting RRsets should be removed [RFC2181]; however, as the additional data is not critical, even all of it could be safely removed.
当有太多的“礼貌”附加数据时，至少应移除不合适的RRSET[RFC2181]；但是，由于附加数据并不重要，因此即使是所有数据都可以安全删除。
When there is too much "critical" additional data, TC bit will have to be set, and the recipient should ignore the response and retry using TCP; if some data were to be left in the UDP response, the issue is which data could be retained.
当“关键”附加数据过多时，必须设置TC位，接收方应忽略响应并使用TCP重试；如果UDP响应中保留了一些数据，问题是可以保留哪些数据。
However, the practice may differ from the specification. Testing and code analysis of three recent implementations [TC-TEST] confirm this. None of the tested implementations have a strict separation of critical and courtesy additional data, while some forms of additional data may be treated preferably. All the implementations remove some (critical or courtesy) additional data RRsets without setting the TC bit if the response would not otherwise fit.
然而，实践可能与规范不同。最近三次实现的测试和代码分析[TC-TEST]证实了这一点。没有一个经过测试的实现对关键和礼貌的附加数据进行严格的分离，而某些形式的附加数据可能会得到更好的处理。如果响应不适合，则所有实现都会删除一些（关键或礼貌）附加数据集，而不设置TC位。
Failing to discard the response with the TC bit or omitting critical information but not setting the TC bit lead to an unrecoverable problem. Omitting only some of the RRsets if all would not fit (but not setting the TC bit) leads to a performance problem. These are discussed in the next two subsections.
未能放弃带有TC位的响应或忽略关键信息但未设置TC位会导致无法恢复的问题。如果所有RRSET都不适合，则仅省略部分RRSET（但不设置TC位），会导致性能问题。这些将在接下来的两个小节中讨论。
NOTE: omitting some critical additional data instead of setting the TC bit violates a 'should' in Section 9 of RFC2181. However, as many implementations still do that [TC-TEST], operators need to understand its implications, and we describe that behavior as well.
注：省略一些关键附加数据而不是设置TC位违反RFC2181第9节中的“应”。然而，由于许多实现仍然这样做[TC-TEST]，操作员需要理解其含义，我们也描述了这种行为。
If the implementation decides to keep as much data (whether "critical" or "courtesy") as possible in the UDP responses, it might be tempting to use the transport of the DNS query as a hint in either of these cases: return the AAAA records if the query was done over IPv6, or return the A records if the query was done over IPv4. However, this breaks the model of independence of DNS transport and resource records, as noted in Section 1.2.
如果实现决定在UDP响应中保留尽可能多的数据（无论是“关键的”还是“礼貌的”），那么在以下任一情况下，都可能倾向于使用DNS查询的传输作为提示：如果查询是通过IPv6完成的，则返回AAAA记录；如果查询是通过IPv4完成的，则返回a记录。然而，这打破了DNS传输和资源记录的独立性模型，如第1.2节所述。
With courtesy additional data, as long as enough RRsets will be removed so that TC will not be set, it is allowed to send as many complete RRsets as the implementations prefers. However, the implementations are also free to omit all such RRsets, even if complete. Omitting all the RRsets (when removing only some would suffice) may create a performance penalty, whereby the client may need to issue one or more additional queries to obtain necessary and/or consistent information.
有了额外的数据，只要删除足够多的RRSET，以便不设置TC，就可以根据实施情况发送尽可能多的完整RRSET。然而，这些实现也可以省略所有这样的RRSET，即使是完整的。省略所有RRSET（仅删除一些就足够）可能会造成性能损失，因此客户可能需要发出一个或多个附加查询以获得必要和/或一致的信息。
With critical additional data, the alternatives are either returning nothing (and absolutely requiring a retry with TCP) or returning something (working also in the case if the recipient does not discard the response and retry using TCP) in addition to setting the TC bit. If the process for selecting "something" from the critical data would otherwise be practically "flipping the coin" between A and AAAA records, it could be argued that if one looked at the transport of the query, it would have a larger possibility of being right than just 50/50. In other words, if the returned critical additional data would have to be selected somehow, using something more sophisticated than a random process would seem justifiable.
对于关键的额外数据，除了设置TC位外，其他选择要么不返回任何内容（并且绝对需要使用TCP重试），要么返回某些内容（在收件人不放弃响应并使用TCP重试的情况下也有效）。如果从关键数据中选择“某物”的过程实际上是在A和AAAA记录之间“掷硬币”，那么可以说，如果我们看一下查询的传输，它的正确性将比50/50的可能性更大。换句话说，如果必须以某种方式选择返回的关键附加数据，那么使用比随机过程更复杂的方法似乎是合理的。
That is, leaving in some intelligently selected critical additional data is a trade-off between creating an optimization for those resolvers that ignore the "should discard" recommendation and causing a protocol problem by propagating inconsistent information about "critical" records in the caches.
也就是说，在为忽略“应放弃”建议的解析程序创建优化和通过在缓存中传播有关“关键”记录的不一致信息而导致协议问题之间，保留一些智能选择的关键附加数据是一种折衷。
Similarly, leaving in the complete courtesy additional data RRsets instead of removing all the RRsets is a performance trade-off as described in the next section.
类似地，保留完整的附加数据RRSET而不是删除所有RRSET是一种性能权衡，如下一节所述。
As noted above, the temptation for omitting only some of the additional data could be problematic. This is discussed more below.
如上所述，仅省略部分附加数据的诱惑可能会产生问题。下面将对此进行详细讨论。
For courtesy additional data, this causes a potential performance problem as this requires that the clients issue re-queries for the potentially omitted RRsets. For critical additional data, this causes a potential unrecoverable problem if the response is not discarded and the query not re-tried with TCP, as the nameservers might be reachable only through the omitted RRsets.
对于额外的数据，这会导致潜在的性能问题，因为这需要客户端对可能省略的RRSET发出重新查询。对于关键的附加数据，如果不放弃响应，并且不使用TCP重新尝试查询，则会导致潜在的不可恢复问题，因为只有通过省略的RRSET才能访问名称服务器。
If an implementation would look at the transport used for the query, it is worth remembering that often the host using the records is different from the node requesting them from the authoritative DNS server (or even a caching resolver). So, whichever version the requestor (e.g., a recursive server in the middle) uses makes no difference to the ultimate user of the records, whose transport capabilities might differ from those of the requestor. This might result in, e.g., inappropriately returning A records to an IPv6-only node, going through a translation, or opening up another IP-level session (e.g., a Packet Data Protocol (PDP) context [RFC4215]). Therefore, at least in many scenarios, it would be very useful if the information returned would be consistent and complete -- or if that is not feasible, leave it to the client to query again.
如果一个实现将查看用于查询的传输，那么值得记住的是，使用记录的主机通常与从权威DNS服务器（甚至缓存解析程序）请求记录的节点不同。因此，无论请求者使用哪个版本（例如，中间的递归服务器），对记录的最终用户都没有影响，因为记录的传输能力可能与请求者的传输能力不同。这可能导致，例如，不适当地将记录返回到仅IPv6的节点、进行转换或打开另一个IP级会话（例如，分组数据协议（PDP）上下文[RFC4215]）。因此，至少在许多情况下，如果返回的信息是一致和完整的，或者如果这不可行，则将其留给客户机再次查询，这将非常有用。
The problem of too much additional data seems to be an operational one: the zone administrator entering too many records that will be returned truncated (or missing some RRsets, depending on implementations) to the users. A protocol fix for this is using Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity for larger UDP packet sizes, pushing up the relevant threshold. Further, DNS server implementations should omit courtesy additional data completely rather than including only some RRsets [RFC2181]. An operational fix for this is having the DNS server implementations return a warning when the administrators create zones that would result in too much additional data being returned. Further, DNS server implementations should warn of or disallow such zone configurations that are recursive or otherwise difficult to manage by the protocol.
过多额外数据的问题似乎是一个操作问题：区域管理员输入了太多记录，这些记录将被截断（或丢失一些RRSET，具体取决于实现）返回给用户。一种协议修复方法是使用DNS扩展机制（EDNS0）[RFC2671]向较大UDP数据包大小发送容量信号，从而提高相关阈值。此外，DNS服务器实现应该完全省略额外的数据，而不是只包括一些RRSET[RFC2181]。对此的操作修复是，当管理员创建区域时，DNS服务器实现将返回警告，这将导致返回太多额外数据。此外，DNS服务器实现应警告或禁止此类递归区域配置或协议难以管理的区域配置。
Authors' Addresses
作者地址
Alain Durand Comcast 1500 Market St. Philadelphia, PA 19102 USA
阿兰·杜兰德康卡斯特1500市场圣费城，宾夕法尼亚州，19102年
EMail: Alain_Durand@cable.comcast.com
EMail: Alain_Durand@cable.comcast.com
Johan Ihren Autonomica Bellmansgatan 30 SE-118 47 Stockholm Sweden
瑞典斯德哥尔摩约翰·伊赫伦自治区贝尔曼斯加坦30 SE-118 47
EMail: johani@autonomica.se
EMail: johani@autonomica.se
Pekka Savola CSC/FUNET Espoo Finland
佩卡·萨沃拉CSC/芬兰福内·埃斯波
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。