Internet Engineering Task Force (IETF) L. Howard
Request for Comments: 8501 Retevia
Category: Informational November 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) L. Howard
Request for Comments: 8501 Retevia
Category: Informational November 2018
ISSN: 2070-1721
Reverse DNS in IPv6 for Internet Service Providers
Internet服务提供商IPv6中的反向DNS
Abstract
摘要
In IPv4, Internet Service Providers (ISPs) commonly provide IN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.
在IPv4中，互联网服务提供商（ISP）通常通过为每个可用地址预填充一条PTR记录来为其客户提供In-ADDR.ARPA信息。这种做法在IPv6中无法扩展。本文件分析了ISP管理IP6.ARPA区域的不同方法和注意事项。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8501.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8501.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3
1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4
2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4
2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4
2.2. Wildcard Match . . . . . . . . . . . . . . . . . . . . . 5
2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6
2.3.2. Dynamic DNS through Residential Gateways . . . . . . 7
2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7
2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8
2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8
2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8
2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Dynamically Generate PTR When Queried ("On the Fly") . . 9
3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 10
4. Considerations and Recommendations . . . . . . . . . . . . . 10
5. Security and Privacy Considerations . . . . . . . . . . . . . 11
5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11
5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11
5.3. Considerations for Other Uses of the DNS . . . . . . . . 12
5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 12
5.5. User Creativity . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3
1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4
2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4
2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4
2.2. Wildcard Match . . . . . . . . . . . . . . . . . . . . . 5
2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6
2.3.2. Dynamic DNS through Residential Gateways . . . . . . 7
2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7
2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8
2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8
2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8
2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Dynamically Generate PTR When Queried ("On the Fly") . . 9
3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 10
4. Considerations and Recommendations . . . . . . . . . . . . . 10
5. Security and Privacy Considerations . . . . . . . . . . . . . 11
5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11
5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11
5.3. Considerations for Other Uses of the DNS . . . . . . . . 12
5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 12
5.5. User Creativity . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
[RFC1912] recommended that "every Internet-reachable host should have a name" and says "Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all". While the need for a PTR record and for it to match is debatable as a best practice, some network services (see Section 4) still do rely on PTR lookups, and some check the source address of incoming connections and verify that the PTR and A records match before providing service.
[RFC1912]建议“每个可访问Internet的主机都应该有一个名称”，并表示“如果没有匹配的PTR和a记录，可能会导致Internet服务丢失，类似于根本没有在DNS中注册”。虽然PTR记录及其匹配的必要性作为最佳实践存在争议，但一些网络服务（见第4节）仍然依赖于PTR查找，一些网络服务在提供服务之前检查传入连接的源地址并验证PTR和记录匹配。
Individual Internet users on the residential or consumer scale, including small and home businesses, are constantly connecting to or moving around the Internet. For large ISPs who serve residential users, maintenance of individual PTR records is impractical.
住宅或消费者规模的个人互联网用户，包括小型和家庭企业，不断连接到互联网或在互联网上移动。对于服务于住宅用户的大型ISP来说，维护个人PTR记录是不切实际的。
Administrators at ISPs should consider whether customer PTR records are needed, and if so, evaluate methods for responding to reverse DNS queries in IPv6.
ISP的管理员应该考虑是否需要客户PTR记录，如果是这样的话，评估响应IPv6中反向DNS查询的方法。
ISPs that provide access to many residential users typically assign one or a few IPv4 addresses to each of those users and populate an IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some ISPs also configure forward zones with matching A records so that lookups match. For instance, if an ISP Example.com aggregated 192.0.2.0/24 at a network hub in one region, the reverse zone might look like:
为许多住宅用户提供访问权限的ISP通常为这些用户中的每一个分配一个或几个IPv4地址，并使用每个IPv4地址的一个PTR记录填充一个IN-ADDR.ARPA区域。一些ISP还使用匹配的A记录配置转发区域，以便查找匹配。例如，如果ISP Example.com在一个区域的网络集线器处聚合192.0.2.0/24，则反向区域可能如下所示：
1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com.
1.2.0.192.IN-ADDR.ARPA。在PTR 1.string.region.example.com中。
2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com.
2.2.0.192.IN-ADDR.ARPA。在PTR 2.string.region.example.com中。
3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
3.2.0.192.IN-ADDR.ARPA。在PTR 3.string.region.example.com中。
.
.
.
.
.
.
254.2.0.192.IN-ADDR.ARPA. IN PTR 254.string.region.example.com.
254.2.0.192.IN-ADDR.ARPA。在PTR 254.string.region.example.com中。
The conscientious Example.com might then also have a zone:
然后，良心示例网站也可能有一个区域：
1.string.region.example.com. IN A 192.0.2.1
1.string.region.example.com。在192.0.2.1中
2.string.region.example.com. IN A 192.0.2.2
2.string.region.example.com。在192.0.2.2中
3.string.region.example.com. IN A 192.0.2.3
3.string.region.example.com。在192.0.2.3中
.
.
.
.
.
.
254.string.region.example.com. IN A 192.0.2.254
254.string.region.example.com。在192.0.2.254中
Many ISPs generate PTR records for all IP addresses used for customers, and many create the matching A record.
许多ISP为客户使用的所有IP地址生成PTR记录，许多ISP创建匹配的PTR记录。
A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be:
2001:0db8:0f00:0000:0012:34ff:fe56:789a的示例条目可能是：
a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2 .IP6.ARPA. IN PTR 1.string.region.example.com.
a、 9.8.7.6.5.e.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.0.2.IP6.ARPA。在PTR 1.string.region.example.com中。
ISPs will often delegate an IPv6 prefix to their customers. Since 2^^80 possible addresses could be configured in a single /48 zone alone, it is impractical to write a zone with every possible address entered, even with automation. If 1000 entries could be written per second, the zone would still not be complete after 38 trillion years.
ISP通常会将IPv6前缀委托给其客户。由于2^^80个可能的地址可以单独在一个/48区域中配置，因此即使在自动化的情况下，用输入的每个可能的地址编写区域也是不切实际的。如果每秒可以写入1000条条目，那么在38万亿年后，该区域仍将不完整。
Furthermore, it is often impossible to associate hostnames and addresses, since the 64 bits in the Interface Identifier portion of the address are frequently assigned using Stateless Address Autoconfiguration (SLAAC) [RFC4862] when the host comes online, and they may be short-lived.
此外，通常不可能关联主机名和地址，因为当主机联机时，地址的接口标识符部分中的64位经常使用无状态地址自动配置（SLAAC）[RFC4862]进行分配，并且它们可能是短期的。
[RFC1912] is an Informational RFC that says "PTR records must point back to a valid A record" and further that the administrator should "Make sure your PTR and A records match." Herein are considerations for how to follow this advice for AAAA and PTR records.
[RFC1912]是一种信息性RFC，说明“PTR记录必须指向有效的a记录”，并且管理员应“确保您的PTR和a记录匹配”。以下是如何遵循AAAA和PTR记录建议的注意事项。
Several options exist for providing reverse DNS in IPv6. All of these options also exist for IPv4, but the scaling problem is much less severe in IPv4. Each option should be evaluated for its scaling ability, compliance with existing standards and best practices, and availability in common systems.
在IPv6中提供反向DNS有几个选项。IPv4也存在所有这些选项，但在IPv4中，扩展问题不那么严重。应评估每个选项的可扩展性、是否符合现有标准和最佳做法，以及在通用系统中的可用性。
Some ISP DNS administrators may choose to provide only an NXDOMAIN response to PTR queries for subscriber addresses. In some ways, this is the most accurate response, since no name information is known about the host. However, providing a negative response to PTR queries does not satisfy the expectation in [RFC1912] for entries to match. Users of services that are dependent on a successful lookup will have a poor experience. For instance, some web services and Secure Shell (SSH) connections wait for a DNS response, even NXDOMAIN, before responding. For the best user experience, then, it is important to return a response, rather than time out with no answer. On the other hand, external mail servers are likely to reject connections, which might be an advantage in fighting spam.
一些ISP DNS管理员可能会选择仅提供NXDOMAIN响应，以查询订户地址的PTR查询。在某些方面，这是最准确的响应，因为不知道主机的名称信息。但是，对PTR查询提供否定响应并不能满足[RFC1912]中对匹配条目的期望。依赖于成功查找的服务用户的体验会很差。例如，一些web服务和Secure Shell（SSH）连接在响应之前等待DNS响应，甚至是NXDOMAIN。因此，为了获得最佳的用户体验，重要的是返回响应，而不是在没有回答的情况下超时。另一方面，外部邮件服务器可能拒绝连接，这可能是打击垃圾邮件的一个优势。
When evaluating this option, DNS administrators should consider the uses for reverse DNS records and the number of services affecting the number of users.
在评估此选项时，DNS管理员应考虑反向DNS记录的使用和影响用户数量的服务数量。
The use of wildcards in the DNS is described in [RFC4592], and their use in IPv6 reverse DNS is described in [RFC4472].
[RFC4592]中描述了DNS中通配符的使用，而[RFC4472]中描述了它们在IPv6反向DNS中的使用。
While recording all possible addresses is not scalable, it may be possible to record a wildcard entry for each prefix assigned to a customer. Consider also that "inclusion of wildcard NS RRSets in a zone is discouraged, but not barred". [RFC4592]
虽然记录所有可能的地址是不可伸缩的，但可以为分配给客户的每个前缀记录一个通配符条目。还要考虑“在区域中包含通配符NS RRSET是不鼓励的，但不是禁止的”。[RFC4592]
This solution generally scales well. However, since the response will match any address in the wildcard range (/48, /56, /64, etc.), a forward DNS lookup on the response given will not be able to return the same hostname. This method therefore fails the expectation in [RFC1912] that forward and reverse will match. DNSSEC [RFC4035] scalability is limited to signing the wildcard zone, which may be satisfactory.
这种解决方案通常具有良好的扩展性。但是，由于响应将匹配通配符范围（/48、/56、/64等）中的任何地址，因此对给定响应的前向DNS查找将无法返回相同的主机名。因此，该方法无法满足[RFC1912]中的正向和反向匹配的预期。DNSSEC[RFC4035]可扩展性仅限于对通配符区域进行签名，这可能是令人满意的。
One way to ensure that forward and reverse records match is for hosts to update DNS servers dynamically once interface configuration is complete (whether by SLAAC, DHCPv6, or other means), as described in [RFC4472]. Hosts would need to provide both AAAA and PTR updates and would need to know which servers would accept the information.
确保正向和反向记录匹配的一种方法是，主机在接口配置完成后（无论是通过SLAAC、DHCPv6还是其他方式）动态更新DNS服务器，如[RFC4472]中所述。主机需要同时提供AAAA和PTR更新，并且需要知道哪些服务器将接受这些信息。
This option should scale as well or as poorly as IPv4 dynamic DNS (DDNS) does. Dynamic DNS may not scale effectively in large ISP networks that have no single master name server, but a single master server is not best practice. The ISP's DNS system may provide a point for Denial-of-Service attacks, including many attempted DDNS updates. Accepting updates only from authenticated sources may mitigate this risk, but only if authentication itself does not require excessive overhead. No authentication of dynamic DNS updates is inherently provided. Implementers should therefore consider use of TSIG [RFC2845], or at least ingress filtering, so that updates are only accepted from customer address space from internal network interfaces. They should also rate limit the number of updates from a customer per second and consider impacts on scalability. UDP is allowed per [RFC2136], so connection reliability is not assured, though the host should expect an ERROR or NOERROR message from the server; TCP provides transmission control, but the updating host would need to be configured to use TCP.
此选项的可扩展性应与IPv4动态DNS（DDNS）的可扩展性一样好或一样差。在没有单一主服务器的大型ISP网络中，动态DNS可能无法有效扩展，但单一主服务器不是最佳做法。ISP的DNS系统可能会提供拒绝服务攻击点，包括多次尝试的DDNS更新。仅接受来自经过身份验证的源的更新可能会降低此风险，但前提是身份验证本身不需要过多的开销。不提供动态DNS更新的身份验证。因此，实施者应该考虑使用TSIG [RCF254]，或者至少入口过滤，以便仅从内部网络接口接受来自客户地址空间的更新。他们还应该限制每秒更新客户的数量，并考虑对可伸缩性的影响。[RFC2136]允许UDP，因此连接可靠性无法保证，尽管主机应该期望服务器发出错误或无错误消息；TCP提供传输控制，但更新主机需要配置为使用TCP。
Administrators may want to consider user creativity if they provide hostnames, as described in Section 5.5, "User Creativity".
管理员可能想考虑用户创造力，如果他们提供主机名，如第5.5节中所述，“用户创造力”。
There is no assurance of uniqueness if multiple hosts try to update with the same name ("mycomputer.familyname.org"). There is no standard way to indicate to a host what server it should send DDNS updates to; the master listed in the SOA is often assumed to be a DDNS server, but this may not scale.
如果多个主机尝试使用相同的名称（“mycomputer.familyname.org”）进行更新，则无法保证唯一性。没有标准的方法向主机指示应该向哪个服务器发送DDNS更新；SOA中列出的主服务器通常被认为是DDNS服务器，但这可能无法扩展。
In the simplest case, a residential user will have a single host connected to the ISP. Since the typical residential user cannot configure IPv6 addresses or resolving name servers on their hosts, the ISP should provide address information conventionally -- i.e., using their normal combination of Router Advertisements (RAs), DHCP, etc. The ISP should also provide a DNS Recursive Name Server and Domain Search List as described in [RFC3646] or [RFC8106]. In determining its Fully Qualified Domain Name (FQDN), a host will typically use a domain from the Domain Search List. This is an overloading of the parameter; multiple domains could be listed, since hosts may need to search for unqualified names in multiple domains without necessarily being a member of those domains. Administrators should consider whether the Domain Search List actually provides an appropriate DNS suffix(es) when considering use of this option. For the purposes of dynamic DNS, the host would concatenate its local hostname (e.g., "hostname") plus the domain(s) in the Domain Search List (e.g., "customer.example.com"), as in "hostname.customer.example.com".
在最简单的情况下，住宅用户将有一台主机连接到ISP。由于典型的住宅用户无法在其主机上配置IPv6地址或解析名称服务器，ISP应按惯例提供地址信息，即使用路由器广告（RAs）、DHCP等的正常组合。ISP还应提供DNS递归名称服务器和域搜索列表，如中所述[RFC3646]或[RFC8106]。用于确定其完全限定域名（FQDN）主机通常会从域搜索列表中使用域。这是参数的重载；可以列出多个域，因为主机可能需要在多个域中搜索不合格的名称，而不必是这些域的成员。管理员应考虑域搜索列表是否实际上提供了一个考虑使用此选项时，请使用适当的DNS后缀。出于动态DNS的目的，主机将连接其本地主机名（例如，“主机名”）和域搜索列表中的域（例如，“customer.example.com”），如“hostname.customer.example.com”。
Once it learns its address and has a resolving name server, the host must perform an SOA lookup on the IP6.ARPA record to be added in order to find the owner and eventually the server that is authoritative for the zone (which might accept dynamic updates). Several recursive lookups may be required to find the longest prefix that has been delegated. The DNS administrator must designate the Primary Master Server for the longest match required. Once found, the host sends dynamic AAAA and PTR updates using the concatenation defined above ("hostname.customer.example.com").
一旦知道了地址并拥有解析名称服务器，主机必须对要添加的IP6.ARPA记录执行SOA查找，以便找到所有者，并最终找到该区域的权威服务器（可能接受动态更新）。可能需要多次递归查找才能找到已委派的最长前缀。DNS管理员必须为所需的最长匹配指定主主服务器。一旦找到，主机将使用上面定义的连接（“hostname.customer.example.com”）发送动态AAAA和PTR更新。
In order to use this alternative, hosts must be configured to use dynamic DNS. This is not default behavior for many hosts, which is an inhibitor for a large ISP. This option may be scalable, although registration following an outage may cause significant load, and hosts using privacy extensions [RFC4941] may update records daily. It is up to the host to provide matching forward and reverse records and update them when the address changes.
为了使用此替代方案，必须将主机配置为使用动态DNS。这不是许多主机的默认行为，这是大型ISP的一个限制因素。此选项可能是可扩展的，尽管停机后的注册可能会导致大量负载，并且使用隐私扩展[RFC4941]的主机可能会每天更新记录。由主机提供匹配的正向和反向记录，并在地址更改时进行更新。
Residential customers may have a gateway, which may provide DHCPv6 service to hosts from a delegated prefix. ISPs should provide a DNS Recursive Name Server and Domain Search List to the gateway, as described above and in [RFC3646] and [RFC8106]. There are two options for how the gateway uses this information. The first option is for the gateway to respond to DHCPv6 requests with the same DNS Recursive Name Server and Domain Search List provided by the ISP. The alternate option is for the gateway to relay dynamic DNS updates from hosts to the servers and domain provided by the ISP. Host behavior is unchanged; the host sends the same dynamic updates, either to the ISP's server (as provided by the gateway) or to the gateway for it to forward. The gateway would need to be capable of and configured to use dynamic DNS.
住宅客户可能有一个网关，它可以通过委派前缀向主机提供DHCPv6服务。ISP应向网关提供DNS递归名称服务器和域搜索列表，如上文以及[RFC3646]和[RFC8106]中所述。网关如何使用此信息有两个选项。第一个选项是网关使用ISP提供的相同DNS递归名称服务器和域搜索列表响应DHCPv6请求。另一种选择是网关将动态DNS更新从主机中继到ISP提供的服务器和域。宿主行为不变；主机向ISP的服务器（由网关提供）或网关发送相同的动态更新，以便转发。网关需要能够并配置为使用动态DNS。
An ISP may delegate authority for a subdomain, such as "customer12345.town.AW.customer.example.com" or "customer12345.example.com", to the customer's gateway. Each domain thus delegated must be unique within the DNS. The ISP may also then delegate the IP6.ARPA zone for the prefix delegated to the customer, as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA". Then, the customer could provide updates to their own gateway, with forward and reverse. However, individual hosts connected directly to the ISP rarely have the capability to run DNS for themselves; therefore, an ISP can only delegate to customers with gateways capable of being authoritative name servers. If a device requests a DHCPv6 Prefix Delegation, that may be considered a reasonably reliable indicator that it is a gateway, rather than an individual host. It is not necessarily an indicator that the gateway is capable of providing DNS services and therefore cannot be relied upon as a way to test whether this option is feasible. In fact, this kind of delegation will not work for devices complying with [RFC6092], which includes the requirement, "By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server".
ISP可以将子域（如“customer12345.town.AW.customer.example.com”或“customer12345.example.com”）的权限委托给客户的网关。这样委派的每个域在DNS中必须是唯一的。然后，ISP还可以为委托给客户的前缀委托IP6.ARPA区域，如（对于2001:db8:f00:：/48）“0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA”。然后，客户可以为自己的网关提供正向和反向更新。但是，直接连接到ISP的单个主机很少能够自己运行DNS；因此，ISP只能委托给网关能够成为权威名称服务器的客户。如果设备请求DHCPv6前缀委派，则可以认为这是一个合理可靠的指标，表明它是网关，而不是单个主机。它不一定表示网关能够提供DNS服务，因此不能作为测试此选项是否可行的方法。事实上，这种委托不适用于符合[RFC6092]要求的设备，其中包括“默认情况下，任何集成DNS解析服务器都不得处理在外部接口上接收的入站DNS查询”的要求。
If the customer's gateway is the name server, it provides its own information to hosts on the network, as described in [RFC2136], which is often done for enterprise networks.
如果客户的网关是名称服务器，它会向网络上的主机提供自己的信息，如[RFC2136]中所述，这通常适用于企业网络。
An ISP could provide authoritative responses as a secondary server to the customer's master server. For instance, the home gateway name server could be the master server, with the ISP providing the only published NS authoritative servers.
ISP可以作为辅助服务器向客户的主服务器提供权威响应。例如，家庭网关名称服务器可以是主服务器，ISP只提供已发布的NS权威服务器。
To implement this alternative, users' residential gateways must be capable of acting as authoritative name servers capable of dynamic DNS updates. There is no mechanism for an ISP to dynamically communicate to a user's equipment that a zone has been delegated, so user action would be required. Most users have neither the equipment nor the expertise to run DNS servers, so this option is unavailable to the residential ISP.
要实现此替代方案，用户的住宅网关必须能够充当能够进行动态DNS更新的权威名称服务器。ISP没有机制可以动态地与用户的设备通信区域已被委派，因此需要用户采取行动。大多数用户既没有设备也没有运行DNS服务器的专业知识，因此住宅ISP无法使用此选项。
An ISP's name server that receives a dynamic forward or reverse DNS update may create a matching entry. Since a host capable of updating one is generally capable of updating the other, this should not be required, but redundant record creation will ensure that a record exists. ISPs implementing this method should check whether a record already exists before accepting or creating updates.
接收动态正向或反向DNS更新的ISP名称服务器可能会创建匹配条目。由于能够更新其中一个的主机通常能够更新另一个，因此不需要这样做，但冗余记录创建将确保记录存在。实现此方法的ISP应在接受或创建更新之前检查记录是否已存在。
This method is also dependent on hosts being capable of providing dynamic DNS updates, which is not default behavior for many hosts.
此方法还依赖于能够提供动态DNS更新的主机，这不是许多主机的默认行为。
An ISP's DHCPv6 server may populate the forward and reverse zones when the DHCP request is received if the request contains enough information [RFC4704].
当收到DHCP请求时，如果请求包含足够的信息，ISP的DHCPv6服务器可能会填充正向和反向区域[RFC4704]。
However, this method will only work for a single host address (IA_NA); the ISP's DHCP server would not have enough information to update all records for a prefix delegation. If the zone authority is delegated to a home gateway that used this method, the gateway could update records for residential hosts. To implement this alternative, users' residential gateways would have to support the FQDN DHCP option and would have to either have the zones configured or send DDNS messages to the ISP's name server.
但是，此方法仅适用于单个主机地址（IA_NA）；ISP的DHCP服务器没有足够的信息更新前缀委派的所有记录。如果将区域权限委托给使用此方法的家庭网关，则网关可以更新住宅主机的记录。要实现此替代方案，用户的住宅网关必须支持FQDN DHCP选项，并且必须配置区域或向ISP的名称服务器发送DDNS消息。
A user may receive an address or prefix from a RADIUS server [RFC2865], the details of which may be recorded via RADIUS Accounting data [RFC2866]. The ISP may populate the forward and reverse zones from the accounting data if it contains enough information. This solution allows the ISP to populate data concerning allocated prefixes as per Section 2.2 (wildcards) and customer premise equipment (CPE) endpoints. However, as with Section 2.3.5, it does not allow the ISP to populate information concerning individual hosts.
用户可从RADIUS服务器[RFC2865]接收地址或前缀，其详细信息可通过RADIUS记帐数据[RFC2866]记录。如果记帐数据包含足够的信息，ISP可以从中填充正向和反向区域。此解决方案允许ISP根据第2.2节（通配符）和客户前提设备（CPE）端点填充有关已分配前缀的数据。但是，与第2.3.5节一样，它不允许ISP填充有关单个主机的信息。
For customers who are able to run their own DNS servers, such as commercial customers, often the best option is to delegate the reverse DNS zone to them, as described in [RFC2317] (for IPv4). However, since most residential users have neither the equipment nor the expertise to run DNS servers, this method is unavailable to residential ISPs.
对于能够运行自己的DNS服务器的客户（如商业客户），通常最好的选择是将反向DNS区域委托给他们，如[RFC2317]（对于IPv4）中所述。然而，由于大多数住宅用户既没有设备也没有运行DNS服务器的专业知识，住宅ISP无法使用这种方法。
This is a general case of the specific case described in Section 2.3.3. All of the same considerations still apply.
这是第2.3.3节所述具体情况的一般情况。所有这些考虑因素仍然适用。
Common practice in IPv4 is to provide PTR records for all addresses, regardless of whether a host is actually using the address. In IPv6, ISPs may generate PTR records for all IPv6 addresses as the records are requested. Several DNS servers are capable of this.
IPv4中的常见做法是为所有地址提供PTR记录，而不管主机是否实际使用该地址。在IPv6中，ISP可以根据请求为所有IPv6地址生成PTR记录。有几个DNS服务器能够实现这一点。
An ISP using this option should generate a PTR record on demand and cache or prepopulate the forward (AAAA) entry for the duration of the Time to Live of the PTR. Similarly, the ISP would prepopulate the PTR following a AAAA query. To reduce exposure to a Denial-of-Service attack, state or storage should be limited. Alternatively, if an algorithm is used to generate a unique name, it can be employed on the fly in both directions. This option has the advantage of assuring matching forward and reverse entries while being simpler than dynamic DNS. Administrators should consider whether the lack of user-specified hostnames is a drawback. It may be possible to allow user-specified hostnames for some records and generate others on the fly; looking up a record before generating on the fly may slow responses or may not scale well.
使用此选项的ISP应按需生成PTR记录，并在PTR有效期内缓存或预填充转发（AAAA）条目。类似地，ISP将在AAAA查询后预填充PTR。为了减少拒绝服务攻击的风险，应限制状态或存储。或者，如果使用算法生成唯一名称，则可以在两个方向上动态使用该算法。此选项的优点是确保匹配正向和反向条目，同时比动态DNS更简单。管理员应该考虑是否缺少用户指定的主机名是一个缺点。可能允许用户为某些记录指定主机名，并动态生成其他主机名；在动态生成之前查找记录可能会降低响应速度或无法很好地扩展。
DNSSEC [RFC4035] signing records on the fly may increase load; unsigned records can indicate that these records are less trusted, which might be acceptable.
DNSSEC[RFC4035]动态签名记录可能会增加负载；未签名的记录可能表明这些记录不太可信，这可能是可以接受的。
Another consideration is that the algorithm used for generating the record must be the same on all servers for a zone. In other words, any server for the zone must produce the same response for a given query. Administrators managing a variety of rules within a zone might find it difficult to keep those rules synchronized on all servers.
另一个需要考虑的问题是，在一个区域的所有服务器上，用于生成记录的算法必须相同。换句话说，区域的任何服务器都必须为给定查询生成相同的响应。在一个区域内管理各种规则的管理员可能会发现很难在所有服务器上保持这些规则的同步。
It is possible to create a user interface, such as a web page, that would allow end users to enter a hostname to associate with an address. Such an interface would need to be authenticated; only the authorized user could add/change/delete entries. If the ISP changes prefixes assigned to customers, the interface would need to specify only the host bits. The backend would therefore need to be integrated with prefix assignments so that when a new prefix was assigned to a customer, the DNS service would look up user-generated hostnames, delete the old record, and create the new one.
可以创建一个用户界面，如网页，允许最终用户输入主机名以与地址关联。这样的接口需要进行身份验证；只有授权用户才能添加/更改/删除条目。如果ISP更改分配给客户的前缀，接口将只需要指定主机位。因此，后端需要与前缀分配集成，以便在为客户分配新前缀时，DNS服务将查找用户生成的主机名，删除旧记录，并创建新记录。
Considerations about some records being static and others dynamic or dynamically generated (Section 2.5) and the creativity of users (Section 5.5) still apply.
一些记录是静态的，而另一些记录是动态生成的（第2.5节），用户的创造性（第5.5节）仍然适用。
There are six common uses for PTR lookups:
PTR查找有六种常见用途：
Rejecting mail: A PTR with a certain string may indicate "This host is not a mail server", which may be useful for rejecting probable spam. The absence of a PTR leads to the desired behavior.
拒绝邮件：带有特定字符串的PTR可能表示“此主机不是邮件服务器”，这可能有助于拒绝可能的垃圾邮件。缺少PTR会导致期望的行为。
Serving ads: "This host is probably in town.province." An ISP that does not provide PTR records might affect somebody else's geolocation (also see privacy consideration about location).
提供广告：“该主机可能在镇上。省。”不提供PTR记录的ISP可能会影响其他人的地理位置（另请参阅有关位置的隐私考虑）。
Accepting SSH connections: The presence of a PTR may be inferred to mean "This host has an administrator with enough clue to set up forward and reverse DNS". This is a poor inference.
接受SSH连接：可以推断PTR的存在意味着“此主机有一位管理员，他有足够的线索来设置正向和反向DNS”。这是一个糟糕的推论。
Log files: Many systems will record the PTR of remote hosts in their log files to make it easier when reading logs later to see what network the remote host uses.
日志文件：许多系统将在其日志文件中记录远程主机的PTR，以便于以后读取日志以查看远程主机使用的网络。
Traceroute: The ability to identify an interface and name of any intermediate node or router is important for troubleshooting.
Traceroute：识别任何中间节点或路由器的接口和名称的能力对于故障排除非常重要。
Service discovery: [RFC6763] specifies "DNS-Based Service Discovery", and Section 11 specifically describes how PTRs are used.
服务发现：[RFC6763]指定“基于DNS的服务发现”，第11节具体描述了如何使用PTR。
As a general guideline, when address assignment and name are under the same authority, or when a host has a static address and name, AAAA and PTR records should exist and match. For residential users, if these use cases are important to the ISP, the administrator will then need to consider how to provide PTR records.
一般来说，当地址分配和名称处于同一权限下，或者当主机具有静态地址和名称时，AAAA和PTR记录应该存在并匹配。对于住宅用户来说，如果这些用例对ISP很重要，那么管理员将需要考虑如何提供PTR记录。
The best accuracy would be achieved if ISPs delegated authority along with address delegation, but residential users rarely have domain names or authoritative name servers.
如果ISP将授权与地址授权一起进行，则可以实现最佳的准确性，但住宅用户很少拥有域名或权威名称服务器。
Dynamic DNS updates can provide accurate data, but there is no standard way to indicate to residential devices where to send updates, whether the hosts support DDNS, or whether it scales.
动态DNS更新可以提供准确的数据，但是没有标准的方法来指示住宅设备在哪里发送更新，主机是否支持DDN，或者是否可以扩展。
An ISP has no knowledge of its residential users' hostnames and therefore can either provide a wildcard response or a dynamically generated response. A valid negative response (such as NXDOMAIN) is a valid response if the four cases above are not essential; delegation where no name server exists should be avoided.
ISP不知道其住宅用户的主机名，因此可以提供通配符响应或动态生成的响应。如果上述四种情况不是必需的，则有效的否定回答（如NXDOMAIN）是有效的回答；应避免不存在名称服务器的委派。
Some people think the existence of reverse DNS records, or matching forward and reverse DNS records, provides useful information about the hosts with those records. For example, one might infer that the administrator of a network with properly configured DNS records was better informed, and by further inference more responsible, than the administrator of a less thoroughly configured network. For instance, most email providers will not accept incoming connections on port 25 unless forward and reverse DNS entries match. If they match, but information higher in the stack (for instance, mail source) is inconsistent, the packet is questionable. However, these records may be easily forged unless DNSSEC or other measures are taken. The string of inferences is questionable and may become unneeded if other means for evaluating trustworthiness (such as positive reputations) become predominant in IPv6.
有些人认为，反向DNS记录的存在，或匹配正向和反向DNS记录，提供了有关具有这些记录的主机的有用信息。例如，可以推断，具有正确配置的DNS记录的网络的管理员比配置不太彻底的网络的管理员更了解情况，并且通过进一步推断，更负责任。例如，大多数电子邮件提供商将不接受端口25上的传入连接，除非正向和反向DNS条目匹配。如果它们匹配，但堆栈中较高的信息（例如，邮件源）不一致，则数据包有问题。但是，除非采取DNSSEC或其他措施，否则这些记录可能很容易伪造。如果其他评估可信度的方法（如正面声誉）在IPv6中占主导地位，那么这一系列推论是有问题的，可能不再需要。
Providing location information in PTR records is useful for troubleshooting, law enforcement, and geolocation services, but for the same reasons, it can be considered sensitive information.
在PTR记录中提供位置信息对于故障排除、执法和地理定位服务非常有用，但出于同样的原因，可以将其视为敏感信息。
The security considerations for using dynamic DNS are described in [RFC3007]. DNS Security Extensions are documented in [RFC4033].
[RFC3007]中描述了使用动态DNS的安全注意事项。DNS安全扩展记录在[RFC4033]中。
Interactions with DNSSEC are described throughout this document.
与DNSSEC的交互作用在本文件中均有描述。
Several methods exist for providing encryption keys in the DNS. Any of the options presented here may interfere with these key techniques.
有几种方法可用于在DNS中提供加密密钥。此处提供的任何选项都可能干扰这些关键技术。
Given the considerations in [RFC8117], hostnames that provide information about a user compromise that user's privacy. Some users may want to identify their hosts using user-specified hostnames, but the default behavior should not be to identify a user, their location, their connectivity, or other information in a PTR record.
鉴于[RFC8117]中的考虑，提供用户信息的主机名会损害该用户的隐私。某些用户可能希望使用用户指定的主机名标识其主机，但默认行为不应是在PTR记录中标识用户、其位置、其连接或其他信息。
Though not precisely a security consideration, administrators may want to consider what domain will contain the records and who will provide the names. If subscribers provide hostnames, they may provide inappropriate strings. Consider "ihate.example.com" or "badword.customer.example.com" or "celebrityname.committed.illegal.acts.example.com".
虽然不是精确的安全考虑，管理员可能想考虑什么域将包含记录，以及谁将提供名称。如果订阅者提供主机名，他们可能会提供不适当的字符串。考虑“I仇恨。示例.com”或“BordWord。客户。示例.com”或“SigiTyNeNAM.Orth.Realth.Actudio.Simult.com”。
This document has no IANA actions.
本文档没有IANA操作。
[RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, <https://www.rfc-editor.org/info/rfc1912>.
[RFC1912]Barr，D.，“常见DNS操作和配置错误”，RFC 1912，DOI 10.17487/RFC1912，1996年2月<https://www.rfc-editor.org/info/rfc1912>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<https://www.rfc-editor.org/info/rfc2136>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, <https://www.rfc-editor.org/info/rfc2845>.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 2845，DOI 10.17487/RFC2845，2000年5月<https://www.rfc-editor.org/info/rfc2845>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<https://www.rfc-editor.org/info/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>.
[RFC2866]Rigney，C.，“半径会计”，RFC 2866，DOI 10.17487/RFC2866，2000年6月<https://www.rfc-editor.org/info/rfc2866>.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <https://www.rfc-editor.org/info/rfc3007>.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，DOI 10.17487/RFC3007，2000年11月<https://www.rfc-editor.org/info/rfc3007>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3646]Droms，R.，Ed.“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 3646，DOI 10.17487/RFC3646，2003年12月<https://www.rfc-editor.org/info/rfc3646>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<https://www.rfc-editor.org/info/rfc4033>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<https://www.rfc-editor.org/info/rfc4035>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/info/rfc4592>.
[RFC4592]Lewis，E.，“通配符在域名系统中的作用”，RFC 4592，DOI 10.17487/RFC4592，2006年7月<https://www.rfc-editor.org/info/rfc4592>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, <https://www.rfc-editor.org/info/rfc4704>.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，DOI 10.17487/RFC4704，2006年10月<https://www.rfc-editor.org/info/rfc4704>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<https://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<https://www.rfc-editor.org/info/rfc4941>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<https://www.rfc-editor.org/info/rfc6763>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 8106，DOI 10.17487/RFC8106，2017年3月<https://www.rfc-editor.org/info/rfc8106>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>.
[RFC2317]Eidnes，H.，de Groot，G.和P.Vixie，“无类别地址ARPA委托”，BCP 20，RFC 2317，DOI 10.17487/RFC2317，1998年3月<https://www.rfc-editor.org/info/rfc2317>.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, <https://www.rfc-editor.org/info/rfc4472>.
[RFC4472]Durand，A.，Ihren，J.，和P.Savola，“IPv6 DNS的操作注意事项和问题”，RFC 4472，DOI 10.17487/RFC4472，2006年4月<https://www.rfc-editor.org/info/rfc4472>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6092]Woodyatt，J.，Ed.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，DOI 10.17487/RFC6092，2011年1月<https://www.rfc-editor.org/info/rfc6092>.
[RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname Practice Considered Harmful", RFC 8117, DOI 10.17487/RFC8117, March 2017, <https://www.rfc-editor.org/info/rfc8117>.
[RFC8117]Huitema，C.，Thaler，D.，和R.Winter，“认为有害的当前主机名做法”，RFC 8117，DOI 10.17487/RFC81172017年3月<https://www.rfc-editor.org/info/rfc8117>.
Acknowledgements
致谢
The author would like to thank Alain Durand, JINMEI Tatuya, David Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis, John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence, Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, Chris Roosenraad, Fernando Gont, John Levine, and many others who discussed and provided suggestions for this document.
作者要感谢阿兰·杜兰德、金美·塔图亚、大卫·弗里德曼、安德鲁·沙利文、克里斯·格里菲斯、达里尔·坦纳、埃德·刘易斯、约翰·布佐夫斯基、克里斯·唐利、韦斯·乔治、杰森·威尔、约翰·斯彭斯、特德·莱蒙、斯蒂芬·拉格霍姆、施泰纳·豪格、马克·安德鲁斯、克里斯·洛森拉德、费尔南多·冈特、约翰·莱文、，还有许多其他人讨论了本文件并提出了建议。
Author's Address
作者地址
Lee Howard Retevia Fairfax, VA 22032 United States of America
Lee Howard Retevia Fairfax，弗吉尼亚州，美利坚合众国22032
Email: lee.howard@retevia.net
Email: lee.howard@retevia.net