Internet Architecture Board (IAB) J. Peterson
Request for Comments: 6950 NeuStar, Inc.
Category: Informational O. Kolkman
ISSN: 2070-1721 NLnet Labs
H. Tschofenig
Nokia Siemens Networks
B. Aboba
Skype
October 2013
Internet Architecture Board (IAB) J. Peterson
Request for Comments: 6950 NeuStar, Inc.
Category: Informational O. Kolkman
ISSN: 2070-1721 NLnet Labs
H. Tschofenig
Nokia Siemens Networks
B. Aboba
Skype
October 2013
Architectural Considerations on Application Features in the DNS
DNS中应用程序功能的体系结构考虑
Abstract
摘要
A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.
许多互联网应用程序依赖域名系统（DNS）来支持其操作。许多应用程序使用DNS来定位域的服务；例如，有些人将域名以外的标识符转换为DNS可以处理的格式，然后从DNS获取应用程序数据或服务位置数据。结合使用DNS作为基础的复杂应用程序行为的提案提出了DNS作为应用程序平台的角色问题。本文档探讨了使用DNS实现某些应用程序功能的体系结构后果，并为未来的应用程序设计师提供了关于DNS作为基底的局限性以及应考虑替代设计的情况的指导。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6950.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6950.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Motivation ......................................................2
2. Overview of DNS Application Usages ..............................4
2.1. Locating Services in a Domain ..............................5
2.2. NAPTR and DDDS .............................................6
2.3. Arbitrary Data in the DNS ..................................8
3. Challenges for the DNS .........................................10
3.1. Compound Queries ..........................................10
3.1.1. Responses Tailored to the Originator ...............12
3.2. Using DNS as a Generic Database ...........................14
3.2.1. Large Data in the DNS ..............................14
3.3. Administrative Structures Misaligned with the DNS .........16
3.3.1. Metadata about Tree Structure ......................18
3.4. Domain Redirection ........................................20
4. Private DNS and Split Horizon ..................................21
5. Principles and Guidance ........................................23
6. Security Considerations ........................................25
7. IAB Members at the Time of Approval ............................26
8. Acknowledgements ...............................................26
9. Informative References .........................................27
1. Motivation ......................................................2
2. Overview of DNS Application Usages ..............................4
2.1. Locating Services in a Domain ..............................5
2.2. NAPTR and DDDS .............................................6
2.3. Arbitrary Data in the DNS ..................................8
3. Challenges for the DNS .........................................10
3.1. Compound Queries ..........................................10
3.1.1. Responses Tailored to the Originator ...............12
3.2. Using DNS as a Generic Database ...........................14
3.2.1. Large Data in the DNS ..............................14
3.3. Administrative Structures Misaligned with the DNS .........16
3.3.1. Metadata about Tree Structure ......................18
3.4. Domain Redirection ........................................20
4. Private DNS and Split Horizon ..................................21
5. Principles and Guidance ........................................23
6. Security Considerations ........................................25
7. IAB Members at the Time of Approval ............................26
8. Acknowledgements ...............................................26
9. Informative References .........................................27
The Domain Name System (DNS) has long provided a general means of translating domain names into Internet Protocol addresses, which makes the Internet easier to use by providing a valuable layer of indirection between names and lower-layer protocol elements. [RFC0974] documented a further use of the DNS: to locate an application service operating in a domain, via the Mail Exchange (MX) Resource Record; these records help email addressed to the domain to find a mail service for the domain sanctioned by the zone administrator.
域名系统（DNS）长期以来提供了将域名转换为Internet协议地址的通用方法，通过在名称和较低层协议元素之间提供一个有价值的间接层，使得Internet更易于使用。[RFC0974]记录了DNS的进一步使用：通过邮件交换（MX）资源记录定位在域中运行的应用程序服务；这些记录有助于向域发送电子邮件，以查找区域管理员批准的域的邮件服务。
The seminal MX record served as a prototype for other DNS resource records that supported applications associated with a domain name. The SRV Resource Record [RFC2052] provided a more general mechanism for locating services in a domain, complete with a weighting system and selection among transports. The Naming Authority Pointer (NAPTR) Resource Record (originally described in [RFC2168]), especially as it evolved into the more general Dynamic Delegation Discovery System (DDDS) [RFC3401] framework, added a generic mechanism for storing application data in the DNS. Primarily, this involved a client-side algorithm for transforming a string into a domain name, which might then be resolved by the DNS to find NAPTR records. This enabled the resolution of identifiers that do not have traditional host components through the DNS; the best-known examples of this are telephone numbers, as resolved by the DDDS application ENUM. Recent work, such as DomainKeys Identified Mail (DKIM) [RFC6376], has enabled security features of applications to be advertised through the DNS, via the TXT Resource Record.
开创性的MX记录作为支持与域名关联的应用程序的其他DNS资源记录的原型。SRV资源记录[RFC2052]提供了一种更通用的机制，用于在域中定位服务，并提供了一个加权系统和传输之间的选择。命名机构指针（NAPTR）资源记录（最初在[RFC2168]中描述），特别是当它演变为更通用的动态委托发现系统（DDDS）[RFC3401]框架时，添加了一种用于在DNS中存储应用程序数据的通用机制。这主要涉及一个客户端算法，用于将字符串转换为域名，然后DNS可以解析该域名以查找NAPTR记录。这使得通过DNS解析没有传统主机组件的标识符成为可能；最著名的例子是电话号码，由DDDS应用程序ENUM解析。最近的工作，如DomainKeys Identified Mail（DKIM）[RFC6376]，已使应用程序的安全功能能够通过DNS，通过TXT资源记录进行广告。
The scope of application usage of the DNS has thus increased over time. Applications in many environments require features such as confidentiality, and as the contexts in which applications rely on the DNS have increased, some application protocols have looked to extend the DNS to include these sorts of capabilities. However, some proposed usages of, and extensions to, the DNS have become misaligned with both the DNS architecture and the DNS protocol. If we take the example of confidentiality, we see that in the global public DNS, the resolution of domain names to IP addresses is an exchange of public information with no expectation of confidentiality. Thus, the underlying query/response protocol has no encryption mechanism; typically, any security required by an application or service is invoked after the DNS query, when the resolved service has been contacted. Only in private DNS environments (including split-horizon DNS) where the identity of the querier is assured through some external policy can the DNS maintain confidential records, by providing distinct answers to the private and public users of the DNS. In support of load-balancing or other optimizations, a DNS server may return different addresses in response to queries from different sources, or even no response at all; see Section 3.1.1 for details.
因此，DNS的应用范围随着时间的推移而增加。许多环境中的应用程序需要保密性等功能，随着应用程序依赖DNS的环境的增加，一些应用程序协议希望扩展DNS以包括这些功能。然而，DNS的一些拟议用途和扩展已与DNS体系结构和DNS协议不一致。如果我们以保密性为例，我们可以看到，在全球公共DNS中，将域名解析为IP地址是一种公共信息交换，不需要保密。因此，底层查询/响应协议没有加密机制；通常，应用程序或服务所需的任何安全性都会在DNS查询之后，即已联系已解析的服务时调用。只有在通过某些外部策略确保查询者身份的私有DNS环境（包括拆分地平线DNS）中，DNS才能通过向DNS的私有和公共用户提供不同的答案来维护机密记录。为了支持负载平衡或其他优化，DNS服务器可能会返回不同的地址以响应来自不同来源的查询，甚至根本没有响应；详见第3.1.1节。
This document provides guidance to application designers and application protocol designers looking to use the DNS to support features in their applications. It provides an overview of past application usage of the DNS as well as a review of proposed new usages. It identifies concerns and trade-offs and provides guidance on the question, "Should I store this information in the DNS, or use some other means?" when that question arises during protocol development. These guidelines remind application protocol designers
本文档为希望使用DNS支持其应用程序中的功能的应用程序设计人员和应用程序协议设计人员提供指导。它概述了DNS过去的应用程序用法，并回顾了提议的新用法。它确定了关注点和权衡，并就协议开发过程中出现的问题“我应该将此信息存储在DNS中，还是使用其他方法？”提供了指导。这些指南提醒应用程序协议设计者
of the strengths and weaknesses of the DNS in order to make it easier for designers to decide what features the DNS should provide for their application.
分析DNS的优点和缺点，以便设计者更容易决定DNS应为其应用程序提供哪些功能。
The guidance in this document complements the guidance on extending the DNS given in [RFC5507]. Whereas [RFC5507] considers the preferred ways to add new information to the underlying syntax of the DNS (such as defining new resource records or adding prefixes or suffixes to labels), the current document considers broader implications of applications that rely on the DNS for the implementation of certain features, be it through extending the DNS or simply reusing existing protocol capabilities -- implications that may concern the invocation of the resolver by applications; the behavior of name servers, resolvers, or caches; extensions to the underlying DNS protocol; the operational responsibilities of zone administrators; security; or the overall architecture of names. When existing DNS protocol fields are used in ways that their designers did not intend to handle new applications, those applications may demand further changes and extensions that are fundamentally at odds with the strengths of the DNS.
本文件中的指南补充了[RFC5507]中给出的DNS扩展指南。鉴于[RFC5507]考虑了向DNS的底层语法添加新信息的首选方法（例如定义新资源记录或向标签添加前缀或后缀），当前文档考虑了依赖DNS实现某些功能的应用程序的更广泛含义，无论是通过扩展DNS还是简单地重用现有的协议功能——可能涉及应用程序调用解析器的含义；名称服务器、解析程序或缓存的行为；对底层DNS协议的扩展；区域管理员的操作职责；安全或者名称的总体架构。当现有的DNS协议字段以其设计者不打算处理新应用程序的方式使用时，这些应用程序可能需要进一步的更改和扩展，这些更改和扩展从根本上与DNS的优势不符。
[RFC0882] identifies the original and fundamental connection between the DNS and applications. It begins by describing how the interdomain scope of applications creates "formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment". This motivated transitioning the "mapping between host names... and ARPA Internet addresses" from a global table (the original "hosts" file) to a "distributed database that performs the same function". [RFC0882] also envisioned some ways to find the resources associated with mailboxes in a domain: without these extensions, a user trying to send mail to a foreign domain lacked a discovery mechanism to locate the right host in the remote domain to which to connect.
[RFC0882]标识DNS和应用程序之间的原始和基本连接。它首先描述了应用程序的域间范围如何造成“当我们希望创建一致的方法来引用相似但分散在整个环境中的特定资源时，会产生可怕的问题”。这促使将“主机名…和ARPA Internet地址之间的映射”从全局表（原始“主机”文件）转换为“执行相同功能的分布式数据库”。[RFC0882]还设想了一些在域中查找与邮箱关联的资源的方法：如果没有这些扩展，试图向外域发送邮件的用户缺少查找机制，无法在远程域中找到要连接的正确主机。
While a special-purpose service discovery mechanism could be built for each such application protocol that needed this functionality, the universal support for the DNS encourages installing these features into its public tree rather than inventing something new. Thus, over time, several other applications leveraged DNS resource records for locating services in a domain or for storing application data associated with a domain in the DNS. This section gives examples of various types of DNS usage by applications to date.
虽然可以为每个需要此功能的应用程序协议构建专用服务发现机制，但对DNS的通用支持鼓励将这些功能安装到其公共树中，而不是发明新的功能。因此，随着时间的推移，一些其他应用程序利用DNS资源记录来定位域中的服务或在DNS中存储与域关联的应用程序数据。本节给出了迄今为止应用程序使用各种类型DNS的示例。
The MX Resource Record provides the simplest example of an application advertising its domain-level resources in the Domain Name System. The MX Resource Record contains the domain name of a server that receives mail on behalf of the administrative domain in question; that domain name must itself be resolved to one or more IP addresses through the DNS in order to reach the mail server. While naming conventions for applications might serve a similar purpose (a host might be named "mail.example.com", for example), approaching service location through the creation of a new resource record yields important benefits. For example, one can put multiple MX records under the same name, in order to designate backup resources or to load-balance across several such servers (see [RFC1794]); these properties could not easily be captured by naming conventions (see [RFC4367], though more recently DNS-based Service Discovery (DNS-SD) [RFC6763] codifies service instance naming conventions for use across applications to locate services in a domain).
MX资源记录提供了应用程序在域名系统中公布其域级资源的最简单示例。MX资源记录包含代表相关管理域接收邮件的服务器的域名；该域名本身必须通过DNS解析为一个或多个IP地址，才能到达邮件服务器。虽然应用程序的命名约定可能有类似的用途（例如，主机可能被命名为“mail.example.com”），但通过创建新的资源记录来接近服务位置会产生重要的好处。例如，可以将多个MX记录放在同一个名称下，以便指定备份资源或在多个这样的服务器之间实现负载平衡（请参见[RFC1794]）；命名约定无法轻松捕获这些属性（请参见[RFC4367]，尽管最近基于DNS的服务发现（DNS-SD）[RFC6763]对服务实例命名约定进行了编码，以便跨应用程序在域中定位服务）。
While the MX record represents a substantial improvement over naming conventions as a means of service location, it remains specific to a single application. Thus, the general approach of the MX record was adapted to fit a broader class of applications through the Service (SRV) Resource Record (originally described in [RFC2052]). The SRV record allows DNS resolvers to query for particular services and underlying transports (for example, HTTP running over Transport Layer Security (TLS) [RFC2818]) and to learn a host name and port where that service resides in a given domain. It also provides a weighting mechanism to allow load-balancing across several instances of a service.
虽然MX记录作为服务位置的一种方式，与命名约定相比有了实质性的改进，但它仍然是特定于单个应用程序的。因此，MX记录的一般方法通过服务（SRV）资源记录（最初在[RFC2052]中描述）进行了调整，以适应更广泛的应用程序类别。SRV记录允许DNS解析程序查询特定服务和底层传输（例如，通过传输层安全性（TLS）运行的HTTP）[RFC2818]），并了解该服务驻留在给定域中的主机名和端口。它还提供了一种加权机制，允许跨多个服务实例进行负载平衡。
The reliance of applications on the existence of MX and SRV records has important implications for the way that applications manage identifiers and the way that applications pass domain names to resolvers. Email identifiers of the form "user@domain" rely on MX records to provide the convenience of simply specifying a "domain" component rather than requiring an application to guess which particular host handles mail on behalf of the domain. While naming conventions continue to abound ("www.example.com") for applications like web browsing, SRV records allow applications to query for an application-specific protocol and transport in the domain. For the Lightweight Directory Access Protocol (LDAP), the SRV service name corresponds to the URL scheme of the identifier invoked by the application (e.g., when "ldap://example.com" is the identifier, the SRV query passed to the resolver is for "_ldap._tcp.example.com"); for other applications, the SRV service name that the application passes to the resolver may be implicit in the identifier rather than
应用程序依赖MX和SRV记录的存在对应用程序管理标识符的方式以及应用程序将域名传递给解析程序的方式具有重要影响。“表格的电子邮件标识符”user@domain依靠MX记录，只需指定一个“域”组件，而无需应用程序猜测哪个特定主机代表域处理邮件。在web浏览等应用程序的命名约定（www.example.com）继续大量存在的同时，SRV记录允许应用程序在域中查询特定于应用程序的协议和传输。对于轻量级目录访问协议（LDAP），SRV服务名称对应于应用程序调用的标识符的URL方案（例如，当“ldap://example.com是标识符，传递给解析器的SRV查询是针对“_ldap._tcp.example.com”）；对于其他应用程序，应用程序传递给解析器的SRV服务名称可能隐含在标识符中，而不是
explicit. In either case, the application delivers the service name to the DNS to find the location of the host of that service for the domain, the port where the service resides on that host, additional locations or ports for load-balancing and fault tolerance, and related application features.
明确的在任何一种情况下，应用程序都会将服务名称传递给DNS，以查找域中该服务的主机位置、该服务驻留在该主机上的端口、用于负载平衡和容错的其他位置或端口以及相关应用程序功能。
Locating specific services for a domain was the first major function for which applications started using the DNS beyond simple name resolution. SRV broadened and generalized the precedent of MX to make service location available to any application, rather than just to mail. As applications that acquire MX (or SRV) records might need to perform further queries or transformations in order to arrive at an eventual domain name that will resolve to the IP addresses for the service, [RFC1034] allowed that the Additional (data) section of DNS responses may contain the corresponding address records for the names of services designated by the MX record; this optimization, which requires support in the authoritative server and the resolver, is an initial example of how support for application features requires changes to DNS operation. At the same time, this is an example of an extension of the DNS that cannot be universally relied on: many DNS resolver implementations will ignore the addresses in the additional section of the DNS answers because of the trustworthiness issues described in [RFC2181].
定位域的特定服务是应用程序开始使用DNS的第一个主要功能，而不仅仅是简单的名称解析。SRV扩展和推广了MX的先例，使服务位置可用于任何应用程序，而不仅仅是邮件。由于获取MX（或SRV）记录的应用程序可能需要执行进一步的查询或转换，以获得最终域名，该域名将解析为服务的IP地址，[RFC1034]允许附加（数据）DNS响应的部分可能包含MX记录指定的服务名称的相应地址记录；这种优化需要权威服务器和解析器的支持，这是支持应用程序功能需要更改DNS操作的初始示例。同时，这是一个无法普遍依赖的DNS扩展示例：由于[RFC2181]中描述的可信问题，许多DNS解析器实现将忽略DNS应答的附加部分中的地址。
The NAPTR Resource Record evolved to fulfill a need in the transition from Uniform Resource Locators (URLs) to the more mature Uniform Resource Identifier (URI) [RFC3986] framework, which incorporated Uniform Resource Names (URNs). Unlike URLs, URNs typically do not convey enough semantics internally to resolve them through the DNS, and consequently a separate URI-transformation mechanism is required to convert these types of URIs into domain names. This allows identifiers with no recognizable domain component to be treated as domain names for the purpose of name resolution. Once these transformations result in a domain name, applications can retrieve NAPTR records under that name in the DNS. NAPTR records contain a far more rich and complex structure than MX or SRV Resource Records. A NAPTR record contains two different weighting mechanisms ("order" and "preference"), a "service" field to designate the application that the NAPTR record describes, and then two fields that can contain translations: a "replacement" field or a "regexp" (regular expression) field, only one of which appears in a given NAPTR record (see [RFC2168]). A "replacement", like NAPTR's ancestor the PTR record, simply designates another domain name where one would look for records associated with this service in the domain. The
NAPTR资源记录的发展是为了满足从统一资源定位器（URL）过渡到更成熟的统一资源标识符（URI）[RFC3986]框架的需要，该框架包含统一资源名称（URN）。与URL不同，URN通常不会在内部传递足够的语义来通过DNS解析它们，因此需要单独的URI转换机制将这些类型的URI转换为域名。这允许不具有可识别域组件的标识符被视为域名，以便进行名称解析。一旦这些转换产生域名，应用程序就可以在DNS中检索该名称下的NAPTR记录。NAPTR记录包含比MX或SRV资源记录更丰富和复杂的结构。NAPTR记录包含两种不同的加权机制（“顺序”和“首选项”）、一个用于指定NAPTR记录描述的应用程序的“服务”字段，以及两个可以包含翻译的字段：“替换”字段或“regexp”（正则表达式）字段，其中只有一个字段出现在给定的NAPTR记录中（请参见[RFC2168]）。“替换”，就像NAPTR的祖先PTR记录一样，只是指定另一个域名，在该域名中查找与该服务相关的记录。这个
"regexp", on the other hand, allows regular expression transformations on the original URI intended to turn it into an identifier that the DNS can resolve.
另一方面，“regexp”允许对原始URI进行正则表达式转换，以便将其转换为DNS可以解析的标识符。
As the abstract of [RFC2915] says, "This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax". Any sort of hierarchical identifier can potentially be encoded as a domain name, and thus historically the DNS has often been used to resolve identifiers that were never devised as a name for an Internet host. A prominent early example is found in the in-addr domain [RFC0883], in which IPv4 addresses are encoded as domain names by applying a string preparation algorithm that required reversing the octets and treating each individual octet as a label in a domain name -- thus, for example, the address 192.0.2.1 became 1.2.0.192.in-addr.arpa. This allowed resolvers to query the DNS to learn name(s) associated with an IPv4 address. The same mechanism has been applied to IPv6 addresses [RFC3596] and other sorts of identifiers that lack a domain component. Eventually, this idea connected with activities to create a system for resolving telephone numbers on the Internet, which became known as ENUM (originally described in [RFC2916]). ENUM borrowed from an earlier proposal, the "tpc.int" domain [RFC1530], which provided a means for encoding telephone numbers as domain names by applying a string preparation algorithm that required reversing the digits and treating each individual digit as a label in a domain name -- thus, for example, the number +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int. In the ENUM system, in place of "tpc.int" the special domain "e164.arpa" was reserved for use.
正如[RFC2915]的摘要所说，“这允许DNS用于查找各种不在域名语法中的资源名（包括URI）的服务”。任何种类的层次标识符都可能被编码为域名，因此历史上DNS经常被用于解析从未被设计为Internet主机名称的标识符。早期一个突出的例子是in-addr域[RFC0883]，在该域中，IPv4地址通过应用字符串准备算法编码为域名，该算法要求反转八位字节，并将每个八位字节作为域名中的标签处理——因此，例如，地址192.0.2.1变为1.2.0.192.in-addr.arpa。这允许解析程序查询DNS以了解与IPv4地址关联的名称。同样的机制也适用于IPv6地址[RFC3596]和其他缺少域组件的标识符。最终，这个想法与创建一个用于解析互联网电话号码的系统的活动相联系，该系统被称为ENUM（最初在[RFC2916]中描述）。ENUM借鉴了早期的一个提议“tpc.int”域[RFC1530]，该域提供了一种将电话号码编码为域名的方法，方法是应用字符串准备算法，该算法需要反转数字，并将每个数字作为域名中的标签来处理——例如，数字+1571434400变为0.0.4.5.4.3.4.1.7.5.1.tpc.int。在ENUM系统中，保留了专用域“e164.arpa”以代替“tpc.int”。
In the more mature form of the NAPTR standard, in the Dynamic Delegation Discovery System (DDDS) [RFC3401] framework, the initial transformation of an identifier (such as a telephone number) to a domain name was called the "First Well Known Rule". The address-reversing mechanism, whereby a query name is formed by reversing an IPv4 address and prepending it to the in-addr.arpa domain, is generalized for the use of NAPTR: each application defines a "First Well Known Rule" that translates a specific resource into a query name. Its flexibility has inspired a number of proposals beyond ENUM to encode and resolve unorthodox identifiers in the DNS. Provided that the identifiers transformed by the "First Well Known Rule" have some meaningful structure and are not overly lengthy, virtually anything can serve as an input for the DDDS structure: for example, civic addresses. Though [RFC3402] stipulates regarding the identifier that "The lexical structure of this string must imply a unique delegation path", there is no requirement that the identifier be hierarchical nor that the points of delegation in the domain name
在NAPTR标准的更成熟形式中，在动态委托发现系统（DDDS）[RFC3401]框架中，标识符（如电话号码）到域名的初始转换被称为“第一条众所周知的规则”。地址反转机制，即通过反转IPv4地址并将其前置到in-addr.arpa域来形成查询名称，对于NAPTR的使用是通用的：每个应用程序定义一个“第一个已知规则”，将特定资源转换为查询名称。它的灵活性激发了ENUM之外的许多建议，以编码和解析DNS中的非正统标识符。如果由“第一条众所周知的规则”转换的标识符具有某种有意义的结构并且不太长，那么几乎任何东西都可以作为DDDS结构的输入：例如，公民地址。尽管[RFC3402]规定了关于标识符的“该字符串的词法结构必须暗示唯一的委托路径”，但不要求标识符具有层次结构，也不要求域名中的委托点
created by the "First Well Known Rule" correspond to any points of administrative delegation inherent in the structure of the identifier.
由“第一条众所周知的规则”创建，对应于标识符结构中固有的任何管理授权点。
While this ability to look up names "which are not in domain name syntax" does not change the underlying DNS protocol -- the names generated by the DDDS algorithm are still just domain names -- it does change the context in which applications pass name to resolvers and can potentially require very different operational practices of zone administrators (see Section 3.3). In terms of the results of a DNS query, the presence of the "regexp" field of NAPTR records enabled unprecedented flexibility in the types of identifiers that applications could resolve with the DNS. Since the output of the regular expression frequently took the form of a URI (in ENUM resolution, for example, a telephone number might be converted into a SIP URI [RFC3261]), anything that could be encoded as a URI might be the result of resolving a NAPTR record -- which, as the next section explores, essentially means arbitrary data.
而这种查找“不在域名语法中”的名称的能力不会更改基础DNS协议（DDDS算法生成的名称仍然只是域名），但会更改应用程序将名称传递给解析程序的上下文，并且可能需要区域管理员采用非常不同的操作实践（请参见第3.3节）。就DNS查询的结果而言，NAPTR记录的“regexp”字段的存在使得应用程序可以通过DNS解析的标识符类型具有前所未有的灵活性。由于正则表达式的输出通常采用URI的形式（例如，在枚举解析中，电话号码可能会转换为SIP URI[RFC3261]），因此任何可以编码为URI的内容都可能是解析NAPTR记录的结果——正如下一节所探讨的，这本质上意味着任意数据。
URI encoding has ways of encapsulating basically arbitrary data: the most extreme example is a data URL [RFC2397]. Thus, the returned NAPTR record might be interpreted to produce output other than a domain name that would subsequently be resolved to IP addresses and contacted for a particular application -- it could give a literal result that would be consumed by the application. Originally, as discussed in [RFC2168], the intended applicability of the regular expression field in NAPTR was narrower: the "regexp" field contained a "substitution expression that is applied to the original URI in order to construct the next domain name to lookup", in order to "change the host that is contacted to resolve a URI" or as a way of "changing the path or host once the URL has been assigned". The regular expression tools available to NAPTR record authors, however, grant much broader powers to alter the input string, and thus applications began to rely on NAPTR to perform more radical transformations that did not serve any of those aforementioned needs. According to [RFC3402], the output of DDDS is wholly application-specific: "the Application must define what the expected output of the Terminal Rule should be", and the example given in the document is one of identifying automobile parts by inputting a part number and receiving at the end of the process information about the manufacturer.
URI编码可以封装基本上任意的数据：最极端的例子是数据URL[RFC2397]。因此，返回的NAPTR记录可能被解释为产生除域名以外的输出，该域名随后将被解析为IP地址并与特定应用程序联系——它可能给出应用程序将使用的文本结果。最初，如[RFC2168]中所述，NAPTR中正则表达式字段的预期适用范围较窄：“regexp”字段包含“应用于原始URI的替换表达式，以便构造下一个要查找的域名”，以便“更改与之联系以解析URI的主机”，或者作为“分配URL后更改路径或主机”。然而，NAPTR记录作者可用的正则表达式工具授予更广泛的更改输入字符串的权限，因此应用程序开始依赖NAPTR执行更激进的转换，而这些转换不满足上述任何需要。根据[RFC3402]，DDDS的输出完全是特定于应用程序的：“应用程序必须定义终端规则的预期输出应该是什么”，文档中给出的示例是通过输入零件号并在过程结束时接收有关制造商的信息来识别汽车零件。
Historically speaking, NAPTR did not pioneer the storage of arbitrary data in the DNS. At the start, [RFC0882] observed that "it is unlikely that all users of domain names will be able to agree on the set of resources or resource information that names will be used to
从历史上讲，NAPTR并没有率先在DNS中存储任意数据。一开始，[RFC0882]观察到，“域名的所有用户都不太可能就域名将被用来访问的资源集或资源信息达成一致
retrieve", and consequently places little restriction on the information that DNS records might carry: it might be "host addresses, mailbox data, and other as yet undetermined information". [RFC1035] defined the TXT record, a means to store arbitrary strings in the DNS; [RFC1035] also specifically stipulates that a TXT contains "descriptive text" and that "the semantics of the text depends on the domain where it is found". The existence of TXT records has long provided new applications with a rapid way of storing data associated with a domain name in the DNS, as adding data in this fashion requires no registration process. [RFC1464] experimented with a means of incorporating name/value pairs to the TXT record structure, which allowed applications to distinguish different chunks of data stored in a TXT record -- surely not just "descriptive text" as the TXT originally specified. In this fashion, an application that wants to store additional data in the DNS can do so without registering a new resource record type, though [RFC5507] points out that it is "difficult to reliably distinguish one application's record from others, and for its parser to avoid problems when it encounters other TXT records".
检索”，因此对DNS记录可能携带的信息几乎没有限制：可能是“主机地址、邮箱数据和其他尚未确定的信息”。[RFC1035]定义了TXT记录，这是在DNS中存储任意字符串的一种方法；[RFC1035]还明确规定TXT包含“描述性文本”“文本的语义取决于它所在的域”。TXT记录的存在长期以来为新的应用程序提供了一种在DNS中快速存储与域名相关的数据的方法，因为以这种方式添加数据不需要注册过程。[RFC1464]试验了一种将名称/值对合并到TXT记录结构的方法，这种方法允许应用程序区分存储在TXT记录中的不同数据块——当然不仅仅是TXT最初指定的“描述性文本”。通过这种方式，希望在DNS中存储额外数据的应用程序可以在不注册新的资源记录类型的情况下执行此操作，尽管[RFC5507]指出“很难可靠地将一个应用程序的记录与其他应用程序的记录区分开来，并且其解析器在遇到其他TXT记录时避免出现问题”。
While open policies surrounding the use of the TXT record have resulted in a checkered past for standardizing application usage of TXT, TXT has been used as a technical solution for many applications. Recently, DKIM [RFC6376] sidestepped the problem of TXT ambiguity by storing keys under a specialized DNS naming structure that includes the component "_domainkeys", which serves to restrict the scope of that TXT solely to DKIM use. Storing keys in the DNS became the preferred solution for DKIM for several reasons: notably, because email applications already queried the DNS in their ordinary operations, because the public keys associated with email required wide public distribution, and because email identifiers contain a domain component that applications can easily use to consult the DNS. If the application had to negotiate support for the DKIM mechanism with mail servers, it would give rise to bid-down attacks (where attackers misrepresent that DKIM is unsupported on the originating side) that are not possible if the DNS delivers the keys (provided that DNSSEC [RFC4033] guarantees authenticity of the data). However, there are potential issues with storing large data in the DNS, as discussed in Section 3.2.1, as well as with the DKIM namespace conventions that complicate the use of DNS wildcards (as discussed in Section 6.1.2 of [RFC6376] and in more general terms in [RFC5507]). If prefixes are used to identify TXT records used by an application, potentially the use of wildcards may furthermore cause leakages that other applications will need to detect.
虽然围绕TXT记录使用的开放政策导致了TXT应用程序使用标准化的曲折历程，但TXT已被用作许多应用程序的技术解决方案。最近，DKIM[RFC6376]通过将密钥存储在一个专门的DNS命名结构下（该结构包括组件“_domainkeys”），避免了TXT的歧义问题，该组件用于将TXT的范围仅限于DKIM使用。将密钥存储在DNS中成为DKIM的首选解决方案有几个原因：值得注意的是，因为电子邮件应用程序已经在其正常操作中查询DNS，因为与电子邮件相关联的公钥需要广泛的公共分发，而且，因为电子邮件标识符包含一个域组件，应用程序可以轻松地使用该组件来查询DNS。如果应用程序必须与邮件服务器协商对DKIM机制的支持，则会引发拒绝出价攻击（攻击者错误地表示发起端不支持DKIM），如果DNS提供密钥（前提是DNSSEC[RFC4033]保证数据的真实性），则不可能发生这种攻击。但是，如第3.2.1节所述，在DNS中存储大数据以及使DNS通配符的使用复杂化的DKIM命名空间约定（如[RFC6376]第6.1.2节所述，以及[RFC5507]中更一般的术语所述）存在潜在问题。如果使用前缀识别应用程序使用的TXT记录，则使用通配符可能会进一步导致其他应用程序需要检测的泄漏。
The methods discussed in the previous section for transforming arbitrary identifiers into domain names and returning arbitrary data in response to DNS queries both represent significant departures from the basic function of translating host names to IP addresses, yet neither fundamentally alters the underlying semantics of the DNS. When we consider, however, that the URIs returned by DDDS might be base-64-encoded binary data in a data URL, the DNS could effectively implement the entire application feature set of any simple query-response protocol. Effectively, the DDDS framework considers the DNS a generic database -- indeed, the DDDS framework was designed to work with any sort of underlying database; as [RFC3403] says, the DNS is only one potential database for DDDS to use. Whether the DNS as an underlying database can support the features that some applications of DDDS require, however, is a more complicated question.
上一节讨论的将任意标识符转换为域名和返回任意数据以响应DNS查询的方法都与将主机名转换为IP地址的基本功能有很大的不同，但这两种方法都没有从根本上改变DNS的基本语义。然而，当我们考虑DDDS返回的URI可能是数据URL中的基本664编码二进制数据时，DNS可以有效地实现任何简单的查询响应协议的整个应用程序特征集。实际上，DDDS框架将DNS视为一个通用数据库——事实上，DDDS框架设计用于处理任何类型的底层数据库；正如[RFC3403]所说，DNS只是DDDS可以使用的一个潜在数据库。然而，作为底层数据库的DNS是否能够支持DDDS的某些应用程序所需的功能是一个更复杂的问题。
As the following subsections will show, the potential for applications to rely on the DNS as a generic database gives rise to additional requirements that one might expect to find in a database access protocol: authentication of the source of queries for comparison to access control lists, formulating complex relational queries, and asking questions about the structure of the database itself. The global public DNS was not designed to provide these sorts of properties, and extending the DNS protocols to encompass them could result in a fundamental alteration to its model. Ultimately, this document concludes that efforts to retrofit these capabilities into the DNS would be better invested in selecting, or if necessary inventing, other Internet services with broader powers than the DNS. If an application protocol designer wants these properties from a database, in general this is a good indication that the DNS cannot, or can only partly, meet the needs of the application in question.
如以下小节所示，应用程序依赖DNS作为通用数据库的可能性会产生额外的要求，人们可能期望在数据库访问协议中找到这些要求：验证查询源以与访问控制列表进行比较，制定复杂的关系查询，以及询问有关数据库本身结构的问题。全球公共DNS并不是为了提供这些属性而设计的，扩展DNS协议以包含这些属性可能会导致其模型的根本性改变。最终，本文档得出结论，将这些功能改进到DNS中的努力将更好地投资于选择或在必要时发明具有比DNS更广泛功能的其他互联网服务。如果应用程序协议设计人员希望从数据库中获取这些属性，通常这表明DNS无法或只能部分满足相关应用程序的需要。
Since many of these new requirements have emerged from the ENUM space, the following sections use ENUM as an illustrative example; however, any application using the DNS as a feature-rich database could easily end up with similar requirements.
由于这些新需求中有许多是从ENUM空间中产生的，因此以下各节使用ENUM作为示例；但是，任何将DNS用作功能丰富的数据库的应用程序都可能很容易满足类似的要求。
Traditionally, DNS RRsets are uniquely identified by domain name, resource record type, and class. DNS queries are based on this 3-tuple, and the replies are resource record sets that are to be treated as atomic data elements (see [RFC2181]); to applications, the behavior of the DNS has traditionally been that of an exact-match query-response lookup mechanism. Outside of the DNS space, however, there are plenty of query-response applications that require a
传统上，DNS RRSET是由域名、资源记录类型和类唯一标识的。DNS查询基于此3元组，回复是将被视为原子数据元素的资源记录集（请参见[RFC2181]）；对于应用程序来说，DNS的行为传统上是精确匹配查询响应查找机制。然而，在DNS空间之外，有许多查询响应应用程序需要
compound or relational search, one taking into account more than one factor in formulating a response or one that uses no single factor as a key to the database. For example, in the telephony space, telephone call routing often takes into account numerous factors aside from the dialed number, including originating trunk groups, interexchange carrier selection, number portability data, time of day, and so on. All are considered simultaneously in generating a route. While in its original conception ENUM hoped to circumvent the traditional Public Switched Telephone Network (PSTN) and route directly to Internet-enabled devices, the infrastructure ENUM effort to support the migration of traditional carrier routing functions to the Internet aspires to achieve feature parity with traditional number routing. However, [RFC3402] explicitly states that "it is an assumption of the DDDS that the lexical element used to make a delegation decision is simple enough to be contained within the Application Unique String itself. The DDDS does not solve the case where a delegation decision is made using knowledge contained outside the AUS and the Rule (time of day, financial transactions, rights management, etc.)". Consequently, some consideration has been given to ways to append additional data to ENUM queries to give the DNS server sufficient information to return a suitable URI (see Section 3.1.1).
复合搜索或关系搜索，在制定响应时考虑多个因素，或不使用单个因素作为数据库键的搜索。例如，在电话空间中，电话呼叫路由通常考虑除已拨号码之外的许多因素，包括始发中继组、交换载波选择、号码可携性数据、一天中的时间等。在生成路由时同时考虑所有路由。虽然在最初的构想中，ENUM希望绕过传统的公共交换电话网（PSTN）并直接路由到支持互联网的设备，但基础设施ENUM支持传统运营商路由功能迁移到互联网的努力，希望实现与传统号码路由的功能对等。但是，[RFC3402]明确指出，“DDDS假设用于做出委托决策的词汇元素足够简单，可以包含在应用程序唯一字符串本身中。DDDS不能解决使用AUS和规则之外的知识做出委托决策的情况（一天中的时间、财务交易、权限管理等）。因此，考虑了将附加数据附加到ENUM查询的方法，以便为DNS服务器提供足够的信息，以返回合适的URI（参见第3.1.1节）。
From a sheer syntactical perspective, however, domain names do not admit of this sort of rich structure. Several workarounds have attempted to instantiate these sorts of features in DNS queries. For example, the domain name itself could be compounded with the additional parameters: one could take a name like 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk group identifier to it, for example, of the form tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in this particular case a DNS server can adhere to its traditional behavior in locating resource records, the syntactical viability of encoding additional parameters in this fashion is dubious, especially if more than one additional parameter is required and the presence of parameters is optional so that the application needs multiple queries to assess the completeness of the information it needs to perform its function.
然而，从纯粹的句法角度来看，域名不允许这种丰富的结构。有几种变通方法试图在DNS查询中实例化这些类型的功能。例如，域名本身可以与其他参数组合：可以采用类似于0.0.4.5.4.3.4.1.7.5.1.e164.arpa的名称，并向其附加中继组标识符，例如，格式为tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa。虽然在这种特殊情况下，DNS服务器在定位资源记录时可以遵循其传统行为，但以这种方式编码附加参数的语法可行性是值得怀疑的，特别是如果需要多个附加参数，并且参数的存在是可选的，因此应用程序需要多个查询来评估执行其功能所需信息的完整性。
As an alternative, it has been proposed that we piggyback additional query parameters as Extension Mechanisms for DNS (EDNS(0)) extensions (see [RFC6891]). This might be problematic for three reasons. First, supporting EDNS(0) extensions requires significant changes to name server behavior; these changes need to be supported by the authoritative and recursive name servers on which the application relies and might be very hard to realize on a global scale. In addition, the original stated applicability of the EDSN(0) mechanism, as [RFC2671] states, was to "a particular transport level message and not to any actual DNS data", and consequently the OPT Resource
作为替代方案，有人建议我们携带额外的查询参数作为DNS（EDNS（0））扩展的扩展机制（请参见[RFC6891]）。这可能有三个原因。首先，支持EDNS（0）扩展需要对名称服务器行为进行重大更改；这些更改需要由应用程序所依赖的权威和递归名称服务器支持，并且可能很难在全局范围内实现。此外，正如[RFC2671]所述，EDSN（0）机制最初声明的适用性是“特定的传输级别消息，而不是任何实际的DNS数据”，因此是OPT资源
Records it specifies are never to be forwarded. The use of EDNS(0) for compound queries, however, clearly is intended to discriminate actual DNS data rather than to facilitate transport-layer handling. Finally, [RFC6891] also specifies that "OPT RRs MUST NOT be cached, forwarded, or stored" (see the next paragraph). For these reasons, this memo recommends against crafting compound DNS queries by using EDNS(0).
它指定的记录永远不会被转发。然而，在复合查询中使用EDN（0）显然是为了区分实际的DNS数据，而不是为了方便传输层处理。最后，[RFC6891]还规定“不得缓存、转发或存储OPT RRs”（见下一段）。出于这些原因，本备忘录建议不要使用EDN（0）手工制作复合DNS查询。
The implications of these sorts of compound queries for recursion and caching are potentially serious. The logic used by the authoritative server to respond to a compound query may not be understood by any recursive servers or caches; intermediaries that naively assume that the response was selected based on the domain name, type, and class alone might serve responses to queries in a different way than the authoritative server intends. Therefore, were EDNS(0) to be employed this way, its attributes would not be transitive, and if this were not considered where intermediaries are employed, as is normally the case in the global DNS, brokenness might occur.
这类复合查询对递归和缓存的影响可能很严重。权威服务器用于响应复合查询的逻辑可能不为任何递归服务器或缓存所理解；天真地假设响应仅基于域名、类型和类进行选择的中介可能会以与权威服务器不同的方式提供查询响应。因此，如果以这种方式使用EDN（0），其属性将不会是可传递的，并且如果在使用中介的情况下不考虑这一点（如全局DNS中通常的情况），则可能会发生断开。
DNS responses tailored to the identity of their originator, where some sort of administrative identity of the originator must be conveyed to the DNS, constitute the most important subcase of these compound queries. We must first distinguish this from cases where the originating IP address or a similar indication is used to serve a location-specific name. For those sorts of applications, which generally lack security implications, relying on factors like the source IP address introduces little harm; for example, when providing a web portal customized to the region of the client, it would not be a security breach if the client saw the localized portal of the wrong country. Because recursive resolvers may obscure the origination network of the DNS client, a recent proposal suggested introducing a new DNS query parameter to be populated by DNS recursive resolvers in order to preserve the originating IP address (see [EDNS-CLIENT-IP]). However, aside from purely cosmetic uses, these approaches have known limitations due to the prevalence of private IP addresses, VPNs, and so on, which obscure the source IP address and instead supply the IP address of an intermediary that may be very distant from the originating endpoint. Implementing technology such as the one described by [EDNS-CLIENT-IP] would require significant changes in the operation of recursive resolvers and the authoritative servers that would rely on the original source IP address to select resource records, and moreover a fundamental change to caching behavior as well. As a result, such technology cannot be rolled out in an incremental, unilateral fashion but could only be successful when implemented bilaterally (by authoritative server and recursive resolver); this is a significant bar to deployment.
根据发端人身份定制的DNS响应（发端人的某种管理身份必须传达给DNS）构成了这些复合查询的最重要子类别。我们必须首先将其与原始IP地址或类似指示用于提供特定于位置的名称的情况区分开来。对于那些通常缺乏安全含义的应用程序，依赖源IP地址等因素带来的危害很小；例如，在提供针对客户所在地区定制的web门户时，如果客户看到错误国家/地区的本地化门户，则不会构成安全漏洞。由于递归解析程序可能会掩盖DNS客户端的原始网络，最近的一项提案建议引入一个新的DNS查询参数，由DNS递归解析程序填充，以保留原始IP地址（请参见[EDNS-client-IP]）。然而，除了纯粹的装饰性用途外，由于私有IP地址、VPN等的普遍存在，这些方法具有已知的局限性，这些局限性掩盖了源IP地址，而是提供了可能距离原始端点很远的中介的IP地址。实现[EDNS-CLIENT-IP]描述的技术需要对递归解析器和权威服务器的操作进行重大更改，这些服务器将依赖原始源IP地址来选择资源记录，此外，还需要对缓存行为进行根本性更改。因此，这种技术无法以增量、单边的方式推广，但只有在双边（由权威服务器和递归解析器）实施时才能成功；这是部署的一个重要障碍。
In other deployments in use today, including those based on the BIND "views" feature, the source IP address is used to grant access to a selected, and potentially sensitive, set of resource records. The security implications of trusting the source IP address of a DNS query have prevented most solutions along these lines from being standardized (see [RFC6269]), though the practice remains widespread in "split horizon" private DNS deployments (see Section 4), which typically rely on an underlying security layer, such as a physical network, a clear perimeter demarcation at a network perimeter point (with network-layer anti-spoofing countermeasures), or an IPsec VPN, to prevent spoofing of the source IP address. These deployments do have a confidentiality requirement to prevent information intended for a constrained audience (internal to an enterprise, for example) from leaking to the public Internet -- while these internal network resources may use private IP addresses that should not be useful on the public Internet anyway, in some cases this leakage would reveal topology or other information that the name server administrator hopes to keep private. More recently, TSIG [RFC2845] has been employed as a way of selecting among "views" in BIND; this provides a stronger level of security than merely relying on the source IP address, but typically many users share the same secret to access a given view, and moreover TSIG does not provide confidentiality properties to DNS messages -- without network-layer separation between users of different views, eavesdroppers might capture the DNS queries and responses.
在目前使用的其他部署（包括基于绑定“视图”功能的部署）中，源IP地址用于授予对选定且可能敏感的资源记录集的访问权限。信任DNS查询的源IP地址所带来的安全问题阻碍了这些方面的大多数解决方案的标准化（请参见[RFC6269]），尽管这种做法在“拆分地平线”专用DNS部署中仍然很普遍（请参见第4节），这类部署通常依赖于底层安全层，如物理网络，在网络周界点（具有网络层反欺骗对策）或IPsec VPN处进行清晰的周界划分，以防止对源IP地址进行欺骗。这些部署确实有保密要求，以防止面向受限受众（例如，企业内部）的信息泄漏到公共Internet，而这些内部网络资源可能使用在公共Internet上无论如何都不应该有用的私有IP地址，在某些情况下，此泄漏会泄露名称服务器管理员希望保密的拓扑或其他信息。最近，TSIG[RFC2845]被用作BIND中“视图”的选择方式；这提供了比仅仅依赖源IP地址更高级别的安全性，但通常许多用户共享相同的机密来访问给定视图，而且TSIG不为DNS消息提供保密属性——不同视图的用户之间没有网络层分离，窃听者可能会捕获DNS查询和响应。
The use of source IP addresses as a discriminator to select DNS resource records, regardless of its lack of acceptance by the standards community, has widespread acceptance in the field. Some applications, however, go even further and propose extending the DNS to add an application-layer identifier of the originator; for example, [EDNS-OPT-CODE] provides a SIP URI in an EDNS(0) parameter. Effectively, this conveyance of application-layer information about the administrative identity of the originator through the DNS is a weak authentication mechanism, on the basis of which the DNS server makes an authorization decision before sharing resource records. This can approximate a confidentiality mechanism per resource record, where only a specific set of originators is permitted to see resource records, or a case where a query for the same name by different entities results in completely different resource record sets. However, without any underlying cryptographic security, this mechanism must rely on external layers for security (such as VPNs) rather than any direct assurance. Again, caching, forwarding, and recursion introduce significant challenges for applications that attempt to offload this responsibility to the DNS. Achieving feature parity with even the simplest authentication mechanisms available at the application layer would likely require significant rearchitecture of the DNS.
使用源IP地址作为鉴别器来选择DNS资源记录，尽管其未被标准团体接受，但在该领域已得到广泛接受。然而，一些应用程序甚至更进一步，建议扩展DNS以添加发起人的应用层标识符；例如，[EDNS-OPT-CODE]在EDNS（0）参数中提供SIPURI。实际上，通过DNS传输关于发端人的管理身份的应用层信息是一种弱身份验证机制，DNS服务器在此基础上在共享资源记录之前做出授权决策。这可以近似于每个资源记录的保密机制，其中仅允许一组特定的发起人查看资源记录，或者不同实体对相同名称的查询导致完全不同的资源记录集。然而，在没有任何底层加密安全性的情况下，该机制必须依赖外部层（如VPN）来实现安全性，而不是任何直接保证。同样，缓存、转发和递归为那些试图将此职责转移给DNS的应用程序带来了重大挑战。即使在应用层使用最简单的身份验证机制，也要实现功能奇偶性，这可能需要对DNS进行重大的重新架构。
As previously noted, applications can use a method like the "First Well Known Rule" of DDDS to transform an arbitrary string into a domain name and then receive from the DNS arbitrary data stored in TXT RRs, in the "regexp" of NAPTRs, or even in custom records. Some query-response applications, however, require queries and responses that simply fall outside the syntactic capabilities of the DNS. For example, domain names themselves must consist of labels that do not exceed 63 octets, while the total length of the encoded name may not exceed 255 octets, and applications that use label characters outside the traditional ASCII set may run into problems (however, see the discussion in [RFC6055], Section 3 for definitive guidance on the use of non-ASCII in the DNS). The DNS therefore cannot be a completely generic database. Similar concerns apply to the size of DNS responses.
如前所述，应用程序可以使用DDDS的“第一条众所周知的规则”等方法将任意字符串转换为域名，然后从DNS接收存储在TXT RRs、NAPTRs的“regexp”甚至自定义记录中的任意数据。但是，一些查询响应应用程序需要的查询和响应超出了DNS的语法功能。例如，域名本身必须由不超过63个八位字节的标签组成，而编码名称的总长度不得超过255个八位字节，并且在传统ASCII集之外使用标签字符的应用程序可能会遇到问题（但是，请参阅[RFC6055]中的讨论），第3节获取有关在DNS中使用非ASCII的最终指南）。因此，DNS不能是完全通用的数据库。类似的问题也适用于DNS响应的大小。
While the "data" URL specification [RFC2397] notes that it is "only useful for short values", unfortunately it gives no particular guidance about what "short" might mean. Some applications today use quite large data URLs (containing a megabyte or more of data) as workarounds in environments where only URIs can syntactically appear (for example, in Apple iOS, to pass objects between applications). The meaning of "short" in an application context is probably very different from how we should understand it in a DNS message. Referring to a typical public DNS deployment, [RFC5507] observes that "there's a strong incentive to keep DNS messages short enough to fit in a UDP datagram, preferably a UDP datagram short enough not to require IP fragmentation". And while EDNS(0) allows for mechanisms to negotiate DNS message sizes larger than the traditional 512 octets, there is a high risk that a long payload will cause UDP fragmentation, in particular when the DNS message already carries DNSSEC information. If EDNS(0) is not available, or the negotiated EDNS(0) packet size is too small to fit the data, or UDP fragments are dropped, the DNS may (eventually) resort to using TCP. While TCP allows DNS responses to be quite long, this requires stateful operation of servers, which can be costly in deployments where servers have only fleeting connections to many clients. Ultimately, there are forms of data that an application might store in the DNS that exceed reasonable limits: in the ENUM context, for example, something like storing base-64-encoded mp3 files of custom ringtones.
虽然“数据”URL规范[RFC2397]指出它“仅对短值有用”，但不幸的是，它没有给出关于“短”可能意味着什么的具体指导。今天，一些应用程序使用相当大的数据URL（包含一兆字节或更多的数据）作为解决方案，在只有URI可以语法显示的环境中（例如，在Apple iOS中，在应用程序之间传递对象）。应用程序上下文中“short”的含义可能与我们在DNS消息中应该如何理解它大不相同。参考一个典型的公共DNS部署，[RFC5507]观察到“有一个强烈的动机使DNS消息足够短以适合UDP数据报，最好是UDP数据报足够短以不需要IP碎片”。虽然EDNS（0）允许协商大于传统512个八位字节的DNS消息大小的机制，但长有效负载将导致UDP碎片的风险很高，特别是当DNS消息已携带DNSSEC信息时。如果EDN（0）不可用，或者协商的EDN（0）数据包大小太小，无法容纳数据，或者UDP片段被丢弃，DNS可能（最终）求助于使用TCP。虽然TCP允许DNS响应相当长，但这需要服务器的有状态操作，这在服务器与许多客户机之间只有短暂连接的部署中可能代价高昂。最终，应用程序可能会在DNS中存储超出合理限制的数据形式：例如，在枚举上下文中，类似于存储自定义铃声的base-64编码mp3文件。
Designs relying on storage of large amounts of data within DNS RRs furthermore need to minimize the potential damage achievable in a reflection attack (see [RFC4732], Section 3), in which the attacker sends UDP-only DNS queries with a forged source address, and the
依赖于在DNS RRs中存储大量数据的设计还需要将反射攻击（请参见[RFC4732]，第3节）中可能造成的潜在损害降至最低，在反射攻击中，攻击者使用伪造的源地址发送仅UDP的DNS查询，并且
victim receives the response. The attacker relies on amplification, where a small query generates a large response directed at the victim. Where the responder supports EDNS(0), an attacker may set the requester maximum payload size to a larger value while querying for a large resource record, such as a certificate [RFC4398]. Thus, the combination of large data stored in DNS RRs and responders supporting large payload sizes has the potential to increase the potential damage achievable in a reflection attack.
受害者收到回应。攻击者依赖于放大，其中一个小查询生成一个指向受害者的大响应。当响应程序支持EDN（0）时，攻击者可以在查询大型资源记录（如证书[RFC4398]）时，将请求程序的最大有效负载大小设置为更大的值。因此，存储在DNS RRs中的大数据和支持大负载大小的响应者的组合有可能增加反射攻击中可实现的潜在损害。
Since a reflection attack can be launched from any network that does not implement source address validation, these attacks are difficult to eliminate absent the ubiquitous deployment of source address validation or "heavier" transport protocols such as TCP. The bandwidth that can be mustered in a reflective amplification attack directed by a botnet reflecting off a recursive name server on a high-bandwidth network is sobering. For example, if the responding resolver could be directed to generate a 10KB response in reply to a 50-octet query, then magnification of 200:1 would be attainable. This would enable a botnet controlling 10000 hosts with 1 Mbps of bandwidth to focus 200 Gbps of traffic on the victim, more than sufficient to congest any site on today's Internet.
由于反射攻击可以从未实现源地址验证的任何网络发起，因此，如果不普遍部署源地址验证或“更重”的传输协议（如TCP），则很难消除这些攻击。在高带宽网络上，僵尸网络通过递归名称服务器反射的反射放大攻击中可以聚集的带宽令人警醒。例如，如果可以指示响应的解析器生成10KB响应以响应50个八位组的查询，则可以实现200:1的放大。这将使一个僵尸网络能够控制10000台主机，带宽为1Mbps，从而将200Gbps的流量集中到受害者身上，这足以使当今互联网上的任何站点拥塞。
DNS reflection attacks typically utilize UDP queries; it is prohibitively difficult to complete a TCP three-way handshake begun from a forged source address for DNS reflection attacks. Unless the attacker uses EDNS(0) [RFC6891] to enlarge the requester's maximum payload size, a response can only reach 576 octets before the truncate bit is set in the response. This limits the maximum magnification achievable from a DNS query that does not utilize EDNS(0). As the large disparity between the size of a query and size of the response creates this amplification, techniques for mitigating this disparity should be further studied, though this is beyond the scope of this memo (for an analysis of the effects of limiting EDNS(0) responses while still accommodating DNSSEC, see [Lindsay]). For example, some implementations could limit EDNS(0) responses to a specific ratio compared to the request size, where the precise ratio can be configured on a per-deployment basis (taking into account DNSSEC response sizes). Without some means of mitigating the potential for amplification, EDNS(0) could cause significant harm.
DNS反射攻击通常利用UDP查询；完成从伪造源地址开始的用于DNS反射攻击的TCP三方握手非常困难。除非攻击者使用EDNS（0）[RFC6891]扩大请求者的最大有效负载大小，否则在响应中设置截断位之前，响应只能达到576个八位字节。这限制了不使用EDN的DNS查询可实现的最大放大率（0）。由于查询大小和响应大小之间的巨大差异造成了这种放大，因此应进一步研究缓解这种差异的技术，尽管这超出了本备忘录的范围（关于限制EDN（0）响应，同时仍适应DNSSEC的影响分析，见[Lindsay]）。例如，一些实现可以将EDN（0）响应限制为与请求大小相比的特定比率，其中可以在每个部署的基础上配置精确比率（考虑DNSSEC响应大小）。如果没有某种减轻放大可能性的方法，EDN（0）可能会造成重大伤害。
In summary, there are two operational forces that tend to drive the practically available EDNS(0) sizes down: possible UDP fragmentation and minimizing amplification in case of reflection attacks. DNSSEC data will use a significant fraction of the available space in a DNS packet. Therefore -- appreciating that given the current DNSSEC and
总之，有两种作战力量倾向于降低实际可用的EDN（0）大小：可能的UDP碎片和在反射攻击情况下最小化放大。DNSSEC数据将使用DNS数据包中相当一部分可用空间。因此，鉴于目前的DNSSEC和
EDNS(0) deployment experience, precise numbers are impossible to give -- the generic payload available to other DNS data, given the premise that TCP fallback is to be minimized, is likely to be closer to several hundred octets than a few thousand octets.
根据EDNS（0）部署经验，无法给出精确的数字——在TCP回退最小化的前提下，其他DNS数据可用的通用有效负载可能比几千个八位字节更接近几百个八位字节。
While the DDDS framework enables any sort of alphanumeric data to serve as a domain name through the application of the "First Well Known Rule", the delegative structure of the resulting domain name may not reflect any administrative division of responsibilities inherent in the original data. While [RFC3402] requires only that the "Application Unique String has some kind of regular, lexical structure that the rules can be applied to", DDDS is first and foremost a delegation system: its abstract stipulates that "Well-formed transformation rules will reflect the delegation of management of information associated with the string". Telephone numbers in the United States, for example, are assigned and delegated in a relatively complex manner. Historically, the first six digits of a nationally specific number (called the "NPA/NXX") reflected a point of administrative delegation from the number assignment agency to a carrier; from these blocks of ten thousand numbers, the carrier would in turn delegate individual assignments of the last four digits (the "XXXX" portion) to particular customers. However, after the rise of North American telephone number portability in the 1990s, the first point of delegation went away: the delegation is effectively from the number authority to the carrier for each complete ten-digit number (NPA/NXX-XXXX). While technical implementation details differ from nation to nation, number portability systems with similar administrative delegations now exist worldwide.
虽然DDDS框架通过应用“第一条众所周知的规则”允许任何种类的字母数字数据作为域名，但由此产生的域名的授权结构可能不会反映原始数据中固有的任何行政责任划分。虽然[RFC3402]只要求“应用程序唯一字符串具有规则可应用的某种规则、词汇结构”，但DDDS首先是一个委托系统：其摘要规定“格式良好的转换规则将反映与字符串相关的信息管理的委托”。例如，美国的电话号码是以一种相对复杂的方式分配和委派的。历史上，国家特定号码（称为“NPA/NXX”）的前六位数字反映了号码分配机构向承运人的行政授权点；从这些一万个数字块中，承运人将依次将最后四位数字（“XXXX”部分）的个人分配委托给特定客户。然而，在20世纪90年代北美电话号码便携性兴起后，第一个授权点就消失了：每一个完整的十位数号码（NPA/NXX-XXXX）的授权实际上是从号码管理局到运营商的。虽然各国的技术实施细节各不相同，但具有类似管理授权的号码可移植系统目前在全世界都存在。
To render these identifiers as domain names in accordance with the DDDS Rule for ENUM yields a large flat administrative domain with no points of administrative delegation from the country-code administrator, e.g., 1.e164.arpa, down to the ultimate assignee of a number. Under the assumption that one administrative domain is maintained within one DNS zone containing potentially over five billion names, scalability difficulties manifest in a number of areas: the scalability that results from caching depends on these points of delegation, so that cached results for intermediate servers take the load off higher-tier servers. If there are no such delegations, then as in the telephone number example the zone apex server must bear the entire load for queries. Worse still, number portability also introduces far more dynamism in number assignment, where in some regions updated assignees for ported numbers must propagate within fifteen minutes of a change in administration. Jointly, these two problems make caching the zone extremely problematic. Moreover, traditional tools for DNS replication, such
根据ENUM的DDDS规则将这些标识符呈现为域名将产生一个大型的扁平管理域，没有国家代码管理员（例如1.e164.arpa）的管理授权点，直至数字的最终受让人。假设一个管理域在一个DNS区域内维护，其中包含可能超过50亿个名称，可伸缩性困难表现在许多方面：缓存产生的可伸缩性取决于这些委托点，因此，中间服务器的缓存结果可以减轻高层服务器的负载。如果没有此类委托，则如电话号码示例中所示，zone apex服务器必须承担查询的全部负载。更糟糕的是，号码可移植性还为号码分配带来了更大的活力，在某些地区，已移植号码的更新受让人必须在管理变更后15分钟内传播。这两个问题共同导致缓存区域的问题非常严重。此外，用于DNS复制的传统工具，如
as the zone transfer protocols AXFR [RFC1034] and IXFR [RFC1995], might not scale to accommodate zones with these dimensions and properties.
由于分区传输协议AXFR[RFC1034]和IXFR[RFC1995]可能无法扩展以适应具有这些尺寸和特性的分区。
In practice, the maximum sizes of telephone number administrative domains are closer to 300M (the current amount of allocated telephone numbers in the United States today -- still more than three times the number of .com domain names), and one can alleviate some of the scalability issues mentioned above by artificially dividing the administrative domain into a hierarchy of DNS zones. Still, the fact that traditional DNS management tools no longer apply to the structures that an application tries to provision in the DNS is a clue that the DNS might not be the right place for an application to store its data.
实际上，电话号码管理域的最大规模接近3亿（美国目前分配的电话号码数量——仍然是.com域名数量的三倍多），通过人为地将管理域划分为DNS区域的层次结构，可以缓解上面提到的一些可伸缩性问题。然而，传统DNS管理工具不再适用于应用程序试图在DNS中提供的结构这一事实表明，DNS可能不是应用程序存储其数据的正确位置。
While DDDS is the most obvious example of these concerns, the point is more generic: for example, were address portability to be implemented for IP addresses and their administration thus to become non-hierarchical, the same concerns would apply to in-addr.arpa names. The difficulty of mapping the DNS to administrative structures can even occur with traditional domain names, where applications expect clients to infer or locate zone cuts. In the web context, for example, it can be difficult for applications to determine whether two domains represent the same "site" when comparing security credentials with URLs (see Section 3.4 below for more on this). This has also caused known problems in determining the scope of web cookies, in contexts where applications must infer where administrative domains end in order to grant cookies that are as narrowly scoped as possible.
虽然DDDS是这些问题中最明显的例子，但这一点更为普遍：例如，如果IP地址的地址可移植性及其管理因此变得非层次化，那么同样的问题也适用于in-addr.arpa名称。将DNS映射到管理结构的困难甚至可能发生在传统域名上，在传统域名中，应用程序希望客户端推断或定位区域切割。例如，在web环境中，应用程序在将安全凭据与URL进行比较时，很难确定两个域是否代表同一个“站点”（有关详细信息，请参阅下面的第3.4节）。这也导致了确定web Cookie范围的已知问题，在这种情况下，应用程序必须推断管理域的结束位置，以便授予范围尽可能窄的Cookie。
In summary, the "First Well Known Rule" of DDDS provides a capability that transforms arbitrary strings into domain names, but those names play well with the DNS only when the input strings have an administrative structure that maps to DNS delegations. In the first place, delegation implies some sort of hierarchical structure. Any mechanism to map a hierarchical identifier into a domain name should be constructed such that the resulting domain name does match the natural hierarchy of the original identifier. Although telephone numbers, even in North America, have some hierarchical qualities (like the geographical areas corresponding to their first three digits), after the implementation of number portability these points no longer mapped onto an administrative delegation. If the input string to the DDDS does not have a hierarchical structure representing administrative delegations that can map onto the DNS distribution system, then that string probably is not a good candidate for translating into a domain name.
总之，DDDS的“第一条众所周知的规则”提供了将任意字符串转换为域名的功能，但只有当输入字符串具有映射到DNS委托的管理结构时，这些名称才能很好地与DNS配合使用。首先，委托意味着某种层次结构。任何将层次标识符映射到域名的机制的构造都应该确保生成的域名与原始标识符的自然层次结构匹配。尽管电话号码，即使是在北美，也具有一定的等级性质（如前三位数字对应的地理区域），但在实施号码可移植性后，这些点不再映射到行政授权。如果DDDS的输入字符串没有表示可以映射到DNS分发系统的管理委派的层次结构，那么该字符串可能不是翻译为域名的好候选。
There are also other ways in which the delegative structure of an identifier may not map well onto the DNS. Traditionally, DNS resolvers assume that when they receive a domain name from an application the name is complete -- that it is not a fragment of a domain name that a user is still in the middle of typing. For some communications systems, however, this assumption does not apply. ENUM use cases have surfaced a couple of optimization requirements to reduce unnecessary calls and queries; proposed solutions include metadata in the DNS that describes the contents and structure of ENUM DNS trees to help applications handle incomplete queries or queries for domains not in use.
还有其他方式，标识符的delegative结构可能无法很好地映射到DNS。传统上，DNS解析器假设当他们从应用程序接收到域名时，名称是完整的，这不是一个域名的碎片，用户仍然处于打字的中间。但是，对于某些通信系统，此假设不适用。枚举用例提出了一些优化需求，以减少不必要的调用和查询；建议的解决方案包括DNS中的元数据，用于描述枚举DNS树的内容和结构，以帮助应用程序处理不完整的查询或未使用的域的查询。
In particular, the "send-n" proposal [ENUM-Send-N] hoped to reduce the number of DNS queries sent in regions with variable-length numbering plans. When a dialed number potentially has a variable length, a telephone switch ordinarily cannot anticipate when a dialed number is complete, as only the numbering plan administrator (who may be a national regulator, or even in open number plans a private branch exchange) knows how long a telephone number needs to be. Consequently, a switch trying to resolve such a number through a system like ENUM might send a query for a telephone number that has only partially been dialed in order to test its completeness. The send-n proposal installs in the DNS a hint informing the telephone switch of the minimum number of digits that must be collected by placing in zones corresponding to incomplete telephone numbers some resource records that state how many more digits are required -- effectively how many steps down the DNS tree one must take before querying the DNS again. Unsurprisingly, those boundaries reflect points of administrative delegation, where the parent in a number plan yields authority to a child. With this information, the application is not required to query the DNS every time a new digit is dialed but can wait to collect sufficient digits to receive a response. As an optimization, this practice thus saves the resources of the DNS server, though the call cannot complete until all digits are collected, so this mechanism simply reduces the time the system will wait before sending an ENUM query after collecting the final dialed digit. A tangentially related proposal, [ENUM-UNUSED], similarly places resource records in the DNS that tell the application that it need not attempt to reach a number on the telephone network, as the number is unassigned -- a comparable general DNS mechanism would identify, for a domain name with no records available in the DNS, whether or not the domain had been allocated by a registry to a registrant (which is a different condition than a name merely being unresolvable, per the semantics of NXDOMAIN).
特别是，“send-n”提案[ENUM-send-n]希望减少在具有可变长度编号计划的区域中发送的DNS查询的数量。当一个已拨号码可能具有可变长度时，电话交换机通常无法预测一个已拨号码何时完成，因为只有编号计划管理员（可能是国家监管机构，甚至在开放号码计划中是私人分支交换机）知道一个电话号码需要多长时间。因此，试图通过类似ENUM的系统解析这样一个号码的交换机可能会发送一个查询，查询只拨了一部分的电话号码，以测试其完整性。send-n提案在DNS中安装了一个提示，通知电话交换机必须收集的最小位数，方法是将一些资源记录放置在与不完整电话号码对应的区域中，这些资源记录说明还需要多少位数——实际上，在查询请求之前必须在DNS树中执行多少步又是DNS。毫不奇怪，这些边界反映了行政授权点，即数字计划中的家长将权力让给了孩子。有了此信息，应用程序无需在每次拨打新数字时查询DNS，但可以等待收集足够的数字以接收响应。作为一种优化，这种做法因此节省了DNS服务器的资源，尽管在收集所有数字之前呼叫无法完成，因此这种机制简单地减少了系统在收集最终拨号数字后发送枚举查询之前等待的时间。与此相关的方案[ENUM-UNUSED]同样在DNS中放置资源记录，告知应用程序无需尝试访问电话网络上的某个号码，因为该号码是未分配的——对于DNS中没有可用记录的域名，类似的通用DNS机制将识别，域是否已由注册中心分配给注册人（根据NXDOMAIN的语义，这与名称不可解析不同）。
Both proposals optimize application behavior by placing metadata in the DNS that predicts the success of future queries or application invocation by identifying points of administrative delegation or assignment in the tree. In some respects, marking a point in the tree where a zone begins or ends has some features in common with the traditional parent zone use of the NS record type, except that instead of pointing to a child zone these metadata proposals point to distant grandchildren. While this does not change resolver behavior as such (instead, it changes the way that applications invoke the resolver), it does have implications for the practices for zone administrators. Metadata in one administrative domain would need to remain synchronized with the state of the resources it predicts in another administrative domain in the DNS namespace, in a case like overlap dialing where the carrier delegates to a zone controlled by an enterprise. When dealing with external resources associated with other namespaces, like number assignments in the PSTN or the databases of a registry operator, other synchronization requirements arise; maintaining that synchronization requires that the DNS have "semi-real time" updates that may conflict with scale and caching mechanisms of the DNS.
这两个方案都通过在DNS中放置元数据来优化应用程序行为，通过在树中标识管理委派或分配点来预测未来查询或应用程序调用的成功。在某些方面，在树中标记区域开始或结束的点与使用NS记录类型的传统父区域有一些共同的特点，除了这些元数据建议不指向子区域，而是指向遥远的孙子。虽然这不会改变解析器的行为（相反，它会改变应用程序调用解析器的方式），但它确实会对区域管理员的实践产生影响。一个管理域中的元数据需要与它在DNS名称空间中预测的另一个管理域中的资源状态保持同步，这种情况类似于重叠拨号，其中运营商委托到企业控制的区域。当处理与其他名称空间相关联的外部资源时，如PSTN中的号码分配或注册表操作员的数据库，会出现其他同步要求；保持同步需要DNS具有可能与DNS的规模和缓存机制冲突的“半实时”更新。
Placing metadata in the DNS may also raise questions about the authority and delegation model. Who gets to supply records for unassigned names? While in the original but little-used e164.arpa root of ENUM this would almost certainly be a numbering plan administrator, it is far less clear who that would be in the more common and successful "infrastructure" ENUM models (see Section 4). Ultimately, these metadata proposals share some qualities with DNS redirection services offered by ISPs (for example, [DNS-REDIRECT]) that "help" web users who try to browse to sites that do not exist. Similarly, metadata proposals like [ENUM-UNUSED] create DNS records for unallocated zones that redirect to a service provider's web page. However, in the [DNS-REDIRECT] cases, at least the existence or non-existence of a domain name is a fact about the Internet namespace, rather than about an external namespace like the telephony E.164 namespace (which must be synchronized with the DNS tree in the metadata proposals). In send-n, different leaf zones that administer telephone numbers of different lengths can only provision their hints at their own apex, which provides an imperfect optimization: they cannot install it themselves in a parent, both because they lack the authority and because different zones would want to provision contradictory data. The later the hint appears in the tree, however, the less optimization will result. An application protocol designer managing identifiers whose administrative model does not map well onto the DNS namespace and delegations structure would be better served to implement such features outside the DNS.
在DNS中放置元数据也可能会引起有关权限和委托模型的问题。谁可以提供未分配姓名的记录？虽然在最初但很少使用的e164.arpa ENUM根中，这几乎肯定是一个编号计划管理员，但在更常见和成功的“基础设施”ENUM模型中，谁将是谁还不太清楚（见第4节）。最终，这些元数据方案与ISP提供的DNS重定向服务（例如，[DNS-REDIRECT]）具有一些共同的特性，这些服务“帮助”试图浏览到不存在的站点的web用户。类似地，类似于[ENUM-UNUSED]的元数据建议为重定向到服务提供商网页的未分配区域创建DNS记录。然而，在[DNS-REDIRECT]情况下，至少域名的存在或不存在是关于Internet名称空间的事实，而不是关于外部名称空间，如telephony E.164名称空间（必须与元数据提案中的DNS树同步）。在send-n中，管理不同长度电话号码的不同叶区只能在自己的顶点提供提示，这提供了一个不完美的优化：它们无法将其自身安装到父级中，这既是因为它们缺乏权限，也是因为不同的叶区希望提供相互矛盾的数据。然而，提示在树中出现的时间越晚，优化效果就越差。如果应用程序协议设计人员管理的标识符的管理模型不能很好地映射到DNS命名空间和委派结构，则可以更好地在DNS之外实现此类功能。
Most Internet application services provide a redirection feature -- when one attempts to contact a service, the service may refer the person to a different service instance, potentially in another domain, that is for whatever reason better suited to service a request. In HTTP and SIP, for example, this feature is implemented by the 300 class responses containing one or more URIs, which may indicate that a resource has moved temporarily or permanently to another service. Several tools in the DNS, including the SRV record, can provide a similar feature at a DNS level, and consequently some applications as an optimization offload the responsibility for redirection to the DNS; NAPTR can also provide this capability on a per-application basis, and numerous DNS resource records can provide redirection on a per-domain basis. This can prevent the unnecessary expenditure of application resources on a function that could be performed as a component of a DNS lookup that is already a prerequisite for contacting the service. Consequently, in some deployment architectures this DNS-layer redirection is used for virtual hosting services.
大多数Internet应用程序服务都提供了重定向功能——当一个人试图联系某个服务时，该服务可能会将此人转介到另一个域中的另一个服务实例，无论出于何种原因，该实例更适合为请求提供服务。例如，在HTTP和SIP中，此功能由包含一个或多个URI的300类响应实现，这可能表示资源已临时或永久移动到另一个服务。DNS中的几个工具，包括SRV记录，可以在DNS级别提供类似的功能，因此一些应用程序作为优化，可以减轻重定向到DNS的责任；NAPTR还可以在每个应用程序的基础上提供此功能，许多DNS资源记录可以在每个域的基础上提供重定向。这可以防止将应用程序资源不必要地花费在可以作为DNS查找组件执行的功能上，DNS查找已经是联系服务的先决条件。因此，在某些部署体系结构中，此DNS层重定向用于虚拟主机服务。
Implementing domain redirection in the DNS, however, has important consequences for application security. In the absence of universal DNSSEC, applications must blindly trust that their request has not been hijacked at the DNS layer and redirected to a potentially malicious domain, unless some subsequent application mechanism can provide the necessary assurance. By way of contrast, application-layer protocols supporting redirection, such as HTTP and SIP, have available security mechanisms, including TLS, that can use certificates to attest that a 300 response came from the domain that the originator initially hoped to contact.
但是，在DNS中实现域重定向对应用程序安全具有重要影响。在缺少通用DNSSEC的情况下，应用程序必须盲目相信其请求没有在DNS层被劫持并重定向到潜在的恶意域，除非某些后续应用程序机制能够提供必要的保证。相比之下，支持重定向的应用层协议（如HTTP和SIP）具有可用的安全机制，包括TLS，可以使用证书证明300响应来自发起人最初希望联系的域。
A number of applications have attempted to provide an after-the-fact
security mechanism that verifies the authority of a DNS delegation in
the absence of DNSSEC. The specification for dereferencing SIP URIs
([RFC3263], reaffirmed in [RFC5922]), requires that during TLS
establishment the site eventually reached by a SIP request present a
certificate corresponding to the original URI expected by the user;
this requires a virtual hosting service to possess a certificate
corresponding to the hosted domain. (In other words, if example.com
redirects to example.net in the DNS, this mechanism expects that
example.net will supply a certificate for example.com in TLS, per the
HTTP precedent in [RFC2818]). This restriction rules out many styles
of hosting deployments common in the web world today, however.
[HARD-PROBLEM] explores this problem space. [RFC6125] proposes a
solution for all applications that use TLS, which relies on new
application-specific identifiers in certificates, as does [RFC4985]);
note, however, that support for such certificates would require
A number of applications have attempted to provide an after-the-fact
security mechanism that verifies the authority of a DNS delegation in
the absence of DNSSEC. The specification for dereferencing SIP URIs
([RFC3263], reaffirmed in [RFC5922]), requires that during TLS
establishment the site eventually reached by a SIP request present a
certificate corresponding to the original URI expected by the user;
this requires a virtual hosting service to possess a certificate
corresponding to the hosted domain. (In other words, if example.com
redirects to example.net in the DNS, this mechanism expects that
example.net will supply a certificate for example.com in TLS, per the
HTTP precedent in [RFC2818]). This restriction rules out many styles
of hosting deployments common in the web world today, however.
[HARD-PROBLEM] explores this problem space. [RFC6125] proposes a
solution for all applications that use TLS, which relies on new
application-specific identifiers in certificates, as does [RFC4985]);
note, however, that support for such certificates would require
changes to existing certificate authority practices as well as application behavior. With DNSSEC in place, DNS-based Authentication of Named Entities (DANE) [RFC6394] offers another way to bind certificates to particular applications and services.
对现有证书颁发机构做法以及应用程序行为的更改。有了DNSSEC，基于DNS的命名实体身份验证（DANE）[RFC6394]提供了另一种将证书绑定到特定应用程序和服务的方法。
All of these application-layer measures attempt to mirror the delegation of administrative authority in the DNS, when the DNS itself serves as the ultimate authority on how domains are delegated. (Note: changing the technical delegation structure by changing NS records in the DNS is not the same as administrative delegation, e.g., when a domain changes ownership.) Synchronizing a static instrument like a certificate with a delegation in the DNS, however, is problematic because delegations are not static: revoking and reissuing a certificate every time an administrative delegation changes is cumbersome operationally. In environments where DNSSEC is not available, the problems with securing DNS-layer redirections would be avoided by performing redirections in the application layer. This inevitably gives rise to various design trade-offs involving performance, load, and related factors, but in these application environments, the security properties typically take priority.
所有这些应用层措施都试图反映DNS中的管理权限委托，而DNS本身是如何委托域的最终权限。（注意：通过更改DNS中的NS记录来更改技术委派结构与管理委派不同，例如，当域更改所有权时。）但是，将静态工具（如证书）与DNS中的委派同步，这是有问题的，因为委派不是静态的：每次管理委派更改时撤销和重新颁发证书在操作上很麻烦。在DNSSEC不可用的环境中，通过在应用层执行重定向，可以避免DNS层重定向安全问题。这不可避免地会导致各种设计权衡，包括性能、负载和相关因素，但在这些应用程序环境中，安全属性通常优先考虑。
The classic view of the uniqueness of domain names in the DNS is given in [RFC2826]:
DNS中域名唯一性的经典视图见[RFC2826]：
DNS names are designed to be globally unique, that is, for any one DNS name at any one time there must be a single set of DNS records uniquely describing protocol addresses, network resources and services associated with that DNS name. All of the applications deployed on the Internet which use the DNS assume this, and Internet users expect such behavior from DNS names.
DNS名称被设计为全局唯一，即，对于任何一个DNS名称，在任何时间都必须有一组唯一描述与该DNS名称相关联的协议地址、网络资源和服务的DNS记录。部署在Internet上的所有使用DNS的应用程序都假定了这一点，Internet用户期望DNS名称具有这种行为。
[RFC2826] "does not preclude private networks from operating their own private name spaces" but notes that if private networks "wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy". There are various DNS deployments outside of the global public DNS, including "split horizon" deployments and DNS usages on private (or virtual private) networks. In a split horizon, an authoritative server gives different responses to queries from the public Internet than they do to internal resolvers; while some deployments differentiate internal queries from public queries by the source IP address, the concerns in Section 3.1.1 relating to trusting source IP addresses apply to such deployments. When the internal address space range is private [RFC1918], this makes it both easier for the server to discriminate public from private and harder for public entities to impersonate nodes in the private network. Networks that are made
[RFC2826]“不排除专用网络运行其自己的专用名称空间”，但指出，如果专用网络“希望使用为全球互联网唯一定义的名称，则必须从全球DNS命名层次结构获取该信息”。全球公共DNS之外有各种DNS部署，包括“拆分地平线”部署和专用（或虚拟专用）网络上的DNS使用。在一个分离的视界中，权威服务器对来自公共互联网的查询的响应与对内部解析程序的响应不同；虽然某些部署通过源IP地址区分内部查询和公共查询，但第3.1.1节中有关信任源IP地址的问题适用于此类部署。当内部地址空间范围为私有[RFC1918]时，这使得服务器更容易区分公共和私有，公共实体也更难模拟私有网络中的节点。制造的网络
private physically, or logically by cryptographic tunnels, make these private deployments more secure. The most complex deployments along these lines use multiple virtual private networks to serve different answers for the same name to many distinct networks.
通过加密隧道在物理上或逻辑上实现私有，使这些私有部署更加安全。这些线路上最复杂的部署使用多个虚拟专用网络为许多不同的网络提供相同名称的不同答案。
The use cases that motivate split-horizon DNS typically involve restricting access to some network services -- intranet resources such as internal web sites, development servers, or directories, for example -- while preserving the ease of use offered by domain names for internal users. While for many of these resources the split horizon would not return answers to public resolvers for those internal resources (those records are kept confidential from the public), in some cases the same name (e.g., "mail.example.com") might resolve to one host internally but another externally. The requirements for multiple-VPN private deployments, however, are different: in this case the authoritative server gives different, and confidential, answers to a set of resolvers querying for the same name. While these sorts of use cases rarely arise for traditional domain names, where, as [RFC2826] says, users and applications expect a unique resolution for a name, they can easily arise when other sorts of identifiers have been translated by a mechanism such as the "First Well Known Rule" of DDDS into "domain name syntax". Telephone calls, for example, are traditionally routed through highly mediated networks, in which an attempt to find a route for a call often requires finding an appropriate intermediary based on the source network and location rather than finding an endpoint (see the distinction between the Look-Up Function and Location Routing Function in [RFC5486]). Moreover, the need for responses tailored to the originator, and for confidentiality, is easily motivated when the data returned by the DNS is no longer "describing protocol addresses, network resources and services" [RFC2826] but instead is arbitrary data. Although, for example, ENUM was originally intended for deployment in the global public root of the DNS (under e164.arpa), the requirements of maintaining telephone identifiers in the DNS quickly steered operators into private deployments.
激励拆分地平线DNS的用例通常涉及限制对某些网络服务的访问，例如内部网站、开发服务器或目录等内部网资源，同时保留域名为内部用户提供的易用性。虽然对于这些资源中的许多资源，split horizon不会向这些内部资源的公共解析程序返回答案（这些记录对公众保密），但在某些情况下，相同的名称（例如，“mail.example.com”）可能在内部解析到一台主机，但在外部解析到另一台主机。但是，对多个VPN专用部署的要求是不同的：在这种情况下，权威服务器对查询相同名称的一组解析程序给出了不同且机密的答案。虽然这些类型的用例很少出现在传统域名上，正如[RFC2826]所说，用户和应用程序期望一个名称具有唯一的解析，但当其他类型的标识符被DDDS的“第一条众所周知的规则”等机制翻译成“域名语法”时，它们很容易出现。例如，电话呼叫传统上通过高度中介的网络进行路由，在这种网络中，试图找到呼叫的路由通常需要根据源网络和位置找到合适的中介，而不是找到端点（请参阅中查找功能和位置路由功能之间的区别）[RFC5486]）。此外，当DNS返回的数据不再“描述协议地址、网络资源和服务”[RFC2826]时，很容易激发针对发起者的响应以及保密性的需求但实际上是任意数据。例如，尽管ENUM最初打算部署在DNS的全局公共根目录中（根据e164.arpa），但在DNS中维护电话标识符的要求很快将运营商引导到了私有部署中。
In private environments, it is also easier to deploy any necessary extensions than it is in the public DNS: in the first place, proprietary non-standard extensions and parameters can more easily be integrated into DNS queries or responses, as the implementations of resolvers and servers can likely be controlled; secondly, confidentiality and custom responses can be provided by deploying, respectively, underlying physical or virtual private networks to shield the private tree from public queries, and effectively different virtual DNS trees for each administrative entity that might launch a query; thirdly, in these constrained environments, caching and recursive resolvers can be managed or eliminated in order to prevent any unexpected intermediary behavior. While these private
在私有环境中，部署任何必要的扩展也比在公共DNS中容易：首先，专有的非标准扩展和参数可以更容易地集成到DNS查询或响应中，因为解析程序和服务器的实现可能可以控制；其次，可以通过分别部署底层物理或虚拟专用网络来提供机密性和自定义响应，以保护私有树不受公共查询的影响，并为可能启动查询的每个管理实体有效地部署不同的虚拟DNS树；第三，在这些受限环境中，可以管理或消除缓存和递归解析器，以防止任何意外的中介行为。这些是私人的
deployments serve an important role in the marketplace, there are risks in using techniques intended only for deployment in private and constrained environments as the basis of a standard solution. When proprietary parameters or extensions are deployed in private environments, experience teaches us that these implementations will begin to interact with the public DNS and that the private practices will leak.
部署在市场中扮演着重要角色，使用仅用于在私有和受限环境中部署的技术作为标准解决方案的基础存在风险。当在私有环境中部署专有参数或扩展时，经验告诉我们，这些实现将开始与公共DNS交互，并且私有实践将泄漏。
While such leakage is not a problem when using the mechanisms described in Sections 3.1, 3.2, and 3.5 (with private RR types) of [RFC5507], other extension mechanisms might cause confusion or harm if leaked. The use of a dedicated suffix (Section 3.3 of [RFC5507]) in a private environment might cause confusion if leaked to the public Internet, for example.
虽然在使用[RFC5507]第3.1、3.2和3.5节（使用专用RR类型）中描述的机制时，此类泄漏不是问题，但如果泄漏，其他扩展机制可能会导致混淆或损害。例如，在私人环境中使用专用后缀（RFC5507第3.3节）可能会导致混淆，如果泄露到公共互联网上。
That this kind of leakage of protocol elements from private deployments to public deployments does happen has been demonstrated, for example, with SIP: SIP implemented a category of supposedly private extensions ( the "P-" headers) that saw widespread success and use outside of the constrained environments for which they were specifically designed. There is no reason to think that implementations with similar "private" extensions to the DNS protocols would not similarly end up in use in public environments.
这种协议元素从私有部署泄漏到公共部署的情况已经被证明，例如，SIP:SIP实现了一类假定的私有扩展（“P-”头）这见证了广泛的成功，并在专门为其设计的受限环境之外使用。没有理由认为对DNS协议进行类似“私有”扩展的实现不会在公共环境中使用。
The success of the global public DNS relies on the fact that it is a distributed database, one that has the property that it is loosely coherent and offers lookup instead of search functionality. Loose coherency means that answers to queries are coherent within the bounds of data replication between authoritative servers (as controlled by the administrator of the zone) and caching behavior by recursive name servers. Today, this term increasingly must also include load-balancing or related features that rely on the source IP address of the resolver. It is critical that application designers who intend to use the DNS to support their applications consider the implications that their uses have for the behavior of resolvers; intermediaries, including caches and recursive resolvers; and authoritative servers.
全球公共DNS的成功依赖于这样一个事实：它是一个分布式数据库，具有松散一致性的特性，并提供查找而不是搜索功能。松散一致性意味着查询的答案在权威服务器（由区域管理员控制）之间的数据复制和递归名称服务器的缓存行为的范围内是一致的。如今，这个术语还必须越来越多地包括依赖于解析器的源IP地址的负载平衡或相关功能。至关重要的是，打算使用DNS来支持应用程序的应用设计者考虑其使用对解析器行为的影响；中介，包括缓存和递归解析器；和权威服务器。
It is likely that the DNS provides a good match whenever the needs of applications are aligned with the following properties:
只要应用程序的需求符合以下属性，DNS就可能提供良好的匹配：
o Data stored in the DNS can be propagated and cached using conventional DNS mechanisms, without intermediaries needing to understand exceptional logic (considerations beyond the name, type, and class of the query) used by the authoritative server to formulate responses
o 存储在DNS中的数据可以使用传统的DNS机制进行传播和缓存，而无需中介机构了解权威服务器用于制定响应的异常逻辑（除了查询的名称、类型和类别之外的考虑因素）
o Data stored in the DNS is indexed by keys that do not violate the syntax or semantics of domain names
o DNS中存储的数据由不违反域名语法或语义的键索引
o Applications invoke the DNS to resolve complete names, not fragments
o 应用程序调用DNS来解析完整的名称，而不是片段
o Answers do not depend on an application-layer identity of the entity doing the query
o 答案不取决于执行查询的实体的应用程序层标识
o Ultimately, applications invoke the DNS to assist in communicating with a service whose name is resolved through the DNS
o 最终，应用程序调用DNS来帮助与通过DNS解析名称的服务进行通信
Whenever one of the five properties above does not apply to one's data, one should seriously consider whether the DNS is the best place to store actual data. On the other hand, if one has to worry about the following items, then these items are good indicators that the DNS is not the appropriate tool for solving problems:
每当上面的五个属性中的一个不适用于某个人的数据时，就应该认真考虑DNS是否是存储实际数据的最佳位置。另一方面，如果必须担心以下事项，则这些事项很好地表明DNS不是解决问题的适当工具：
o Populating metadata about domain boundaries within the tree -- the points of administrative delegation in the DNS are something that applications are not in general aware of
o 在树中填充关于域边界的元数据——DNS中的管理委派点是应用程序通常不知道的
o Domain names derived from identifiers that do not share a semantic or administrative model compatible with the DNS
o 从与DNS不共享语义或管理模型的标识符派生的域名
o Selective disclosure of data stored in and provided by the DNS
o 选择性披露DNS中存储和提供的数据
o DNS responses not fitting into UDP packets, unless EDNS(0) is available, and only then with the caveats discussed in Section 3.2.1
o DNS响应不适合UDP数据包，除非EDN（0）可用，并且只有在符合第3.2.1节中讨论的注意事项的情况下
In cases where applications require these sorts of features, they are likely better instantiated by independent application-layer protocols than the DNS. For example, the objects that HTTP can carry in both queries and responses can easily contain the necessary structure to manage compound queries. Many applications already use HTTP because of widespread support for it in middleboxes. Similarly, HTTP has numerous ways to provide the necessary authentication, authorization, and confidentiality properties that some features require, as well as
在应用程序需要这些功能的情况下，它们可能比DNS更好地由独立的应用程序层协议实例化。例如，HTTP可以在查询和响应中携带的对象可以轻松包含管理复合查询所需的结构。许多应用程序已经使用HTTP，因为它在中间件中得到了广泛的支持。类似地，HTTP有许多方法来提供某些功能所需的必要身份验证、授权和机密性属性，以及
the redirection properties discussed in Section 3.4. These differences highlight the fact that the DNS and HTTP offer very different services and have different applicabilities; while both are query-response protocols, HTTP should not be doing the job of DNS, and DNS should not be doing the job of HTTP. Similarly, DNS should not be doing the job of Diameter, LDAP, or other application-layer protocols. The overhead of using any application-layer protocol may not be appropriate for all environments, of course, but even in environments where a more lightweight protocol is appropriate, DNS is usually not the only alternative.
第3.4节中讨论的重定向属性。这些差异突出表明，DNS和HTTP提供非常不同的服务，具有不同的适用性；虽然两者都是查询响应协议，但HTTP不应执行DNS的工作，DNS也不应执行HTTP的工作。类似地，DNS不应该执行Diameter、LDAP或其他应用层协议的工作。当然，使用任何应用层协议的开销可能并不适用于所有环境，但即使在更轻量级协议适用的环境中，DNS通常也不是唯一的选择。
Where the administrative delegations of the DNS form a necessary component in the instantiation of an application feature, there are various ways that the DNS can bootstrap access to an independent application-layer protocol better suited to field the queries in question. For example, since NAPTR or URI [URI-RR] Resource Records can contain URIs, those URIs can in turn point to an external query-response service such as an HTTP service where more syntactically and semantically rich queries and answers might be exchanged. Any protocol designer considering where to implement features must perform their own gap analysis and determine whether or not implementing some features is worth the potential cost in increased network state, latency, and so on, but implementing some features simply requires heavier structures than others.
当DNS的管理授权在应用程序功能的实例化中形成必要的组件时，有多种方式DNS可以引导对更适合于所讨论的字段查询的独立应用层协议的访问。例如，由于NAPTR或URI[URI-RR]资源记录可以包含URI，因此这些URI可以依次指向外部查询响应服务，例如HTTP服务，在该服务中可以交换语法和语义更丰富的查询和答案。任何考虑在何处实现功能的协议设计者都必须执行他们自己的差距分析，并确定在网络状态、延迟等增加的情况下，实现某些功能是否值得付出潜在成本，但实现某些功能只需要比其他功能更重的结构。
Many of the concerns about how applications use the DNS discussed in this document involve security. The perceived need to authenticate the source of DNS queries (see Section 3.1.1) and authorize access to particular resource records also illustrates the fundamental security principles that arise from offloading certain application features to the DNS. As Section 3.2.1 observes, large data in the DNS can provide a means of generating reflection attacks, and without the remedies discussed in that section (regarding the use of EDNS(0) and TCP) the presence of large sets of records (e.g., ANY queries) is not recommended. Section 3.4 discusses a security problem concerning redirection that has surfaced in a number of protocols (see [HARD-PROBLEM]).
本文档中讨论的有关应用程序如何使用DNS的许多问题涉及安全性。对DNS查询源进行身份验证（见第3.1.1节）和授权访问特定资源记录的感知需求也说明了将某些应用程序功能卸载到DNS所产生的基本安全原则。如第3.2.1节所述，DNS中的大数据可以提供一种生成反射攻击的方法，如果没有该节中讨论的补救措施（关于EDN（0）和TCP的使用），则不建议存在大记录集（例如，任何查询）。第3.4节讨论了在许多协议中出现的与重定向有关的安全问题（参见[硬问题]）。
While DNSSEC, were it deployed universally, can play an important part in securing application redirection in the DNS, DNSSEC does not provide a means for a resolver to authenticate itself to a server, nor a framework for servers to return selective answers based on the authenticated identity of resolvers, nor a confidential mechanism. Some implementations may support authenticating users through TSIG, provided that the security association with a compliant server has been pre-established, though authentication is typically not needed
尽管普遍部署的DNSSEC可以在DNS中保护应用程序重定向方面发挥重要作用，但DNSSEC既不提供解析程序向服务器进行身份验证的方法，也不提供服务器根据解析程序的身份验证返回选择性答案的框架，也不提供保密机制。一些实现可能支持通过TSIG对用户进行身份验证，前提是预先建立了与兼容服务器的安全关联，但通常不需要身份验证
for queries in the global public DNS. The existing feature set of DNSSEC is, however, sufficient for providing security for most of the ways that applications traditionally have used the DNS. The deployment of DNSSEC ([RFC4033] and related specifications) is heartily encouraged. Nothing in this document is intended to discourage the implementation, deployment, or use of Secure DNS Dynamic Updates [RFC3007], though this document does recommend that large data in the DNS be treated in accordance with the guidance in Section 3.2.1.
用于全局公共DNS中的查询。然而，DNSSEC的现有功能集足以为应用程序传统上使用DNS的大多数方式提供安全性。我们衷心鼓励部署DNSSEC（[RFC4033]和相关规范）。本文件中的任何内容均无意阻止安全DNS动态更新[RFC3007]的实施、部署或使用，尽管本文件确实建议按照第3.2.1节中的指南处理DNS中的大数据。
Internet Architecture Board Members at the time this document was approved were:
本文件批准时，互联网体系结构委员会成员为：
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig
伯纳德·阿博巴·贾里·阿尔科·马克·布兰切特·罗斯·卡隆·艾莉莎·库珀·斯宾塞·道金斯·乔尔·哈尔本·罗斯·霍斯利·大卫·凯森斯·丹尼·麦克弗森·乔恩·彼得森·戴夫·泰勒·汉内斯·茨霍芬尼
The IAB appreciates the comments and often spirited disagreements of Eric Osterweil, John Levine, Stephane Bortzmeyer, Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson, Patrik Faltstrom, and Eliot Lear.
IAB赞赏Eric Osterweil、John Levine、Stephane Bortzmeyer、Ed Lewis、Dave Crocker、Ray Bellis、Lawrence Conroy、Ran Atkinson、Patrik Faltstrom和Eliot Lear的评论和经常激烈的分歧。
[DNS-REDIRECT] Creighton, T., Griffiths, C., Livingood, J., and R. Weber, "DNS Redirect Use by Service Providers", Work in Progress, October 2010.
[DNS-REDIRECT]Creighton，T.，Griffiths，C.，Livingood，J.，和R.Weber，“服务提供商使用DNS重定向”，正在进行的工作，2010年10月。
[EDNS-CLIENT-IP] Contavalli, C., van der Gaast, W., Leach, S., and D. Rodden, "Client IP information in DNS requests", Work in Progress, May 2010.
[EDNS-CLIENT-IP]Contavalli，C.，van der Gaast，W.，Leach，S.，和D.Rodden，“DNS请求中的客户端IP信息”，正在进行的工作，2010年5月。
[EDNS-OPT-CODE] Kaplan, H., Walter, R., Gorman, P., and M. Maharishi, "EDNS Option Code for SIP and PSTN Source Reference Info", Work in Progress, October 2011.
[EDNS-OPT-CODE]Kaplan，H.，Walter，R.，Gorman，P.，和M.Maharishi，“SIP和PSTN源参考信息的EDNS选项代码”，正在进行的工作，2011年10月。
[ENUM-Send-N] Bellis, R., "IANA Registrations for the 'Send-N' Enumservice", Work in Progress, June 2008.
[ENUM-Send-N]Bellis，R.，“发送-N”ENUM服务的IANA注册”，正在进行的工作，2008年6月。
[ENUM-UNUSED] Stastny, R., Conroy, L., and J. Reid, "IANA Registration for Enumservice UNUSED", Work in Progress, March 2008.
[ENUM-UNUSED]R.斯塔斯尼、L.康罗伊和J.里德，“ENUM服务未使用的IANA注册”，正在进行的工作，2008年3月。
[HARD-PROBLEM] Barnes, R. and P. Saint-Andre, "High Assurance Re-Direction (HARD) Problem Statement", Work in Progress, July 2010.
[难题]Barnes，R.和P.Saint Andre，“高保证再指导（难题）问题陈述”，进展中的工作，2010年7月。
[Lindsay] Lindsay, G., "DNSSEC and DNS Amplification Attacks", April 2012.
[Lindsay]Lindsay，G.，“DNSSEC和DNS放大攻击”，2012年4月。
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, November 1983.
[RFC0882]Mockapetris，P.，“域名：概念和设施”，RFC 882，1983年11月。
[RFC0883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, November 1983.
[RFC0883]Mockapetris，P.，“域名：实现规范”，RFC 883，1983年11月。
[RFC0974] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986.
[RFC0974]帕特里奇，C.，“邮件路由和域系统”，STD 10，RFC 974，1986年1月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1464]Rosenbaum，R.，“使用域名系统存储任意字符串属性”，RFC 1464，1993年5月。
[RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", RFC 1530, October 1993.
[RFC1530]Malamud，C.和M.Rose，“TPC.INT子域的操作原则：一般原则和政策”，RFC 1530，1993年10月。
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[RFC1794]Brisco，T.，“DNS对负载平衡的支持”，RFC17941995年4月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]Ohta，M.，“DNS中的增量区域转移”，RFC 1995，1996年8月。
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2052]Gulbrandsen，A.和P.Vixie，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2052，1996年10月。
[RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[RFC2168]Daniel，R.和M.Mealling，“使用域名系统解析统一资源标识符”，RFC 2168，1997年6月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2397]Masinter，L.“数据”URL方案”，RFC 2397，1998年8月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]互联网体系结构委员会，“IAB关于唯一DNS根的技术评论”，RFC 2826，2000年5月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2915]Mealling，M.和R.Daniel，“命名机构指针（NAPTR）DNS资源记录”，RFC 2915，2000年9月。
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[RFC2916]Faltstrom，P.，“E.164编号和DNS”，RFC 29162000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401]Mealling，M.“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3402]Mealling，M.“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，2002年10月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403]Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC34032002年10月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4367] Rosenberg, J., Ed., and IAB, "What's in a Name: False Assumptions about DNS Names", RFC 4367, February 2006.
[RFC4367]Rosenberg，J.，Ed.，和IAB，“名称中的内容：关于DNS名称的错误假设”，RFC 4367，2006年2月。
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, March 2006.
[RFC4398]Josefsson，S.，“在域名系统（DNS）中存储证书”，RFC 4398，2006年3月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月。
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[RFC4985]Santesson，S.，“互联网X.509公钥基础设施主体服务名称表达的备选名称”，RFC 4985，2007年8月。
[RFC5486] Malas, D., Ed., and D. Meyer, Ed., "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]Malas，D.，Ed.，和D.Meyer，Ed.，“多媒体互连的会话对等（SPEERMINT）术语”，RFC 54862009年3月。
[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC5507]IAB，Faltstrom，P.，Ed.，Austein，R.，Ed.，和P.Koch，Ed.，“扩展DNS时的设计选择”，RFC 5507，2009年4月。
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922]Gurbani，V.，Lawrence，S.，和A.Jeffrey，“会话启动协议（SIP）中的域证书”，RFC 59222010年6月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 60552011年2月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)", RFC 6394, October 2011.
[RFC6394]巴恩斯，R.“基于DNS的命名实体身份验证（DANE）的用例和要求”，RFC 63942011年10月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS（EDNS（0））的扩展机制”，STD 75，RFC 6891，2013年4月。
[URI-RR] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", Work in Progress, July 2013.
[URI-RR]Faltstrom，P.和O.Kolkman，“统一资源标识符（URI）DNS资源记录”，正在进行的工作，2013年7月。
Authors' Addresses
作者地址
Jon Peterson NeuStar, Inc.
乔恩·彼得森纽斯达公司。
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz
Olaf Kolkman NLnet Labs
Olaf Kolkman NLnet实验室
EMail: olaf@nlnetlabs.nl
EMail: olaf@nlnetlabs.nl
Hannes Tschofenig Nokia Siemens Networks
Hannes Tschofenig诺基亚西门子网络公司
EMail: Hannes.Tschofenig@gmx.net
EMail: Hannes.Tschofenig@gmx.net
Bernard Aboba Skype
伯纳德·阿博巴Skype
EMail: Bernard_aboba@hotmail.com
EMail: Bernard_aboba@hotmail.com