Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 8244 Nominum, Inc.
Category: Informational R. Droms
ISSN: 2070-1721
W. Kumari
Google
October 2017
Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 8244 Nominum, Inc.
Category: Informational R. Droms
ISSN: 2070-1721
W. Kumari
Google
October 2017
Special-Use Domain Names Problem Statement
特殊用途域名问题声明
Abstract
摘要
The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.
根据经验，RFC 6761中为“特殊用途域名”注册处的IANA注册定义的政策已被证明会带来RFC 6761编写时未预料到的挑战。这份备忘录列出了一份全面的清单，列出了此后发现的问题。此外，它还回顾了域名的历史，总结了当前的IETF出版物以及其他组织与特殊用途域名相关的一些出版物。
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.
对于希望就特殊用途域名主题发表知情意见的IETF参与者，本文件应视为必读。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8244.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8244.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems Associated with Special-Use Domain Names . . . . . . 4
4. Existing Practice regarding Special-Use Domain Names . . . . 10
4.1. Primary Special-Use Domain Name Documents . . . . . . . . 10
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10
4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 12
4.1.3. MoU Concerning the Technical Work of IANA . . . . . . 13
4.1.4. Liaison Statement on Technical Use of Domain Names . 14
4.1.5. IAB Statement on the Registration of Special Use
Names in the ARPA Domain . . . . . . . . . . . . . . 15
4.2. Secondary Documents Relating to the Special-Use Domain
Name Question . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 15
4.2.2. The '.onion' Special-Use Top-Level Domain Name . . . 16
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 16
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 17
4.2.5. SSAC Advisory on the Stability of the Domain
Namespace . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis . . . . . . . . . . . . . . . . . . . . . . 17
4.2.7. Additional Reserved Top-Level Domains . . . . . . . . 18
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Informative References . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems Associated with Special-Use Domain Names . . . . . . 4
4. Existing Practice regarding Special-Use Domain Names . . . . 10
4.1. Primary Special-Use Domain Name Documents . . . . . . . . 10
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10
4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 12
4.1.3. MoU Concerning the Technical Work of IANA . . . . . . 13
4.1.4. Liaison Statement on Technical Use of Domain Names . 14
4.1.5. IAB Statement on the Registration of Special Use
Names in the ARPA Domain . . . . . . . . . . . . . . 15
4.2. Secondary Documents Relating to the Special-Use Domain
Name Question . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 15
4.2.2. The '.onion' Special-Use Top-Level Domain Name . . . 16
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 16
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 17
4.2.5. SSAC Advisory on the Stability of the Domain
Namespace . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis . . . . . . . . . . . . . . . . . . . . . . 17
4.2.7. Additional Reserved Top-Level Domains . . . . . . . . 18
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Informative References . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
One of the key services required to use the Internet is name resolution. Name resolution is the process of translating a symbolic name into some object or set of objects to which the name refers, most typically one or more IP addresses. These names are often referred to as "domain names". When reading this document, care must be taken not to assume that the term domain name implies the use of the Domain Name System [RFC1034] for resolving these names. An excellent presentation on this topic can be found in Domain Names [DOMAIN-NAMES].
使用Internet所需的关键服务之一是名称解析。名称解析是将符号名称转换为名称所指的某个对象或对象集的过程，最典型的是一个或多个IP地址。这些名称通常被称为“域名”。阅读本文档时，必须注意不要假设术语域名意味着使用域名系统[RFC1034]解析这些名称。在域名[域名]中可以找到关于这一主题的精彩介绍。
"Special-Use Domain Names" [RFC6761] created the "Special-Use Domain Names" IANA registry [SDO-IANA-SUDR], defined policies for adding to the registry, and made some suggestions about how those policies might be implemented. Since the publication of RFC 6761, the IETF has been asked to designate several new Special-Use Domain Names in this registry. During the evaluation process for these Special-Use Domain Names, the IETF encountered several different sorts of issues. Because of this, the IETF has decided to investigate the problem and decide if and how the process defined in RFC 6761 can be improved, or whether it should be deprecated. The IETF DNSOP Working Group charter was extended to include conducting a review of the process for adding names to the registry that is defined in RFC 6761. This document is a product of that review.
“特殊用途域名”[RFC6761]创建了“特殊用途域名”IANA注册表[SDO-IANA-SUDR]，定义了添加到注册表的策略，并就如何实施这些策略提出了一些建议。自RFC 6761发布以来，IETF已被要求在此注册表中指定几个新的特殊用途域名。在这些特殊用途域名的评估过程中，IETF遇到了几种不同的问题。因此，IETF决定调查该问题，并决定是否以及如何改进RFC 6761中定义的流程，或者是否应弃用该流程。IETF DNSOP工作组章程被扩展，包括对RFC 6761中定义的向注册中心添加名称的过程进行审查。本文件是该审查的结果。
Based on current ICANN and IETF practice, including RFC 6761, there are several different types of names in the root of the Domain Namespace:
根据当前ICANN和IETF实践，包括RFC 6761，域名空间的根目录中有几种不同类型的名称：
o Names reserved by the IETF for technical purposes
o IETF为技术目的保留的名称
o Names assigned by ICANN to the public DNS root; some names reserved by the IETF for technical purposes may appear in the global DNS root for reasons pertaining to the operation of the DNS
o ICANN分配给公共DNS根目录的名称；出于与DNS操作相关的原因，IETF为技术目的保留的一些名称可能会出现在全局DNS根目录中
o ICANN Reserved Names; names that may not be applied for as TLDs (see "Reserved Names" and "Treatment of Country or Territory Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of [SDO-ICANN-DAG]).
o ICANN保留名称；不适用于TLD的名称（参见[SDO-ICANN-DAG]的“保留名称”和“国家或地区名称的处理”（分别第2.2.1.2.1节和第2.2.1.4.1节）。
o Names used by other organizations without following established processes
o 未遵循既定流程的其他组织使用的名称
o Names that are unused and are available for assignment to one of the previous categories
o 未使用的名称，可分配给以前的类别之一
This document presents a list, derived from a variety of sources, including discussion in the IETF DNSOP Working Group, of the problems associated with the assignment of Special-Use Domain Names. The list is intended to be an unfiltered compilation of issues. In support of its analysis of the particular set of issues described here, the document also includes descriptions of existing practice as it relates to the use of domain names, a brief history of domain names, and some observations by various IETF participants who have experience with various aspects of the current situation.
本文件提供了一份列表，该列表来源于各种来源，包括IETF DNSOP工作组中的讨论，列出了与特殊用途域名分配相关的问题。该清单旨在对问题进行未经过滤的汇编。为了支持其对此处所述特定问题集的分析，本文件还包括与域名使用相关的现有实践说明、域名简史以及具有当前情况各方面经验的IETF参与者的一些观察结果。
This document uses the terminology from RFC 7719 [RFC7719]. Other terms used in this document are defined here:
本文件使用RFC 7719[RFC7719]中的术语。本文件中使用的其他术语定义如下：
Domain Name: This document uses the term "domain name" as defined in Section 2 of RFC 7719 [RFC7719].
域名：本文件使用RFC 7719[RFC7719]第2节中定义的术语“域名”。
Domain Namespace: The set of all possible domain names.
域名空间：所有可能的域名的集合。
Special-Use Domain Name: A domain name listed in the "Special-Use Domain Names" registry [SDO-IANA-SUDR].
特殊用途域名：列在“特殊用途域名”注册表[SDO-IANA-SUDR]中的域名。
For the sake of brevity, this document uses some abbreviations, which are expanded here:
为简洁起见，本文件使用了一些缩写，并在此处展开：
IANA: Internet Assigned Numbers Authority
IANA：互联网分配号码管理局
ICANN: Internet Corporation for Assigned Names and Numbers
ICANN：互联网名称和号码分配公司
TLD: Top-Level Domain, as defined in Section 2 of RFC 7719 [RFC7719]
TLD：顶级域，如RFC 7719[RFC7719]第2节所定义
gTLD: Generic Top-Level Domain (see Section 2 of RFC 2352 [RFC2352])
gTLD：通用顶级域（参见RFC 2352[RFC2352]第2节）
This section presents a list of problems that have been identified with respect to the assignment of Special-Use Domain Names. Solutions to these problems, including their costs or trade-offs, are out of scope for this document and will be covered in a separate document. New problems that might be created in the process of solving problems described in this document are also out of scope: these problems are expected to be addressed in the process of evaluating potential solutions.
本节列出了与特殊用途域名分配相关的问题清单。这些问题的解决方案（包括其成本或权衡）不在本文件范围内，将在单独的文件中介绍。在解决本文件所述问题的过程中可能产生的新问题也超出了范围：这些问题预计将在评估潜在解决方案的过程中解决。
Special-Use Domain Names exist to solve a variety of problems. This document has two goals: enumerate all of the problems that have been identified to which Special-Use Domain Names are a solution and enumerate all of the problems that have been raised in the process of trying to use RFC 6761 as it was intended. As some of those problems may fall into both categories, this document makes no attempt to categorize the problems.
专门使用域名可以解决各种问题。本文档有两个目标：列举已确定的特殊用途域名解决方案的所有问题，以及在尝试按预期使用RFC 6761的过程中提出的所有问题。由于其中一些问题可能属于这两类，本文件不尝试对这些问题进行分类。
There is a broad diversity of opinion about this set of problems. Not every participant agrees that each of the problems enumerated in this document is actually a problem. This document takes no position on the relative validity of the various problems that have been enumerated, nor on the organization responsible for addressing each individual problem, if it is to be addressed. This document only enumerates the problems, provides the reader with context for thinking about them, and provides a context for future discussion of solutions, regardless of whether such solutions may work for IETF, ICANN, IANA, or some other group.
对这一系列问题有着广泛的不同意见。并非所有参与者都同意本文件中列举的每一个问题实际上都是一个问题。本文件对所列举的各种问题的相对有效性不采取任何立场，也不对负责解决每一个问题的组织（如果需要解决的话）采取任何立场。本文件仅列举问题，为读者提供思考问题的背景，并为解决方案的未来讨论提供背景，无论此类解决方案是否适用于IETF、ICANN、IANA或其他组织。
The list of problems is not presented in order of importance; numbers are assigned so that each problem can easily be referenced by number, not to indicate priority. The list of problems is as follows:
问题清单未按重要性顺序列出；分配数字是为了使每个问题都能很容易地被数字引用，而不是表示优先级。问题清单如下：
1. Although the IETF and ICANN have a liaison relationship through which special-use allocations can be discussed, there exists no formal process for coordinating these allocations (see Section 4.1.3). The lack of coordination complicates the management of the root of the Domain Namespace and could lead to conflicts in name assignments [SDO-ICANN-SAC090].
1. 尽管IETF和ICANN之间存在联络关系，可以通过联络关系讨论特殊用途分配，但不存在协调这些分配的正式流程（见第4.1.3节）。缺乏协调会使域名称空间根的管理复杂化，并可能导致名称分配冲突[SDO-ICANN-SAC090]。
2. There is no explicit scoping as to what can constitute a "technical use" [RFC2860] and what cannot; there is also no consensus within the IETF as to what this term means.
2. 对于什么可以构成“技术用途”[RFC2860]，什么不能，没有明确的范围界定；IETF内部也没有就这个术语的含义达成共识。
3. Not all developers of protocols on the Internet agree that authority over the entire Domain Namespace should reside solely with the IETF and ICANN.
3. 并非所有互联网协议的开发者都同意，整个域名空间的权限应仅由IETF和ICANN拥有。
4. Although the IETF and ICANN nominally have authority over this namespace, neither organization can enforce that authority over any third party who wants to just start using a subset of the namespace. Such parties may observe that the IETF has never asserted control or authority over what protocols are "allowed" on the Internet, and that the principle of "permissionless innovation" suggests there should be a way for people to include new uses of domain names in new protocols and applications.
4. 尽管IETF和ICANN名义上拥有对该名称空间的权限，但两个组织都不能对任何想要开始使用该名称空间子集的第三方强制执行该权限。这些缔约方可能会注意到，IETF从未声称对互联网上“允许”的协议拥有控制权或权威，而且“无许可创新”原则表明，人们应该有一种方法将域名的新用途包括在新协议和应用中。
5. Organizations do in fact sometimes use subsets of the Domain Namespace without following established processes. Reasons a third party might do this include:
5. 事实上，组织有时确实使用域命名空间的子集，而不遵循已建立的流程。第三方这样做的原因包括：
1. Lack of knowledge that a process exists for assigning such names.
1. 不知道存在分配此类名称的流程。
2. Intended use is covered by the gTLD process [SDO-ICANN-DAG], but no gTLD process is ongoing.
2. gTLD流程[SDO-ICANN-DAG]涵盖了预期用途，但没有正在进行的gTLD流程。
3. Intended use is covered by the gTLD process, but the third party doesn't want to pay a fee.
3. gTLD流程涵盖预期用途，但第三方不想支付费用。
4. Intended use is covered by some IETF process, but the third party doesn't want to follow the process.
4. 某些IETF流程涵盖了预期用途，但第三方不希望遵循该流程。
5. Intended use is covered by an ICANN or IETF process, but the third party expects that the outcome will be refusal or non-action.
5. ICANN或IETF流程涵盖预期用途，但第三方预期结果将是拒绝或不采取行动。
6. Lack of knowledge that a name intended to be used only locally may nevertheless leak.
6. 不知道仅在本地使用的名称可能会泄漏。
7. Lack of knowledge that a name used locally with informal allocation may subsequently be allocated formally, creating operational problems.
7. 不知道本地非正式分配使用的名称可能随后被正式分配，从而造成操作问题。
6. There is demand for more than one name resolution protocol for domain names. Domain names contain no metadata to indicate which protocol to use to resolve them. Domain name resolution APIs do not provide a way to specify which protocol to use.
6. 对于域名，需要不止一个名称解析协议。域名不包含元数据来指示使用哪个协议来解析它们。域名解析API不提供指定使用哪个协议的方法。
7. When a Special-Use Domain Name is added to the "Special-Use Domain Names" registry, not all software that processes such names will understand the special use of that name. In many cases, name resolution software will use the Domain Name System for resolution of names not known to have a special use. Consequently, any such use will result in queries for Special-Use Domain Names being sent to Domain Name System authoritative servers. These queries may constitute an operational problem for operators of root zone authoritative name servers. These queries may also inadvertently reveal private information through the contents of the query, which is a privacy consideration.
7. 当特殊用途域名被添加到“特殊用途域名”注册表时，并非所有处理此类名称的软件都会理解该名称的特殊用途。在许多情况下，名称解析软件将使用域名系统解析不具有特殊用途的名称。因此，任何此类使用都将导致向域名系统权威服务器发送对特殊用途域名的查询。这些查询可能会对根区域权威名称服务器的操作员造成操作问题。这些查询还可能无意中通过查询内容泄露私人信息，这是出于隐私考虑。
8. Some protocol developers have assumed that they could not succeed in getting a name assigned through the IETF using the process defined in RFC 6761. This is because when the IETF has attempted to follow the process defined in RFC 6761, it has been slow and uncertain. For example, the process of assigning the first new name ('.local') using the process defined in RFC 6761 took more than ten years from beginning to end: longer by a factor of ten than any other part of the protocol development process (largely because this ten years included time to develop the process as well as use it). Other uses of the process have proceeded more smoothly, but there is a reasonably justified perception that using this process is likely to be slow and difficult, with an uncertain outcome.
8. 一些协议开发人员认为，他们无法使用RFC 6761中定义的过程通过IETF成功地获得分配的名称。这是因为当IETF试图遵循RFC 6761中定义的过程时，其速度缓慢且不确定。例如，使用RFC 6761中定义的流程分配第一个新名称（“.local”）的过程从开始到结束花费了十多年：比协议开发过程的任何其他部分都要长十倍（主要是因为这十年包括开发和使用流程的时间）。该过程的其他应用进展更为顺利，但有一种合理的看法，即使用该过程可能缓慢而困难，结果不确定。
9. There is strong resistance within the IETF to assigning domain names to resolution systems outside of the DNS, for a variety of reasons:
9. IETF内部强烈抵制将域名分配给DNS之外的解析系统，原因有多种：
1. It requires a mechanism for identifying which set of resolution processes is required in order to resolve a particular name.
1. 它需要一种机制来识别解析特定名称所需的解析过程集。
2. Assertion of authority: there is a sense that the Domain Namespace is "owned" by the IETF or by ICANN, so, if a name is claimed without following their processes, the person or entity that claimed that name should suffer some consequence that would, presumably, deter future circumvention of the official processes.
2. 权威声明：有一种感觉是，域名名称空间由IETF或ICANN“拥有”，因此，如果在未遵循其流程的情况下声明某个名称，则声明该名称的个人或实体应遭受某种后果，这可能会阻止未来对官方流程的规避。
3. More than one name resolution protocol is bad, in the sense that a single protocol is less complicated to implement and deploy.
3. 多个名称解析协议是不好的，因为单个协议的实现和部署不那么复杂。
4. The semantics of alternative resolution protocols may differ from the DNS protocol; DNS has the concept of RRtypes, whereas other protocols may not support RRtypes or may support some entirely different data structuring mechanism.
4. 备选解析协议的语义可能不同于DNS协议；DNS具有RRTYPE的概念，而其他协议可能不支持RRTYPE，或者可能支持一些完全不同的数据结构机制。
5. If there is an IETF process through which a TLD can be assigned at zero cost other than time, this process will be used as an alternative to the more costly process of getting the name registered through ICANN.
5. 如果存在一个IETF流程，通过该流程可以以零成本（时间除外）分配TLD，则该流程将被用作通过ICANN注册名称这一成本更高的流程的替代方案。
6. A name might be assigned for a particular purpose when a more general use of the name would be more beneficial.
6. 当一个名字的更普遍的使用会更有益时，可以为一个特定的目的指定一个名字。
7. If the IETF assigns a name that some third party or parties believe belongs to them in some way, the IETF could become embroiled in an expensive dispute with those parties.
7. 如果IETF指定了一个或多个第三方认为以某种方式属于他们的名称，IETF可能会卷入与这些第三方的昂贵纠纷。
10. If there were no process for assigning names for technical use through the IETF, there is a concern that protocols that require such names would not be able to get them.
10. 如果没有通过IETF为技术用途分配名称的过程，那么需要此类名称的协议将无法获得这些名称。
11. In some cases where the IETF has made assignments through the process defined in RFC 6761, technical mistakes have been made due to misunderstandings as to the actual process that RFC 6761 specifies (e.g., treating the list of suggested considerations for assigning a name as a set of requirements, all of which must be met). In other cases, the IETF has made de facto assignments of Special-Use Domain Names without following the process in RFC 6761 (see [RFC7050] and [RFC7788]).
11. 在某些情况下，IETF通过RFC 6761中定义的过程进行分配，由于对RFC 6761规定的实际过程的误解，出现了技术错误（例如，将分配名称的建议注意事项列表视为一组要求，必须满足所有要求）。在其他情况下，IETF未遵循RFC 6761中的流程（参见[RFC7050]和[RFC7788]），对特殊用途域名进行了事实上的分配。
12. There are several Top-Level Domain Names that are in use without due process for a variety of purposes. The status of these names need to be clarified and recorded to avoid future disputes about their use [SDO-ICANN-COLL].
12. 有几个顶级域名未经正当程序就被用于各种目的。需要对这些名称的状态进行澄清和记录，以避免将来对其使用产生争议[SDO-ICANN-COLL]。
13. In principle, the process defined in RFC 6761 could be used to document the existence of domain names that are not safe to assign and provide information on how those names are used in practice. However, attempts to use RFC 6761 to accomplish this documentation have not been successful (for example, see "Additional Reserved Top Level Domains" [RESERVED-TLDS] and Section 4.2.7 of this document). One side effect of the lack of documentation is that any mitigation effect on the root name servers or on privacy considerations has been missed.
13. 原则上，RFC 6761中定义的过程可用于记录不安全分配域名的存在，并提供有关这些名称在实践中如何使用的信息。然而，使用RFC 6761完成本文档的尝试并未成功（例如，请参阅“其他保留顶级域”[Reserved-TLD]和本文档第4.2.7节）。缺少文档的一个副作用是忽略了对根名称服务器或隐私考虑的任何缓解效果。
14. A domain name can be identified as either a DNS name by placing it in the DNS zone(s) or a Special-Use Domain Name by adding it to the IANA registry. Some names are in both places; for example, some locally served zone names are in DNS zones and documented in the "Special-Use Domain Names" registry. At present, the only way a domain name can be added to the "Special-Use Domain Name" registry is for the IETF to take responsibility for the name and designate it for "technical use". There are other potential uses for domain names that should be recorded in the registry, but for which the IETF should not take responsibility.
14. 域名可以通过将其放置在DNS区域来标识为DNS名称，也可以通过将其添加到IANA注册表来标识为特殊用途域名。有些名字在两个地方；例如，一些本地服务的区域名称位于DNS区域中，并记录在“特殊用途域名”注册表中。目前，将域名添加到“特殊用途域名”登记册的唯一方法是由IETF负责该名称并指定其为“技术用途”。域名还有其他潜在用途，应记录在注册中心，但IETF不应对此负责。
15. In some cases, the IETF may see the need to document that a name is in use without claiming that the use of the name is the IETF's particular use of the name. No mechanism exists in the current registry to mark names in this way.
15. 在某些情况下，IETF可能认为有必要记录某个名称正在使用，而不声称该名称的使用是IETF对该名称的特定使用。当前注册表中不存在以这种方式标记名称的机制。
16. During any of the review stages of a document, there is no formal process in which a check is made to ensure that the document does not unintentionally violate the IETF process for adding Special-Use Domain Names to the registry, as was the case, for example, in RFC 7788 [RFC7788].
16. 在文件的任何审查阶段，没有进行检查以确保文件不会无意中违反IETF向注册中心添加特殊用途域名的流程的正式流程，例如RFC 7788[RFC7788]中的情况。
17. Use of the registry is inconsistent -- some Special-Use Domain Name RFCs specifically add registry entries, some don't; some specify how and whether special-use name delegations should be done, some don't.
17. 注册表的使用是不一致的——一些专门使用域名的RFC专门添加注册表项，一些不添加注册表项；有些指定了如何以及是否应该进行特殊使用名称委托，有些则没有。
18. There exists no safe, non-process-violating mechanism for ad hoc assignment of Special-Use Domain Names.
18. 对于特殊用途域名的临时分配，不存在安全、不违反进程的机制。
19. It is generally assumed that protocols that need a Special-Use Domain Name need a mnemonic, single-label, human-readable Special-Use Domain Name for use in user interfaces such as command lines or URL entry fields. While this assumption is correct in some cases, it is likely not correct in all cases, for example, in applications where the domain name is never visible to a user.
19. 通常假设需要特殊用途域名的协议需要一个助记符、单标签、人类可读的特殊用途域名，以便在命令行或URL输入字段等用户界面中使用。虽然这种假设在某些情况下是正确的，但可能并非在所有情况下都是正确的，例如，在用户永远看不到域名的应用程序中。
20. RFC 6761 uses the term "domain name" to describe the thing for which special uses are registered. This creates a great deal of confusion because some readers take "domain name" to imply the use of the DNS protocol.
20. RFC6761使用术语“域名”来描述注册特殊用途的事物。这造成了很大的混乱，因为一些读者认为“域名”意味着使用DNS协议。
21. The use of DNSSEC with Special-Use Domain Names is an open issue. There is no consensus or guidance about how to use DNSSEC with various classes of Special-Use Domain Names. Considerations in the use of DNSSEC with Special-Use Domain Names include:
21. 将DNSSEC与专用域名一起使用是一个悬而未决的问题。关于如何将DNSSEC与各类特殊用途域名一起使用，目前尚无共识或指导。将DNSSEC与专用域名一起使用时的注意事项包括：
1. What class of Special-Use Domain Name is under consideration: non-DNS, locally served zone, or other?
1. 正在考虑哪类特殊用途域名：非DNS、本地服务区或其他？
2. Does the Special-Use Domain Name require a delegation in the root zone; if so, should that delegation be signed or not? If there is no delegation, then this will be treated by validating resolvers as a secure denial of existence for that zone. This would not be appropriate for a name being resolved using the DNS protocol.
2. 特殊用途域名是否需要在根区域进行授权；如果是，该代表团是否应该签字？如果没有委派，那么将通过验证解析程序将其视为该区域的安全拒绝存在。这不适用于使用DNS协议解析的名称。
3. A process would be required through which the IETF can cause a delegation in the root zone to be instantiated.
3. 需要一个过程，通过该过程IETF可以实例化根区域中的委托。
4. What are the recommended practices for using DNS with the specific Special-Use Domain Name?
4. 在特定的专用域名中使用DNS的推荐做法是什么？
The above list represents the current understanding of the authors as to the complete set of problems that have been identified during discussion by the working group on this topic. The remainder of this document provides additional context that will be needed for reasoning related to these problems.
上述清单代表了作者目前对工作组在讨论这一专题期间确定的一整套问题的理解。本文档的其余部分提供了与这些问题相关的推理所需的其他上下文。
There are three primary (see Section 4.1) and numerous secondary (Section 4.2) documents to consider when thinking about the Special-Use Domain Names process.
有三个主要（见第4.1节）和许多次要（第4.2节）文件，当考虑特殊用途域名处理时要考虑。
How names are resolved is ambiguous, in the sense that some names are Special-Use Domain Names that require special handling and some names can be resolved using the DNS protocol with no special handling.
如何解析名称是不明确的，因为有些名称是需要特殊处理的专用域名，有些名称可以使用DNS协议解析，而无需特殊处理。
The assignment of Internet Names is not under the sole control of any one organization. The IETF has authority in some cases, but only with respect to "technical uses". At present, ICANN is the designated administrator of the root zone; but generally not of zones other than the root zone. Neither of these authorities can, in any practical sense, exclude the practice of ad hoc use of names. Unauthorized use of domain names can be accomplished by any entity that has control over one or more name servers or resolvers, in the context of any hosts and services that entity operates. It can also be accomplished by authors of software who decide that a Special-Use Domain Name is the right way to indicate the use of an alternate resolution mechanism.
互联网名称的分配不受任何一个组织的单独控制。IETF在某些情况下具有权限，但仅限于“技术用途”。目前，ICANN是根区域的指定管理员；但通常不包括根区域以外的区域。在任何实际意义上，这两个当局都不能排除临时使用姓名的做法。未经授权使用域名可以由控制一个或多个名称服务器或解析程序的任何实体在该实体运行的任何主机和服务的上下文中完成。它也可以由软件作者完成，他们认为特殊用途域名是指示使用替代解析机制的正确方式。
The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice.
主要文件被视为主要文件，因为它们以一般方式直接阐述了IETF过去对该主题的想法，也因为它们描述了IETF在实践中所做的事情。
[RFC2826] is not an IETF consensus document, and it appears to have been written to address a different problem than the Special-Use Domain Name problem. However, it speaks directly to several of the key issues that must be considered, and, coming as it does from the IAB, it is rightly treated as having significant authority despite not being an IETF consensus document.
[RFC2826]不是IETF共识文件，它似乎是为了解决与特殊用途域名问题不同的问题而编写的。然而，它直接涉及到必须考虑的几个关键问题，并且，正如它来自IAB一样，它被正确地视为具有重要的权威性，尽管它不是IETF共识文件。
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names. The main points that appear relevant to the Special-Use Domain Names problem are:
对于希望就特殊用途域名主题发表知情意见的IETF参与者，本文件应视为必读。与特殊用途域名问题相关的要点如下：
o The Internet requires a globally unique namespace: a namespace in which any given name refers to the same information (has the same meaning) no matter who requests that information and no matter from which specific name server they request it.
o Internet需要一个全局唯一的名称空间：一个名称空间，其中任何给定的名称都引用相同的信息（具有相同的含义），无论是谁请求该信息，也不管他们从哪个特定的名称服务器请求该信息。
o Private networks may operate private namespaces, with names that have meanings only locally (within the private network), but they still require that names in the public namespace be globally unique.
o 专用网络可以运行专用名称空间，其名称仅在本地（专用网络内）具有含义，但它们仍然要求公共名称空间中的名称是全局唯一的。
o The Domain Name System [RFC1035] is not the only protocol that may be used for resolving domain names.
o 域名系统[RFC1035]不是可用于解析域名的唯一协议。
o Users cannot be assumed to know how to distinguish between symbolic references that have local meaning and references that have global meaning. Therefore, users may share references that incorporate domain names with no global meaning (for example, a URL of 'http://mysite.example.corp', where 'example.corp' is a domain used privately and informally as described in [SDO-ICANN-COLL]).
o 不能假设用户知道如何区分具有局部意义的符号引用和具有全局意义的引用。因此，用户可以共享包含没有全局意义的域名的引用（例如，URL'http://mysite.example.corp，其中“example.corp”是[SDO-ICANN-COLL]中所述的私人和非正式使用的域名。
o While such a reference in the user's context refers to the object the user wishes to share, when the reference is used in a different context, it could refer either to some different object in the recipient's context or to no object at all. The effect of this reference escaping the context in which it is valid is that the user's intended communication will not be able to be understood by the recipients of the communication.
o 虽然用户上下文中的此类引用指的是用户希望共享的对象，但当引用在不同上下文中使用时，它可能指的是收件人上下文中的某个不同对象，也可能根本不指任何对象。此引用脱离其有效的上下文的效果是，通信的接收者将无法理解用户的预期通信。
This same problem can also occur when a single user copies a name from one context in which it has one meaning into a different context in which it has a different meaning -- for example, copying a '.onion' domain name out of a Tor Browser [TOR], where it has meaning, and pasting this name into an SSH client that doesn't support connecting over the Tor network.
当单个用户将一个名称从一个具有一种含义的上下文复制到另一个具有不同含义的上下文时，也会出现同样的问题，例如，将“.洋葱”域名从具有含义的Tor浏览器[Tor]中复制出来，并将此名称粘贴到不支持通过Tor网络连接的SSH客户端。
We can summarize the advice in this document as follows:
我们可以将本文件中的建议总结如下：
o Domain names with unambiguous global meaning are preferable to domain names with local meaning that will be ambiguous. Nevertheless, both globally meaningful and locally special names are in use and must be supported.
o 具有明确全局含义的域名比具有模糊局部含义的域名更可取。然而，全球意义的名称和本地特殊名称都在使用，必须得到支持。
o At the time of the writing of this document, the IAB was of the opinion that there might well be more than one name resolution protocol used to resolve domain names.
o 在编写本文件时，IAB认为可能有不止一个名称解析协议用于解析域名。
The second important document is "Special-Use Domain Names" [RFC6761]. RFC 6761 represents the current IETF consensus on designating and recording Special-Use Domain Names. The IETF has experienced problems with the designation process described in RFC 6761; these concerns motivate this document. Familiarity with RFC 6761 is a prerequisite for having an informed opinion on the topic of Special-Use Domain Names.
第二个重要文件是“特殊用途域名”[RFC6761]。RFC 6761代表了当前IETF关于指定和记录特殊用途域名的共识。IETF在RFC 6761中描述的指定过程中遇到问题；这些关切促使编写本文件。熟悉RFC 6761是对特殊用途域名主题发表知情意见的先决条件。
RFC 6761 defines two aspects of Special-Use Domain Names: designating a domain name to have a special purpose and registering that special use in the "Special-Use Domain Names" registry. The designation process is defined in a single sentence (RFC 6761, Section 4):
RFC 6761定义了特殊用途域名的两个方面：指定具有特殊用途的域名和在“特殊用途域名”注册中心注册该特殊用途。指定过程在一句话中定义（RFC 6761，第4节）：
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]。
This sentence requires that any designation of a Special-Use Domain Name is subject to the same open review and consensus process as used to produce and publish all other IETF specifications.
本句要求，任何特殊用途域名的指定都应遵循与生成和发布所有其他IETF规范相同的公开审查和协商一致过程。
The registration process is a purely mechanical process, in which the existence of the newly designated Special-Use Domain Name is recorded, with a pointer to a section in the relevant specification document that defines the ways in which special handling is to be applied to the name.
注册过程是一个纯粹的机械过程，其中记录了新指定的特殊用途域名的存在，指针指向相关规范文件中的一个部分，该部分定义了对该名称应用特殊处理的方式。
RFC 6761 provides the process whereby "Multicast DNS" [RFC6762] designated '.local' as a Special-Use Domain Name and included it in the "Special-Use Domain Names" registry. RFC 6761 also enumerates a set of names that were previously used or defined to have special uses prior to its publication. Since there had been no registry for these names prior to the publication of RFC 6761, the documents defining these names could not have added them to the registry.
RFC 6761提供了一个过程，“多播DNS”[RFC6762]将“.local”指定为特殊用途域名，并将其包含在“特殊用途域名”注册表中。RFC 6761还列举了一组名称，这些名称在发布之前曾被使用或定义为具有特殊用途。由于在RFC 6761出版之前，这些名称没有登记册，因此定义这些名称的文件不可能将其添加到登记册中。
Several important points to think about with respect to RFC 6761 are:
关于RFC 6761，需要考虑的几个要点是：
o A Special-Use Domain Name may be a name that should be resolved using the DNS protocol with no special handling. An example of this is 'in-addr.arpa' (which is an example of a Special-Use Domain Name that is not a TLD).
o 特殊用途域名可以是应使用DNS协议解析的名称，无需特殊处理。例如“in addr.arpa”（这是一个非TLD的特殊用途域名的示例）。
o A Special-Use Domain Name may be a name that is resolved using the DNS protocol and that requires no special handling in the stub resolver but that requires special handling in the recursive resolver. An example of this would be '10.in-addr.arpa.'.
o 特殊用途域名可以是使用DNS协议解析的名称，不需要在存根解析程序中进行特殊处理，但需要在递归解析程序中进行特殊处理。例如“10.in addr.arpa”。
o A Special-Use Domain Name may be a name that requires special handling in the stub resolver. An example would be a Special-Use Top-Level Domain Name like '.local', which acts as a signal to indicate that the local stub resolver should use a non-DNS protocol for name resolution.
o 特殊用途域名可能是需要在存根解析程序中进行特殊处理的名称。例如，一个特殊用途的顶级域名，如“.local”，它充当一个信号，指示本地存根解析器应使用非DNS协议进行名称解析。
o The current IETF consensus (from a process perspective, not necessarily from the perspective of what would be consensus if the IETF were to attempt to produce a new consensus document) is that all of these purposes for Special-Use Domain Names are valid.
o 当前的IETF共识（从过程的角度来看，如果IETF试图产生新的共识文件，不一定是从共识的角度来看）是所有这些特殊用途域名的目的都是有效的。
In this case, the term "stub resolver" does not mean "DNS protocol stub resolver". The stub resolver is the entity within a particular software stack that takes a question about a domain name and answers it. One way a stub resolver can answer such a question is using the DNS protocol; however, it is in the stub resolver (as we are using the term here) that the decision as to whether to use a protocol (and if so, which protocol) or a local database of some sort is made.
在这种情况下，术语“存根解析器”并不意味着“DNS协议存根解析器”。存根解析器是特定软件堆栈中的实体，它接受有关域名的问题并回答该问题。存根解析器回答此类问题的一种方法是使用DNS协议；然而，在存根解析器（正如我们在这里使用的术语）中，决定是否使用协议（如果是，使用哪个协议）或某种本地数据库。
RFC 6761 does not limit Special-Use Domain Names to TLDs. However, at present, all Special-Use Domain Names registered in the "Special-Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be resolved using the DNS protocol, are TLDs, or are both. That is, at present there exist no Special-Use Domain Names that require special handling by stub resolvers and which are not at the top level of the naming hierarchy.
RFC 6761不将特殊用途域名限制为TLD。然而，目前，在“特殊用途域名”注册处[SDO-IANA-SUDR]注册的所有特殊用途域名要么打算使用DNS协议解析，要么是TLD，要么两者都是。也就是说，目前不存在需要存根解析程序进行特殊处理且不在命名层次结构顶层的特殊用途域名。
One point to take from this is that there is already a requirement in RFC 6762 that when a stub resolver encounters the special label, 'local' as the rightmost label of a domain name, it can only use the Multicast DNS (mDNS) protocol to resolve that domain name.
需要注意的一点是，RFC 6762中已经有一项要求，即当存根解析程序遇到特殊标签“local”作为域名最右边的标签时，它只能使用多播DNS（mDNS）协议解析该域名。
There exists a Memorandum of Understanding (MoU) [RFC2860] between the IETF and ICANN that discusses how names and numbers will be managed through IANA. This document is important to the discussion of Special-Use Domain Names because, while it delegates authority for managing the DNS Namespace generally to ICANN, it reserves to the IETF the authority that is then formalized in RFC 6761. RFC 2860 specifically states:
IETF和ICANN之间存在一份谅解备忘录（MoU）[RFC2860]，讨论如何通过IANA管理名称和数字。本文件对特殊用途域名的讨论非常重要，因为虽然它将管理DNS名称空间的权限一般委托给ICANN，但它将随后在RFC 6761中正式化的权限保留给IETF。RFC 2860特别指出：
Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4.
请注意，（a）用于技术用途的域名分配（例如用于反向DNS查找的域名），（b）专用地址块的分配（例如多播或选播块），以及（c）实验分配不被视为政策问题，并且应遵守本第4节的规定。
The above text is an addendum to the following:
上述文本是对以下内容的补充：
Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU.
除了IETF规定的技术注意事项外，还有两个特定的分配空间存在政策问题：域名的分配和IP地址块的分配。这些政策问题不在本谅解备忘录的范围内。
The assignment of names in the DNS root zone, and the management of the Domain Namespace, is by default a function that is performed by ICANN. However, the MoU specifically exempts domain names assigned for technical use and uses the example of domains used for inverse DNS lookup. Both 'in-addr.arpa' and 'ip6.arpa' are in the "Special-Use Domain Names" registry.
DNS根区域中名称的分配和域名空间的管理默认由ICANN执行。然而，谅解备忘录明确豁免了指定用于技术用途的域名，并使用了用于反向DNS查找的域的示例。“in addr.arpa”和“ip6.arpa”都在“特殊用途域名”注册表中。
Implicit in the MoU is the fact that the IETF and ICANN retain, between them, sole authority for assigning any names from the Domain Namespace. Both the IETF and ICANN have internal processes for making such assignments.
谅解备忘录中隐含的事实是，IETF和ICANN之间保留分配域名空间中任何名称的唯一权限。IETF和ICANN都有进行此类分配的内部流程。
The point here is not to say what the implications of this statement in the MoU are, but rather to call the reader's attention to the existence of this statement.
这里的重点不是要说明谅解备忘录中这一声明的含义，而是要提请读者注意这一声明的存在。
When the IETF received processing requests to add names to the "Special-Use Domain Names" registry, as documented in [RESERVED-TLDS] and [P2P-DOMAIN-NAMES], the IETF chartered a review of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The IETF sent a liaison statement [SDO-IAB-ICANN-LS] to ICANN to notify them of the review, affirm that the discussion would be "open and transparent to participation by interested parties", and explicitly invite members of the ICANN community to participate.
当IETF收到向“特殊用途域名”注册中心添加名称的处理请求时，如[RESERVED-TLDS]和[P2P-Domains-names]中所述，IETF特许审查RFC 6761中定义的向注册中心添加名称的过程（如前所述）。IETF向ICANN发送了一份联络声明[SDO-IAB-ICANN-LS]，通知他们审查情况，确认讨论将“对相关方的参与公开透明”，并明确邀请ICANN社区成员参与。
4.1.5. IAB Statement on the Registration of Special Use Names in the ARPA Domain
4.1.5. IAB关于在ARPA领域注册特殊用途名称的声明
As part of the process of resolving the controversy mentioned in Section 4.2.7, the IAB issued a statement saying, in part:
作为解决第4.2.7节所述争议过程的一部分，IAB发布了一份声明，部分内容如下：
There is currently no process defined with ICANN for special use names to be delegated in the root zone; it has seemed likely to take significant effort to create one. The IAB has noted that .arpa can be used "for technical infrastructure established by IETF standards" [SDO-IAB-SUDN-REG].
目前，ICANN没有为根区域中要委派的特殊用途名称定义任何流程；似乎要花很大的努力才能创造一个。IAB指出，.arpa可“用于IETF标准建立的技术基础设施”[SDO-IAB-SUDN-REG]。
Given the lack of an established process with ICANN, IETF documents cannot reserve names in the root of the DNS namespace if those names are to be delegated (that is, used by the DNS protocol). It would be possible to work with ICANN to develop a process for such delegations, but the success of that joint work, and the amount of time it would take, would still be uncertain.
鉴于缺乏与ICANN建立的流程，IETF文档无法在DNS名称空间的根目录中保留名称，如果这些名称要被委派（即，由DNS协议使用）。可以与ICANN合作，为此类代表团制定一个流程，但这项联合工作的成功与否以及所需的时间仍不确定。
4.2. Secondary Documents Relating to the Special-Use Domain Name Question
4.2. 与特殊用途域名问题相关的辅助文件
In addition to these documents, there are several others with which participants in this discussion should be familiar.
除这些文件外，本次讨论的参与者还应熟悉其他一些文件。
Multicast DNS [RFC6762] defines the Multicast DNS protocol, which uses the '.local' Special-Use Top-Level Domain Name. Section 3 describes the semantics of "multicast DNS names". It is of considerable historical importance to note that the -00 version of the document that eventually became RFC 6762, an individual submission, was published in July of 2001. The version posted at that time contains substantially the same text in Section 3 as RFC 6762 did when published and was discussed in the DNSEXT Working Group at IETF 51 in August of 2001 [IETF-PRO-51]. The July 2001 draft designated '.local.arpa' as the Special-Use Domain Name. This idea was strongly opposed by DNSEXT Working Group participants, and as a result, the author eventually switched to using '.local'.
多播DNS[RFC6762]定义多播DNS协议，该协议使用“.local”特殊用途顶级域名。第3节描述了“多播DNS名称”的语义。值得注意的是，该文件的-00版本（最终成为RFC 6762，一份单独提交的文件）于2001年7月发布，具有相当重要的历史意义。当时发布的版本在第3节中包含与RFC 6762发布时基本相同的文本，并于2001年8月在IETF 51上由DNSEXT工作组讨论[IETF-PRO-51]。2001年7月的草案将“.local.arpa”指定为特殊用途域名。这一想法遭到DNSEXT工作组参与者的强烈反对，因此，作者最终改用“.local”。
The history of RFC 6762 is documented in substantial detail in Appendix H of RFC 6762; some notable milestones include the initial proposal to replace AppleTalk's Name Binding Protocol (NBP) in July 1997, the chartering of the Zeroconf Working Group in September 1999, and the assignment of a multicast address for link-local name discovery in April of 2000. A companion requirements document, eventually published as [RFC6760], was first published in September of 2001.
RFC 6762的历史详细记录在RFC 6762附录H中；一些值得注意的里程碑包括1997年7月取代AppleTalk的名称绑定协议（NBP）的初步提议、1999年9月成立Zeroconf工作组以及2000年4月为链路本地名称发现分配多播地址。2001年9月首次发布了一份配套需求文件，最终发布为[RFC6760]。
The point of mentioning these dates is so that discussions involving the time when the '.local' domain was first deployed, and the context in which it was deployed, may be properly informed.
提及这些日期的目的是为了能够正确地告知有关“.local”域首次部署的时间以及部署该域的上下文的讨论。
The '.onion' Special-Use Top-Level Domain Name [RFC7686] is important because it is the most recent IETF action on the topic of Special-Use Domain Names; although it does not set a new policy, the mere fact of its publication is worth thinking about.
“.洋葱”特殊用途顶级域名[RFC7686]非常重要，因为它是IETF针对特殊用途域名主题的最新行动；虽然它没有制定新的政策，但它的公布本身就值得思考。
Two important points to consider about this document are that:
关于这个文件需要考虑的两个要点是：
o The IETF gained consensus to publish it.
o IETF获得了出版它的共识。
o Devising a resolution to the situation was constrained by at least two factors. First, there was no process for allocating Special-Use Domain Names at the time that the '.onion' project started using the name; at the time, and since the scope of use of the name was expected to be very constrained, the developers chose to allocate it unilaterally rather than asking the IETF or some other Standards Development Organization (SDO) to create a new process.
o 制定解决方案至少受到两个因素的制约。首先，“.onion”项目开始使用该名称时，没有分配特殊用途域名的过程；当时，由于名称的使用范围预计会非常有限，开发人员选择单方面分配名称，而不是要求IETF或其他一些标准开发组织（SDO）创建新流程。
Second, for some time, the CA/Browser Forum [SDO-CABF] had been issuing certificates for what they referred to as "internal names". Internal names are names allocated unilaterally for use in site-specific contexts. Issuing certificates for such names came to be considered problematic, since no formal process for testing the validity of such names existed. Consequently, the CA/ Browser Forum decided to phase out the use of such names in certificates [SDO-CABF-INT] and set a deadline after which no new certificates for such names would be issued [SDO-CABF-DEADLINE]. Because the '.onion' domain was allocated unilaterally, this would mean that certificates for subdomains of '.onion' could no longer be issued.
其次，一段时间以来，CA/浏览器论坛[SDO-CABF]一直在为他们所谓的“内部名称”颁发证书。内部名称是单方面分配用于站点特定上下文的名称。为这些名称颁发证书被认为是有问题的，因为没有正式的程序来测试这些名称的有效性。因此，CA/浏览器论坛决定逐步停止在证书[SDO-CABF-INT]中使用此类名称，并设定一个最后期限，在此期限之后，不会为此类名称颁发新的证书[SDO-CABF-DETAILD]。由于“.onion”域是单方面分配的，这意味着“.onion”子域的证书将无法再颁发。
The IETF's designation of '.onion' as a Special-Use Top-Level Domain Name was needed to facilitate the development of a certificate issuance process specific to '.onion' domain names [SDO-CABF-BALLOT144].
IETF需要将“.onion”指定为特殊用途顶级域名，以促进针对“.onion”域名的证书颁发流程的开发[SDO-CABF-BALLOT144]。
"Locally Served DNS Zones" [RFC6303] describes a particular use case for zones that exist by definition and that are resolved using the DNS protocol, but that cannot have a global meaning because the host IP addresses they reference are not unique. This applies to a variety of addresses, including private IPv4 addresses [RFC1918],
“本地服务DNS区域”[RFC6303]描述了根据定义存在并使用DNS协议解析的区域的特定用例，但这些区域不能具有全局含义，因为它们引用的主机IP地址不是唯一的。这适用于各种地址，包括专用IPv4地址[RFC1918]，
"Unique Local IPv6 Unicast Addresses" [RFC4193] (in which this practice was first described), and "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598].
“唯一本地IPv6单播地址”[RFC4193]（首次描述此实践的地方）和“IANA为共享地址空间保留IPv4前缀”[RFC6598]。
This use case is distinct from the use case for Special-Use Domain Names like '.local' and '.onion' in that the names are resolved using the DNS protocol (but they do require extensions or exceptions to the usual DNS resolution to enforce resolution in a local context rather than the global DNS context). It shares the problem that such names can be assumed neither to be unique across all contexts nor functional for all Internet-connected hosts.
此用例与特殊用途域名（如“.local”和“.onion”）的用例不同，因为名称是使用DNS协议解析的（但它们确实需要对常用DNS解析的扩展或例外，以便在本地上下文而不是全局DNS上下文中强制解析）。它也有一个共同的问题，即这样的名称既不能在所有上下文中都是唯一的，也不能对所有连接到Internet的主机起作用。
"Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was commissioned by ICANN in an attempt to characterize the potential risk to the Internet of adding global DNS delegations for names that were not previously delegated in the DNS and were not reserved under any RFC, but were also known to be (in the case of '.home') or surmised to be (in the case of '.corp') in significant use for Special-Use-type reasons (local scope DNS or other resolution protocols altogether).
“DNS中的名称冲突”[SDO-ICANN-COLL]是由ICANN委托进行的一项研究，目的是描述为以前未在DNS中授权且未在任何RFC下保留，但已知为（在“.home”的情况下）或推测为的名称添加全局DNS授权对互联网的潜在风险（在“.corp”的情况下）由于特殊使用类型的原因（本地范围DNS或其他解析协议）被大量使用。
The ICANN Security and Stability Advisory Committee (SSAC) [SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the Domain Namespace" [SDO-ICANN-SAC090] reports on some issues surrounding the conflicting uses, interested parties, and processes related to the Domain Namespace. The specification recommends the development of collaborative processes among the various interested parties to coordinate their activities related to the Domain Namespace.
ICANN安全与稳定咨询委员会（SSAC）[SDO-ICANN-SSAC]规范“域名称空间稳定性的SSAC咨询”[SDO-ICANN-SAC090]报告了与域名称空间相关的冲突使用、相关方和过程相关的一些问题。该规范建议在各相关方之间开发协作流程，以协调其与域名称空间相关的活动。
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050] is an example of a document that successfully used the process in RFC 6761 to designate '.ipv4only.arpa' as a Special-Use Domain Name; in this case, the process worked smoothly and without controversy.
“发现用于IPv6地址合成的IPv6前缀”[RFC7050]是成功使用RFC 6761中的过程将“.ipv4only.arpa”指定为特殊用途域名的文档示例；在这种情况下，这一过程顺利进行，没有争议。
Unfortunately, while the IETF process worked smoothly, in the sense that there was little controversy or delay in approving the new use, it did not work correctly: the name 'ipv4only.arpa' was never added to the "Special-Use Domain Names" registry. This appears to have happened because the document did not explicitly request the addition of an entry for 'ipv4only.arpa' in the "Special-Use Domain Names"
不幸的是，尽管IETF过程进展顺利，在批准新用途方面几乎没有争议或延迟，但它并没有正常工作：名称“ipv4only.arpa”从未添加到“特殊用途域名”注册表中。这似乎是因为文档没有明确要求在“特殊用途域名”中添加“ipv4only.arpa”条目
registry. This is an illustration of one of the problems that we have with the process in RFC 6761: it is apparently fairly easy to miss the step of adding the name to the registry.
登记处。这是我们在RFC6761过程中遇到的问题之一的一个例子：显然很容易错过将名称添加到注册表的步骤。
"Additional Reserved Top Level Domains" [RESERVED-TLDS] is an example of a document that attempted to reserve several TLDs identified by ICANN as particularly at risk for collision as Special-Use Domain Names with no documented use. This attempt failed.
“其他保留顶级域名”[Reserved-TLD]是一份文件的示例，该文件试图将ICANN确定为特别有冲突风险的几个TLD保留为特殊用途域名，但没有记录在案的用途。这次尝试失败了。
Although the aforementioned document failed to gain consensus to be published, the need it was intended to fill still exists. Unfortunately, although a fair amount is known about the use of these names, no RFC exists that describes how they are used and why it would be a problem to delegate them. Additionally, to the extent that the uses being made of these names are valid, no document exists indicating when it might make sense to use them and when it would not make sense to use them.
尽管上述文件未能达成一致意见予以公布，但它本打算填补的需要仍然存在。不幸的是，尽管对这些名称的使用有相当多的了解，但没有任何RFC描述如何使用它们以及为什么委派它们会是一个问题。此外，如果这些名称的使用是有效的，则不存在任何文件，表明何时使用它们可能有意义，何时使用它们没有意义。
RFC 7788 [RFC7788] defines the Top-Level Domain Name '.home' for use as the default name for name resolution relative to a home network context. Although, as defined in RFC 7788, '.home' is a Special-Use Domain Name, RFC 7788 did not follow the process specified in RFC 6761: it did not request that '.home' be added to the "Special-Use Domain Names" registry. This was recognized as a mistake and resulted in the posting of an errata report [Err4677]. Additionally, '.home' is an example of an attempt to reuse a domain name that has already been put into use for other purposes without following established processes [SDO-ICANN-COLL], which further complicates the situation. At the time RFC 8244 was written, the IETF was developing a solution to this problem.
RFC 7788[RFC7788]定义顶级域名“.home”，用作相对于家庭网络上下文的名称解析的默认名称。尽管按照RFC 7788中的定义，“.home”是一个特殊用途域名，但RFC 7788没有遵循RFC 6761中指定的流程：它没有请求将“.home”添加到“特殊用途域名”注册表中。这被认为是一个错误，并导致发布勘误表报告[Err4677]。此外，“.home”是一个试图在不遵循既定流程的情况下重用已用于其他目的的域名[SDO-ICANN-COLL]的例子，这使情况进一步复杂化。在编写RFC 8244时，IETF正在为这个问题开发解决方案。
A newcomer to the problem of resolving domain names may be under the impression that the DNS sprang fully formed directly from Paul Mockapetris' head (as was the birth of Athena in Greek Mythology). This is not the case. At the time the IAB technical document was written [RFC2826], memories would have been fresh of the evolutionary process that led to DNS' dominance as a protocol for domain name resolution.
解决域名问题的新手可能会有这样的印象：DNS完全是由保罗·莫卡佩特里斯（Paul Mockapetris）的脑袋直接产生的（就像希腊神话中雅典娜的诞生一样）。事实并非如此。在撰写IAB技术文件[RFC2826]时，人们对导致DNS作为域名解析协议占据主导地位的进化过程记忆犹新。
In fact, in the early days of the Internet, hostnames were resolved using a text file, HOSTS.TXT, which was maintained by a central authority, the Network Information Center, and distributed to all hosts on the Internet using the File Transfer Protocol (FTP)
事实上，在互联网的早期，主机名是使用文本文件HOSTS.TXT解析的，该文件由中央机构网络信息中心维护，并使用文件传输协议（FTP）分发给互联网上的所有主机
[RFC959]. The inefficiency of this process is cited as a reason for the development of the DNS [RFC882] [RFC883] in 1983.
[RFC959]。1983年，DNS[RFC882][RFC883]的开发以该过程的低效为理由。
However, the transition from HOSTS.TXT to the DNS was not smooth. For example, Sun Microsystems' Network Information System (NIS) [CORP-SUN-NIS], at the time known as Yellow Pages, was an active competitor to the DNS, although it failed to provide a complete solution to the global naming problem.
但是，从HOSTS.TXT到DNS的转换并不顺利。例如，Sun Microsystems的网络信息系统（NIS）[CORP-Sun-NIS]，当时被称为黄页，是DNS的积极竞争对手，尽管它未能为全球命名问题提供完整的解决方案。
Another example was NetBIOS Name Service, also known as WINS [RFC1002]. This protocol was used mostly by Microsoft Windows machines, but also by open-source BSD and Linux operating systems to do name resolution using Microsoft's own name resolution protocol.
另一个例子是NetBIOS名称服务，也称为WINS[RFC1002]。此协议主要由Microsoft Windows计算机使用，但开源BSD和Linux操作系统也使用此协议使用Microsoft自己的名称解析协议进行名称解析。
Most modern operating systems can still use the '/etc/hosts' file for name resolution. Many still have a name service switch that can be configured on the host to resolve some domains using the NIS or WINS. Most have the capability to resolve names using mDNS by recognizing the special meaning of the '.local' Special-Use Top-Level Domain Name.
大多数现代操作系统仍然可以使用“/etc/hosts”文件进行名称解析。许多服务器仍然有一个名称服务交换机，可以在主机上配置该交换机，以使用NIS或WINS解析某些域。大多数都能够通过识别“.local”特殊用途顶级域名的特殊含义，使用MDN解析名称。
The Sun Microsystems model of having private domains within a corporate site, while supporting the global Domain Name System for off-site, persisted even after the NIS protocol fell into disuse. Microsoft used to recommend that site administrators use a "private" TLD for internal use, and this practice was very much a part of the zeitgeist at the time (see Section 5.1 of [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at the root of the widespread practice of simply picking an apparently unused TLD and using it for experimental purposes, which persists even at the time of writing of this memo.
Sun Microsystems的模式是在公司站点内拥有私有域，同时支持用于非站点的全局域名系统，即使在NIS协议被废弃之后，这种模式仍然存在。微软曾建议站点管理员在内部使用“私有”TLD，而这种做法在当时是时代精神的一部分（见[SDO-ICANN-COLL]第5.1节和[RFC6762]附录G）。这种态度是普遍做法的根源，即简单地选择一个显然未使用的TLD并将其用于实验目的，这种做法甚至在撰写本备忘录时仍然存在。
This history is being presented because discussions about Special-Use Domain Names in the IETF often come down to the question of why users of new name resolution protocols choose to use domain names rather than using some other naming concept that doesn't overlap with the namespace that, in modern times is, by default, resolved using the DNS.
之所以介绍这段历史，是因为IETF中关于特殊用途域名的讨论通常归结为一个问题，即为什么新名称解析协议的用户选择使用域名，而不是使用与名称空间不重叠的其他命名概念，而在现代，名称空间默认使用DNS解析。
The answer is that as a consequence of this long history of resolving domain names using a wide variety of name resolution systems, domain names are required in a large variety of contexts in user interfaces and applications programming interfaces. Any name that appears in such a context is a domain name. So, developers of new name resolution systems that must work in existing contexts actually have no choice: they must use a Special-Use Domain Name to segregate a portion of the namespace for use with their system.
答案是，由于使用各种名称解析系统解析域名的悠久历史，在用户界面和应用程序编程界面的各种上下文中都需要域名。出现在这种上下文中的任何名称都是域名。因此，必须在现有上下文中工作的新名称解析系统的开发人员实际上别无选择：他们必须使用特殊用途域名来隔离名称空间的一部分，以便与系统一起使用。
This document mentions various security and privacy considerations in the text. However, this document creates no new security or privacy concerns.
本文件在正文中提到了各种安全和隐私注意事项。但是，本文档不会产生新的安全或隐私问题。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[CORP-SUN-NIS] Wikipedia, "Network Information Service", August 2017, <https://en.wikipedia.org/wiki/ Network_Information_Service>.
[CORP-SUN-NIS]维基百科，“网络信息服务”，2017年8月<https://en.wikipedia.org/wiki/ 网络信息服务>。
[DOMAIN-NAMES] Lewis, E., "Domain Names, A Case for Clarifying", Work in Progress, draft-lewis-domain-names-09, August 2017.
[域名]Lewis，E.，“域名，澄清的案例”，正在进行的工作，草稿-Lewis-DOMAIN-NAMES-092017年8月。
[Err4677] RFC Errata, "Erratum ID 4677", RFC 7788, <https://www.rfc-editor.org/errata/eid4677>.
[Err4677]RFC勘误表，“勘误表ID 4677”，RFC 7788<https://www.rfc-editor.org/errata/eid4677>.
[IETF-PRO-51] IETF, "Proceedings of the 51st IETF Meeting", August 2001, <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[IETF-PRO-51]IETF，“第51次IETF会议记录”，2001年8月<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[P2P-DOMAIN-NAMES] Grothoff, C., Wachs, M., Wolf, H., Ed., Appelbaum, J., and L. Ryge, "Special-Use Domain Names of Peer-to-Peer Systems", Work in Progress, draft-grothoff-iesg-special-use-p2p-names-04, January 2015.
[P2P-域名]Grothoff，C.，Wachs，M.，Wolf，H.，Ed.，Appelbaum，J.，和L.Ryge，“对等系统的特殊用途域名”，正在进行的工作，草稿-Grothoff-iesg-Special-Use-P2P-NAMES-042015年1月。
[PROBLEM-SPECIAL-NAMES] Huston, G., Koch, P., Durand, A., and W. Kumari, "Problem Statement for the Reservation of Special-Use Domain Names using RFC6761", Work in Progress, draft-adpkja-dnsop-special-names-problem-06, September 2016.
[PROBLEM-SPECIAL-NAMES]Huston，G.，Koch，P.，Durand，A.，和W.Kumari，“使用RFC6761保留特殊用途域名的问题声明”，正在进行的工作，草稿-adpkja-dnsop-SPECIAL-NAMES-PROBLEM-062016年9月。
[RESERVED-TLDS] Chapin, L. and M. McFadden, "Additional Reserved Top Level Domains", Work in Progress, draft-chapin-additional-reserved-tlds-02, March 2015.
[RESERVED-TLDS]Chapin，L.和M.McFadden，“其他保留顶级域”，正在进行的工作，草稿-Chapin-Additional-RESERVED-TLDS-022015年3月。
[RFC882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, <https://www.rfc-editor.org/info/rfc882>.
[RFC882]Mockapetris，P.，“域名：概念和设施”，RFC 882，DOI 10.17487/RFC0882，1983年11月<https://www.rfc-editor.org/info/rfc882>.
[RFC883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>.
[RFC883]Mockapetris，P.，“域名：实现规范”，RFC 883，DOI 10.17487/RFC0883，1983年11月<https://www.rfc-editor.org/info/rfc883>.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.
[RFC959]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，DOI 10.17487/RFC0959，1985年10月<https://www.rfc-editor.org/info/rfc959>.
[RFC1002] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, <https://www.rfc-editor.org/info/rfc1002>.
[RFC1002]国防高级研究计划局、互联网活动委员会和端到端服务工作组的NetBIOS工作组，“TCP/UDP传输上NetBIOS服务的协议标准：详细规范”，STD 19，RFC 1002，DOI 10.17487/RFC1002，1987年3月<https://www.rfc-editor.org/info/rfc1002>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc1918>.
[RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain Names", RFC 2352, DOI 10.17487/RFC2352, May 1998, <https://www.rfc-editor.org/info/rfc2352>.
[RFC2352]Vaughan，O.，“将法定名称用作域名的公约”，RFC 2352，DOI 10.17487/RFC2352，1998年5月<https://www.rfc-editor.org/info/rfc2352>.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, <https://www.rfc-editor.org/info/rfc2826>.
[RFC2826]互联网体系结构委员会，“关于唯一DNS根的IAB技术评论”，RFC 2826，DOI 10.17487/RFC2826，2000年5月<https://www.rfc-editor.org/info/rfc2826>.
[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, <https://www.rfc-editor.org/info/rfc2860>.
[RFC2860]Carpenter，B.，Baker，F.和M.Roberts，“关于互联网分配号码管理局技术工作的谅解备忘录”，RFC 2860，DOI 10.17487/RFC2860，2000年6月<https://www.rfc-editor.org/info/rfc2860>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 4193，DOI 10.17487/RFC4193，2005年10月<https://www.rfc-editor.org/info/rfc4193>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>.
[RFC6303]Andrews，M.，“本地服务DNS区域”，BCP 163，RFC 6303，DOI 10.17487/RFC6303，2011年7月<https://www.rfc-editor.org/info/rfc6303>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <https://www.rfc-editor.org/info/rfc6598>.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，DOI 10.17487/RFC6598，2012年4月<https://www.rfc-editor.org/info/rfc6598>.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, DOI 10.17487/RFC6760, February 2013, <https://www.rfc-editor.org/info/rfc6760>.
[RFC6760]Cheshire，S.和M.Krocmal，“替代AppleTalk名称绑定协议（NBP）的协议要求”，RFC 6760，DOI 10.17487/RFC6760，2013年2月<https://www.rfc-editor.org/info/rfc6760>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.
[RFC6761]Cheshire，S.和M.Krochmal，“特殊用途域名”，RFC 6761，DOI 10.17487/RFC6761，2013年2月<https://www.rfc-editor.org/info/rfc6761>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]Cheshire，S.和M.Krochmal，“多播DNS”，RFC 6762，DOI 10.17487/RFC6762，2013年2月<https://www.rfc-editor.org/info/rfc6762>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050]Savolainen，T.，Korhonen，J.，和D.Wing，“用于IPv6地址合成的IPv6前缀的发现”，RFC 7050，DOI 10.17487/RFC7050，2013年11月<https://www.rfc-editor.org/info/rfc7050>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC7686]Appelbaum，J.和A.Muffett，“洋葱”特殊用途域名，RFC 7686，DOI 10.17487/RFC7686，2015年10月<https://www.rfc-editor.org/info/rfc7686>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC7719]Hoffman，P.，Sullivan，A.和K.Fujiwara，“DNS术语”，RFC 7719，DOI 10.17487/RFC77192015年12月<https://www.rfc-editor.org/info/rfc7719>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7788]Stenberg，M.，Barth，S.，和P.Pfister，“家庭网络控制协议”，RFC 7788，DOI 10.17487/RFC7788，2016年4月<https://www.rfc-editor.org/info/rfc7788>.
[SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page", <https://cabforum.org>.
[SDO-CABF]CA/浏览器论坛，“CA/浏览器论坛主页”<https://cabforum.org>.
[SDO-CABF-BALLOT144] CA/Browser Forum, "Ballot 144 - Validation Rules for .onion Names", February 2015, <https://cabforum.org/2015/ 02/18/ballot-144-validation-rules-dot-onion-names>.
[SDO-CABF-BALLOT144]CA/浏览器论坛，“选票144-洋葱名称验证规则”，2015年2月<https://cabforum.org/2015/ 02/18/ballot-144-validation-rules-dot-onion-names>。
[SDO-CABF-DEADLINE] CA/Browser Forum, "SSL Certificates for Internal Server Names", January 2013, <https://www.digicert.com/internal-names.htm>.
[SDO-CABF-DEADLINE]CA/浏览器论坛，“内部服务器名称的SSL证书”，2013年1月<https://www.digicert.com/internal-names.htm>.
[SDO-CABF-INT] CA/Browser Forum, "Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses", June 2012, <https://cabforum.org/internal-names/>.
[SDO-CABF-INT]CA/Browser论坛，“内部服务器名称和保留IP地址弃用指南”，2012年6月<https://cabforum.org/internal-names/>.
[SDO-IAB-ICANN-LS] IETF, "Liaison Statement from the IAB to the ICANN Board on Technical Use of Domain Names", September 2014, <https://datatracker.ietf.org/liaison/1351>.
[SDO-IAB-ICANN-LS]IETF，“IAB向ICANN董事会提交的关于域名技术使用的联络声明”，2014年9月<https://datatracker.ietf.org/liaison/1351>.
[SDO-IAB-SUDN-REG] IAB, "Internet Architecture Board statement on the registration of special use names in the ARPA domain", March 2017, <https://www.iab.org/documents/ correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/>.
[SDO-IAB-SUDN-REG]IAB，“互联网架构委员会关于注册ARPA域中特殊用途名称的声明”，2017年3月<https://www.iab.org/documents/ 通信报告文件/2017-2/iab关于arpa域中特殊用途名称注册的声明/>。
[SDO-IANA-SUDR] IANA, "Special-Use Domain Names", <http://www.iana.org/ assignments/special-use-domain-names>.
[SDO-IANA-SUDR]IANA，“特殊用途域名”<http://www.iana.org/ 分配/特殊用途域名>。
[SDO-ICANN-COLL] Interisle Consulting Group, LLC, "Name Collision in the DNS", Version 1.5, August 2013, <https://www.icann.org/ en/system/files/files/name-collision-02aug13-en.pdf>.
[SDO-ICANN-COLL]Interisle Consulting Group，LLC，“DNS中的名称冲突”，版本1.5，2013年8月<https://www.icann.org/ en/system/files/files/name-collision-02aug13-en.pdf>。
[SDO-ICANN-DAG] ICANN, "gTLD Applicant Guidebook", Version 2012-06-04, June 2012, <https://newgtlds.icann.org/en/applicants/agb/ guidebook-full-04jun12-en.pdf>.
[SDO-ICANN-DAG]ICANN，“gTLD申请人指南”，2012年6月版，2012-06-04<https://newgtlds.icann.org/en/applicants/agb/ 指南-full-04jun12-en.pdf>。
[SDO-ICANN-SAC090] ICANN Security and Stability Advisory Committee, "SSAC Advisory on the Stability of the Domain Namespace", ICANN SAC090, December 2016, <https://www.icann.org/en/ system/files/files/sac-090-en.pdf>.
[SDO-ICANN-SAC090]ICANN安全与稳定咨询委员会，“域名名称空间稳定性的SSAC咨询”，ICANN SAC0902016年12月<https://www.icann.org/en/ system/files/files/sac-090-en.pdf>。
[SDO-ICANN-SSAC] ICANN, "Security and Stability Advisory Committee (SSAC)", December 2016, <https://www.icann.org/groups/ssac>.
[SDO-ICANN-SSAC]ICANN，“安全与稳定咨询委员会（SSAC）”，2016年12月<https://www.icann.org/groups/ssac>.
[TOR] Tor, "Tor - Anonymity Online", <https://www.torproject.org>.
[TOR]TOR，“TOR-匿名在线”<https://www.torproject.org>.
Contributors
贡献者
Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron Falk, and Suzanne Woolf all made helpful and insightful observations or patiently answered questions. This should not be taken as an indication that any of these folks actually agree with what the document says, but their generosity with time and thought are appreciated in any case.
马克·安德鲁斯、斯图亚特·柴郡、大卫·康拉德、保罗·埃伯斯曼、亚伦·福克和苏珊娜·伍尔夫都进行了有益和有见地的观察，或耐心地回答了问题。这不应被视为表明这些人中的任何人实际上同意文件所说的话，但无论如何，他们对时间和思想的慷慨是值得赞赏的。
Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr Spacek, and others provided significant review and/or useful comments.
Stephane Bortzmeyer、John Dickinson、Bob Harold、Paul Hoffman、Russ Housley、Joel Jaeggli、Andrew McConachie、George Michaelson、Petr Spacek和其他人提供了重要的评论和/或有用的评论。
This document also owes a great deal to Ed Lewis' excellent work on what a "domain name" is [DOMAIN-NAMES].
这份文件还很大程度上归功于Ed Lewis在“域名”是什么[域名]方面的出色工作。
We would also like to acknowledge the authors of [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter Koch, and Joe Abley, for their efforts to frame the issues and engage the working group, as well as their contributions to the list of issues from their document [PROBLEM-SPECIAL-NAMES].
我们还要感谢[特殊问题名称]的作者，包括Alain Durand、Geoff Huston、Peter Koch和Joe Abley，感谢他们为制定问题和与工作组接触所做的努力，以及他们在文件[特殊问题名称]中对问题清单的贡献。
Authors' Addresses
作者地址
Ted Lemon Nominum, Inc. 800 Bridge Parkway Redwood City, CA 94065 United States of America
Ted Lemon Nominum，Inc.美国加利福尼亚州红木市800桥公园路94065号
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com
Ralph Droms
拉尔夫·德罗姆斯
Email: rdroms.ietf@gmail.com
Email: rdroms.ietf@gmail.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari谷歌1600圆形剧场公园道山景，加利福尼亚州94043美利坚合众国
Email: warren@kumari.net
Email: warren@kumari.net