Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6761 M. Krochmal
Updates: 1918, 2606 Apple Inc.
Category: Standards Track February 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6761 M. Krochmal
Updates: 1918, 2606 Apple Inc.
Category: Standards Track February 2013
ISSN: 2070-1721
Special-Use Domain Names
特殊用途域名
Abstract
摘要
This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.
本文档描述了当保留域名（DNS名称）是合适的时候，保留域名（DNS名称）用于特殊用途的含义，以及这样做的过程。它为这些域名建立了IANA注册中心，并为其中一些已经建立的特殊域名添加了条目。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6761.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6761.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Certain individual IP addresses and IP address ranges are treated specially by network implementations and, consequently, are not suitable for use as unicast addresses. For example, IPv4 addresses 224.0.0.0 to 239.255.255.255 are multicast addresses [RFC5735], with 224.0.0.1 being the "all hosts" multicast address [RFC1112] [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host" address [RFC5735].
某些单独的IP地址和IP地址范围由网络实现专门处理，因此不适合用作单播地址。例如，IPv4地址224.0.0.0到239.255.255.255是多播地址[RFC5735]，其中224.0.0.1是“所有主机”多播地址[RFC1112][RFC5771]。另一个例子是127.0.0.1，IPv4“本地主机”地址[RFC5735]。
Analogous to Special-Use IPv4 Addresses [RFC5735], the Domain Name System (DNS) [RFC1034][RFC1035] has its own concept of reserved names, such as "example.com.", "example.net.", and "example.org.", or any name falling under the top-level pseudo-domain "invalid." [RFC2606]. However, "Reserved Top Level DNS Names" [RFC2606] does not state whether implementations are expected to treat such names differently, and if so, in what way.
与特殊用途IPv4地址[RFC5735]类似，域名系统（DNS）[RFC1034][RFC1035]有自己的保留名称概念，例如“example.com.”、“example.net.”和“example.org.”，或者属于顶级伪域“invalid.”[RFC2606]的任何名称。然而，“保留的顶级DNS名称”[RFC2606]并未说明是否期望实现以不同的方式对待此类名称，如果是，以何种方式。
This document specifies under what circumstances special treatment is appropriate, and in what ways.
本文件规定了在何种情况下，以何种方式进行特殊处理是合适的。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于指示需求水平的关键词”[RFC2119]中的描述进行解释。
When IP multicast was created [RFC1112], implementations had to be updated to understand what an IP multicast address means and what to do with it. Adding IP multicast to a networking stack entailed more than merely adding the right routing table entries for those addresses. Moreover, supporting IP multicast entails some level of commonality that is consistent across all conformant hosts, independent of what networks those hosts may be connected to. While it is possible to build a private isolated network using whatever valid unicast IP addresses and routing topology one chooses (regardless of whether those unicast IP addresses are already in use by other hosts on the public Internet), the IPv4 multicast address 224.0.0.1 is always the "all hosts" multicast address, and that's not a local decision.
创建IP多播时[RFC1112]，必须更新实现，以了解IP多播地址的含义以及如何使用它。将IP多播添加到网络堆栈不仅仅需要为这些地址添加正确的路由表条目。此外，支持IP多播需要一定程度的通用性，这在所有一致的主机上都是一致的，与这些主机可能连接到的网络无关。虽然可以使用您选择的任何有效单播IP地址和路由拓扑构建专用隔离网络（无论这些单播IP地址是否已被公共Internet上的其他主机使用），但IPv4多播地址224.0.0.1始终是“所有主机”多播地址，这不是当地的决定。
Similarly, if a domain name has special properties that affect the way hardware and software implementations handle the name, that apply universally regardless of what network the implementation may be connected to, then that domain name may be a candidate for having the
类似地，如果域名具有影响硬件和软件实现处理该名称的方式的特殊属性，并且无论实现可能连接到哪个网络，这些属性都普遍适用，那么该域名可能是具有该名称的候选域名
IETF declare it to be a Special-Use Domain Name and specify what special treatment implementations should give to that name. On the other hand, if declaring a given name to be special would result in no change to any implementations, then that suggests that the name may not be special in any material way, and it may be more appropriate to use the existing DNS mechanisms [RFC1034] to provide the desired delegation, data, or lack-of-data, for the name in question. Where the desired behaviour can be achieved via the existing domain name registration processes, that process should be used. Reservation of a Special-Use Domain Name is not a mechanism for circumventing normal domain name registration processes.
IETF将其声明为一个特殊用途域名，并指定实现应给予该名称的特殊处理。另一方面，如果将给定名称声明为特殊名称不会导致对任何实现的更改，则这表明该名称可能在任何实质性方面都不特殊，并且可能更适合使用现有DNS机制[RFC1034]为所讨论的名称提供所需的委派、数据或缺少数据。如果可以通过现有域名注册流程实现所需行为，则应使用该流程。保留特殊用途域名并不是规避正常域名注册过程的机制。
As an example, suppose there were to be an IETF document specifying that a particular name (or set of names) is guaranteed to produce an NXDOMAIN ("Name Error" [RFC1035]) result. Such a document falls within the responsibilities of the IETF. The IETF is responsible for protocol rules. The IETF defines name character set, length limits, syntax, the fact that in DNS "A" is equivalent to "a", etc. [RFC1034] [RFC1035]. Portions of the namespace created by those rules are given to ICANN to manage, but, due to established DNS protocol rules, ICANN is not free to allocate "COM" and "com" to two different name servers. The IETF has responsibility for specifying how the DNS protocol works, and ICANN is responsible for allocating the names made possible by that DNS protocol. Now, suppose a developer were to use this special "guaranteed nonexistent" name, "knowing" that it's guaranteed to return NXDOMAIN, and suppose also that the user's DNS server fails to return NXDOMAIN for this name. The developer's software then fails. Who do the user and/or developer complain to? ICANN? The IETF? The DNS server operator? If the developer can't depend on the special "guaranteed nonexistent" name to always return NXDOMAIN, then the special name is worthless, because it can't be relied on to do what it is supposed to. For this special "guaranteed nonexistent" name to have any use, it has to be defined to return NXDOMAIN, BY PROTOCOL, for all installations, not just by ICANN allocation on the public Internet. ICANN has no jurisdiction over how users choose to configure their own private DNS servers on their own private networks, but developers need a protocol specification that states that returning positive answers for the special "guaranteed nonexistent" name is a protocol violation on *all* networks, not just the public Internet. Hence, the act of defining such a special name creates a higher-level protocol rule, above ICANN's management of allocable names on the public Internet.
例如，假设有一个IETF文档指定一个特定名称（或一组名称）保证产生一个NXDOMAIN（“名称错误”[RFC1035]）结果。此类文件属于IETF的职责范围。IETF负责协议规则。IETF定义了名称字符集、长度限制、语法，以及在DNS中“A”等同于“A”的事实[RFC1034][RFC1035]。由这些规则创建的部分名称空间交给ICANN管理，但是，由于已建立的DNS协议规则，ICANN不能自由地将“COM”和“COM”分配给两个不同的名称服务器。IETF负责指定DNS协议的工作方式，ICANN负责分配该DNS协议可能提供的名称。现在，假设开发人员使用这个特殊的“保证不存在”名称，“知道”它保证返回NXDOMAIN，并且假设用户的DNS服务器无法返回该名称的NXDOMAIN。开发人员的软件随后失败。用户和/或开发人员向谁投诉？ICANN？IETF？DNS服务器操作员？如果开发人员不能依靠特殊的“保证不存在”名称来始终返回NXDOMAIN，那么这个特殊名称就毫无价值，因为它不能被依赖来完成它应该做的事情。为了使这个特殊的“保证不存在”名称有任何用途，必须定义它为所有安装返回NXDOMAIN（通过协议），而不仅仅是通过公共互联网上的ICANN分配。ICANN对用户如何选择在自己的专用网络上配置自己的专用DNS服务器没有管辖权，但开发人员需要一个协议规范，该规范规定，对特殊的“保证不存在”名称返回肯定答案是对*所有*网络（而不仅仅是公共互联网）的协议违反。因此，定义这样一个特殊名称的行为创建了一个更高级别的协议规则，高于ICANN对公共互联网上可分配名称的管理。
If it is determined that special handling of a name is required in order to implement some desired new functionality, then an IETF "Standards Action" or "IESG Approval" specification [RFC5226] MUST be published describing the new functionality.
如果确定需要对名称进行特殊处理以实现某些期望的新功能，则必须发布描述新功能的IETF“标准行动”或“IESG批准”规范[RFC5226]。
The specification MUST state how implementations determine that the special handling is required for any given name. This is typically done by stating that any fully qualified domain name ending in a certain suffix (i.e., falling within a specified parent pseudo-domain) will receive the special behaviour. In effect, this carves off a sub-tree of the DNS namespace in which the modified name treatment rules apply, analogous to how IP multicast [RFC1112] or IP link-local addresses [RFC3927] [RFC4862] carve off chunks of the IP address space in which their respective modified address treatment rules apply.
规范必须说明实现如何确定任何给定名称都需要特殊处理。这通常是通过声明任何以特定后缀结尾的完全限定域名（即，属于指定的父伪域）将接收特殊行为来实现的。实际上，这分割了DNS名称空间的一个子树，其中应用了修改后的名称处理规则，类似于IP多播[RFC1112]或IP链路本地地址[RFC3927][RFC4862]如何分割其各自修改后的地址处理规则应用的IP地址空间块。
The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied. If in all seven categories the answer is "none", then possibly no special treatment is required and requesting reservation of a Special-Use Domain Name may not be appropriate.
规范还必须说明，在以下七个“域名保留注意事项”类别中的每一个类别中，将应用什么特殊处理（如有）。如果在所有七个类别中，答案都是“无”，那么可能不需要特殊处理，请求保留特殊用途域名可能不合适。
An IETF "Standards Action" or "IESG Approval" document specifying some new naming behaviour, which requires a Special-Use Domain Name be reserved to implement this desired new behaviour, needs to contain a subsection of the "IANA Considerations" section titled "Domain Name Reservation Considerations" giving answers in the seven categories listed below. In the case of algorithmically generated DNS names, the specifying document needs to clearly identify the set of names generated by the algorithm that would require the proposed special treatment.
IETF“标准行动”或“IESG批准”文件规定了一些新的命名行为，要求保留一个特殊用途的域名以实现这种期望的新行为，需要包含“IANA注意事项”一节中题为“域名保留注意事项”的小节在下面列出的七个类别中给出答案。对于算法生成的DNS名称，指定文档需要清楚地标识算法生成的名称集，该名称集需要建议的特殊处理。
1. Users:
1. 用户：
Are human users expected to recognize these names as special and use them differently? In what way?
是否期望人类用户将这些名称识别为特殊名称并以不同方式使用它们？以什么方式？
2. Application Software:
2. 应用软件：
Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? (For example, if a human user enters such a name, should the application software reject it with an error message?)
应用软件的作者是否期望他们的软件将这些名称识别为特殊名称，并以不同的方式对待它们？以什么方式？（例如，如果人类用户输入了这样的名称，应用软件是否应拒绝该名称并显示错误消息？）
3. Name Resolution APIs and Libraries:
3. 名称解析API和库：
Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?
名称解析API和库的编写者是否希望他们的软件将这些名称识别为特殊名称并以不同的方式对待它们？如果是，怎么做？
4. Caching DNS Servers:
4. 缓存DNS服务器：
Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
缓存域名服务器的开发人员是否希望他们的实现将这些名称识别为特殊名称，并以不同的方式对待它们？如果是，怎么做？
5. Authoritative DNS Servers:
5. 权威DNS服务器：
Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
权威域名服务器的开发人员是否希望他们的实现将这些名称识别为特殊名称并以不同的方式对待它们？如果是，怎么做？
6. DNS Server Operators:
6. DNS服务器操作员：
Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?
此保留的专用域名是否对DNS服务器运营商有任何潜在影响？如果他们试图将其权威DNS服务器配置为此保留名称的权威，兼容名称服务器软件是否会将其视为无效而拒绝？DNS服务器运营商需要了解这一点并了解原因吗？即使名称服务器软件不阻止他们使用此保留名称，是否有其他方式可能无法按预期工作，DNS服务器运营商应了解这些情况？
7. DNS Registries/Registrars:
7. DNS注册机构/注册机构：
How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity? (For example, the name "www.example.org" is reserved for documentation examples and is not available for registration; however, the name is in fact registered; and there is even a web site at that name, which states circularly that the name is reserved for use in documentation and cannot be registered!)
DNS注册机构/注册机构应如何处理注册此保留域名的请求？这些要求是否应该被拒绝？是否应允许此类请求，但仅允许向特别指定的实体提出？（例如，名称“www.example.org”是为文档示例保留的，不可注册；但是，该名称实际上已注册；甚至还有一个以该名称命名的网站，该网站循环声明该名称保留用于文档中，不能注册！）
The initial IANA "Special-Use Domain Names" registry shall contain entries for the private-address [RFC1918] reverse-mapping domains and for the existing Reserved Top Level DNS Names [RFC2606].
初始IANA“特殊用途域名”注册表应包含专用地址[RFC1918]反向映射域和现有保留顶级DNS名称[RFC2606]的条目。
The private-address [RFC1918] reverse-mapping domains listed below, and any names falling within those domains, are Special-Use Domain Names:
下面列出的专用地址[RFC1918]反向映射域以及这些域中的任何名称都是专用域名：
10.in-addr.arpa. 21.172.in-addr.arpa. 26.172.in-addr.arpa. 16.172.in-addr.arpa. 22.172.in-addr.arpa. 27.172.in-addr.arpa. 17.172.in-addr.arpa. 30.172.in-addr.arpa. 28.172.in-addr.arpa. 18.172.in-addr.arpa. 23.172.in-addr.arpa. 29.172.in-addr.arpa. 19.172.in-addr.arpa. 24.172.in-addr.arpa. 31.172.in-addr.arpa. 20.172.in-addr.arpa. 25.172.in-addr.arpa. 168.192.in-addr.arpa.
10.in-addr.arpa。21.172.in-addr.arpa。26.172.in-addr.arpa。16.172.in-addr.arpa。22.172.in-addr.arpa。27.172.in-addr.arpa。17.172.in-addr.arpa。30.172.in-addr.arpa。28.172.in-addr.arpa。18.172.in-addr.arpa。23.172.in-addr.arpa。29.172.in-addr.arpa。19.172.in-addr.arpa。24.172.in-addr.arpa。31.172.in-addr.arpa。20.172.in-addr.arpa。25.172.in-addr.arpa。168.192.in-addr.arpa。
These domains, and any names falling within these domains, are special in the following ways:
这些域以及属于这些域的任何名称在以下方面都是特殊的：
1. Users are free to use these names as they would any other reverse-mapping names. However, since there is no central authority responsible for use of private addresses, users SHOULD be aware that these names are likely to yield different results on different networks.
1. 用户可以像使用任何其他反向映射名称一样自由使用这些名称。但是，由于没有负责使用专用地址的中央机构，用户应该知道，这些名称可能在不同的网络上产生不同的结果。
2. Application software SHOULD NOT recognize these names as special, and SHOULD use these names as they would other reverse-mapping names.
2. 应用软件不应将这些名称识别为特殊名称，而应像使用其他反向映射名称一样使用这些名称。
3. Name resolution APIs and libraries SHOULD NOT recognize these names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for these names to their configured caching DNS server(s).
3. 名称解析API和库不应将这些名称视为特殊名称，也不应区别对待。名称解析API应将这些名称的查询发送到其配置的缓存DNS服务器。
4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD, by default, generate immediate (positive or negative) responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolution of such names, for use in private networks where private-address reverse-mapping names are known to be handled by an authoritative DNS server in said private network.
4. 缓存DNS服务器应将这些名称识别为特殊名称，默认情况下，不应尝试查找这些名称的NS记录，或以其他方式查询权威DNS服务器以尝试解析这些名称。相反，默认情况下，缓存DNS服务器应该为所有此类查询生成即时（肯定或否定）响应。这是为了避免根名称服务器和其他名称服务器上不必要的负载。缓存DNS服务器应提供配置选项（默认情况下禁用），以启用此类名称的上游解析，以便在私有网络中使用，其中已知私有地址反向映射名称由所述私有网络中的权威DNS服务器处理。
5. Authoritative DNS servers SHOULD recognize these names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for private-address reverse-mapping names.
5. 权威DNS服务器应将这些名称识别为特殊名称，并且在默认情况下，应立即为所有此类查询生成否定响应，除非管理员明确配置为对私有地址反向映射名称给出肯定回答。
6. DNS server operators SHOULD, if they are using private addresses, configure their authoritative DNS servers to act as authoritative for these names.
6. 如果DNS服务器运营商使用专用地址，则应将其权威DNS服务器配置为这些名称的权威服务器。
7. DNS Registries/Registrars MUST NOT grant requests to register any of these names in the normal way to any person or entity. These names are reserved for use in private networks, and fall outside the set of names available for allocation by registries/ registrars. Attempting to allocate one of these names as if it were a normal DNS domain name will probably not work as desired, for reasons 4, 5 and 6 above.
7. DNS注册机构/注册机构不得向任何个人或实体授予以正常方式注册任何此类名称的请求。这些名称保留在专用网络中使用，不属于登记处/登记处可分配的名称集。由于上述原因4、5和6，尝试将这些名称中的一个作为普通DNS域名进行分配可能无法正常工作。
The domain "test.", and any names falling within ".test.", are special in the following ways:
域“test.”和“.test.”中的任何名称在以下方面都是特殊的：
1. Users are free to use these test names as they would any other domain names. However, since there is no central authority responsible for use of test names, users SHOULD be aware that these names are likely to yield different results on different networks.
1. 用户可以像使用任何其他域名一样自由使用这些测试名称。然而，由于没有负责使用测试名称的中央机构，用户应该知道这些名称可能会在不同的网络上产生不同的结果。
2. Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names.
2. 应用软件不应将测试名称识别为特殊名称，而应像使用其他域名一样使用测试名称。
3. Name resolution APIs and libraries SHOULD NOT recognize test names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for test names to their configured caching DNS server(s).
3. 名称解析API和库不应将测试名称识别为特殊名称，也不应区别对待它们。名称解析API应向其配置的缓存DNS服务器发送测试名称查询。
4. Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolving of test names, for use in networks where test names are known to be handled by an authoritative DNS server in said private network.
4. 缓存DNS服务器应将测试名称识别为特殊名称，默认情况下，不应尝试查找它们的NS记录，或以其他方式查询权威DNS服务器以尝试解析测试名称。相反，默认情况下，缓存DNS服务器应立即为所有此类查询生成否定响应。这是为了避免根名称服务器和其他名称服务器上不必要的负载。缓存DNS服务器应提供配置选项（默认情况下禁用），以启用测试名称的上游解析，以便在已知测试名称由所述专用网络中的权威DNS服务器处理的网络中使用。
5. Authoritative DNS servers SHOULD recognize test names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for test names.
5. 权威DNS服务器应将测试名称识别为特殊名称，并且在默认情况下，应立即为所有此类查询生成否定响应，除非管理员明确配置为对测试名称给出肯定回答。
6. DNS server operators SHOULD, if they are using test names, configure their authoritative DNS servers to act as authoritative for test names.
6. 如果DNS服务器操作员正在使用测试名称，则应将其权威DNS服务器配置为作为测试名称的权威服务器。
7. DNS Registries/Registrars MUST NOT grant requests to register test names in the normal way to any person or entity. Test names are reserved for use in private networks and fall outside the set of names available for allocation by registries/registrars. Attempting to allocate a test name as if it were a normal DNS domain name will probably not work as desired, for reasons 4, 5, and 6 above.
7. DNS注册中心/注册中心不得向任何个人或实体授予以正常方式注册测试名称的请求。测试名称保留在专用网络中使用，不属于注册中心/注册中心可分配的名称集。由于上述原因4、5和6，尝试将测试名称当作普通DNS域名来分配可能无法按预期工作。
The domain "localhost." and any names falling within ".localhost." are special in the following ways:
域“localhost.”和“.localhost.”范围内的任何名称在以下方面都是特殊的：
1. Users are free to use localhost names as they would any other domain names. Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.
1. 用户可以像使用任何其他域名一样自由使用本地主机名。用户可能会假设对本地主机名的IPv4和IPv6地址查询将始终解析为相应的IP环回地址。
2. Application software MAY recognize localhost names as special, or MAY pass them to name resolution APIs as they would for other domain names.
2. 应用程序软件可能会将本地主机名识别为特殊名称，或者可能会像对待其他域名一样将其传递给名称解析API。
3. Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).
3. 名称解析API和库应将本地主机名识别为特殊名称，并应始终为地址查询返回IP环回地址，为所有其他查询类型返回否定响应。名称解析API不应向其配置的缓存DNS服务器发送本地主机名称查询。
4. Caching DNS servers SHOULD recognize localhost names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve localhost names. Instead, caching DNS servers SHOULD, for all such address queries, generate an immediate positive response giving the IP loopback address, and for all other query types, generate an immediate negative response. This is to avoid unnecessary load on the root name servers and other name servers.
4. 缓存DNS服务器应将本地主机名识别为特殊名称，并且不应尝试查找它们的NS记录，或以其他方式查询权威DNS服务器以尝试解析本地主机名。相反，缓存DNS服务器应该为所有此类地址查询生成立即的肯定响应，给出IP环回地址，并为所有其他查询类型生成立即的否定响应。这是为了避免根名称服务器和其他名称服务器上不必要的负载。
5. Authoritative DNS servers SHOULD recognize localhost names as special and handle them as described above for caching DNS servers.
5. 权威DNS服务器应将本地主机名识别为特殊名称，并如上所述处理它们以缓存DNS服务器。
6. DNS server operators SHOULD be aware that the effective RDATA for localhost names is defined by protocol specification and cannot be modified by local configuration.
6. DNS服务器操作员应注意，本地主机名的有效RDATA由协议规范定义，不能由本地配置修改。
7. DNS Registries/Registrars MUST NOT grant requests to register localhost names in the normal way to any person or entity. Localhost names are defined by protocol specification and fall outside the set of names available for allocation by registries/ registrars. Attempting to allocate a localhost name as if it were a normal DNS domain name will probably not work as desired, for reasons 2, 3, 4, and 5 above.
7. DNS注册中心/注册中心不得向任何个人或实体授予以正常方式注册本地主机名的请求。本地主机名由协议规范定义，不属于可由注册表/注册器分配的名称集。由于上述原因2、3、4和5，尝试将本地主机名当作普通DNS域名进行分配可能无法正常工作。
The domain "invalid." and any names falling within ".invalid." are special in the ways listed below. In the text below, the term "invalid" is used in quotes to signify such names, as opposed to names that may be invalid for other reasons (e.g., being too long).
域“invalid.”和任何在“.invalid.”范围内的名称在以下列出的方式中都是特殊的。在下文中，“无效”一词用引号表示此类名称，而不是因其他原因（如过长）而无效的名称。
1. Users are free to use "invalid" names as they would any other domain names. Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses.
1. 用户可以像使用任何其他域名一样自由使用“无效”名称。用户可能认为对“无效”名称的查询将始终返回域响应。
2. Application software MAY recognize "invalid" names as special or MAY pass them to name resolution APIs as they would for other domain names.
2. 应用软件可能会将“无效”名称识别为特殊名称，或者像对待其他域名一样将其传递给名称解析API。
3. Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).
3. 名称解析API和库应将“无效”名称识别为特殊名称，并应始终立即返回否定响应。名称解析API不应向其配置的缓存DNS服务器发送“无效”名称的查询。
4. Caching DNS servers SHOULD recognize "invalid" names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve "invalid" names. Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers.
4. 缓存DNS服务器应将“无效”名称识别为特殊名称，并且不应尝试查找这些名称的NS记录，或者以其他方式查询权威DNS服务器以尝试解析“无效”名称。相反，缓存DNS服务器应该为所有此类查询生成即时的域响应。这是为了避免根名称服务器和其他名称服务器上不必要的负载。
5. Authoritative DNS servers SHOULD recognize "invalid" names as special and handle them as described above for caching DNS servers.
5. 权威DNS服务器应将“无效”名称识别为特殊名称，并如上所述进行处理以缓存DNS服务器。
6. DNS server operators SHOULD be aware that the effective RDATA for "invalid" names is defined by protocol specification to be nonexistent and cannot be modified by local configuration.
6. DNS服务器操作员应注意，“无效”名称的有效RDATA由协议规范定义为不存在，并且不能通过本地配置进行修改。
7. DNS Registries/Registrars MUST NOT grant requests to register "invalid" names in the normal way to any person or entity. These "invalid" names are defined by protocol specification to be nonexistent, and they fall outside the set of names available for allocation by registries/registrars. Attempting to allocate a "invalid" name as if it were a normal DNS domain name will probably not work as desired, for reasons 2, 3, 4, and 5 above.
7. DNS注册机构/注册机构不得以正常方式向任何个人或实体授予注册“无效”名称的请求。协议规范将这些“无效”名称定义为不存在，并且它们不属于可由注册中心/注册中心分配的名称集。由于上述原因2、3、4和5，尝试将“无效”名称当作普通DNS域名来分配可能无法正常工作。
The domains "example.", "example.com.", "example.net.", "example.org.", and any names falling within those domains, are special in the following ways:
域“example.”、“example.com.”、“example.net.”、“example.org.”以及属于这些域的任何名称在以下方面都是特殊的：
1. Users SHOULD understand that example names are reserved for use in documentation.
1. 用户应该理解，示例名称是为在文档中使用而保留的。
2. Application software SHOULD NOT recognize example names as special and SHOULD use example names as they would other domain names.
2. 应用软件不应将示例名称识别为特殊名称，而应像使用其他域名一样使用示例名称。
3. Name resolution APIs and libraries SHOULD NOT recognize example names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for example names to their configured caching DNS server(s).
3. 名称解析API和库不应将示例名称识别为特殊名称，也不应区别对待它们。名称解析API应向其配置的缓存DNS服务器发送例如名称的查询。
4. Caching DNS servers SHOULD NOT recognize example names as special and SHOULD resolve them normally.
4. 缓存DNS服务器不应将示例名称识别为特殊名称，并应正常解析它们。
5. Authoritative DNS servers SHOULD NOT recognize example names as special.
5. 权威DNS服务器不应将示例名称识别为特殊名称。
6. DNS server operators SHOULD be aware that example names are reserved for use in documentation.
6. DNS服务器操作员应注意，示例名称保留在文档中使用。
7. DNS Registries/Registrars MUST NOT grant requests to register example names in the normal way to any person or entity. All example names are registered in perpetuity to IANA:
7. DNS注册机构/注册机构不得向任何个人或实体授予以正常方式注册示例名称的请求。所有示例名称均永久注册到IANA：
Domain Name: EXAMPLE.COM
Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
Whois Server: whois.iana.org
Referral URL: http://res-dom.iana.org
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 26-mar-2004
Creation Date: 14-aug-1995
Expiration Date: 13-aug-2011
Domain Name: EXAMPLE.COM
Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
Whois Server: whois.iana.org
Referral URL: http://res-dom.iana.org
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 26-mar-2004
Creation Date: 14-aug-1995
Expiration Date: 13-aug-2011
IANA currently maintains a web server providing a web page explaining the purpose of example domains.
IANA目前维护一个web服务器，提供一个解释示例域用途的网页。
This document outlines the circumstances in which reserving a domain name for special use is appropriate, and the procedure for having that Special-Use Domain Name recorded by IANA. Any document requesting such a Special-Use Domain Name needs to contain an appropriate "Security Considerations" section which describes any security issues relevant to that special use.
本文件概述了保留域名用于特殊用途的适当情况，以及IANA记录该特殊用途域名的程序。任何请求此类特殊用途域名的文件都需要包含一个适当的“安全注意事项”部分，该部分描述了与该特殊用途相关的任何安全问题。
IANA has created a new registry of Special-Use Domain Names, initially populated with the private-address reverse-mapping domains and the Reserved Top Level DNS Names outlined above in Section 6.
IANA已经创建了一个新的特殊用途域名注册中心，最初由专用地址反向映射域和上文第6节中概述的保留顶级DNS名称填充。
When IANA receives a request to record a new "Special-Use Domain Name", it should verify, in consultation with the IESG, that the IETF "Standards Action" or "IESG Approval" document [RFC5226] includes the required "Domain Name Reservation Considerations" section stating how the special meaning of this name affects the behavior of hardware, software, and humans in the seven categories. If IANA and the IESG determine that special handling of this "Special-Use Domain Name" is appropriate, IANA should record the Special-Use Domain Name, and a reference to the specification that documents it, in the registry.
当IANA收到记录新“特殊用途域名”的请求时，应与IESG协商，核实IETF“标准行动”或“IESG批准”文件[RFC5226]包括规定的“域名保留注意事项”部分，说明该名称的特殊含义如何影响硬件行为，软件和七类人。如果IANA和IESG确定对该“特殊用途域名”的特殊处理是适当的，IANA应在注册中心记录该特殊用途域名以及对记录该域名的规范的引用。
[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月。
[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月。
[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月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[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月。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.
[RFC5771]Cotton，M.，Vegoda，L.，和D.Meyer，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 57712010年3月。
Authors' Addresses
作者地址
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krocmal Apple Inc.美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
Phone: +1 408 974 4368
EMail: marc@apple.com
Phone: +1 408 974 4368
EMail: marc@apple.com