Internet Engineering Task Force (IETF) M. Andrews
Request for Comments: 6303 ISC
BCP: 163 July 2011
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Andrews
Request for Comments: 6303 ISC
BCP: 163 July 2011
Category: Best Current Practice
ISSN: 2070-1721
Locally Served DNS Zones
本地服务DNS区域
Abstract
摘要
Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics.
域名系统（DNS）的经验表明，除非另有配置，否则所有迭代解析程序和递归名称服务器都应该自动服务于许多DNS区域。RFC 4193规定D.F.IP6.ARPA应发生这种情况。本文件扩展了实践，涵盖RFC 1918地址空间的IN-ADDR.ARPA区域和其他具有类似特征的知名区域。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc6303.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6303.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Reserved Words .............................................3
2. Effects on Sites Using RFC 1918 Addresses .......................3
3. Changes to Iterative Resolver Behaviour .........................4
4. Lists Of Zones Covered ..........................................5
4.1. RFC 1918 Zones .............................................5
4.2. RFC 5735 and RFC 5737 Zones ................................5
4.3. Local IPv6 Unicast Addresses ...............................6
4.4. IPv6 Locally Assigned Local Addresses ......................6
4.5. IPv6 Link-Local Addresses ..................................7
4.6. IPv6 Example Prefix ........................................7
5. Zones That Are Out of Scope .....................................7
6. IANA Considerations .............................................8
7. Security Considerations .........................................8
8. Acknowledgements ................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
1. Introduction ....................................................2
1.1. Reserved Words .............................................3
2. Effects on Sites Using RFC 1918 Addresses .......................3
3. Changes to Iterative Resolver Behaviour .........................4
4. Lists Of Zones Covered ..........................................5
4.1. RFC 1918 Zones .............................................5
4.2. RFC 5735 and RFC 5737 Zones ................................5
4.3. Local IPv6 Unicast Addresses ...............................6
4.4. IPv6 Locally Assigned Local Addresses ......................6
4.5. IPv6 Link-Local Addresses ..................................7
4.6. IPv6 Example Prefix ........................................7
5. Zones That Are Out of Scope .....................................7
6. IANA Considerations .............................................8
7. Security Considerations .........................................8
8. Acknowledgements ................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References ....................................10
Experience with the Domain Name System (DNS, [RFC1034] and [RFC1035]) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers SHOULD automatically serve, unless intentionally configured otherwise. These zones include, but are not limited to, the IN-ADDR.ARPA zones for the address space allocated by [RFC1918] and the IP6.ARPA zones for locally assigned unique local IPv6 addresses defined in [RFC4193].
域名系统（DNS、[RFC1034]和[RFC1035]）的经验表明，有许多DNS区域，所有迭代解析程序和递归名称服务器都应自动服务，除非有意另行配置。这些区域包括但不限于[RFC1918]分配的地址空间的IN-ADDR.ARPA区域和[RFC4193]中定义的本地分配的唯一本地IPv6地址的IP6.ARPA区域。
This recommendation is made because data has shown that significant leakage of queries for these namespaces is occurring, despite instructions to restrict them, and because it has therefore become necessary to deploy sacrificial nameservers to protect the immediate parent nameservers for these zones from excessive, unintentional query load [AS112] [RFC6304] [RFC6305]. There is every expectation that the query load will continue to increase unless steps are taken as outlined here.
之所以提出这一建议，是因为数据表明，尽管有限制这些名称空间的指示，但这些名称空间的查询仍在大量泄漏，因此有必要部署牺牲性名称服务器，以保护这些区域的直接父名称服务器不受过多、无意的查询负载的影响[AS112][RFC6304][RFC6305]。除非采取此处概述的步骤，否则查询负载将继续增加。
Additionally, queries from clients behind badly configured firewalls that allow outgoing queries for these namespaces, but drop the responses, put a significant load on the root servers (forward zones but not reverse zones are configured). They also cause operational load for the root server operators, as they have to reply to enquiries about why the root servers are "attacking" these clients. Changing the default configuration will address all these issues for the zones listed in Section 4.
此外，来自配置不当的防火墙后面的客户机的查询允许对这些名称空间进行传出查询，但会丢弃响应，这会给根服务器带来很大的负载（配置了正向区域，但没有配置反向区域）。它们还会给根服务器操作员带来操作负载，因为他们必须回答有关根服务器为什么“攻击”这些客户端的询问。更改默认配置将解决第4节所列区域的所有这些问题。
[RFC4193] recommends that queries for D.F.IP6.ARPA be handled locally. This document extends the recommendation to cover the IN-ADDR.ARPA zones for [RFC1918] and other well-known IN-ADDR.ARPA and IP6.ARPA zones for which queries should not appear on the public Internet.
[RFC4193]建议在本地处理对D.F.IP6.ARPA的查询。本文件扩展了该建议，以涵盖[RFC1918]的IN-ADDR.ARPA区域以及其他众所周知的IN-ADDR.ARPA和IP6.ARPA区域，这些区域的查询不应出现在公共互联网上。
It is hoped that by doing this the number of sacrificial servers [AS112] will not have to be increased, and may in time be reduced.
希望通过这样做，牺牲服务器[AS112]的数量不必增加，并且可以及时减少。
This recommendation should also help DNS responsiveness for sites that are using [RFC1918] addresses but do not follow the last paragraph in Section 3 of [RFC1918].
本建议还应有助于使用[RFC1918]地址但未遵循[RFC1918]第3节最后一段的站点的DNS响应。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
For most sites using [RFC1918] addresses, the changes here will have little or no detrimental effect. If the site does not already have the reverse tree populated, the only effect will be that the name error responses will be generated locally rather than remotely.
对于大多数使用[RFC1918]地址的站点，此处的更改几乎没有有害影响。如果站点尚未填充反向树，则唯一的影响是将在本地而不是远程生成名称错误响应。
For sites that do have the reverse tree populated, most will either have a local copy of the zones or will be forwarding the queries to servers that have local copies of the zone. Therefore, this recommendation will not be relevant.
对于已填充反向树的站点，大多数站点要么具有区域的本地副本，要么将查询转发到具有区域本地副本的服务器。因此，本建议将不相关。
The most significant impact will be felt at sites that make use of delegations for [RFC1918] addresses and have populated these zones. These sites will need to override the default configuration expressed in this document to allow resolution to continue. Typically, such sites will be fully disconnected from the Internet and have their own root servers for their own non-Internet DNS tree.
对[RFC1918]地址使用代表团并居住在这些区域的站点将产生最显著的影响。这些站点需要覆盖本文档中表示的默认配置，以便继续解析。通常，此类站点将与Internet完全断开连接，并为其非Internet DNS树拥有自己的根服务器。
Unless configured otherwise, an iterative resolver will now return authoritatively (AA=1) name errors (RCODE=3) for queries within the zones in Section 4, with the obvious exception of queries for the zone name itself where SOA, NS, and "no data" responses will be returned as appropriate to the query type. One common way to do this all at once is to serve empty (SOA and NS only) zones.
除非另有配置，否则迭代解析器现在将为第4节中区域内的查询返回授权（AA=1）名称错误（RCODE=3），区域名称本身的查询除外，其中SOA、NS和“无数据”响应将根据查询类型返回。一次完成这一切的一种常见方法是为空（仅限SOA和NS）区域提供服务。
An implementation of this recommendation MUST provide a mechanism to disable this new behaviour, and SHOULD allow this decision on a zone-by-zone basis.
本建议的实施必须提供一种机制来禁用这种新行为，并应允许在分区的基础上作出这一决定。
If using empty zones one SHOULD NOT use the same NS and SOA records as used on the public Internet servers, as that will make it harder to detect the origin of the responses and thus any leakage to the public Internet servers. It is RECOMMENDED that the NS record defaults to the name of the zone and the SOA MNAME defaults to the name of the only NS RR's (Resource Record's) target. The SOA RNAME SHOULD default to "nobody.invalid." [RFC2606]. Implementations SHOULD provide a mechanism to set these values. No address records need to be provided for the nameserver.
如果使用空区域，则不应使用公共Internet服务器上使用的相同NS和SOA记录，因为这将使检测响应的来源变得更加困难，从而导致泄漏到公共Internet服务器。建议NS记录默认为区域名称，SOA MNAME默认为唯一NS RR（资源记录）目标的名称。SOA RNAME应该默认为“nobody.invalid.”[RFC2606]。实现应该提供设置这些值的机制。不需要为名称服务器提供地址记录。
Below is an example of a generic empty zone in master file format. It will produce a negative cache Time to Live (TTL) of 3 hours.
下面是主文件格式的通用空白区域的示例。它将产生3小时的负缓存生存时间（TTL）。
@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
@ 10800 IN NS @
@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
@ 10800 IN NS @
The SOA RR is needed to support negative caching [RFC2308] of name error responses and to point clients to the primary master for DNS dynamic updates.
SOA RR需要支持名称错误响应的负缓存[RFC2308]，并将客户端指向主主机进行DNS动态更新。
SOA values of particular importance are the MNAME, the SOA RR's TTL, and the negTTL value. Both TTL values SHOULD match. The rest of the SOA timer values MAY be chosen arbitrarily since they are not intended to control any zone transfer activity.
特别重要的SOA值是MNAME、SOARR的TTL和negTTL值。两个TTL值应匹配。其余的SOA计时器值可以任意选择，因为它们不用于控制任何区域传输活动。
The NS RR is needed as some UPDATE [RFC2136] clients use NS queries to discover the zone to be updated. Having no address records for the nameserver is expected to abort UPDATE processing in the client.
由于某些更新[RFC2136]客户端使用NS查询来发现要更新的区域，因此需要NS RR。如果没有名称服务器的地址记录，则应中止客户端中的更新处理。
The following subsections are the initial contents of the IANA registry as described in the IANA Considerations section. Following the caveat in that section, the list contains only reverse zones corresponding to permanently assigned address space. The zone name is the entity to be registered.
以下小节是IANA注册中心的初始内容，如IANA注意事项部分所述。按照该部分中的警告，列表仅包含与永久分配的地址空间相对应的反向区域。区域名称是要注册的实体。
The following zones correspond to the IPv4 address space reserved in [RFC1918].
以下区域对应于[RFC1918]中保留的IPv4地址空间。
+----------------------+
| Zone |
+----------------------+
| 10.IN-ADDR.ARPA |
| 16.172.IN-ADDR.ARPA |
| 17.172.IN-ADDR.ARPA |
| 18.172.IN-ADDR.ARPA |
| 19.172.IN-ADDR.ARPA |
| 20.172.IN-ADDR.ARPA |
| 21.172.IN-ADDR.ARPA |
| 22.172.IN-ADDR.ARPA |
| 23.172.IN-ADDR.ARPA |
| 24.172.IN-ADDR.ARPA |
| 25.172.IN-ADDR.ARPA |
| 26.172.IN-ADDR.ARPA |
| 27.172.IN-ADDR.ARPA |
| 28.172.IN-ADDR.ARPA |
| 29.172.IN-ADDR.ARPA |
| 30.172.IN-ADDR.ARPA |
| 31.172.IN-ADDR.ARPA |
| 168.192.IN-ADDR.ARPA |
+----------------------+
+----------------------+
| Zone |
+----------------------+
| 10.IN-ADDR.ARPA |
| 16.172.IN-ADDR.ARPA |
| 17.172.IN-ADDR.ARPA |
| 18.172.IN-ADDR.ARPA |
| 19.172.IN-ADDR.ARPA |
| 20.172.IN-ADDR.ARPA |
| 21.172.IN-ADDR.ARPA |
| 22.172.IN-ADDR.ARPA |
| 23.172.IN-ADDR.ARPA |
| 24.172.IN-ADDR.ARPA |
| 25.172.IN-ADDR.ARPA |
| 26.172.IN-ADDR.ARPA |
| 27.172.IN-ADDR.ARPA |
| 28.172.IN-ADDR.ARPA |
| 29.172.IN-ADDR.ARPA |
| 30.172.IN-ADDR.ARPA |
| 31.172.IN-ADDR.ARPA |
| 168.192.IN-ADDR.ARPA |
+----------------------+
The following zones correspond to those address ranges from [RFC5735] and [RFC5737] that are not expected to appear as source or destination addresses on the public Internet; as such, there are no globally unique names associated with the addresses in these ranges.
以下区域对应于[RFC5735]和[RFC5737]之间的地址范围，这些地址范围预计不会作为源地址或目标地址出现在公共互联网上；因此，不存在与这些范围内的地址关联的全局唯一名称。
The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not an attempt to discourage any practice to provide a PTR RR for 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse mapping should exist, but the exact setup is out of the scope of this document. Similar logic applies to the reverse mapping for ::1 (Section 4.3). The recommendations made here simply assume that no other coverage for these domains exists.
为空区127.IN-ADDR.ARPA提供服务的建议并不是试图阻止在本地为1.0.0.127.IN-ADDR.ARPA提供PTR RR的任何做法。事实上，应该存在一个有意义的反向映射，但确切的设置不在本文档的范围之内。类似的逻辑适用于：：1的反向映射（第4.3节）。这里提出的建议只是假设这些域不存在其他覆盖范围。
+------------------------------+-----------------------+
| Zone | Description |
+------------------------------+-----------------------+
| 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
| 127.IN-ADDR.ARPA | IPv4 Loopback NETWORK |
| 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
| 2.0.192.IN-ADDR.ARPA | IPv4 TEST-NET-1 |
| 100.51.198.IN-ADDR.ARPA | IPv4 TEST-NET-2 |
| 113.0.203.IN-ADDR.ARPA | IPv4 TEST-NET-3 |
| 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
+------------------------------+-----------------------+
+------------------------------+-----------------------+
| Zone | Description |
+------------------------------+-----------------------+
| 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
| 127.IN-ADDR.ARPA | IPv4 Loopback NETWORK |
| 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
| 2.0.192.IN-ADDR.ARPA | IPv4 TEST-NET-1 |
| 100.51.198.IN-ADDR.ARPA | IPv4 TEST-NET-2 |
| 113.0.203.IN-ADDR.ARPA | IPv4 TEST-NET-3 |
| 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
+------------------------------+-----------------------+
The reverse mappings ([RFC3596], Section 2.5 ("IP6.ARPA Domain")) for the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC4291], Sections 2.4, 2.5.2, and 2.5.3) are covered by these two zones:
以下两个区域涵盖IPv6未指定（：：）和环回（：：1）地址（[RFC4291]，第2.4、2.5.2和2.5.3节）的反向映射（[RFC3596]，第2.5节（“IP6.ARPA域”）：
+-------------------------------------------+
| Zone |
+-------------------------------------------+
| 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
| 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
| 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
| 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
+-------------------------------------------+
+-------------------------------------------+
| Zone |
+-------------------------------------------+
| 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
| 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
| 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
| 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
+-------------------------------------------+
Note: Line breaks and escapes ('\') have been inserted above for readability and to adhere to line width constraints. They are not parts of the zone names.
注意：为了可读性和遵守线宽限制，在上面插入了换行符和转义符（“\”）。它们不是区域名称的一部分。
Section 4.4 of [RFC4193] already required special treatment of:
[RFC4193]第4.4节已要求对以下内容进行特殊处理：
+--------------+
| Zone |
+--------------+
| D.F.IP6.ARPA |
+--------------+
+--------------+
| Zone |
+--------------+
| D.F.IP6.ARPA |
+--------------+
IPv6 Link-Local Addresses as described in [RFC4291], Section 2.5.6 are covered by four distinct reverse DNS zones:
[RFC4291]第2.5.6节中所述的IPv6链路本地地址由四个不同的反向DNS区域覆盖：
+----------------+
| Zone |
+----------------+
| 8.E.F.IP6.ARPA |
| 9.E.F.IP6.ARPA |
| A.E.F.IP6.ARPA |
| B.E.F.IP6.ARPA |
+----------------+
+----------------+
| Zone |
+----------------+
| 8.E.F.IP6.ARPA |
| 9.E.F.IP6.ARPA |
| A.E.F.IP6.ARPA |
| B.E.F.IP6.ARPA |
+----------------+
IPv6 example prefix [RFC3849].
IPv6示例前缀[RFC3849]。
+--------------------------+
| Zone |
+--------------------------+
| 8.B.D.0.1.0.0.2.IP6.ARPA |
+--------------------------+
+--------------------------+
| Zone |
+--------------------------+
| 8.B.D.0.1.0.0.2.IP6.ARPA |
+--------------------------+
Note: 8.B.D.0.1.0.0.2.IP6.ARPA is not being used as an example here.
注：此处未将8.B.D.0.1.0.0.2.IP6.ARPA用作示例。
IPv6 site-local addresses (deprecated, see [RFC4291] Sections 2.4 and 2.5.7), and IPv6 non-locally assigned local addresses ([RFC4193]) are not covered here.
IPv6站点本地地址（已弃用，请参见[RFC4291]第2.4节和第2.5.7节）以及IPv6非本地分配的本地地址（[RFC4193]）在此不作介绍。
It is expected that IPv6 site-local addresses will be self correcting as IPv6 implementations remove support for site-local addresses. However, sacrificial servers for the zones C.E.F.IP6.ARPA through F.E.F.IP6.ARPA may still need to be deployed in the short term if the traffic becomes excessive.
由于IPv6实施取消了对站点本地地址的支持，预计IPv6站点本地地址将自动更正。但是，如果流量过大，短期内可能仍需要部署C.E.F.IP6.ARPA到F.E.F.IP6.ARPA区域的牺牲服务器。
For IPv6 non-locally assigned local addresses (L = 0) [RFC4193], there has been no decision made about whether the Regional Internet Registries (RIRs) will provide delegations in this space or not. If they don't, then C.F.IP6.ARPA will need to be added to the list in Section 4.4. If they do, then registries will need to take steps to ensure that nameservers are provided for these addresses.
对于IPv6非本地分配的本地地址（L=0）[RFC4193]，尚未决定区域互联网注册中心（RIR）是否在该空间提供授权。如果没有，则需要将C.F.IP6.ARPA添加到第4.4节的列表中。如果是这样，那么注册中心将需要采取措施确保为这些地址提供名称服务器。
IP6.INT was once used to provide reverse mapping for IPv6. IP6.INT was deprecated in [RFC4159] and the delegation removed from the INT zone in June 2006. While it is possible that legacy software continues to send queries for names under the IP6.INT domain, this document does not specify that IP6.INT be considered a local zone.
IP6.INT曾经用于为IPv6提供反向映射。IP6.INT在[RFC4159]中被弃用，该授权于2006年6月从INT区域移除。虽然遗留软件可能会继续发送对IP6.INT域下名称的查询，但本文档并未指定将IP6.INT视为本地区域。
This document has also deliberately ignored names immediately under the root domain. While there is a subset of queries to the root nameservers that could be addressed using the techniques described here (e.g., .local, .workgroup, and IPv4 addresses), there is also a vast amount of traffic that requires a different strategy (e.g., lookups for unqualified hostnames, IPv6 addresses).
此文档还故意忽略了根域下的名称。虽然可以使用此处描述的技术（例如，本地、、工作组和IPv4地址）解决对根名称服务器的查询子集，但也有大量流量需要不同的策略（例如，查找不合格的主机名、IPv6地址）。
IANA has established a registry of zones that require this default behaviour. The initial contents of this registry are defined in Section 4. Implementors are encouraged to periodically check this registry and adjust their implementations to reflect changes therein.
IANA已建立了需要此默认行为的区域的注册表。本登记册的初始内容见第4节。鼓励实现者定期检查此注册表并调整其实现以反映其中的更改。
This registry can be amended through "IETF Review" as per [RFC5226]. As part of this review process, it should be noted that once a zone is added it is effectively added permanently; once an address range starts being configured as a local zone in systems on the Internet, it will be impossible to reverse those changes.
可根据[RFC5226]通过“IETF审查”对该注册表进行修订。作为审查过程的一部分，应注意的是，一旦添加了一个分区，该分区将被永久有效地添加；一旦某个地址范围开始在Internet上的系统中配置为本地区域，就不可能逆转这些更改。
IANA should coordinate with the RIRs to ensure that, as DNS Security (DNSSEC) is deployed in the reverse tree, delegations for these zones are made in the manner described in Section 7.
IANA应与RIR协调，以确保在反向树中部署DNS安全（DNSSEC）时，按照第7节所述的方式对这些区域进行授权。
During the initial deployment phase, particularly where [RFC1918] addresses are in use, there may be some clients that unexpectedly receive a name error rather than a PTR record. This may cause some service disruption until their recursive nameserver(s) have been re-configured.
在初始部署阶段，特别是在使用[RFC1918]地址的情况下，可能会有一些客户端意外收到名称错误而不是PTR记录。在重新配置递归名称服务器之前，这可能会导致某些服务中断。
As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers.
由于DNSSEC部署在IN-ADDR.ARPA和IP6.ARPA命名空间中，因此需要将上面列出的区域委派为不安全委派，或委派在不安全区域内。这将允许DNSSEC验证在这些空间中的查询成功，尽管没有从委托服务器得到答复。
It is recommended that sites actively using these namespaces secure them using DNSSEC [RFC4035] by publishing and using DNSSEC trust anchors. This will protect the clients from accidental import of unsigned responses from the Internet.
建议积极使用这些名称空间的站点通过发布和使用DNSSEC信任锚来使用DNSSEC[RFC4035]保护它们。这将保护客户端免受意外从Internet导入未签名响应的影响。
This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
这项工作得到了美国国家科学基金会（研究资助SCIO 0427 144）和DNS OARC的支持。
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake 3rd，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[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月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4159] Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, August 2005.
[RFC4159]Huston，G.，“ip6.int的弃用”，BCP 109，RFC 4159，2005年8月。
[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月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[AS112] "AS112 Project", <http://www.as112.net/>.
[AS112]“AS112项目”<http://www.as112.net/>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849]Huston，G.，Lord，A.，和P.Smith，“为文档保留IPv6地址前缀”，RFC 3849，2004年7月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，2010年1月。
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.
[RFC6304]Abley，J.和W.Maton，“AS112名称服务器操作”，RFC6304，2011年7月。
[RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by PRISONER.IANA.ORG!", RFC 6305, July 2011.
[RFC6305]Abley，J.和W.Maton，“我被囚犯攻击了。IANA.ORG！”，RFC63052011年7月。
Author's Address
作者地址
Mark P. Andrews Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 US
Mark P.Andrews Internet Systems Consortium 950 Charter Street Redwood City，加利福尼亚州，美国94063
EMail: marka@isc.org
EMail: marka@isc.org