Independent Submission J. Klensin
Request for Comments: 8324 February 2018
Category: Informational
ISSN: 2070-1721
Independent Submission J. Klensin
Request for Comments: 8324 February 2018
Category: Informational
ISSN: 2070-1721
DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?
DNS隐私、授权、特殊用途、编码、字符、匹配和根结构：是时候再看看了？
Abstract
摘要
The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.
域名系统的基本设计几乎在30年前完成。这一时期的后半部分的特点是需求和期望发生了重大变化，其中一些要求更改DNS的使用方式，或者只能适应得很差或根本不适应。本文档提出的问题是，是否应该重新设计和更换DNS，以满足当前的需求和期望（而不是继续尝试设计和实施不完全令人满意的增量修补程序）或者，对不真正需要的功能或应该以其他方式执行的功能划清界限。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc8324.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8324.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background and Hypothesis . . . . . . . . . . . . . . . . . . 5
3. Warts and Tensions with the Current DNS . . . . . . . . . . . 6
3.1. Multi-type Queries . . . . . . . . . . . . . . . . . . . 6
3.2. Matching Part I: Case Sensitivity in Labels and Other
Anomalies . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Matching Part II: Non-ASCII ("Internationalized") Domain
Name Labels . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Matching Part III: Label Synonyms, Equivalent Names, and
Variants . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Query Privacy . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Alternate Namespaces for Public Use in the DNS Framework:
The CLASS Problem . . . . . . . . . . . . . . . . . . . . 10
3.7. Loose Synchronization . . . . . . . . . . . . . . . . . . 10
3.8. Private Namespaces and Special Names . . . . . . . . . . 11
3.9. Alternate Query or Response Encodings . . . . . . . . . . 12
3.10. Distribution and Management of Root Servers . . . . . . . 12
3.11. Identifiers versus Brands and Other Convenience Names . . 13
3.12. A Single Hierarchy with a Centrally Controlled Root . . . 14
3.13. Newer Application Protocols, New Requirements, and DNS
Evolution . . . . . . . . . . . . . . . . . . . . . . . . 14
3.13.1. The Extensions . . . . . . . . . . . . . . . . . . . 15
3.13.2. Extensions and Deployment Pressures -- The TXT
RRTYPE . . . . . . . . . . . . . . . . . . . . . . . 15
3.13.3. Periods and Zone Cut Issues . . . . . . . . . . . . 16
3.14. Scaling of Reputation and Other Ancillary Information . . 17
3.15. Tensions among Transport, Scaling, and Content . . . . . 18
4. The Inverse Lookup Requirement . . . . . . . . . . . . . . . 19
5. Internet Scale, Function Support, and Incremental Deployment 20
6. Searching and the DNS -- An Historical Note . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background and Hypothesis . . . . . . . . . . . . . . . . . . 5
3. Warts and Tensions with the Current DNS . . . . . . . . . . . 6
3.1. Multi-type Queries . . . . . . . . . . . . . . . . . . . 6
3.2. Matching Part I: Case Sensitivity in Labels and Other
Anomalies . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Matching Part II: Non-ASCII ("Internationalized") Domain
Name Labels . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Matching Part III: Label Synonyms, Equivalent Names, and
Variants . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Query Privacy . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Alternate Namespaces for Public Use in the DNS Framework:
The CLASS Problem . . . . . . . . . . . . . . . . . . . . 10
3.7. Loose Synchronization . . . . . . . . . . . . . . . . . . 10
3.8. Private Namespaces and Special Names . . . . . . . . . . 11
3.9. Alternate Query or Response Encodings . . . . . . . . . . 12
3.10. Distribution and Management of Root Servers . . . . . . . 12
3.11. Identifiers versus Brands and Other Convenience Names . . 13
3.12. A Single Hierarchy with a Centrally Controlled Root . . . 14
3.13. Newer Application Protocols, New Requirements, and DNS
Evolution . . . . . . . . . . . . . . . . . . . . . . . . 14
3.13.1. The Extensions . . . . . . . . . . . . . . . . . . . 15
3.13.2. Extensions and Deployment Pressures -- The TXT
RRTYPE . . . . . . . . . . . . . . . . . . . . . . . 15
3.13.3. Periods and Zone Cut Issues . . . . . . . . . . . . 16
3.14. Scaling of Reputation and Other Ancillary Information . . 17
3.15. Tensions among Transport, Scaling, and Content . . . . . 18
4. The Inverse Lookup Requirement . . . . . . . . . . . . . . . 19
5. Internet Scale, Function Support, and Incremental Deployment 20
6. Searching and the DNS -- An Historical Note . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
This document explores contemporary expectations of the Internet's domain system (DNS) and compares them to the assumptions and properties of the DNS design, including both those documented in the RFC Series, an important early paper by the principal author of the original RFCs [Mockapetris-1988], and a certain amount of oral tradition. It is primarily intended to ask the question of whether the differences are causing enough stresses on the system, stresses that cannot be resolved satisfactorily by further patching, that the Internet community should be considering designing a new system, one that is better adapted to current needs and expectations, and developing a deployment and transition strategy for it. For those (perhaps the majority of us) for whom actually replacing the DNS is too radical to be realistic, the document may be useful in two other ways. It may provide a foundation for discussing what functions the DNS should not be expected to support and how those functions can be supported in other ways, perhaps via an intermediate system that then calls on the DNS or by using some other type of database technology for some set of functions while leaving the basic DNS functions intact. Or it may provide a basis for "better just get used to that and the way it works" discussions to replace fantasies about what the DNS might do in some alternate reality.
本文件探讨了互联网域系统（DNS）的当代期望，并将其与DNS设计的假设和属性进行了比较，包括RFC系列中记录的假设和属性，RFC系列是原始RFC的主要作者[Mockapetris-1988]的重要早期论文，以及一定数量的口头传统。其主要目的是问这样一个问题：这些差异是否对系统造成了足够的压力，这些压力无法通过进一步修补得到满意的解决，互联网社区应该考虑设计一个新的系统，一个更好地适应当前需要和期望的系统，并为其制定部署和过渡战略。对于那些（可能是我们中的大多数人）来说，实际替换DNS过于激进而不现实的人来说，该文档在另外两个方面可能很有用。它可以为讨论DNS不应该期望支持哪些功能以及如何以其他方式支持这些功能提供基础，可能是通过中间系统然后调用DNS，或者通过使用一些其他类型的数据库技术来实现某些功能，同时保留基本DNS功能完好无损。或者，它可以为“更好地适应它和它的工作方式”的讨论提供基础，以取代关于DNS在另一种现实中可能做什么的幻想。
There is a key design or philosophical question associated with the analysis in this document that the document does not address. It is whether changes to perceived requirements to DNS functionality as described here are, in most respects, evolutionary or whether many of them are instances of trying to utilize the DNS for new requirements because it exists and is already deployed independent of whether the DNS is really appropriate or not. The latter might be an instance of a problem often described in the IETF as "when all you have is a hammer, everything looks like a nail".
本文件中有一个与分析相关的关键设计或哲学问题，但本文件并未解决。这里所描述的对DNS功能的感知需求的变化在大多数方面是否是进化的，或者其中许多变化是否是尝试利用DNS满足新需求的实例，因为它存在并且已经独立于DNS是否真正合适而部署。后者可能是IETF中经常描述的问题的一个例子，“当你只有一把锤子时，一切看起来都像钉子”。
Other recent work, including a short article by Vint Cerf [Cerf2017], has discussed an overlapping set of considerations from a different perspective, reinforcing the view that it may be time to ask fundamental questions about the evolution and future of the DNS.
其他最近的工作，包括Vint Cerf[Cerf2017]的一篇短文，从不同的角度讨论了一组重叠的考虑因素，强化了这样一种观点，即现在可能是时候提出有关DNS的演变和未来的基本问题了。
While this document does not assume deep technical or operational knowledge of the DNS, it does assume some knowledge and at least general familiarity with the concepts of RFC 1034 [RFC1034] and RFC 1035 [RFC1035] and the terminology discussed in RFC 7719 [RFC7719] and elsewhere. Although some of the comments it contains might be taken as hints or examples of different ways to think about the design issues, it makes no attempt to explore, much less offer a tutorial on, alternate naming systems or database technologies.
虽然本文件并未假定对DNS有深入的技术或操作知识，但它假定对RFC 1034[RFC1034]和RFC 1035[RFC1035]的概念以及RFC 7719[RFC7719]和其他地方讨论的术语有一定的了解，至少一般熟悉。虽然它包含的一些注释可能被视为思考设计问题的不同方式的提示或示例，但它没有尝试探索，更不用说提供关于替代命名系统或数据库技术的教程。
It is perhaps worth noting that, while the perspective is different and more than a dozen years have passed, many of the issues discussed in this document were analyzed and described (most of them with more extensive explanations) in a 2005 US National Research Council report [NRC-Signposts].
也许值得注意的是，尽管观点不同，十几年过去了，但本文件中讨论的许多问题在2005年美国国家研究委员会报告[NRC路标]中进行了分析和描述（其中大多数问题有更广泛的解释）。
Readers should note that several references are to obsolete documents. That was done because they are intended to show the documents and dates that introduced particular features or concepts. When current versions are intended, they are referenced.
读者应注意，有几处引用的是过时的文档。之所以这样做，是因为它们旨在显示引入特定功能或概念的文档和日期。当计划使用当前版本时，将引用它们。
The Domain Name System (DNS) [RFC1034] was designed starting in the early 1980s [RFC0799] [RFC0881] [RFC0882] [RFC0883] with the main goal of replacing the flat, centrally administered, host table system [RFC0810] [RFC0952] [RFC0953] with a hierarchical, administratively distributed, system. The DNS design included some features that, after initial implementation and deployment, were judged to be unworkable and either replaced (e.g., the mail destination (MD) and mail forwarder (MF) approach [RFC0882] that were replaced by the MX approach [RFC0974]), abandoned (e.g., the mechanism for using email local parts as labels described in RFC 1034, Section 3.3), or deprecated (e.g., the WKS RR TYPE [RFC1123]). Newer ideas and requirements have identified a number of other features, some of which were less developed than others. Of course the original designers could not anticipate everything that has come to be expected of the DNS in the last 30 years.
域名系统（DNS）[RFC1034]是从20世纪80年代初开始设计的[RFC0799][RFC0881][RFC0882][RFC0883]，其主要目标是将扁平的、集中管理的主机表系统[RFC0810][RFC0952][RFC0953]替换为分层的、管理分布式的系统。DNS设计包括一些功能，在初始实施和部署后，这些功能被判定为不可行，或者被替换（例如，被MX方法[RFC0974]替换的邮件目的地（MD）和邮件转发器（MF）方法[RFC0882]），或者被放弃（例如，RFC 1034第3.3节中描述的将电子邮件本地部分用作标签的机制）或已弃用（例如，WKS RR类型[RFC1123]）。更新的想法和要求确定了许多其他功能，其中一些功能的开发程度低于其他功能。当然，最初的设计师无法预测过去30年中DNS的所有预期功能。
In recent years, demand for new and extended services and uses of the DNS have, in turn, led to proposals for DNS extensions or changes of various sorts. Some have been adopted, including a model for negotiating extended functionality [RFC2671] (commonly known as EDNS(0)) and to support IPv6 [RFC3596], others were found to be impracticable, and still others continue to be under consideration. Some examples of the latter two categories are discussed below. A few features of the original DNS specification, such as the CLASS property and label types, have also been suggested to be so badly specified that they should be deprecated [Sullivan-Class].
近年来，对新的和扩展的服务以及DNS的使用的需求反过来导致了对DNS扩展或各种更改的建议。一些已经被采用，包括协商扩展功能[RFC2671]（通常称为EDN（0））的模型和支持IPv6的模型[RFC3596]，其他模型被认为是不可行的，还有一些仍在考虑之中。下文将讨论后两类的一些例子。原始DNS规范的一些功能，如类属性和标签类型，也被认为是指定得非常糟糕，应该弃用[Sullivan CLASS]。
Unlike earlier changes such as the Internationalized Domain Names for Applications (IDNA) mechanisms for better incorporating non-ASCII labels without modifying the DNS structure itself [RFC3490] [RFC5890], some recent proposals require or strongly suggest changes to APIs, formats, or interfaces by programs that need to retrieve information from the DNS or interpret that information. Differences between the DNS architecture and the requirements that imply those proposals suggest that it may be time to stop patching the DNS or
与早期的更改不同，例如在不修改DNS结构本身的情况下更好地合并非ASCII标签的国际化应用程序域名（IDNA）机制[RFC3490][RFC5890]，最近的一些提案要求或强烈建议更改API、格式、，或需要从DNS检索信息或解释该信息的程序的接口。DNS体系结构与暗示这些建议的要求之间的差异表明，可能是时候停止修补DNS或
trying to extend it in small increments. Instead, we should be considering moving some current or proposed functionality elsewhere or developing a new system that better meets today's needs and a transition strategy to it.
尝试以小增量扩展它。相反，我们应该考虑将一些当前或拟议的功能转移到其他地方，或者开发一个更好地满足当今需求的新系统，以及向它的过渡战略。
The next section of this document discusses a number of issues with the current DNS design that could appropriately be addressed by a different and newer design model. In at least some cases, changing the model and protocols could bring significant benefits to the Internet and/or its administration.
本文档的下一节将讨论当前DNS设计中的一些问题，这些问题可以通过不同的、更新的设计模型得到适当的解决。至少在某些情况下，更改模型和协议可以为Internet和/或其管理带来重大好处。
This document is not a proposal for a new protocol. It is intended to stimulate thought about how far we want to try to push the existing DNS, to examine whether expectations of it are already exceeding its plausible capabilities, and to start discussion of a redesign or alternatives to one if the time for that decision has come.
本文件不是新议定书的提案。它的目的是激发人们对我们希望将现有DNS推向何种程度的思考，检查人们对它的期望是否已经超过了它看似合理的能力，并开始讨论重新设计或替代方案，如果做出决定的时候到了。
As suggested above, there are many signs that the DNS is incapable of meeting contemporary expectations of how it should work and functionality it should support. Some of those expectations are unrealistic under any imaginable circumstances; others are impossible (or merely problematic) in the current DNS structure but could be accommodated in a redesign. These are examples, rather than a comprehensive list, and do not appear in any particular order.
如上所述，有许多迹象表明DNS无法满足当前对其工作方式和功能的期望。其中一些期望在任何可以想象的情况下都是不切实际的；其他的在当前DNS结构中是不可能的（或者仅仅是有问题的），但是可以在重新设计中进行调整。这些都是示例，而不是一个全面的列表，并且不会以任何特定的顺序出现。
The DNS does not gracefully support multi-type queries. The current case where this problem rears its head involves attempts at solutions that return both TYPE A (IPv4) and type AAA (IPv6) addresses collectively. The problem was originally seen with "QTYPE=MAILA" [RFC0882] for the original MA and MD RRTYPEs, an experience that strongly suggests that some very careful thinking about cache effects (and possibly additional DNS changes) would be needed. Other solutions might seem equally or more plausible. What they, including "two types of addresses", probably have in common is that they illustrate stresses on the system and that changing the DNS to deal with those stresses is not straightforward or likely to be problem-free.
DNS不支持多类型查询。当前出现此问题的案例涉及尝试同时返回A型（IPv4）和AAA型（IPv6）地址的解决方案。问题最初出现在原始MA和MD RRTYPE的“QTYPE=MAILA”[RFC0882]上，这一经验强烈表明，需要非常仔细地考虑缓存效应（以及可能的附加DNS更改）。其他解决方案似乎同样或更合理。它们（包括“两种类型的地址”）的共同点可能是，它们说明了系统上的压力，并且更改DNS以处理这些压力并不简单，也不可能没有问题。
The DNS specifications assume that labels are octet strings and octets with the high bit zero have seven-bit ASCII codes in the remaining bits. They require that, when a domain name used in a query is matched to one stored in the database, those ASCII characters be interpreted in a case-independent way, i.e., upper- and lower-case letters are treated as equivalent (digits and symbols are not affected) [RFC4343]. For non-ASCII octets, i.e., octets in labels with the first bit turned on, there are no assumptions about the character coding used, much less any rules about character case equivalence -- strings must be compared by matching bits in sequence. Even though the current model for handling non-ASCII (i.e., "internationalized") domain name labels (IDNs) [RFC5890] (see Section 3.3 below) encodes information so the DNS is not directly affected, the notion that some characters in labels are handled in a case-insensitive way and that others are case sensitive (or that upper case must be prohibited entirely as IDNA does) has caused a good deal of confusion and resentment. Those concerns and complaints about inconsistent behavior and mishandling (or suboptimal handling) of case relationships for some languages have not been mitigated by repeated explanations that the relationships between "decorated" lower-case characters and their upper-case equivalents are often sensitive to language and locality and therefore not deterministic with information available to DNS servers.
DNS规范假定标签是八位字符串，并且高位为零的八位字节在剩余位中有七位ASCII码。它们要求，当查询中使用的域名与数据库中存储的域名匹配时，这些ASCII字符应以独立于大小写的方式进行解释，即大写和小写字母被视为等效的（数字和符号不受影响）[RFC4343]。对于非ASCII八位字节，即打开第一位的标签中的八位字节，对于所使用的字符编码没有任何假设，更不用说任何关于字符大小写等价性的规则了——字符串必须通过按顺序匹配位来进行比较。尽管当前处理非ASCII（即“国际化”）域名标签（IDN）[RFC5890]（见下文第3.3节）的模型对信息进行编码，因此DNS不会直接受到影响，但标签中的某些字符是以不区分大小写的方式处理的，而其他字符是区分大小写的（或者必须像IDNA一样完全禁止大写）已经引起了大量的混乱和不满。对于某些语言的不一致行为和错误处理（或次优处理）案例关系的担忧和抱怨，并没有因为反复解释“修饰”和“修饰”之间的关系而减轻小写字符及其大写等价物通常对语言和位置敏感，因此无法确定DNS服务器可用的信息。
3.3. Matching Part II: Non-ASCII ("Internationalized") Domain Name Labels
3.3. 匹配第二部分：非ASCII（“国际化”）域名标签
Quite independent of the case-sensitivity problem, one of the fundamental properties of Unicode [Unicode] is that some abstract characters can be represented in multiple ways, such as by a single, precomposed, code point or by a base code point followed by one or more code points that specify combining characters. While Unicode Normalization can be used to eliminate many (but not all) of those distinctions for comparison (matching) purposes, it is best applied during matching rather than by changing one string into another. The first version of IDNA ("IDNA2003") made the choice to change strings during processing for either storage or retrieval [RFC3490] [RFC3491]; the second ("IDNA2008") required that all strings be normalized and that upper-case characters are not allowed at all [RFC5891]. Neither is optimal, if only because, independent of where they are changed if they are changed at all, transforming the strings themselves implies that the input string in an application may not be the same as the string used in processing and perhaps later display.
Unicode[Unicode]的一个基本特性是，某些抽象字符可以用多种方式表示，例如通过单个预合成的代码点，或由一个基本代码点后跟一个或多个指定组合字符的代码点，这与区分大小写的问题无关。虽然Unicode规范化可用于消除许多（但不是全部）差异以进行比较（匹配），但最好在匹配过程中应用，而不是将一个字符串更改为另一个字符串。IDNA的第一个版本（“IDNA2003”）选择在存储或检索的处理过程中更改字符串[RFC3490][RFC3491]；第二个（“IDNA2008”）要求对所有字符串进行规范化，并且根本不允许使用大写字符[RFC5891]。这两种方法都不是最优的，因为，不管它们在什么地方被改变（如果它们被改变的话），转换字符串本身意味着应用程序中的输入字符串可能与处理中使用的字符串不同，也许以后会显示。
It would almost certainly be preferable, and more consistent with Unicode recommendations, to use normalization (and perhaps other techniques if they are appropriate) at matching time rather than altering the strings at all, even if there were still only a single matching algorithm, i.e., normalization were added to the existing ASCII-only case folding. However, even Unicode's discussion of normalization [Unicode-UAX15] indicates that there are special, language-dependent, cases (the most commonly cited example is the dotless "i" (U+0131)). Not only does the DNS lack any information about languages that could be used in a mapping algorithm, but, as long as there is a requirement that there be only one mapping algorithm for the entire system, that information could not be used even if it were available. One could imagine a successor system that would use information stored at nodes in the hierarchy to specify different matching rules for subsidiary nodes (or equivalent arrangements for non-hierarchical systems). It is not clear whether that would be a good idea, but it certainly is not possible with the DNS as we know it.
几乎可以肯定的是，在匹配时使用规范化（或者其他技术，如果合适的话），而不是改变字符串，这将是更可取的，并且更符合Unicode的建议，即使仍然只有一个匹配算法，即。，将标准化添加到现有的仅ASCII大小写折叠中。然而，即使是Unicode对规范化[Unicode-UAX15]的讨论也表明存在特殊的、依赖于语言的情况（最常引用的例子是无点的“i”（U+0131））。DNS不仅缺少有关可用于映射算法的语言的任何信息，而且只要整个系统只有一个映射算法，即使该信息可用，也无法使用。可以想象一个后继系统将使用层次结构中节点存储的信息为辅助节点指定不同的匹配规则（或非层次结构系统的等效安排）。目前还不清楚这是否是一个好主意，但这肯定是不可能的DNS，因为我们知道它。
As the initial phases of work on IDNs started to conclude, it became obvious that the nature and evolution of human language and writing systems required treating some names as "the same as" others. The first important example of this involved the relatively recent effort to simplify the Chinese writing system, thereby creating a distinction between "Simplified" and "Traditional" Chinese even though the meaning of the characters remained the same in almost all cases (in so-called ideographic character sets, characters have meaning rather than exclusively representing sounds). A joint effort among the relevant Country Code Top-Level Domain (ccTLD) registries and some other interested parties produced a set of recommendations for dealing with the issues with that script [RFC3743] and introduced the concept of "variant" characters and domain names.
随着IDN工作的初始阶段开始结束，很明显，人类语言和书写系统的性质和演变要求将某些名称视为“与其他名称相同”。这方面的第一个重要例子涉及到相对较新的简化中文书写系统的努力，从而在“简体”和“繁体”中文之间建立了区别，尽管汉字的含义在几乎所有情况下都保持不变（在所谓的表意字符集中，字符具有含义，而不仅仅代表声音）。相关国家代码顶级域（ccTLD）注册中心和其他一些相关方共同努力，提出了一套解决该脚本问题的建议[RFC3743]，并引入了“变体”字符和域名。
However, when names are seen as having meanings, rather than merely being mnemonics, especially when they represent brands or the equivalent, or when spelling for a particular written language is not completely standardized, demands to treat different strings as exact equivalents are obvious and inevitable. As a trivial English-language example, it is widely understood that "colour" and "color" represent the same word, so does that imply that, if they are used as DNS labels in domain names all of whose other labels are identical, the two domain names should be treated as identical? Examples for other languages or writing systems, especially ones in which some or all markings that distinguish characters or words by sound or tone or that change the pronunciation of words are optional, are often more numerous and more problematic than national spelling differences in
然而，当名称被视为具有意义，而不仅仅是助记符时，特别是当它们代表品牌或等效物时，或者当特定书面语言的拼写没有完全标准化时，将不同字符串视为完全等效物的要求显然是不可避免的。作为一个简单的英语示例，“color”和“color”代表同一个单词，这是否意味着，如果它们在所有其他标签相同的域名中用作DNS标签，则这两个域名应被视为相同？其他语言或书写系统的例子，尤其是那些通过声音或音调区分字符或单词或改变单词发音的部分或全部标记是可选的，通常比国家拼写差异更为众多，问题也更为严重
English, but they are harder to explain to those unfamiliar with those other languages or writing systems (and hard to illustrate in ASCII-only Internet-Drafts and RFCs). Although approximations are possible, the DNS cannot handle that requirement: not only do its aliasing mechanisms (CNAME, DNAME, and various proposals for newer and different types of aliasing [DNS-Aliases] [DNS-BNAME]) not provide a strong enough binding, but the ability to use those aliases from a subtree controlled by one administrative entity to that of another one implies that there is little or no possibility of the owner (in either the DNS sense or the registrar-registrant one) of a particular name to control the synonyms for it. Some of that issue can be dealt with at the application level, e.g., by redirects in web protocols, but taking that approach, which is the essential characteristic of "if both names belong to the same owner, everything is OK" approaches, results in names being handled in inconsistent ways in different protocols.
英语，但它们更难向那些不熟悉其他语言或书写系统的人解释（也很难用仅ASCII的互联网草稿和RFC进行说明）。虽然近似是可能的，但DNS无法处理该要求：不仅其别名机制（CNAME、DNAME和各种新的和不同类型的别名[DNS别名][DNS-BNAME]）没有提供足够强的绑定，但是，从一个管理实体控制的子树到另一个管理实体控制的子树使用这些别名的能力意味着特定名称的所有者（无论是DNS意义上的所有者还是注册者）几乎不可能控制其同义词。其中一些问题可以在应用程序级别解决，例如，通过web协议中的重定向，但采用这种方法（即“如果两个名称属于同一所有者，则一切正常”的基本特征）会导致名称在不同协议中以不一致的方式处理。
A different way of looking at part of this issue (and, to some degree, of the one discussed above in Section 3.3) is that these perceived equivalences and desired transformations are context-dependent, but the DNS resolution process is not [RFC6912].
另一种看待这一问题的方式（在某种程度上，也就是上文第3.3节中讨论的方式）是，这些感知的等价性和所需的转换取决于上下文，但DNS解析过程并非如此[RFC6912]。
Similar problems arise as people notice that some characters are easily mistaken for others and that might be an opportunity for user confusion and attacks. Commonly cited examples include the Latin and Cyrillic script "a" characters, which are identical [CACM-Homograph], the characters in many scripts that look like open circles or vertical or horizontal lines, and even the Latin script letter "l" and the European digit "1", but examples abound in other scripts and combinations of scripts as well. The most common proposed solution within the DNS context has been to treat these cases, as well as those involving orthographic variations, as "variants" (but variants different from the system for Chinese characters mentioned above) and either ban all but one (or a few) of the possible labels from the DNS (possibly on a first come, first served basis) or ensure that any collection of such strings that are delegated as assigned to the same ownership (see above). Neither solution is completely satisfactory: if all but one string is excluded, users who guess at a different form, perhaps in trying to transcribe characters from written or printed form, don't find what they are looking for and, as pointed out above, "same ownership" is sufficient only with carefully designed and administered applications protocol support, and sometimes not then.
当人们注意到一些字符很容易被误认为其他字符时，也会出现类似的问题，这可能会导致用户混淆和攻击。通常引用的例子包括拉丁语和西里尔语字母“a”字符，它们是相同的[CACM同形异义词]，许多脚本中的字符看起来像开放圆或垂直或水平线，甚至还有拉丁语字母“l”和欧洲数字“1”，但其他脚本和脚本组合中也有大量例子。在DNS上下文中，最常见的建议解决方案是将这些情况以及涉及正字法变体的情况视为“变体”（但与上述汉字系统不同的变体），并禁止DNS中除一个（或几个）外的所有可能标签（可能以先到先得的方式）或确保委托给同一所有权的任何此类字符串集合（见上文）。这两种解决方案都不是完全令人满意的：如果排除除一个字符串以外的所有字符串，猜测不同形式的用户（可能是在试图从书面或印刷形式转录字符时）无法找到他们要查找的内容，并且如上所述，“相同的所有权”只有经过精心设计和管理的应用程序协议支持才能满足要求，有时甚至不能满足要求。
Some of these issues are discussed at more length in an ICANN report [ICANN-VIP].
其中一些问题在ICANN报告[ICANN-VIP]中进行了更详细的讨论。
There has been growing concern in recent years that DNS queries occur in cleartext on the public Internet and that, if those queries can be intercepted, they can expose a good deal of information about interests and contacts that could compromise individual privacy. While a number of proposals, including query name minimization [RFC7816] and running DNS over an encrypted tunnel [RFC7858], have been made to mitigate that problem, they all appear to share the common properties of security patches rather than designed-in security or privacy mechanisms. While experience may prove otherwise once (and if) they are widely deployed, it does not appear that any of them are as satisfactory as a system with query privacy designed in might be. More general tutorials on this issue have appeared recently [Huston2017a].
近年来，人们越来越担心DNS查询以明文形式出现在公共互联网上，如果这些查询能够被截获，它们可能会暴露大量可能危害个人隐私的利益和联系人信息。虽然已经提出了许多建议，包括查询名称最小化[RFC7816]和通过加密隧道运行DNS[RFC7858]，以缓解该问题，但它们似乎都共享安全补丁的共同属性，而不是在安全或隐私机制中设计的。尽管一旦（如果）它们被广泛部署，经验可能会证明它们并非如此，但它们中的任何一个似乎都不如中设计的具有查询隐私的系统那样令人满意。最近出现了更多关于这个问题的一般教程[Huston2017a]。
3.6. Alternate Namespaces for Public Use in the DNS Framework: The CLASS Problem
3.6. DNS框架中公共使用的备用名称空间：类问题
The DNS standards include specification of a CLASS value, which "identifies a protocol family or instance of a protocol" (RFC 1034, Section 3.6, and elsewhere). While CLASS was used effectively in the early days of the DNS to manage different protocol families within the same administrative environment, recent attempts to use it to either partition the DNS namespace in other ways such as for non-ASCII names (partially to address the issues in Sections 3.2 and 3.3) or use DNS mechanisms for entirely different namespaces have exposed fundamental problems with the mechanism [Sullivan-Class]. Perhaps the most fundamental of those problems is disagreement about whether multiple CLASSes were intended to exist within a given zone (with records within RRSETs) or whether different CLASSes implied different zones. Different implementations make different assumptions [Faltstrom-2004] [Vixie-20170704]. These problems have led to recommendations that it be dropped entirely [Sullivan-Class], but discussions on the IETF list and in WGs in mid-2017 made it clear that there is no clear consensus on that matter.
DNS标准包括类值的规范，该类值“标识协议系列或协议实例”（RFC 1034，第3.6节和其他地方）。虽然在DNS早期，类被有效地用于在同一管理环境中管理不同的协议系列，但最近尝试使用它以其他方式（如非ASCII名称）对DNS命名空间进行分区（部分是为了解决第3.2节和第3.3节中的问题）或者对完全不同的名称空间使用DNS机制暴露了该机制的基本问题[Sullivan Class]。也许这些问题中最基本的是关于多个类是否打算存在于给定区域内（记录在RRSET内）或不同类是否意味着不同区域的分歧。不同的实施会做出不同的假设[Faltstrom-2004][Vixie-20170704]。这些问题导致建议完全取消[沙利文级]，但2017年年中关于IETF列表和WGs的讨论表明，在这一问题上没有明确的共识。
The DNS model of master and slave servers, with the latter initiating updates based on expiration interval values, and local caches with updates based on TTL values, depends heavily on an approach that has come to be called "loose synchronization", i.e., that there can be no expectation that all of the servers that might reasonably answer a query will have exactly the same data unless those data have been unchanged for a rather long period. Put differently, if some or all of the records associated with a particular node in the DNS
主服务器和从服务器的DNS模型（后者根据过期间隔值启动更新）和本地缓存（根据TTL值进行更新）严重依赖于一种被称为“松散同步”的方法，即。，除非这些数据在相当长的一段时间内保持不变，否则不可能期望所有可能合理地回答查询的服务器都具有完全相同的数据。换句话说，如果与DNS中特定节点关联的部分或所有记录
(informally, a fully qualified domain name (FQDN)) change, one cannot expect those changes to be propagated immediately.
（非正式地说，一个完全限定的域名（FQDN））改变了，人们不能期望这些改变立即传播。
That model has worked rather well since the DNS was first deployed, protecting the system from requirements for mechanisms that are typical where a simultaneous update of multiple systems is needed. Such mechanisms include elaborate locking, complex update procedures and handshaking, or journaling. As has often been pointed out with the Internet, implementation and operational complexity are often the enemy of stability, security, and robustness. Loose synchronization has helped keep the DNS as simple and robust as possible.
自DNS首次部署以来，该模型工作得相当好，保护系统不受需要同时更新多个系统的典型机制要求的影响。这些机制包括复杂的锁定、复杂的更新过程和握手或日志记录。正如人们在互联网上经常指出的那样，实现和操作的复杂性往往是稳定性、安全性和健壮性的敌人。松散的同步有助于保持DNS尽可能简单和健壮。
A number of recent ideas about using the DNS to store data for which important changes occur very rapidly are, however, largely incompatible with loose synchronization. Efforts to use very short (or zero) refresh times (in SOA records for slave updates from masters) and TTLs (for caches) to simulate nearly simultaneous updating may work up to a point but appear to impose very heavy loads on servers and distribution mechanisms that were not designed to accommodate that style of working. Similar observations can be made about attempts to use the NOTIFY extension [RFC1996] or dynamic, "server-push", updating rather than the traditional DNS mechanisms. While the NOTIFY and push mechanisms normally provide refresh times and update mechanisms faster than those specified in RFCs 1034 and 1035, they imply that a "master" server must know the identities of (and have good connectivity to all of) its slaves. That defeats at least some of the advantages associated with stealth slaves, particularly those associated with reduction of query traffic across the Internet. Those mechanisms do nothing for cache updates: unless servers keep track of the source of every query for names associated with a specific zone and then somehow notify the query source systems, the only alternative to having information that might be obsolete stored in caches is to use very short or zero TTLs so the cached data time out almost immediately after being stored (or are not stored at all), requiring a new query to an authoritative server each time a resolver attempts to look up a name.
然而，最近关于使用DNS来存储数据的一些想法在很大程度上与松散同步不兼容，因为这些数据的重要更改会非常迅速地发生。使用非常短（或零）的刷新时间（在主服务器的从属更新的SOA记录中）和TTL（用于缓存）来模拟几乎同时更新的努力可能会在一定程度上起作用，但似乎会对服务器和分发机制施加非常重的负载，而这些服务器和分发机制的设计并不能适应这种工作方式。对于尝试使用NOTIFY扩展[RFC1996]或动态“服务器推送”更新而不是传统的DNS机制，也可以进行类似的观察。虽然通知和推送机制通常提供的刷新时间和更新机制比RFCs 1034和1035中指定的要快，但它们意味着“主”服务器必须知道其从属服务器的身份（并与所有从属服务器具有良好的连接）。这至少挫败了隐形奴隶的一些优势，特别是那些与减少互联网上的查询流量相关的优势。这些机制对缓存更新没有任何作用：除非服务器跟踪与特定区域关联的名称的每个查询的源，然后以某种方式通知查询源系统，将可能过时的信息存储在缓存中的唯一替代方法是使用非常短或零的TTL，这样缓存的数据在存储（或根本不存储）后几乎立即超时，每次解析程序尝试查找名称时都需要向权威服务器进行新的查询。
Almost since the DNS was first deployed, there have been situations in which it is desirable to use DNS-like names, and often DNS resolution mechanisms or modifications of them, with namespaces for which globally available and consistent resolution using the public DNS is either unfeasible or undesirable (and for which the use of CLASS is not an appropriate mechanism). The need to isolate names and addresses on LANs from the public Internet, typically via "split horizon" approaches, is one example of this requirement although often not recognized as such. Another example that has generated a
几乎自DNS首次部署以来，就出现了希望使用类似DNS的名称以及DNS解析机制或其修改的情况，其中使用公共DNS进行全局可用和一致解析的名称空间是不可行或不可取的（并且类的使用不是一种合适的机制）。通常通过“拆分地平线”方法将局域网上的名称和地址与公共互联网隔离的需要就是这一要求的一个例子，尽管通常不被认为是这样。另一个例子产生了
good deal of controversy involves "special names" -- labels or pseudo-labels, often in TLD positions, that signal that the full name should not be subject to normal DNS resolution or other processing [RFC6761] [RFC8244].
大量争议涉及“特殊名称”——标签或伪标签，通常位于TLD位置，表示全名不应接受正常DNS解析或其他处理[RFC6761][RFC8244]。
Independent of troublesome policy questions about who should allocate such names and the procedures to be used, they almost inherently require either a syntax convention to identify them (there actually was such a convention, but it was abandoned many years ago and there is no plausible way to reinstitute it) or tables of such names that are known to, and kept updated on, every resolver on the Internet, at least if spurious queries to the root servers are to be avoided.
独立于关于谁应该分配这些名称和要使用的程序的棘手政策问题，它们几乎本质上需要一个语法约定来识别它们（实际上有这样一个约定，但它在多年前就被放弃了，并且没有合理的方法来重新建立它）或者是互联网上每个解析器都知道并不断更新的此类名称的表，至少要避免对根服务器的虚假查询。
If the DNS were to be redesigned and replaced, we could recognize this requirement as part of the design and handle it much better than it is possible to handle it today.
如果重新设计和更换DNS，我们可以将此需求视为设计的一部分，并比今天更好地处理它。
The DNS specifies formats for queries and data responses, based on the state of the art and best practices at the time it was designed. Recent work has suggested that there would be significant advantages to supporting at least a description of the DNS messages in one or more alternate formats, such as JSON [Hoffman-DNS-JSON] [Hoffman-SimpleDNS-JSON]. While that work has been carefully done to avoid requiring changes to the DNS, much of the argument for having such a JSON-based description format could easily be turned into an argument that, if the DNS were being revised, that format might be preferable as a more direct alternative to having DNS queries and responses in the original form.
DNS根据设计时的最新技术和最佳实践，指定查询和数据响应的格式。最近的工作表明，至少以一种或多种替代格式支持DNS消息的描述，例如JSON[Hoffman DNS JSON][Hoffman SimpleDNS JSON]，将具有显著的优势。虽然这项工作已经仔细完成，以避免需要更改DNS，但使用这种基于JSON的描述格式的许多论点可以很容易地转化为一个论点，即如果DNS正在修改，那么这种格式可能会比使用原始形式的DNS查询和响应更直接。
The DNS model requires a collection of root servers that hold, at minimum, information about top-level domains. Over the years, that requirement has evolved from a technically fairly minor function, normally carried out as a service to the broader Internet community and its users and systems, to a subject that is intensely controversial with regard to control of those servers, including how they should be distributed and where they should be located. While a number of mechanisms, most recently including making the information more local [RFC7706], have been proposed and one (anycast [RFC7094]) is in very active use to mitigate some of the real and perceived problems, it seems obvious that a DNS successor, designed for today's global Internet and perceived requirements, could handle these problems in a technically more appropriate and less controversial way. Some additional discussion of the issues involved appears in a recent paper [Huston2017b].
DNS模型需要一组根服务器，这些根服务器至少包含顶级域的信息。多年来，这一要求已从技术上相当次要的功能，通常是作为对更广泛的互联网社区及其用户和系统的服务，演变为一个在这些服务器的控制方面引起激烈争议的问题，包括这些服务器应如何分布以及它们应位于何处。虽然已经提出了许多机制，最近包括使信息更本地化[RFC7706]，其中一种（anycast[RFC7094]）正在积极使用，以缓解一些实际和感知的问题，但很明显，DNS的继任者是为当今的全球互联网和感知需求而设计的，可以以技术上更合适、争议更少的方式处理这些问题。最近的一篇论文[Huston2017b]对所涉及的问题进行了一些补充讨论。
A key design element of the original network object naming systems for the ARPANET, largely inherited by the DNS, was that the names, while expected to be mnemonic, were identifiers and their being highly distinguishable and not prone to ambiguity was important. That led to restrictive rules about what could appear in a name. Those restrictions originated with the host table and even earlier [RFC0236] [RFC0247] and came to the DNS (largely via SMTP) as the "preferred syntax" (RFC 1034, Section 3.5) or what we now often call the letter-digit-hyphen (LDH) rule. Similar rules to make identifiers easier to use, less prone to ambiguity, or less likely to interfere with syntax occur frequently in more formal languages. For example, almost every programming language has restrictions on what can appear in an identifier, and Unicode provides general recommendations about identifier composition [Unicode-USA31]. Both are quite restrictive as compared to the number of characters and total number of strings that can be written using that character coding system.
最初的ARPANET网络对象命名系统主要由DNS继承，其一个关键设计元素是，这些名称虽然被认为是助记符，但却是标识符，它们的高度可分辨性和不易产生歧义非常重要。这导致了关于名字中可能出现的内容的限制性规则。这些限制源于主机表，甚至更早的[RFC0236][RFC0247]，并作为“首选语法”（RFC 1034，第3.5节）或我们现在经常称之为字母数字连字符（LDH）规则来到DNS（主要通过SMTP）。类似的规则使标识符更易于使用，不易产生歧义，或不太可能干扰语法，这些规则在更正式的语言中经常出现。例如，几乎每种编程语言都对标识符中可能出现的内容有限制，Unicode提供了关于标识符组合的一般建议[Unicode-USA31]。与使用该字符编码系统可以写入的字符数和字符串总数相比，两者都有很大的限制。
That model, which originally prohibited labels starting with digits in order to avoid any possible confusion with IP addresses, began to break down in 1987 or 1988 when a company named 3Com wanted to use its corporate name as a label within the COM TLD, and the rule was relaxed [RFC1123].
该模式最初禁止以数字开头的标签，以避免与IP地址的任何可能混淆，但在1987年或1988年，一家名为3Com的公司希望在COM TLD中使用其公司名称作为标签，该规则被放宽[RFC1123]。
In the last decade or two, the perspective that company names should be supported if possible has expanded and done so largely without its limits, if any, being explicitly understood or acknowledged. In the current form, the DNS is really (and primarily) a system for expressing thoughts and concepts. Those include free expression of ideas in as close to natural language as possible as well as representation of product names and brands. That view requires letter-like characters that might not be reasonable in identifiers along with a variety of symbols and punctuation. It may also require indicators of preferred type styles to provide information in a form that exactly matches personal or legal preferences. At least if carried to an extreme, that perspective would argue for standardizing word and sentence separators, removing the limit of 63 octets per label and probably the limit of 255 octets on the total length of a domain name, and perhaps even eliminating the hierarchy or allowing separators for labels in presentation form (now fixed at "." for the DNS) to be different according to context. It suggests that, at least, the original design was defective in not prioritizing those uses over the more restrictive approach associated with prioritizing unique and unambiguous identifiers.
在过去的十年或二十年中，如果可能的话，公司名称应该得到支持的观点已经扩大，并且在很大程度上没有受到明确理解或承认的限制（如果有的话）。在当前的形式中，DNS实际上（主要）是一个表达思想和概念的系统。其中包括尽可能用自然语言自由表达想法，以及代表产品名称和品牌。这种观点需要类似字母的字符，这些字符在标识符中可能不合理，还需要各种符号和标点符号。它还可能要求首选类型样式的指示符以与个人或法律偏好完全匹配的形式提供信息。至少，如果将这一观点发挥到极致，它将支持标准化单词和句子分隔符，取消每个标签63个八位字节的限制，可能取消域名总长度255个八位字节的限制，甚至可能取消层次结构或允许在表示形式中使用标签分隔符（现在固定为“）对于DNS），将根据上下文而有所不同。它表明，至少，原始设计在没有优先考虑这些用途方面存在缺陷，而不是与优先考虑唯一和明确标识符相关的更严格的方法。
So we have two or, depending on how one counts, three very different use cases. The historical one is support for unique identifiers. The other is expression of ideas and, if one considers them separate, presentation of brand and product names. Because they inherently involve different constraints, priorities, and success criteria, these perspectives are, at best, only loosely compatible.
因此，我们有两个或三个非常不同的用例，具体取决于一个用例的计算方式。历史的一个是对唯一标识符的支持。另一种是想法的表达，如果认为它们是分开的，则是品牌和产品名称的表达。因为它们内在地涉及不同的约束、优先级和成功标准，所以这些观点充其量只是松散兼容的。
We cannot simultaneously optimize both the identifier perspective and either or both of the others in the same system. At best, there are some complex trade-offs involved. Even then, it is not clear that the same DNS (or other system) can accommodate all of them. Until we come to terms with that, the differences manifest themselves with friction among communities, most often with tension between "we want to do (or use or sell) these types of labels" and "not good for the operational Internet or the DNS".
我们不能同时优化标识符透视图和同一系统中的其他透视图中的一个或两个。充其量也有一些复杂的权衡。即使如此，也不清楚同一个DNS（或其他系统）是否可以容纳所有这些DNS。在我们接受这一点之前，差异表现为社区之间的摩擦，通常表现为“我们想做（或使用或销售）这些类型的标签”和“不利于运营互联网或DNS”之间的紧张关系。
A good many Internet policy discussions in the last two decades have revolved around such questions of how many top-level domains there should be, what they should be, who should control them and how, how (or if) their individual operations and policy decisions should be accountable to others, and what processes should be used (and by what entities or organizational structures) to make those decisions. Several people have pointed out that, if we were designing a next-generation DNS using today's technology, it should be possible to remove the technical requirement for a central authority over the root (some people have suggested that blockchain approaches would be helpful for this purpose; others believe they just would not scale adequately, at least at acceptable cost, but that other options are possible). Whether elimination of a single, centrally controlled, root would be desirable or not is fairly obviously a question of perspective and priorities.
在过去二十年中，许多互联网政策讨论都围绕着这样的问题展开：应该有多少顶级域名，应该是什么域名，谁应该控制这些域名，以及如何、如何（或是否）对他人负责，以及应该使用什么流程（以及通过什么实体或组织结构）来做出这些决定。一些人指出，如果我们使用今天的技术设计下一代DNS，那么应该可以取消对根目录上的中央权限的技术要求（一些人认为区块链方法有助于实现这一目标；另一些人认为它们无法充分扩展，至少成本可以接受，但其他选择是可能的）。消除单一、中央控制的根源是否可取，显然是一个观点和优先事项的问题。
New work done in other areas has led to demands for new DNS features, many of them involving data values that require recursively referencing the DNS. Early record types that did that were accompanied by restrictions that reduced the risk of looping references or other difficulties. For example, while the MX RRTYPE has a fully qualified domain name as its data, SMTP imposes "primary name" restrictions that prevent the name used from being, e.g., a CNAME. While loops with CNAMEs are possible, Section 3.6 of RFC 1034 includes a discussion about ways to avoid problems and how they should be handled. Some newer protocols and conventions can cause more stress. There are separate issues with additions and with how the DNS has been extended to try to deal with them.
在其他领域所做的新工作导致了对新DNS功能的需求，其中许多涉及需要递归引用DNS的数据值。这样做的早期记录类型伴随着减少循环引用风险或其他困难的限制。例如，虽然MX RRTYPE有一个完全限定的域名作为其数据，但SMTP施加了“主要名称”限制，以防止使用的名称成为CNAME等名称。虽然可以使用CNAMEs进行循环，但RFC 1034第3.6节讨论了避免问题的方法以及应如何处理这些问题。一些较新的协议和约定可能会造成更大的压力。关于添加和DNS如何扩展以尝试处理它们，存在着不同的问题。
Some examples of DNS extensions for new protocol demands that illustrate, or have led to, increased stress include:
针对新协议需求的DNS扩展的一些示例说明或导致压力增加，包括：
NAPTR: Requires far more complex data in the DNS for ENUM (e.g., Voice over IP (VoIP), specifically SIP) support, including URI information and hence recursive or repeated lookups, than any of the RRTYPEs originally supported. The RRSET associated with these records can become quite large because the separator between the various records is part of the RDATA, and not the {owner, class, type} triple (a problem slightly related to the problem with overloading of TXT RRTYPE discussed in Section 3.13.2). This problem, and similar ones for some of the cases below. may suggest that any future design is in need of a different TYPE model such as systematic arrangements for subtypes or some explicit hierarchy in the TYPEs.
NAPTR：需要DNS中更复杂的数据来支持枚举（例如，IP语音（VoIP），特别是SIP），包括URI信息，因此需要递归或重复查找，而不是最初支持的任何RRT类型。与这些记录相关联的RRSET可能变得相当大，因为不同记录之间的分隔符是RDATA的一部分，而不是{owner，class，type}三元组（这个问题与第3.13.2节讨论的TXT RRTYPE重载问题稍有关联）。这个问题，以及下面一些情况下的类似问题。可能表明未来的任何设计都需要不同的类型模型，例如子类型的系统安排或类型中的某些明确层次结构。
URI: Has a URI as its data, typically also requiring recursive or repeated lookups.
URI：有一个URI作为其数据，通常也需要递归或重复查找。
Service location (SRV) and credential information (including Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)): Require structured data and, especially for the latter two, significantly more data than most original RRTYPEs.
服务位置（SRV）和凭据信息（包括发件人策略框架（SPF）和域密钥标识邮件（DKIM））：需要结构化数据，尤其是后两种类型，比大多数原始RRV类型的数据要多得多。
URI/URL: The early design decision for the World Wide Web that its mechanism for identifying digital web content (now known as Uniform Resource Identifiers [RFC3986]) did so by using domain names and hence the network location of the information or other material. That, in turn, has required systems intended to improve web performance by locating and retrieving a "nearest copy" (rather than the single copy designated by the URL) to intercept DNS queries and respond with values that are not precisely those stored for the designated domain name in the DNS or to otherwise access information in a way not supported by the DNS itself.
URI/URL：万维网的早期设计决策，其识别数字网络内容的机制（现在称为统一资源标识符[RFC3986]）通过使用域名以及信息或其他材料的网络位置来实现。这反过来又要求系统通过定位和检索“最近的副本”（而不是URL指定的单个副本）来提高web性能拦截DNS查询并使用并非为DNS中指定域名存储的值进行响应，或者以DNS本身不支持的方式访问信息。
Unfortunately (but unsurprisingly), and despite IETF efforts to make things easier [RFC6895], DNS support libraries have often been slow to add full support for new RRTYPEs. This has impeded deployment of applications that depend on those types and that must ask (query) explicitly for them. Both to get faster deployment and, at least until recently, to avoid burdensome IETF approval procedures, many application designers have chosen to push protocol-critical
不幸的是（但并不奇怪），尽管IETF努力使事情变得更简单[RFC6895]，DNS支持库在添加对新RRT类型的完全支持方面往往进展缓慢。这阻碍了依赖于这些类型且必须显式请求（查询）它们的应用程序的部署。为了获得更快的部署，并且至少直到最近，为了避免繁琐的IETF批准程序，许多应用程序设计者都选择推动协议关键
information into records with TXT RRTYPE, a record type that was originally intended to include only information equivalent to comments.
使用TXT RRTYPE将信息转换为记录，该记录类型最初旨在仅包含与注释等效的信息。
This causes two problems. First, TXT records used this way tend to get long and complex, which is a problem in itself if one is trying to minimize TCP connections. Second, applications that are attempting to obtain data cannot merely ask for the relevant QTYPE; they must obtain all of the records with QTYPE TXT and parse them to determine which ones are of interest. That would be easier if there was some standard for how to do that parsing, but, at least in part because the clear preference in the DNS design is for distinct RRTYPEs for different kinds of information, there is no such standard. (There was a proposal in 1993 to structure the TXT DATA in a way that would have addressed the issue [RFC1464], but it apparently never went anywhere.)
这导致了两个问题。首先，以这种方式使用的TXT记录往往会变得长而复杂，如果试图最小化TCP连接，这本身就是一个问题。第二，试图获取数据的应用程序不能仅仅要求相关的QTYPE；他们必须获得QTYPE TXT的所有记录，并对其进行解析以确定感兴趣的记录。如果有一些关于如何进行解析的标准，这将更容易，但是，至少部分是因为DNS设计中明确的偏好是针对不同类型的信息使用不同的RRTYPE，因此没有这样的标准。（1993年，有人提议以一种能够解决这个问题的方式来构造TXT数据[RFC1464]，但显然从未付诸实施。）
On the other hand, this issue is somewhat different from most of the others described in this document because (as the IETF has recommended several times) the problem is easily solved within the current DNS design by allocating and supporting new RRTYPEs when needed rather than using TXT as a workaround (that does not mean that other solutions are impossible, either with the current DNS or with some other design). The problem then lies in the implementations and/or mechanisms that deter or impede rapid deployment of support for new RRTYPEs.
另一方面，该问题与本文档中描述的大多数其他问题有所不同，因为（正如IETF多次建议的那样）在当前DNS设计中，通过在需要时分配和支持新的RRTYPE，而不是使用TXT作为解决方法，可以轻松解决该问题（这并不意味着其他解决方案是不可能的，无论是使用当前的DNS还是其他设计）。问题在于阻止或阻碍快速部署新类型支持的实现和/或机制。
One of the DNS characteristics that is poorly understood by non-experts is that the period (".", U+002E) character can be used in four different ways:
非专家很少了解的DNS特征之一是，周期（“.”，U+002E）字符可以用四种不同的方式使用：
o As a label separator in the presentation form that also designates a "zone break" (delegation boundary). For example, foo.bar.example.com indicates the owner, "foo", of records in the "bar.example.com" zone.
o 作为演示表单中的标签分隔符，该分隔符还指定“区域分隔符”（委派边界）。例如，foo.bar.example.com表示“bar.example.com”区域中记录的所有者“foo”。
o As a label separator in the presentation form that does not designate a zone break. For example, foo.bar.example.com indicates the owner, "foo.bar", of records in the "example.com" zone.
o 作为表示形式中的标签分隔符，不指定区域分隔符。例如，foo.bar.example.com表示“example.com”区域中记录的所有者“foo.bar”。
o As a character within a label, including as a substitute for an at-sign ("@") when an email address appears in an SOA record or in a label that denotes such an address (see Section 2 above). The ability to embed periods in labels in this way has also led to attacks in which, e.g., a domain name consisting of the labels
o 作为标签中的一个字符，包括当电子邮件地址出现在SOA记录或表示此类地址的标签中时，作为at符号（“@”）的替代物（见上文第2节）。以这种方式在标签中嵌入句点的能力也导致了攻击，例如，由标签组成的域名
"example" followed by "com" is deliberately confused with the single label "example.com" with an embedded period.
“example”后跟“com”故意与带有嵌入句点的单个标签“example.com”混淆。
o At the end of a fully qualified domain name to designate the root zone, e.g., "example.com." (RFC 1034, Section 3.1).
o 在完全限定域名的末尾指定根区域，例如，“example.com.”（RFC 1034，第3.1节）。
In general, these cases cannot be distinguished by looking at them. The third is problematic for non-DNS reasons, e.g., "john.doe.example.net" can be interpreted as either a simple FQDN or as a notation for john@doe.example.net, john.doe@example.net, or even (at least in principle) john.doe.example@net.
一般来说，通过观察这些情况无法区分这些情况。第三个问题是由于非DNS原因，例如，“john.doe.example.net”可以解释为简单的FQDN或作为john@doe.example.net，约翰。doe@example.net，甚至（至少在原则上）约翰·多伊。example@net.
The distinction between the FQDN interpretation and the first email-like one was probably not important as the DNS was originally intended to be used. However, as soon as RRTYPEs (other than NS records that define the zone cut) are used that are sensitive to the boundaries between zones, the distinctions become important to people other than the relevant zone administrators. DNSSEC [RFC4033] involves one such set of relationships. It increases the importance of questions about what should go in a parent zone and what should go in child zones and how much difference it makes if NS records in a parent zone for a child zone are consistent with the records and data in the child zone. This also causes application issues and may raise questions about relationships between registrars and one or more registries or, if they are separate, DNS operators.
FQDN解释和第一封类似电子邮件的解释之间的区别可能并不重要，因为最初打算使用DNS。但是，一旦使用了对分区之间的边界敏感的RRTYPE（定义分区切割的NS记录除外），这些区别对于相关分区管理员以外的人就变得很重要。DNSSEC[RFC4033]涉及一组这样的关系。它增加了以下问题的重要性：父区域中应该包含哪些内容，子区域中应该包含哪些内容，以及如果子区域的父区域中的NS记录与子区域中的记录和数据一致，会产生多大的差异。这也会导致应用程序问题，并可能引发有关注册者和一个或多个注册中心之间的关系的问题，或者，如果它们是独立的，DNS运营商之间的关系问题。
The original design for DNS administration, reflected in RFC 1591 [RFC1591] and elsewhere, assumed that all domains would exhibit a very high level of responsibility toward and for the community and that level of responsibility would be enforced if necessary.
最初的DNS管理设计反映在RFC 1591[RFC1591]和其他地方，假设所有域对社区和对社区都表现出很高的责任水平，并且在必要时将强制执行该责任水平。
More recent decisions, many of them associated with commercialization of the DNS, have eroded those very strong assumptions of registry responsibility and accountability to the point that many consider decisions about delegation of names, identification of registrants, and relationships among names to be matters of "registrant beware" and even "user and applications beware". While some recent protocols and proposals at least partially reflect that original model of a high level of responsibility (see, e.g., IDNA [RFC5890] and a more recent discussion [Klensin-5891bis]), other decisions and actions tend to shift responsibility to the registrant or try to avoid accountability entirely. One possible approach to the problems, especially security problems, that are enabled by those new trends and the associated environment is to establish reputation systems associated with clearly defined administrative boundaries and with
最近的决策，其中许多与DNS的商业化有关，侵蚀了那些非常强烈的注册表责任和问责假设，以至于许多人认为关于名称的委派、注册人的识别以及姓名之间的关系的决定是“注册者小心”的问题，甚至是。“用户和应用程序当心”。虽然最近的一些协议和提案至少部分反映了高责任的原始模型（例如，参见IDNA[RFC5890]和最近的讨论[Klensin-5891bis]），其他决定和行动倾向于将责任转移给注册人或试图完全避免问责。解决这些新趋势和相关环境导致的问题，特别是安全问题的一种可能方法是建立与明确界定的行政边界相关的声誉体系与
warnings to users, even if those reputation systems are managed by parties not directly associated with the DNS.
向用户发出警告，即使这些信誉系统由与DNS不直接关联的各方管理。
The IETF DBOUND WG [IETF-DBOUND] addressed ways to establish and document boundaries more precise than simple dependencies on TLDs, but it was not successful in producing a standard.
IETF-DBOUND工作组[IETF-DBOUND]提出了比TLD上的简单依赖关系更精确地建立和记录边界的方法，但未能成功地制定标准。
A TLD reputation-based approach was adopted by some web browsers after IDNs and a growing number of Generic Top-Level Domains (gTLDs) were introduced; that approach was based on a simple list and does not scale to the current size of the DNS or even the DNS root.
在IDN和越来越多的通用顶级域（GTLD）被引入后，一些web浏览器采用了基于TLD信誉的方法；这种方法基于一个简单的列表，不能扩展到DNS的当前大小，甚至不能扩展到DNS根。
The original design for the DNS envisaged a simple query and response protocol where both the command and the response could be readily mapped into a single IP packet. The host requirements specification [RFC1123] required all DNS applications to accept a UDP query or response over UDP with up to 512 octets of DNS payload. TCP was seen as a fallback when the response was greater than this 512-octet limit, and this fallback to use TCP as the transport protocol was considered to be the exception rather than the rule.
DNS的原始设计设想了一个简单的查询和响应协议，其中命令和响应可以很容易地映射到单个IP数据包中。主机需求规范[RFC1123]要求所有DNS应用程序通过UDP接受UDP查询或响应，最多512个八位字节的DNS负载。当响应大于此512个八位字节限制时，TCP被视为回退，而将TCP用作传输协议的回退被视为例外而不是规则。
Over the intervening years, we have seen the rise of a common assumption of an Internet-wide Maximum Transmission Unit (MTU) size of 1,500 octets, accompanied with an assumption that UDP fragmentation is generally viable. This underpins the adoption of the Extension Mechanisms for DNS (EDNS(0)) [RFC6891] to, among other things, specify a UDP buffer size larger than 512 octets and a suggestion within that specification to use 4,096 as a suitable compromise for the UDP payload size. This has proved to be fortuitous for the DNSSEC security extensions where the addition of DNSSEC security credentials in DNS responses [RFC4034] can lead to the use of large DNS responses. However, this exposes some tensions over the handling of fragmentation in IP, where UDP fragments have been observed to be filtered by various firewalls. Additionally for IPv6, there are the factors of filtering the ICMPv6 Packet Too Big diagnostic messages and discarding the IPv6 packets that contain extension headers [RFC7872]. More generally, fragmented UDP packets appear to have a lower level of reliability than unfragmented TCP packets.
在这几年中，我们看到了一个普遍的假设，即互联网范围内的最大传输单元（MTU）大小为1500个八位字节，并伴随着一个假设，即UDP分段通常是可行的。这支持DNS（EDNS（0））[RFC6891]采用扩展机制，除其他外，指定大于512个八位字节的UDP缓冲区大小，并建议在该规范中使用4096作为UDP有效负载大小的合适折衷方案。事实证明，这对于DNSSEC安全扩展是偶然的，在DNS响应[RFC4034]中添加DNSSEC安全凭据可能会导致使用大型DNS响应。然而，这暴露了IP中碎片处理的一些紧张关系，在IP中UDP碎片被观察到被各种防火墙过滤。此外，对于IPv6，还存在过滤过大诊断消息的ICMPv6数据包和丢弃包含扩展头的IPv6数据包的因素[RFC7872]。更一般地说，碎片化UDP数据包的可靠性似乎低于未碎片化TCP数据包。
Behind this observation about relative reliability of delivery is the tension between the lightweight load of UDP and the downside of elevated probability of discarding of packet fragments as compared to TCP, which offers increased levels of assurance of content delivery, but with the associated imposition of TCP session state and the downside of reduced DNS scalability and increased operational cost.
与TCP相比，UDP的轻量级负载与丢弃数据包碎片的概率增加的缺点之间存在着紧张关系，后者提供了更高水平的内容交付保证，但是伴随着相关的TCP会话状态的强加以及DNS可伸缩性降低和运营成本增加的负面影响。
The requirement for an inverse lookup capability, i.e., the ability to find a domain name given an address and, in principle, to find the owner of a record by any of its data elements, was recognized in RFC 882. The feature was identified as optional but carried forward into RFCs 1034 and 1035 but was explicitly deprecated by RFC 1034 for address-to-hostname lookup (although RFC 1035 uses exactly that type of lookup in an example). Despite the discussion of inverted forms of the database in RFC 1035, inverse lookup has rarely, if ever, been implemented, at least in its general form. The fundamental difficulties with inverse lookup in either the form described in RFC 882 or the "in-addr.arpa" approach mentioned below are consistent with the problems described in fundamental papers on database management [Codd1970] but were not described in RFC 1035 or related contemporary IETF documents.
RFC 882中确认了反向查找功能的要求，即能够找到给定地址的域名，并且原则上能够通过记录的任何数据元素找到记录的所有者。该功能被标识为可选功能，但转入了RFC 1034和1035，但RFC 1034明确反对将其用于从地址到主机名的查找（尽管RFC 1035在示例中正是使用这种类型的查找）。尽管在RFC1035中讨论了数据库的反转形式，但反转查找很少（如果有的话）被实现，至少在一般形式上是如此。以RFC 882中所述的形式或下文所述的“in addr.arpa”方法进行反向查找的基本困难与数据库管理基础论文[Codd1970]中所述的问题一致，但RFC 1035或相关的当代IETF文件中没有描述。
It is interesting to speculate on how many of the current requirements to treat aliases as an integrated set of synonyms (e.g., for variant handling) would have been addressed if inverse lookups could reliably produce the owners of CNAME records.
有趣的是，如果反向查找能够可靠地生成CNAME记录的所有者，那么将别名视为一组完整的同义词（例如，变量处理）的当前需求中有多少能够得到满足。
At the same time, it was obviously important to have some mechanism for address-to-name resolution. It was provided by PTR RRTYPE entries in the IN-ADDR.ARPA zone, with delegations on octet boundaries. However, that approach required that information be maintained in parallel, in separate zones, for the name-to-address and address-to-name mappings. That synchronization requirement for two copies of essentially the same data was another popular topic in the database management literature a decade or more before the DNS and, predictably, led to many inconsistencies and other failures.
同时，显然有一些地址到名称的解析机制很重要。它由in-ADDR.ARPA区域中的PTR RRTYPE条目提供，并在八位字节边界上授权。然而，这种方法要求在单独的区域中并行维护名称到地址和地址到名称映射的信息。对基本相同数据的两个副本的同步要求是DNS出现前十年或更长时间数据库管理文献中的另一个热门话题，可以预见，这导致了许多不一致和其他故障。
The introduction of Classless Inter-Domain Routing (CIDR) [RFC1518] and Provider-Dependent addresses made the situation even more difficult, because it was no longer possible to delegate the administration of reverse mapping records for small networks to the actual operators of those networks. ISPs and other aggregators often had no incentive to maintain reverse mapping records consistent with network operator assignment of domain names. A proposal to use binary labels to work around that issue [RFC2673] was abandoned somewhat over three years later [RFC6891].
无类别域间路由（CIDR）[RFC1518]和依赖于提供商的地址的引入使得情况更加困难，因为不再可能将小型网络反向映射记录的管理委托给这些网络的实际运营商。ISP和其他聚合商通常没有动机维护与网络运营商域名分配一致的反向映射记录。一项使用二进制标签解决该问题的提议[RFC2673]在三年后被放弃[RFC6891]。
Independent of how much or little harm the absence of a general inverse lookup facility has caused and how effective the "in-addr.arpa" approach has been, inverse lookup remains a facility that was anticipated and known to be useful in the original DNS design but that has never been fully realized.
无论缺少通用反向查找功能造成的危害有多大或有多小，以及“in addr.arpa”方法的有效性如何，反向查找仍然是一种在原始DNS设计中预期和已知有用但从未完全实现的功能。
In addition to the stresses caused by the new functions, including those described in Section 3.13, incremental deployment of systems that utilize them means that some functions will work in some environments and not others. This has been especially problematic with complex, multi-record, capabilities like DNSSEC that provide or require special validation mechanisms and with some EDNS(0) extensions [RFC6891] that require both the client and server to accept particular extensions. When DNS functionality is required in embedded devices, deployment of new features across the entire Internet in a reasonable period of time is nearly impossible.
除了新功能（包括第3.13节中描述的功能）造成的压力外，使用这些功能的系统的增量部署意味着某些功能将在某些环境中工作，而不是在其他环境中工作。对于提供或需要特殊验证机制的DNSSEC等复杂、多记录的功能，以及要求客户端和服务器都接受特定扩展的某些EDN（0）扩展[RFC6891]，这一问题尤其严重。当嵌入式设备需要DNS功能时，在合理的时间内在整个互联网上部署新功能几乎是不可能的。
If one were redesigning the DNS, one could imagine ways to address these issues that would make them slightly more tractable, and, of course, the features that are known to be necessary today could become part of the baseline, "mandatory to implement", specification.
如果重新设计DNS，可以设想解决这些问题的方法，使其更易于处理，当然，现在已知的必要功能可能成为基线“强制实施”规范的一部分。
Some of the issues identified above might reasonably be addressed, not by changing the DNS itself but by changing our model of what it is about and how it is used. Specifically, one key assumption when the DNS (and the host table system before it) was designed was that it was a naming system for network resources, not, e.g., digital content. As such, exact matching was important, it was reasonable to have labels treated as mnemonics that did not necessarily have linguistic or semantic meaning except to those using them, and so on. A return to that model, presumably by having user-facing applications call on an intermediate layer to disambiguate user-friendly names and map them to DNS names (or network object locators more generally), would significantly reduce stress on the DNS and would also allow dealing with types of matching and similar or synonymous strings that cannot be handled algorithmically no matter how much DNS matching rules were altered.
上面提到的一些问题可能会得到合理的解决，不是通过更改DNS本身，而是通过更改我们关于DNS的内容和使用方式的模型。具体而言，设计DNS（以及之前的主机表系统）时的一个关键假设是，它是网络资源的命名系统，而不是数字内容。因此，精确匹配很重要，将标签视为助记符是合理的，这些助记符除了对使用它们的人以外，不一定具有语言或语义意义，等等。回归到该模型，可能是让面向用户的应用程序在中间层上调用，以消除用户友好名称的歧义，并将其映射到DNS名称（或更普遍的网络对象定位器），将显著减少对DNS的压力，并允许处理匹配类型和类似或同义字符串，无论DNS匹配规则有多大程度的更改，这些字符串都无法通过算法处理。
In some respects, search engines based on free-text analysis and linkages among information have come to serve many of the functions of such an intermediate layer. Many studies and sources have pointed out that few users actually understand, much less care about, the distinction between a DNS name and a search term. Recent versions of some web browsers have both recognized the failure of that distinction and reinforced it by eliminating the separation between "URL" and "search bar".
在某些方面，基于自由文本分析和信息之间联系的搜索引擎已经开始发挥这种中间层的许多功能。许多研究和资料指出，很少有用户真正理解DNS名称和搜索词之间的区别，更不用说关心了。一些网络浏览器的最新版本已经认识到这种区别的失败，并通过消除“URL”和“搜索栏”之间的分离来加强这种区别。
It is worth noting that, while that "search" approach, or some other approach that abstracted and separated several of the issues identified in Section 3 from the DNS protocol and database themselves, it does not address all of them. At least some elements of several of those issues, such as the synchronization ones described in Section 3.7 and the transport ones described in Section 3.15, are inherent in the DNS design, and, if we are not going to replace the DNS, we had best get used to them.
值得注意的是，虽然这种“搜索”方法，或其他一些将第3节中确定的几个问题从DNS协议和数据库本身抽象和分离出来的方法，但它并没有解决所有问题。这些问题中至少有一些是DNS设计中固有的，如第3.7节中描述的同步问题和第3.15节中描述的传输问题，如果我们不打算更换DNS，我们最好习惯它们。
In the early part of the last decade, the IETF engaged in some preliminary exploration of the intermediate-layer approach in the context of IDNs and what were then called "Internet keywords" [DNS-search]. While that exploratory effort met several times informally, it never became an organized IETF activity, largely because of the choice of what became the IDNA approach but also in part by signs that the "Internet keywords" efforts were beginning to fall apart.
在过去十年的早期，IETF在IDN和所谓的“互联网关键词”[DNS搜索]的背景下对中间层方法进行了一些初步探索。虽然这项探索性工作非正式地进行了数次，但它从未成为一项有组织的IETF活动，这主要是因为选择了后来的IDNA方法，但部分原因是有迹象表明“互联网关键词”工作开始分崩离析。
It may be time to reexamine intermediate-layer approaches. If so,
the effort should examine use of those approaches by appropriate
user-facing applications that might be used to address some of the
issues identified above. The Internet and the DNS have changed
considerably since the 2000-2003 period. Several of those changes
are discussed elsewhere in this document; others, including
repurposing of the DNAME RRTYPE from support for transitions
[RFC2672] to a general-purpose mechanism for aliases of subtrees
[RFC6672] and the addition of over a thousand new TLDs
[IANA-TLD-registry], are not but nonetheless are part of the context
for intermediate-layer work that did not exist in 2003.
It may be time to reexamine intermediate-layer approaches. If so,
the effort should examine use of those approaches by appropriate
user-facing applications that might be used to address some of the
issues identified above. The Internet and the DNS have changed
considerably since the 2000-2003 period. Several of those changes
are discussed elsewhere in this document; others, including
repurposing of the DNAME RRTYPE from support for transitions
[RFC2672] to a general-purpose mechanism for aliases of subtrees
[RFC6672] and the addition of over a thousand new TLDs
[IANA-TLD-registry], are not but nonetheless are part of the context
for intermediate-layer work that did not exist in 2003.
A wide range of security issues related to both securing the DNS and also to abilities to use namespaces for nefarious purposes have arisen. Issues of securing the DNS would obviously be essential to a replacement of the DNS. Issues of preventing nefarious use of the namespace (e.g. use of the name that appears or disappears as a signal to bots) would appear to be harder to solve within the naming system.
出现了一系列安全问题，这些问题既涉及到DNS的安全，也涉及到为恶意目的使用名称空间的能力。DNS的安全问题对于DNS的替换显然是至关重要的。在命名系统中，防止恶意使用名称空间（例如，使用出现或消失的名称作为机器人程序的信号）的问题似乎更难解决。
[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>.
[CACM-Homograph] Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", Communications of the ACM, Volume 45, Issue 2, pp. 128, DOI 10.1145/503124.503156, February 2002, <http://www.cs.technion.ac.il/~gabr/papers/ homograph_full.pdf>.
[CACM同形词]Gabrilovich，E.和A.Gontmakher，“同形词攻击”，ACM通讯，第45卷，第2期，第128页，DOI 10.1145/503124.503156，2002年2月<http://www.cs.technion.ac.il/~gabr/papers/homograph\u full.pdf>。
[Cerf2017] Cerf, V., "Desirable Properties of Internet Identifiers", IEEE Internet Computing, Volume 21, Issue 6, pp. 63-64, DOI 10.1109/MIC.2017.4180839, November/December 2017.
[Cerf2017]Cerf，V.，“互联网标识符的理想属性”，IEEE互联网计算，第21卷，第6期，第63-64页，DOI 10.1109/MIC.2017.4180839，2017年11月/12月。
[Codd1970] Codd, E., "A Relational Model of Data for Large Shared Data Banks", Communications of the ACM, Volume 13, Issue 6, pp. 377-387, DOI 10.1145/362384.362685, June 1970, <https://dl.acm.org/citation.cfm?id=362685>.
[Codd1970]Codd，E.，“大型共享数据库的数据关系模型”，《ACM通讯》，第13卷，第6期，第377-387页，DOI 10.1145/362384.3626851970年6月<https://dl.acm.org/citation.cfm?id=362685>.
[DNS-Aliases] Woolf, S., Lee, X., and J. Yao, "Problem Statement: DNS Resolution of Aliased Names", Work in Progress, draft-ietf-dnsext-aliasing-requirements-01, March 2011.
[DNS别名]Woolf，S.，Lee，X.，和J.Yao，“问题陈述：别名的DNS解析”，正在进行的工作，草稿-ietf-dnsext-aliasing-requirements-012011年3月。
[DNS-BNAME] Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name Redirection", Work in Progress, draft-yao-dnsext-bname-06, May 2016.
[DNS-BNAME]Yao，J.，Lee，X.，和P.Vixie，“捆绑DNS名称重定向”，正在进行的工作，草稿-Yao-dnsext-BNAME-062016年5月。
[DNS-search] IETF, "Internet Resource Name Search Service (IRNSS)", 2003, <https://datatracker.ietf.org/wg/irnss/about/>.
[DNS搜索]IETF，“互联网资源名称搜索服务（IRNSS）”，2003年<https://datatracker.ietf.org/wg/irnss/about/>.
[Faltstrom-2004] Faltstrom, P. and R. Austein, "Design Choices When Expanding DNS", Work in Progress, draft-ymbk-dns-choices-00, May 2004.
[Faltstrom-2004]Faltstrom，P.和R.Austein，“扩展DNS时的设计选择”，正在进行的工作，草稿-ymbk-DNS-Choices-00，2004年5月。
[Hoffman-DNS-JSON] Hoffman, P., "Representing DNS Messages in JSON", Work in Progress, draft-hoffman-dns-in-json-13, October 2017.
[Hoffman DNS JSON]Hoffman，P.，“用JSON表示DNS消息”，正在进行的工作，草稿-Hoffman-DNS-in-JSON-132017年10月。
[Hoffman-SimpleDNS-JSON] Hoffman, P., "Simple DNS Queries and Responses in JSON", Work in Progress, draft-hoffman-simplednsjson-01, November 2017.
[Hoffman SimpleDNS JSON]Hoffman，P.，“JSON中的简单DNS查询和响应”，正在进行的工作，草稿-Hoffman-simplednsjson-01，2017年11月。
[Huston2017a] Huston, G. and J. Silva Dama, "DNS Privacy", The Internet Protocol Journal, Vol. 20, No. 1, March 2017, <http://ipj.dreamhosters.com/wp-content/uploads/ issues/2017/ipj20-1.pdf>.
[Huston2017a]Huston，G.和J.Silva Dama，“DNS隐私”，互联网协议杂志，第20卷，第1期，2017年3月<http://ipj.dreamhosters.com/wp-content/uploads/ issues/2017/ipj20-1.pdf>。
[Huston2017b] Huston, G., "The Root of the Domain Name System", The Internet Protocol Journal, Vol. 20, No. 2, pp. 15-25, June 2017, <http://ipj.dreamhosters.com/wp-content/uploads/ 2017/08/ipj20-2.pdf>.
[Huston2017b]Huston，G.，“域名系统的根”，《互联网协议杂志》，第20卷，第2期，第15-25页，2017年6月<http://ipj.dreamhosters.com/wp-content/uploads/ 2017/08/ipj20-2.pdf>。
[IANA-TLD-registry] Internet Assigned Numbers Authority (IANA), "Root Zone Database", <https://www.iana.org/domains/root/db>.
[IANA TLD注册表]互联网分配号码管理局（IANA），“根区域数据库”<https://www.iana.org/domains/root/db>.
[ICANN-VIP] ICANN, "IDN Variant Issues Project: Final Integrated Issues Report Published and Proposed Project Plan for Next Steps is Now Open for Public Comment", February 2012, <https://www.icann.org/news/announcement-2012-02-20-en>.
[ICANN-VIP]ICANN，“IDN变体问题项目：发布的最终综合问题报告和下一步的拟议项目计划现已公开征求公众意见”，2012年2月<https://www.icann.org/news/announcement-2012-02-20-en>.
[IETF-DBOUND] IETF, "Domain Boundaries (dbound)", 2017, <https://datatracker.ietf.org/wg/dbound/about/>.
[IETF-DBOUND]IETF，“域边界（DBOUND）”，2017年<https://datatracker.ietf.org/wg/dbound/about/>.
[Klensin-5891bis] Klensin, J. and A. Freytag, "Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations", Work in Progress, draft-klensin-idna-rfc5891bis-01, September 2017.
[Klensin-5891bis]Klensin，J.和A.Freytag，“应用程序中的国际化域名（IDNA）：注册限制和建议”，正在进行的工作，草稿-Klensin-IDNA-rfc5891bis-012017年9月。
[Mockapetris-1988] Mockapetris, P. and K. Dunlap, "Development of the Domain Name System", SIGCOMM '88 Symposium, pp. 123-133, available from ISI Reprint Series, ISI/RS-88-219 <ftp://ftp.isi.edu/isi-pubs/rs-88-219.pdf>, DOI 10.1145/52324.52338, August 1988, <http://dl.acm.org/citation.cfm?id=52338>.
[Mockapetris-1988]Mockapetris，P.和K.Dunlap，“域名系统的开发”，SIGCOMM'88研讨会，第123-133页，可从ISI重印系列ISI/RS-88-219获得<ftp://ftp.isi.edu/isi-pubs/rs-88-219.pdf>，DOI 10.1145/52324.523381988年8月<http://dl.acm.org/citation.cfm?id=52338>.
[NRC-Signposts] National Research Council, Signposts in Cyberspace: The Domain Name System and Internet Navigation, ISBN 0-309-54979-5, 2005, <https://www.nap.edu/ catalog/11258/signposts-in-cyberspace-the-domain-name-system-and-internet-navigation>.
[NRC路标]国家研究委员会，《网络空间中的路标：域名系统和互联网导航》，ISBN 0-309-54979-52005<https://www.nap.edu/ catalog/11258/signposts in cyberspace域名系统和互联网导航>。
[RFC0236] Postel, J., "Standard host names", RFC 236, DOI 10.17487/RFC0236, September 1971, <https://www.rfc-editor.org/info/rfc236>.
[RFC0236]Postel，J.，“标准主机名”，RFC 236，DOI 10.17487/RFC0236，1971年9月<https://www.rfc-editor.org/info/rfc236>.
[RFC0247] Karp, P., "Proffered set of standard host names", RFC 247, DOI 10.17487/RFC0247, October 1971, <https://www.rfc-editor.org/info/rfc247>.
[RFC0247]Karp，P.，“提供的标准主机名集”，RFC 247，DOI 10.17487/RFC0247，1971年10月<https://www.rfc-editor.org/info/rfc247>.
[RFC0799] Mills, D., "Internet name domains", RFC 799, DOI 10.17487/RFC0799, September 1981, <https://www.rfc-editor.org/info/rfc799>.
[RFC0799]Mills，D.，“互联网域名”，RFC 799，DOI 10.17487/RFC0799，1981年9月<https://www.rfc-editor.org/info/rfc799>.
[RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD Internet host table specification", RFC 810, DOI 10.17487/RFC0810, March 1982, <https://www.rfc-editor.org/info/rfc810>.
[RFC0810]Feinler，E.，Harrenstien，K.，Su，Z.，和V.White，“国防部互联网主机表规范”，RFC 810，DOI 10.17487/RFC0810，1982年3月<https://www.rfc-editor.org/info/rfc810>.
[RFC0881] Postel, J., "Domain names plan and schedule", RFC 881, DOI 10.17487/RFC0881, November 1983, <https://www.rfc-editor.org/info/rfc881>.
[RFC0881]Postel，J.，“域名计划和时间表”，RFC 881，DOI 10.17487/RFC08811983年11月<https://www.rfc-editor.org/info/rfc881>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, <https://www.rfc-editor.org/info/rfc882>.
[RFC0882]Mockapetris，P.，“域名：概念和设施”，RFC 882，DOI 10.17487/RFC0882，1983年11月<https://www.rfc-editor.org/info/rfc882>.
[RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>.
[RFC0883]Mockapetris，P.，“域名：实现规范”，RFC 883，DOI 10.17487/RFC0883，1983年11月<https://www.rfc-editor.org/info/rfc883>.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC0952]Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，DOI 10.17487/RFC0952，1985年10月<https://www.rfc-editor.org/info/rfc952>.
[RFC0953] Harrenstien, K., Stahl, M., and E. Feinler, "Hostname Server", RFC 953, DOI 10.17487/RFC0953, October 1985, <https://www.rfc-editor.org/info/rfc953>.
[RFC0953]Harrenstien，K.，Stahl，M.和E.Feinler，“主机名服务器”，RFC 953，DOI 10.17487/RFC0953，1985年10月<https://www.rfc-editor.org/info/rfc953>.
[RFC0974] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986, <https://www.rfc-editor.org/info/rfc974>.
[RFC0974]帕特里奇，C.，“邮件路由和域系统”，STD 10，RFC 974，DOI 10.17487/RFC0974，1986年1月<https://www.rfc-editor.org/info/rfc974>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<https://www.rfc-editor.org/info/rfc1123>.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, DOI 10.17487/RFC1464, May 1993, <https://www.rfc-editor.org/info/rfc1464>.
[RFC1464]Rosenbaum，R.，“使用域名系统存储任意字符串属性”，RFC 1464，DOI 10.17487/RFC1464，1993年5月<https://www.rfc-editor.org/info/rfc1464>.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518, September 1993, <https://www.rfc-editor.org/info/rfc1518>.
[RFC1518]Rekhter，Y.和T.Li，“具有CIDR的IP地址分配架构”，RFC 1518，DOI 10.17487/RFC1518，1993年9月<https://www.rfc-editor.org/info/rfc1518>.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, <https://www.rfc-editor.org/info/rfc1591>.
[RFC1591]Postel，J.，“域名系统结构和授权”，RFC 1591，DOI 10.17487/RFC15911994年3月<https://www.rfc-editor.org/info/rfc1591>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，DOI 10.17487/RFC1996，1996年8月<https://www.rfc-editor.org/info/rfc1996>.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, <https://www.rfc-editor.org/info/rfc2671>.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 2671，DOI 10.17487/RFC26711999年8月<https://www.rfc-editor.org/info/rfc2671>.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, DOI 10.17487/RFC2672, August 1999, <https://www.rfc-editor.org/info/rfc2672>.
[RFC2672]克劳福德，M.，“非终端DNS名称重定向”，RFC 2672，DOI 10.17487/RFC2672，1999年8月<https://www.rfc-editor.org/info/rfc2672>.
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, DOI 10.17487/RFC2673, August 1999, <https://www.rfc-editor.org/info/rfc2673>.
[RFC2673]克劳福德，M.，“域名系统中的二进制标签”，RFC 2673，DOI 10.17487/RFC2673，1999年8月<https://www.rfc-editor.org/info/rfc2673>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, <https://www.rfc-editor.org/info/rfc3490>.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 3490，DOI 10.17487/RFC3490，2003年3月<https://www.rfc-editor.org/info/rfc3490>.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, DOI 10.17487/RFC3491, March 2003, <https://www.rfc-editor.org/info/rfc3491>.
[RFC3491]Hoffman，P.和M.Blanchet，“Nameprep：国际化域名（IDN）的Stringprep配置文件”，RFC 3491，DOI 10.17487/RFC34912003年3月<https://www.rfc-editor.org/info/rfc3491>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，STD 88，RFC 3596，DOI 10.17487/RFC3596，2003年10月<https://www.rfc-editor.org/info/rfc3596>.
[RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, DOI 10.17487/RFC3743, April 2004, <https://www.rfc-editor.org/info/rfc3743>.
[RFC3743]Konishi，K.，Huang，K.，Qian，H.，和Y.Ko，“中国，日本和韩国国际域名（IDN）注册和管理联合工程团队（JET）指南”，RFC 3743，DOI 10.17487/RFC3743，2004年4月<https://www.rfc-editor.org/info/rfc3743>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<https://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<https://www.rfc-editor.org/info/rfc4034>.
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, <https://www.rfc-editor.org/info/rfc4343>.
[RFC4343]Eastlake 3rd，D.，“域名系统（DNS）案例不敏感澄清”，RFC 4343，DOI 10.17487/RFC4343，2006年1月<https://www.rfc-editor.org/info/rfc4343>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<https://www.rfc-editor.org/info/rfc5891>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/info/rfc6672>.
[RFC6672]Rose，S.和W.Wijngaards，“DNS中的DNAME重定向”，RFC 6672，DOI 10.17487/RFC6672，2012年6月<https://www.rfc-editor.org/info/rfc6672>.
[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>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<https://www.rfc-editor.org/info/rfc6891>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC6895]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 6895，DOI 10.17487/RFC6895，2013年4月<https://www.rfc-editor.org/info/rfc6895>.
[RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, "Principles for Unicode Code Point Inclusion in Labels in the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013, <https://www.rfc-editor.org/info/rfc6912>.
[RFC6912]Sullivan，A.，Thaler，D.，Klensin，J.，和O.Kolkman，“DNS标签中包含Unicode码点的原则”，RFC 6912，DOI 10.17487/RFC6912，2013年4月<https://www.rfc-editor.org/info/rfc6912>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.
[RFC7094]McPherson，D.，Oran，D.，Thaler，D.，和E.Osterweil，“IP选播的架构考虑”，RFC 7094，DOI 10.17487/RFC7094，2014年1月<https://www.rfc-editor.org/info/rfc7094>.
[RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root Servers by Running One on Loopback", RFC 7706, DOI 10.17487/RFC7706, November 2015, <https://www.rfc-editor.org/info/rfc7706>.
[RFC7706]Kumari，W.和P.Hoffman，“通过在环回上运行一个来减少对根服务器的访问时间”，RFC 7706，DOI 10.17487/RFC7706，2015年11月<https://www.rfc-editor.org/info/rfc7706>.
[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>.
[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, <https://www.rfc-editor.org/info/rfc7816>.
[RFC7816]Bortzmeyer，S.，“DNS查询名称最小化以改善隐私”，RFC 7816，DOI 10.17487/RFC7816，2016年3月<https://www.rfc-editor.org/info/rfc7816>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS传输层安全规范（TLS）”，RFC 7858，DOI 10.17487/RFC7858，2016年5月<https://www.rfc-editor.org/info/rfc7858>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, <https://www.rfc-editor.org/info/rfc7872>.
[RFC7872]Gont，F.，Linkova，J.，Chown，T.，和W.Liu，“关于在现实世界中使用IPv6扩展头丢弃数据包的观察”，RFC 7872，DOI 10.17487/RFC7872，2016年6月<https://www.rfc-editor.org/info/rfc7872>.
[RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, October 2017, <https://www.rfc-editor.org/info/rfc8244>.
[RFC8244]Lemon，T.，Droms，R.，和W.Kumari，“特殊用途域名问题声明”，RFC 8244，DOI 10.17487/RFC82442017年10月<https://www.rfc-editor.org/info/rfc8244>.
[Sullivan-Class] Sullivan, A., "The DNS Is Not Classy: DNS Classes Considered Useless", Work in Progress, draft-sullivan-dns-class-useless-03, July 2016.
[Sullivan Class]Sullivan，A.，“DNS不是一流的：DNS类被认为是无用的”，正在进行的工作，草稿-Sullivan-DNS-Class-Uffused-032016年7月。
[Unicode] The Unicode Consortium, The Unicode Standard, Version 9.0.0, (Mountain View, CA: The Unicode Consortium, 2016. ISBN 978-1-936213-13-9), <http://www.unicode.org/versions/Unicode9.0.0/>.
[Unicode]Unicode联盟，Unicode标准，版本9.0.0，（加利福尼亚州山景城：Unicode联盟，2016年。ISBN 978-1-936213-13-9）<http://www.unicode.org/versions/Unicode9.0.0/>.
[Unicode-UAX15] Davis, M. and K. Whistler, "Unicode Standard Annex #15: Unicode Normalization Forms", February 2016, <http://unicode.org/reports/tr15/>.
[Unicode-UAX15]Davis，M.和K.Whistler，“Unicode标准附件#15：Unicode规范化格式”，2016年2月<http://unicode.org/reports/tr15/>.
[Unicode-USA31] Davis, M., "Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax", May 2016, <http://unicode.org/reports/tr31/>.
[Unicode-USA31]Davis，M.，“Unicode标准附件#31：Unicode标识符和模式语法”，2016年5月<http://unicode.org/reports/tr31/>.
[Vixie-20170704] Vixie, P., "Subject: Re: new DNS classes", message to the IETF dnsop mailing list, 4 July 2017, <https://www.ietf.org/mail-archive/web/ietf/current/ msg103486.html>.
[Vixie-20170704]Vixie，P.，“主题：Re:新DNS类”，发送给IETF dnsop邮件列表的信息，2017年7月4日<https://www.ietf.org/mail-archive/web/ietf/current/ msg103486.html>。
Acknowledgements
致谢
Many of the concerns and ideas described in this document reflect conversations over a period of many years, some rooted in DNS "keyword" and "search" discussions that paralleled the development of IDNs. Conversations with, or writings of, Rob Austein, Christine Borgman, Carolina Carvalho, Vint Cerf, Lyman Chapin, Nazli Choucri, Patrik Faltstrom, Geoff Huston, Xiaodong Lee, Karen Liu, Gervase Markham, Yaqub Mueller, Andrew Sullivan, Paul Twomey, Nico Williams, Suzanne Woolf, Jiankang Yao, other participants in the circa 2003 "DNS Search" effort and in the ICANN SSAC Working Party on IDNs, and some others whose names were sadly forgotten, were particularly important to either the content of this document or the motivation for writing it even though they may not agree with the conclusions I have reached and bear no responsibility for them.
本文档中描述的许多关注点和想法反映了多年来的对话，其中一些来源于DNS“关键字”和与IDN开发并行的“搜索”讨论。与罗布·奥斯汀、克里斯蒂娜·博格曼、卡罗莱纳·卡瓦略、文特·瑟夫、莱曼·查宾、纳兹利·乔克里、帕特里克·法特斯特罗姆、杰夫·休斯顿、李晓东、刘凯伦、格瓦塞·马卡姆、雅库布·穆勒、安德鲁·沙利文、保罗·托梅伊、尼科·威廉姆斯、苏珊娜·伍尔夫、姚建康以及2003年左右“域名搜索”的其他参与者的对话或其作品ICANN SSAC IDN工作组的努力和努力，以及其他一些名字不幸被遗忘的人，对于本文件的内容或写作动机尤其重要，尽管他们可能不同意我得出的结论，并且对这些结论不承担任何责任。
Many of the subsections of Section 3 were extracted from comments first made in conjunction with recent email discussions. Comments from Suzanne Woolf about an earlier draft version were particularly important as was material developed with suggestions from Patrik Faltstrom, especially Section 3.13. Feedback and suggestions from several of the above and from Stephane Bortzmeyer, Tony Finch, Bob Harold, Warren Kumari, Craig Partridge, and George Sadowsky were extremely helpful for improving the clarity and accuracy of parts of the document, especially so for a broader audience. Craig Partridge also contributed much of the material about queries for multiple types. Geoff Huston made several useful comments and contributed most of Section 3.15, and Bill Manning pointed out some broader requirements about integrity of information and DNS management and operations.
第3节中的许多小节摘自最早与最近的电子邮件讨论相关的评论。苏珊娜·伍尔夫（Suzanne Woolf）对早期版本草案的评论尤其重要，正如根据帕特里克·法特斯特罗姆（Patrik Faltstrom）的建议编写的材料一样，尤其是第3.13节。上述几位人士以及Stephane Bortzmeyer、Tony Finch、Bob Harold、Warren Kumari、Craig Partridge和George Sadowsky的反馈和建议对提高文件部分的清晰度和准确性极为有用，尤其是对更广泛的读者。Craig Partridge还提供了许多关于查询多种类型的资料。杰夫·休斯顿（Geoff Huston）发表了几条有用的评论，并对第3.15节的大部分内容做出了贡献，比尔·曼宁（Bill Manning）指出了关于信息完整性和DNS管理与操作的一些更广泛的要求。
Special thanks are due to Karen Moore of the RFC Production Center for her efforts, patience, and persistence in preparing this document for publication, a process that raised far more issues that required careful discussion than usual.
特别要感谢RFC制作中心的Karen Moore，感谢她在准备本文件出版过程中所做的努力、耐心和坚持，这一过程提出了比平时更多需要仔细讨论的问题。
Author's Address
作者地址
John C. Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 United States of America
美国马萨诸塞州剑桥市马萨诸塞大道1770号，邮编：322，邮编：02140
Phone: +1 617 245 1457
Email: john-ietf@jck.com
Phone: +1 617 245 1457
Email: john-ietf@jck.com