Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 7535 Dyn, Inc.
Category: Informational B. Dickson
ISSN: 2070-1721 Twitter, Inc.
W. Kumari
Google
G. Michaelson
APNIC
May 2015
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 7535 Dyn, Inc.
Category: Informational B. Dickson
ISSN: 2070-1721 Twitter, Inc.
W. Kumari
Google
G. Michaelson
APNIC
May 2015
AS112 Redirection Using DNAME
AS112使用DNAME重定向
Abstract
摘要
AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.
AS112提供了一种机制，用于处理对非唯一IP地址（例如RFC1918地址）的反向查找。本文档描述了对AS112基础设施的部署和使用的修改，这将允许使用DNAME资源记录更轻松地添加和删除区域。
This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.
这种方法使得任何DNS区域管理员都可以在不与AS112基础设施的运营商协调的情况下，将与其控制下的部分全局DNS命名空间相关的流量接收到AS112基础设施。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7535.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7535.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Design Overview .................................................4
3. AS112 Operations ................................................5
3.1. Extensions to Support DNAME Redirection ....................5
3.2. Redirection of Query Traffic to AS112 Servers ..............5
4. Continuity of AS112 Operations ..................................6
5. Candidate Zones for AS112 Redirection ...........................6
6. DNAME Deployment Considerations .................................7
7. IAB Statement Regarding This .ARPA Request ......................8
8. IANA Considerations .............................................8
8.1. Address Assignment .........................................8
8.2. Hosting of AS112.ARPA .....................................10
8.3. Delegation of AS112.ARPA ..................................10
9. Security Considerations ........................................10
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
Appendix A. Assessing Support for DNAME in the Real World .........13
A.1. Methodology ................................................13
A.2. Results ....................................................15
Acknowledgements ..................................................16
Authors' Addresses ................................................16
1. Introduction ....................................................3
2. Design Overview .................................................4
3. AS112 Operations ................................................5
3.1. Extensions to Support DNAME Redirection ....................5
3.2. Redirection of Query Traffic to AS112 Servers ..............5
4. Continuity of AS112 Operations ..................................6
5. Candidate Zones for AS112 Redirection ...........................6
6. DNAME Deployment Considerations .................................7
7. IAB Statement Regarding This .ARPA Request ......................8
8. IANA Considerations .............................................8
8.1. Address Assignment .........................................8
8.2. Hosting of AS112.ARPA .....................................10
8.3. Delegation of AS112.ARPA ..................................10
9. Security Considerations ........................................10
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
Appendix A. Assessing Support for DNAME in the Real World .........13
A.1. Methodology ................................................13
A.2. Results ....................................................15
Acknowledgements ..................................................16
Authors' Addresses ................................................16
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in [RFC1918] for private use within individual sites.
许多连接到Internet的站点使用的IPv4地址不是全局唯一的。例如，在[RFC1918]中指定的供各个站点内私人使用的地址。
Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
此类环境中的设备有时可能会发起与这些专用地址对应的域名系统（DNS）查询（所谓的“反向查找”）。由于相关地址仅具有本地意义，因此站点管理员最好确保在本地回答此类查询。然而，这种查询遵循公共DNS中的正常委托路径而不是在站点内得到答复的情况并不少见。
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
公共DNS服务器不可能为此类查询提供有用的答案。此外，由于私用地址的广泛部署和互联网的持续增长，此类查询的数量巨大且不断增长。AS112项目旨在为此类查询提供一个分布式接收器，以减少in-ADDR.ARPA权威服务器上的负载。AS112项目以分配给它的自治系统编号（ASN）命名。
Prior to implementation of this technique, the AS112 project did not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist, this presents a problem. This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily.
在实施这项技术之前，AS112项目并不能很好地适应DNS区域的添加和删除。由于已知存在具有明确局部意义的其他区域，因此这就产生了一个问题。本文档描述了对AS112基础设施的部署和使用的修改，这些修改将允许更轻松地添加和删除区域。
The AS112 project is described in detail in [RFC7534].
[RFC7534]中详细描述了AS112项目。
The AS112 nameservers (PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG) are required to answer authoritatively for each and every zone that is delegated to them. If a zone is delegated to AS112 nameservers without those nameservers being configured ahead of time to answer authoritatively for that zone, there is a detrimental impact on clients following referrals for queries within that zone. This misconfiguration is colloquially known as a "lame delegation".
AS112名称服务器（capture.IANA.ORG、BLACKHOLE-1.IANA.ORG和BLACKHOLE-2.IANA.ORG）需要对委托给它们的每个区域进行授权回答。如果将某个区域委托给AS112名称服务器，而没有提前配置这些名称服务器以授权地回答该区域的问题，则会对该区域内查询的客户机产生不利影响。这种误解通俗地称为“跛脚代表团”。
AS112 nameserver operators are only loosely coordinated, and hence adding support for a new zone (or, correspondingly, removing support for a zone that is no longer delegated to the AS112 nameservers) is difficult to accomplish with accuracy. Testing AS112 nameservers remotely to see whether they are configured to answer authoritatively for a particular zone is similarly challenging, since AS112 nodes are distributed using anycast [RFC4786].
AS112名称服务器操作员只是松散协调的，因此添加对新区域的支持（或者相应地，删除对不再委托给AS112名称服务器的区域的支持）很难准确完成。远程测试AS112名称服务器，以查看它们是否配置为对特定区域进行授权应答，同样具有挑战性，因为AS112节点是使用anycast[RFC4786]分发的。
This document defines a more flexible approach for sinking queries on AS112 infrastructure that can be deployed alongside unmodified, existing AS112 nodes. Instead of delegating additional zones directly to AS112 nameservers, DNAME [RFC6672] redirection is used. This approach has the advantage that query traffic for arbitrary parts of the namespace can be directed to AS112 servers without those servers having to be reconfigured every time a zone is added or removed.
本文档定义了一种更灵活的方法，用于在AS112基础设施上进行查询，该基础设施可以与未修改的现有AS112节点一起部署。使用DNAME[RFC6672]重定向，而不是将其他区域直接委托给AS112名称服务器。这种方法的优点是，命名空间任意部分的查询流量可以定向到AS112服务器，而无需在每次添加或删除区域时重新配置这些服务器。
This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.
这种方法使得任何DNS区域管理员都可以在不与AS112基础设施的运营商协调的情况下，将与其控制下的部分全局DNS命名空间相关的流量接收到AS112基础设施。
A new zone, EMPTY.AS112.ARPA, is delegated to a single nameserver BLACKHOLE.AS112.ARPA (IPv4 address 192.31.196.1, IPv6 address 2001:4:112::1).
将一个新区域EMPTY.AS112.ARPA委托给一个名称服务器BLACKHOLE.AS112.ARPA（IPv4地址192.31.196.1，IPv6地址2001:4:112:：1）。
The IPv4 address 192.31.196.1 has been selected from the prefix assigned by the IANA such that the address is coverable by a single IPv4 /24 prefix, and that no other address covered by that prefix is in use. The IPv6 address 2001:4:112::1 has been similarly assigned such that no other address within a covering /48 is in use. This addressing plan accommodates the anycast distribution of the BLACKHOLE.AS112.ARPA service using a single IPv4 service prefix and a single IPv6 service prefix. See [RFC4786] for more discussion of anycast service distribution; see Section 8 for the specific actions completed by IANA per this document.
IPv4地址192.31.196.1是从IANA分配的前缀中选择的，因此该地址可由单个IPv4/24前缀覆盖，并且该前缀覆盖的其他地址不在使用中。IPv6地址2001:4:112:：1已被类似地分配，因此覆盖/48中没有其他地址正在使用。此寻址计划使用单个IPv4服务前缀和单个IPv6服务前缀来适应BLACKHOLE.AS112.ARPA服务的选播分发。有关选播服务分发的更多讨论，请参见[RFC4786]；IANA根据本文件完成的具体行动见第8节。
Some or all of the existing AS112 nodes should be extended to support these new nameserver addresses and to host the EMPTY.AS112.ARPA zone. See [RFC7534] for revised guidance to AS112 server operators.
应扩展部分或所有现有AS112节点，以支持这些新的名称服务器地址，并承载EMPTY.AS112.ARPA区域。请参阅[RFC7534]了解AS112服务器操作员的修订指南。
Each part of the DNS namespace for which it is desirable to sink queries at AS112 nameservers should be redirected to the EMPTY.AS112.ARPA zone using DNAME [RFC6672]. See Section 3.2 for guidance to zone administrators.
需要在AS112名称服务器上接收查询的DNS名称空间的每个部分都应该使用DNAME[RFC6672]重定向到EMPTY.AS112.ARPA区域。有关区域管理员的指导，请参见第3.2节。
Guidance to operators of AS112 nodes is extended to include configuration of the 192.31.196.1 and 2001:4:112::1 addresses, and the corresponding announcement of covering routes for those addresses, and to host the EMPTY.AS112.ARPA zone.
AS112节点运营商指南扩展到包括192.31.196.1和2001:4:112:：1地址的配置，以及相应的覆盖这些地址路由的公告，并承载空的.AS112.ARPA区域。
IPv4-only AS112 nodes should only configure the 192.31.196.1 nameserver address; IPv6-only AS112 nodes should only configure the 2001:4:112::1 nameserver address.
仅IPv4 AS112节点应仅配置192.31.196.1名称服务器地址；仅IPv6 AS112节点应仅配置2001:4:112:：1名称服务器地址。
It is only necessary for a single AS112 server operator to implement these extensions for this mechanism to function as intended. It is beneficial if many more than one AS112 server operator makes these changes, however, since that provides for greater distribution and capacity for the nameservers serving the EMPTY.AS112.ARPA zone. It is not necessary for all AS112 server operators to make these changes for the mechanism to be viable.
只有单个AS112服务器运营商需要实现这些扩展，该机制才能按预期运行。但是，如果有多个AS112服务器运营商进行这些更改，这是有益的，因为这样可以为空的.AS112.ARPA区域提供更大的分发和容量。并非所有AS112服务器运营商都需要对该机制进行这些更改。
Detailed instructions for the implementation of these extensions are included in [RFC7534].
[RFC7534]中包含了实现这些扩展的详细说明。
Once the EMPTY.AS112.ARPA zone has been deployed using the nameservers described in Section 3.1, redirections may be installed in the DNS namespace for queries that are intended to be answered by the AS112 infrastructure.
一旦使用第3.1节中描述的名称服务器部署了EMPTY.AS112.ARPA区域，就可以在DNS名称空间中安装重定向，以供AS112基础设施回答的查询。
For example, reverse queries corresponding to TEST-NET-1 (192.0.2.0/24) [RFC5737] could be redirected to AS112 nameservers by installing a DNAME resource record in the 192.IN-ADDR.ARPA zone, as illustrated in Figure 1.
例如，对应于TEST-NET-1（192.0.2.0/24）[RFC5737]的反向查询可以通过在192.in-ADDR.ARPA区域中安装DNAME资源记录重定向到AS112名称服务器，如图1所示。
$ORIGIN 192.IN-ADDR.ARPA. ... 2.0 IN DNAME EMPTY.AS112.ARPA. ...
$ORIGIN 192.IN-ADDR.ARPA。。。DNAME EMPTY.AS112.ARPA中的2.0。。。
Figure 1
图1
There is no practical limit to the number of redirections that can be configured in this fashion. Redirection of a particular part of the namespace to EMPTY.AS112.ARPA can be removed at any time, under the control of the administrators of the corresponding part of the DNS namespace. No changes to deployed AS112 nodes incorporating the
以这种方式配置的重定向数量没有实际限制。在DNS命名空间相应部分的管理员的控制下，可以随时将命名空间的特定部分重定向到EMPTY.AS112.ARPA。未对部署的AS112节点进行任何更改，包括
extensions described in this document are required to support additional redirections. A list of possible candidates for AS112 redirection can be found in Section 5.
需要本文档中描述的扩展来支持其他重定向。AS112重定向的可能候选列表可在第5节中找到。
DNAME resource records deployed for this purpose can be signed with DNSSEC [RFC4033], providing a secure means of authenticating the legitimacy of each redirection.
为此目的部署的DNAME资源记录可以使用DNSSEC[RFC4033]签名，从而提供一种安全的方法来验证每个重定向的合法性。
Existing guidance to AS112 server operators to accept and respond to queries directed at the PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG nameservers should continue to be followed, and no changes to the delegation of existing zones hosted on AS112 servers should occur. These measures are intended to provide continuity of operations for zones currently delegated to AS112 servers and avoid any accidental client impact due to the changes proposed in this document.
应继续遵循AS112服务器运营商的现有指南，以接受和响应针对Capture.IANA.ORG、BLACKHOLE-1.IANA.ORG和BLACKHOLE-2.IANA.ORG名称服务器的查询，并且不得更改AS112服务器上托管的现有区域的委派。这些措施旨在为当前委托给AS112服务器的区域提供连续的操作，并避免由于本文件中提出的更改而造成的任何意外客户影响。
Once it has become empirically and quantitatively clear that the EMPTY.AS112.ARPA zone is well hosted to the extent that it is thought that the existing, unmodified AS112 servers host 10.IN-ADDR.ARPA, the decision might be made to replace the delegation of those [RFC1918] zones with DNAME redirection. Once implemented, the PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG, and BLACKHOLE-2.IANA.ORG nameservers could be retired. This document gives no such direction to the IANA, however.
一旦从经验和数量上证明EMPTY.AS112.ARPA区域承载良好，认为现有的未修改的AS112服务器承载10.IN-ADDR.ARPA，就可以决定用DNAME重定向替换这些[RFC1918]区域的委托。一旦实施，capture.IANA.ORG、BLACKHOLE-1.IANA.ORG和BLACKHOLE-2.IANA.ORG名称服务器就可以退役。然而，本文件并未向IANA提供此类指示。
All zones listed in [RFC6303] are candidates for AS112 redirection.
[RFC6303]中列出的所有区域都是AS112重定向的候选区域。
Since no pre-provisioning is required on the part of AS112 operators to facilitate sinking of any name in the DNS namespace by AS112 infrastructure, this mechanism supports AS112 redirection by any zone owner in the DNS.
由于AS112运营商不需要预先设置，以便于AS112基础设施在DNS命名空间中的任何名称下沉，因此此机制支持DNS中任何区域所有者进行AS112重定向。
This document is simply concerned with provision of the AS112 redirection service and does not specify that any particular AS112 redirection be put in place.
本文档仅涉及AS112重定向服务的提供，并没有指定任何特定的AS112重定向。
DNAME was specified years after the original implementations of [RFC1035], and hence universal deployment cannot be expected. [RFC6672] specifies a fallback mechanism that makes use of synthesised CNAME RRSets for this reason. The expectation that design choices in the DNAME specification ought to mitigate any lack of deployment is reviewed below. Experimental validation of those expectations is included in Appendix A.
DNAME是在[RFC1035]的原始实现数年后指定的，因此无法预期通用部署。[RFC6672]为此指定了一种使用综合CNAME RRSET的回退机制。DNAME规范中的设计选择应该缓解任何部署不足的期望如下所述。附录A中包含了这些预期的实验验证。
It is a fundamental design requirement of AS112 service that responses be cached. We can safely declare DNAME support on the authoritative server to be a prerequisite for DNAME redirection, but the cases where individual elements in resolver chains do not support DNAME processing deserve closer examination.
缓存响应是AS112服务的基本设计要求。我们可以安全地将权威服务器上的DNAME支持声明为DNAME重定向的先决条件，但解析程序链中的单个元素不支持DNAME处理的情况值得仔细检查。
The expected behaviour when a DNAME response is supplied to a resolver that does not support DNAME is that the accompanying, synthesised CNAME will be accepted and cached. Re-query frequency will be determined by the TTLs (Time to Live) returned by the DNAME-responding authoritative servers.
当向不支持DNAME的解析程序提供DNAME响应时，预期的行为是接受并缓存附带的合成CNAME。重新查询频率将由响应DNAME的权威服务器返回的TTL（生存时间）确定。
Resolution of the CNAME target is straightforward and functions exactly as the AS112 project has operated since it was deployed. The negative caching [RFC2308] of the CNAME target follows the parameters defined in the target zone, EMPTY.AS112.ARPA. This has the side effects that all redirected names ultimately landing on an AS112 node will be negatively cached with the same parameters, but this lack of flexibility seems non-controversial; the effect of reducing the negative cache TTL would be increased query volume on the AS112 node operator concerned, and hence controls seem well aligned with operation.
CNAME目标的解析非常简单，其功能与AS112项目自部署以来的操作完全相同。CNAME目标的负缓存[RFC2308]遵循目标区域EMPTY.AS112.ARPA中定义的参数。这样做的副作用是，所有最终登录到AS112节点的重定向名称都将使用相同的参数进行负面缓存，但这种灵活性的缺乏似乎没有争议；减少负缓存TTL的效果将增加相关AS112节点操作符上的查询量，因此控件似乎与操作保持一致。
Validating resolvers (i.e., those requesting and processing DNSSEC [RFC4033] metadata) are required to implement DNAME and hence should not make use of synthesised CNAME RRs. The lack of signature over a received CNAME RR should hence not limit the ability to sign the (DNAME) redirection point, and for those (DNAME) signatures to be validated.
验证解析程序（即请求和处理DNSSEC[RFC4033]元数据的解析程序）是实现DNAME所必需的，因此不应使用合成的CNAME RRs。因此，在接收到的CNAME RR上缺少签名不应限制对（DNAME）重定向点进行签名的能力，也不应限制对这些（DNAME）签名进行验证的能力。
In the case where a recursive server implements DNAME but DNAME is not implemented in a stub resolver, CNAME synthesis will again provide a viable path.
如果递归服务器实现了DNAME，但在存根解析器中没有实现DNAME，那么CNAME合成将再次提供可行的路径。
DNAME support on AS112 nodes themselves is never required under this proposal.
根据本提案，AS112节点本身不需要DNAME支持。
With the publication of this document, the IAB approves of the delegation of 'AS112' in the ARPA domain. Under [RFC3172], the IAB has requested that IANA delegate and provision "AS112.ARPA" as specified in this specification. However, the IAB does not take any architectural or technical position about this specification.
随着本文件的发布，IAB批准在ARPA领域授权“AS112”。根据[RFC3172]，IAB已要求IANA按照本规范的规定授权并提供“AS112.ARPA”。然而，IAB对本规范不采取任何架构或技术立场。
Per this document, IANA has assigned IPv4 and IPv6 number resources in conformance with Section 4 of [RFC2860].
根据本文件，IANA已按照[RFC2860]第4节的规定分配IPv4和IPv6号码资源。
The IANA has assigned one IPv4 /24 netblock and registered its use in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890] as follows:
IANA已分配一个IPv4/24 netblock，并在“IANA IPv4专用地址注册表”[RFC6890]中注册其使用，如下所示：
+----------------------+-----------------+
| Name | Value |
+----------------------+-----------------+
| Address Block | 192.31.196.0/24 |
| | |
| Name | AS112-v4 |
| | |
| RFC | RFC 7535 |
| | |
| Allocation Date | 2014-12 |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+-----------------+
+----------------------+-----------------+
| Name | Value |
+----------------------+-----------------+
| Address Block | 192.31.196.0/24 |
| | |
| Name | AS112-v4 |
| | |
| RFC | RFC 7535 |
| | |
| Allocation Date | 2014-12 |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+-----------------+
IANA has assigned one IPv6 /48 netblock and registered its use in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890] as follows:
IANA已分配一个IPv6/48 netblock并在“IANA IPv6专用地址注册表”[RFC6890]中注册其使用，如下所示：
+----------------------+-----------------+
| Name | Value |
+----------------------+-----------------+
| Address Block | 2001:4:112::/48 |
| | |
| Name | AS112-v6 |
| | |
| RFC | RFC 7535 |
| | |
| Allocation Date | 2014-12 |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+-----------------+
+----------------------+-----------------+
| Name | Value |
+----------------------+-----------------+
| Address Block | 2001:4:112::/48 |
| | |
| Name | AS112-v6 |
| | |
| RFC | RFC 7535 |
| | |
| Allocation Date | 2014-12 |
| | |
| Termination Date | N/A |
| | |
| Source | True |
| | |
| Destination | True |
| | |
| Forwardable | True |
| | |
| Global | True |
| | |
| Reserved-by-Protocol | False |
+----------------------+-----------------+
The IANA hosts and signs the zone AS112.ARPA using nameservers and DNSSEC signing infrastructure of their choosing, as shown in Figure 2. SOA RDATA may be adjusted by the IANA to suit their operational requirements.
IANA使用自己选择的名称服务器和DNSSEC签名基础设施托管和签名区域AS112.ARPA，如图2所示。IANA可能会调整SOA RDATA以满足其运营需求。
$ORIGIN AS112.ARPA. $TTL 3600
$ORIGIN AS112.ARPA$TTL3600
@ IN SOA BLACKHOLE.AS112.ARPA. NOC.DNS.ICANN.ORG. ( 1 ; serial 10800 ; refresh 3600 ; retry 1209600 ; expire 3600 ) ; negative cache TTL
@在SOA BLACKHOLE.AS112.ARPA中。NOC.DNS.ICANN.ORG。（1；串行10800；刷新3600；重试1209600；过期3600）；负缓存TTL
NS A.IANA-SERVERS.NET. NS B.IANA-SERVERS.NET. NS C.IANA-SERVERS.NET.
NS A.IANA-SERVERS.NET。NS B.IANA-SERVERS.NET。NS C.IANA-SERVERS.NET。
BLACKHOLE A 192.31.196.1
AAAA 2001:4:112::1
BLACKHOLE A 192.31.196.1
AAAA 2001:4:112::1
HOSTNAME NS BLACKHOLE
黑洞
EMPTY NS BLACKHOLE
空NS黑洞
Figure 2
图2
The IANA has arranged delegation from the ARPA zone according to normal IANA procedure for ARPA zone management, to the nameservers used in carrying out the direction in Section 8.2. The whois contact information for the new record is specified by the IAB under [RFC3172].
IANA已根据ARPA区域管理的正常IANA程序安排了从ARPA区域到用于执行第8.2节指示的命名服务器的授权。IAB在[RFC3172]下指定了新记录的whois联系信息。
This document presents no known additional security concerns to the Internet.
本文件未对互联网提出任何已知的其他安全问题。
For security considerations relating to AS112 service in general, see [RFC7534].
有关AS112服务的一般安全注意事项，请参阅[RFC7534]。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <http://www.rfc-editor.org/info/rfc2308>.
[RFC2308]Andrews，M.“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，DOI 10.17487/RFC2308，1998年3月<http://www.rfc-editor.org/info/rfc2308>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.
[RFC6672]Rose，S.和W.Wijngaards，“DNS中的DNAME重定向”，RFC 6672，DOI 10.17487/RFC6672，2012年6月<http://www.rfc-editor.org/info/rfc6672>.
[RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", RFC 7534, DOI 10.17487/RFC7534, May 2015, <http://www.rfc-editor.org/info/rfc7534>.
[RFC7534]Abley，J.和W.Sotomayor，“AS112名称服务器操作”，RFC 7534，DOI 10.17487/RFC7534，2015年5月<http://www.rfc-editor.org/info/rfc7534>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>.
[RFC2860]Carpenter，B.，Baker，F.和M.Roberts，“关于互联网分配号码管理局技术工作的谅解备忘录”，RFC 2860，DOI 10.17487/RFC2860，2000年6月<http://www.rfc-editor.org/info/rfc2860>.
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <http://www.rfc-editor.org/info/rfc3172>.
[RFC3172]Huston，G.，Ed.“地址和路由参数区域域（“arpa”）的管理指南和操作要求”，BCP 52，RFC 3172，DOI 10.17487/RFC3172，2001年9月<http://www.rfc-editor.org/info/rfc3172>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，DOI 10.17487/RFC4786，2006年12月<http://www.rfc-editor.org/info/rfc4786>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <http://www.rfc-editor.org/info/rfc5737>.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，DOI 10.17487/RFC5737，2010年1月<http://www.rfc-editor.org/info/rfc5737>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <http://www.rfc-editor.org/info/rfc6303>.
[RFC6303]Andrews，M.，“本地服务DNS区域”，BCP 163，RFC 6303，DOI 10.17487/RFC6303，2011年7月<http://www.rfc-editor.org/info/rfc6303>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 6890，DOI 10.17487/RFC6890，2013年4月<http://www.rfc-editor.org/info/rfc6890>.
To measure the extent to which the DNAME construct is supported in the Internet, we have used an experimental technique to test the DNS resolvers used by end hosts and derive from the test a measurement of DNAME support within the Internet.
为了衡量DNAME构造在Internet中的支持程度，我们使用了一种实验技术来测试终端主机使用的DNS解析程序，并从测试中得出Internet中DNAME支持的衡量标准。
The test was conducted by loading a user's browser with four URLs to retrieve. The first three comprise the test setup, while the final URL communicates the result to the experiment controller. The URLs are:
该测试是通过加载一个用户的浏览器来进行的，其中包含四个要检索的URL。前三个组成测试设置，而最终URL将结果传递给实验控制器。网址如下：
A http://a.<unique_string>.dname.example.com/1x1.png?
a.<unique_string>.dname
A http://a.<unique_string>.dname.example.com/1x1.png?
a.<unique_string>.dname
B http://b.dname.example.com/1x1.png?
b.<unique_string>.dname
B http://b.dname.example.com/1x1.png?
b.<unique_string>.dname
C http://c.<unique_string>.target.example.net/1x1.png?
c.<unique_string>.target
C http://c.<unique_string>.target.example.net/1x1.png?
c.<unique_string>.target
D http://results.recorder.example.net/1x1.png?
results.<unique_string>?za=<a_result>&zb=<b_result>&zc=<c_result>
D http://results.recorder.example.net/1x1.png?
results.<unique_string>?za=<a_result>&zb=<b_result>&zc=<c_result>
The A URL is designed to test the end user's capability to resolve a name that has never been seen before, so that the resolution of this domain name will reliably result in a query at the authoritative nameserver. This is intended to test the use of domain names where there is a dynamic component that also uses the DNAME construct.
URL设计用于测试最终用户解析以前从未见过的名称的能力，以便解析此域名将可靠地在权威名称服务器上生成查询。这是为了测试域名的使用，其中有一个动态组件也使用DNAME构造。
The B URL is deliberately designed to be cached by caching resolvers that are used in the process of resolving the domain name.
通过缓存解析程序（在解析域名的过程中使用）故意将B URL设计为缓存。
The C URL is a control URL. This is a unique URL, similar to A, but does not refer to a DNAME structure.
C URL是一个控件URL。这是一个唯一的URL，类似于，但不引用DNAME结构。
The D URL uses a static cacheable domain name.
D URL使用静态可缓存域名。
The <unique_string> value is common to the four URLs used in each individual instance of this test but varies from test to test. The result is that each end user is presented with a unique string.
<unique_string>值对于此测试的每个单独实例中使用的四个URL是通用的，但因测试而异。结果是，每个最终用户都会看到一个唯一的字符串。
The contents of the EXAMPLE.COM, TARGET.EXAMPLE.NET, and RECORDER.EXAMPLE.NET zones are shown in Figure 3.
EXAMPLE.COM、TARGET.EXAMPLE.NET和RECORDER.EXAMPLE.NET区域的内容如图3所示。
$ORIGIN EXAMPLE.COM. ... DNAME. IN DNAME TARGET.EXAMPLE.NET. ...
$ORIGIN EXAMPLE.COM。。。DNAME。在DNAME TARGET.EXAMPLE.NET中。。。
$ORIGIN TARGET.EXAMPLE.NET. ... B IN A 192.0.2.0 * IN A 192.0.2.0 ...
$ORIGIN TARGET.EXAMPLE.NET。。。B在192.0.2.0*中在192.0.2.0中。。。
$ORIGIN RECORDER.EXAMPLE.NET. ... RESULTS IN A 192.0.2.0 ...
$ORIGIN RECORDER.EXAMPLE.NET。。。结果是192.0.2.0。。。
Figure 3
图3
The first three URLs (A, B, and C) are loaded as tasks into the user's browser upon execution of the test's script. The script starts a timer with each of these URLs to measure the elapsed time to fetch the URL. The script then waits for the three fetches to complete, or 10 seconds, whichever occurs first. The script then loads the results of the three timers into the GET arguments of the D URL and performs a fetch to pass these results back to the experiment's server.
在执行测试脚本时，前三个URL（A、B和C）作为任务加载到用户的浏览器中。脚本用这些URL中的每一个启动计时器，以测量获取URL所用的时间。然后，脚本等待三次回迁完成，或者等待10秒，以先发生的为准。然后，该脚本将三个计时器的结果加载到D URL的GET参数中，并执行一次fetch以将这些结果传递回实验服务器。
Logs on the web server reached at RESULTS.RECORDER.EXAMPLE.NET will include entries of the form shown in Figure 4. If any of the URLs fail to load within 10 seconds, the D URL will report the failure as a "null" timer value.
在RESULTS.RECORDER.EXAMPLE.NET上访问的web服务器上的日志将包括图4所示形式的条目。如果任何URL未能在10秒内加载，则D URL将以“null”计时器值报告失败。
GET /1x1.png?results.<unique_string>?za=1822&zb=1674&zc=1582
GET /1x1.png?results.<unique_string>?za=null&zb=null&zc=161
GET /1x1.png?results.<unique_string>?za=1822&zb=1674&zc=1582
GET /1x1.png?results.<unique_string>?za=null&zb=null&zc=161
Figure 4
图4
The script has been encoded in Adobe Flash with a simple image in the form of an online advertisement. An online advertisement network has been used to distribute the script. The script is invoked when the advertisement is presented in the end user's browser or application and does not require the user to click on the supplied image in any way. The advertisement placement parameters were set to the broadest possible scope to sample users from across the entire Internet.
该脚本已在AdobeFlash中编码，带有一个简单的在线广告图像。一个在线广告网络已经被用来分发剧本。当广告显示在最终用户的浏览器或应用程序中时，将调用脚本，并且不要求用户以任何方式单击提供的图像。广告投放参数设置为尽可能广泛的范围，以对整个互联网上的用户进行抽样。
The test was loaded into an advertisement distributed on 2013-10-10 and 2013-10-11.
该测试加载到2013年10月10日和2013年10月11日发布的广告中。
+--------------------+---------+------------+
| | Count | Percentage |
+--------------------+---------+------------+
| Recorded Results: | 338,478 | |
| | | |
| A or B Loaded: | 331,896 | 98.1% |
| | | |
| A Fail and B Fail: | 6,492 | 1.9% |
| | | |
| A Fail and B Load: | 4,249 | 1.3% |
| | | |
| A Load and B Fail: | 1,624 | 0.5% |
| | | |
| C Fail: | 9,355 | 2.8% |
+--------------------+---------+------------+
+--------------------+---------+------------+
| | Count | Percentage |
+--------------------+---------+------------+
| Recorded Results: | 338,478 | |
| | | |
| A or B Loaded: | 331,896 | 98.1% |
| | | |
| A Fail and B Fail: | 6,492 | 1.9% |
| | | |
| A Fail and B Load: | 4,249 | 1.3% |
| | | |
| A Load and B Fail: | 1,624 | 0.5% |
| | | |
| C Fail: | 9,355 | 2.8% |
+--------------------+---------+------------+
Table 1
表1
These results indicate that at most 1.9% of tested clients use DNS resolvers that fail to resolve a domain name that contains a DNAME redirection. However, the failure rate of slightly lower than 3% for the control URL indicates that the failure rate for the DNAME construct lies within the bounds of error within the experimental framework. We conclude that there is no evidence of a consistent failure on the part of deployed DNS resolvers to correctly resolve a DNAME construct.
这些结果表明，最多1.9%的测试客户端使用DNS解析程序，这些解析程序无法解析包含DNAME重定向的域名。然而，控制URL的失败率略低于3%，表明DNAME构造的失败率在实验框架内的误差范围内。我们的结论是，没有证据表明部署的DNS解析程序在正确解析DNAME构造方面存在一致性故障。
This experiment was conducted by Geoff Huston and George Michaelson.
这项实验由杰夫·休斯顿和乔治·迈克尔森进行。
Acknowledgements
致谢
The authors acknowledge the valuable contributions of Bob Harold and other participants in the DNSOP working group in the preparation of this document.
作者感谢Bob Harold和DNSOP工作组的其他参与者在编写本文件过程中做出的宝贵贡献。
Authors' Addresses
作者地址
Joe Abley Dyn, Inc. 103-186 Albert Street London, ON N6A 1M1 Canada
Joe Abley Dyn公司，地址：加拿大伦敦艾伯特街103-186号，邮编：N6A 1M1
Phone: +1 519 670 9327
EMail: jabley@dyn.com
Phone: +1 519 670 9327
EMail: jabley@dyn.com
Brian Dickson Twitter, Inc.
布莱恩·迪克森推特公司。
EMail: bdickson@twitter.com
EMail: bdickson@twitter.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
沃伦·库马里谷歌1600圆形剧场公园道山景，加利福尼亚州94043
EMail: warren@kumari.net
EMail: warren@kumari.net
George Michaelson APNIC
乔治·迈克尔森呼吸暂停综合征
EMail: ggm@apnic.net
EMail: ggm@apnic.net