Network Working Group IAB
Request for Comments: 5507 P. Faltstrom, Ed.
Category: Informational R. Austein, Ed.
P. Koch, Ed.
April 2009
Network Working Group IAB
Request for Comments: 5507 P. Faltstrom, Ed.
Category: Informational R. Austein, Ed.
P. Koch, Ed.
April 2009
Design Choices When Expanding the DNS
扩展DNS时的设计选择
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution.
本说明讨论了如何使用新应用程序的新数据扩展DNS。DNS扩展讨论经常集中在TXT资源记录类型的重用上。本文档列出了扩展DNS的不同机制，并得出结论，使用新的DNS资源记录类型是最佳解决方案。
Table of Contents
目录
1. Introduction ....................................................3
2. Background ......................................................4
3. Extension Mechanisms ............................................5
3.1. Place Selectors inside the RDATA of Existing
Resource Record Types ......................................5
3.2. Add a Prefix to the Owner Name .............................6
3.3. Add a Suffix to the Owner Name .............................7
3.4. Add a New Class ............................................8
3.5. Add a New Resource Record Type .............................8
4. Zone Boundaries are Invisible to Applications ...................9
5. Why Adding a New Resource Record Type Is the Preferred
Solution .......................................................10
6. Conclusion and Recommendation ..................................14
7. Creating a New Resource Record Type ............................14
8. Security Considerations ........................................15
9. Acknowledgements ...............................................15
10. IAB Members at the Time of This Writing .......................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
1. Introduction ....................................................3
2. Background ......................................................4
3. Extension Mechanisms ............................................5
3.1. Place Selectors inside the RDATA of Existing
Resource Record Types ......................................5
3.2. Add a Prefix to the Owner Name .............................6
3.3. Add a Suffix to the Owner Name .............................7
3.4. Add a New Class ............................................8
3.5. Add a New Resource Record Type .............................8
4. Zone Boundaries are Invisible to Applications ...................9
5. Why Adding a New Resource Record Type Is the Preferred
Solution .......................................................10
6. Conclusion and Recommendation ..................................14
7. Creating a New Resource Record Type ............................14
8. Security Considerations ........................................15
9. Acknowledgements ...............................................15
10. IAB Members at the Time of This Writing .......................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
The DNS stores multiple categories of data. The two most commonly used categories are infrastructure data for the DNS system itself (NS and SOA Resource Records) and data that have to do with mappings between domain names and IP addresses (A, AAAA, and PTR Resource Records). There are other categories as well, some of which are tied to specific applications like email (MX Resource Records), while others are generic Resource Record Types used to convey information for multiple protocols (SRV and NAPTR Resource Records).
DNS存储多个类别的数据。两个最常用的类别是DNS系统本身的基础设施数据（NS和SOA资源记录）和与域名和IP地址之间的映射有关的数据（A、AAAA和PTR资源记录）。还有其他类别，其中一些与电子邮件（MX资源记录）等特定应用程序相关，而另一些是用于传递多协议信息的通用资源记录类型（SRV和NAPTR资源记录）。
When storing data in the DNS for a new application, the goal must be to store data in such a way that the application can query for the data it wants, while minimizing both the impact on existing applications and the amount of extra data transferred to the client. This implies that a number of design choices have to be made, where the most important is to ensure that a precise selection of what data to return must be made already in the query. A query consists of a triple: {Owner (or name), Resource Record Class, Resource Record Type}.
在为新应用程序在DNS中存储数据时，目标必须是以这样的方式存储数据，即应用程序可以查询所需的数据，同时最小化对现有应用程序的影响和传输到客户端的额外数据量。这意味着必须做出许多设计选择，其中最重要的是确保必须在查询中已经精确选择要返回的数据。查询由三元组组成：{所有者（或名称）、资源记录类、资源记录类型}。
Historically, extending the DNS to store application data tied to a domain name has been done in different ways at different times. MX Resource Records were created as a new Resource Record Type specifically designed to support electronic mail. SRV records are a generic type that use a prefixing scheme in combination with a base domain name. NAPTR records add selection data inside the RDATA. It is clear that the methods used to add new data types to the DNS have been inconsistent, and the purpose of this document is to attempt to clarify the implications of each of these methods, both for the applications that use them and for the rest of the DNS.
从历史上看，在不同的时间以不同的方式扩展DNS以存储与域名相关的应用程序数据。MX资源记录是作为一种新的资源记录类型创建的，专门用于支持电子邮件。SRV记录是一种通用类型，将前缀方案与基本域名结合使用。NAPTR记录在RDATA中添加选择数据。很明显，用于向DNS添加新数据类型的方法不一致，本文档的目的是试图澄清每种方法对使用它们的应用程序和DNS其余部分的影响。
This document talks extensively about use of DNS wildcards. Many people might think use of wildcards is not something that happens today. In reality though, wildcards are in use, especially for certain application-specific data such as MX Resource Records. Because of this, the choice has to be made with the existence of wildcards in mind.
本文档广泛讨论DNS通配符的使用。许多人可能认为使用通配符不是今天发生的事情。但实际上，通配符正在使用，特别是对于某些特定于应用程序的数据，如MX资源记录。因此，必须在考虑通配符存在的情况下做出选择。
Another overall issue that must be taken into account is what the new data in the DNS are to describe. In some cases, they might be completely new data. In other cases, they might be metadata tied to data that already exist in the DNS. Examples of new data are key information for the Secure SHell (SSH) Protocol and data used for authenticating the sender of email messages (metadata tied to MX Resource Records). If the new data are tied to data that already exist in the DNS, an analysis should be made as to whether having (for example) address records and SSH key information in different
必须考虑的另一个总体问题是DNS中的新数据将描述什么。在某些情况下，它们可能是全新的数据。在其他情况下，它们可能是绑定到DNS中已有数据的元数据。新数据的示例包括Secure SHell（SSH）协议的关键信息和用于验证电子邮件发件人的数据（绑定到MX资源记录的元数据）。如果新数据与DNS中已经存在的数据相关联，则应进行分析，以确定（例如）是否具有不同格式的地址记录和SSH密钥信息
DNS zones is a problem or if it is a bonus, and if it is a problem, whether the specification must require all of the related data to be in the same zone. One specific difference between having the records in the same zone or not has to do with maintenance of the records. If they are in the same zone, the same maintainer (from a DNS perspective) manages the two records. Specifically, they must be signed with the same DNSSEC keys if DNSSEC is in use.
DNS区域是一个问题，或者如果它是一个奖励，如果它是一个问题，那么规范是否必须要求所有相关数据都在同一个区域中。记录在同一区域与否的一个具体区别与记录的维护有关。如果它们位于同一区域，则由同一维护者（从DNS的角度）管理这两条记录。特别是，如果使用DNSSEC，则必须使用相同的DNSSEC密钥对其进行签名。
This document does not talk about what one should store in the DNS. It also doesn't discuss whether the DNS should be used for service discovery, or whether the DNS should be used for storage of data specific to the service. In general, the DNS is a protocol that, apart from holding metadata that makes the DNS itself function (NS, SOA, DNSSEC Resource Record Types, etc.), only holds references to service locations (SRV, NAPTR, A, AAAA Resource Record Types) -- though there are exceptions, such as MX Resource Records.
本文档没有讨论应该在DNS中存储什么。它也没有讨论DNS是否应该用于服务发现，或者DNS是否应该用于存储特定于服务的数据。一般来说，DNS是一种协议，除了保存使DNS本身起作用的元数据（NS、SOA、DNSSEC资源记录类型等）外，它只保存对服务位置的引用（SRV、NAPTR、a、AAAA资源记录类型）——尽管存在例外情况，如MX资源记录。
See RFC 5395 [RFC5395] for a brief summary of the DNS query structure. Readers interested in the full story should start with the base DNS specification in RFC 1035 [RFC1035] and continue with the various documents that update, clarify, and extend the base specification.
有关DNS查询结构的简要摘要，请参阅RFC 5395[RFC5395]。对全文感兴趣的读者应该从RFC1035[RFC1035]中的基本DNS规范开始，并继续阅读更新、澄清和扩展基本规范的各种文档。
When composing a DNS query, the parameters used by the protocol are a {owner, class, type} triple. Every Resource Record matching such a triple is said to belong to the same Resource Record Set (RRSet), and the whole RRSet is always returned to the client that queries for it. Splitting an RRSet is a protocol violation (sending a partial RRSet, not truncating the DNS response), because it can result in coherency problems with the DNS caching mechanism. See Section 5 of [RFC2181] for more information.
在编写DNS查询时，协议使用的参数是{owner，class，type}三元组。与这样一个三元组匹配的每个资源记录都被称为属于同一个资源记录集（RRSet），并且整个RRSet总是返回给查询它的客户机。拆分RRSet是一种违反协议的行为（发送部分RRSet，而不是截断DNS响应），因为这会导致DNS缓存机制的一致性问题。详见[RFC2181]第5节。
Some discussions around extensions to the DNS include arguments around MTU size. Note that most discussions about DNS and MTU size are about the size of the whole DNS packet, not about the size of a single RRSet.
关于DNS扩展的一些讨论包括关于MTU大小的参数。请注意，关于DNS和MTU大小的大多数讨论都是关于整个DNS数据包的大小，而不是单个RRSet的大小。
Almost all DNS query traffic is carried over UDP, where a DNS message must fit within a single UDP packet. DNS response messages are almost always larger than DNS query messages, so message size issues are almost always about responses, not queries. The base DNS specification limits DNS messages over UDP to 512 octets; EDNS0 [RFC2671] specifies a mechanism by which a client can signal its willingness to receive larger responses, but deployment of EDNS0 is not universal, in part because of firewalls that block fragmented UDP packets or EDNS0. If a response message won't fit in a single
几乎所有DNS查询流量都通过UDP传输，其中DNS消息必须包含在单个UDP数据包中。DNS响应消息几乎总是比DNS查询消息大，因此消息大小问题几乎总是关于响应，而不是查询。基本DNS规范将UDP上的DNS消息限制为512个八位字节；EDNS0[RFC2671]指定了一种机制，通过该机制，客户端可以发出信号表示愿意接收更大的响应，但EDNS0的部署并不普遍，部分原因是防火墙阻止了碎片化UDP数据包或EDNS0。如果响应消息不适合单个
packet, the name server returns a truncated response, at which point the client may retry using TCP. DNS queries over TCP are not subject to this length limitation, but TCP imposes significantly higher per-query overhead on name servers than UDP. It is also the case that the policies in deployed firewalls far too often are such that they block DNS over TCP, so using TCP might not in reality be an option. There are also risks (although possibly small) that a change of routing while a TCP flow is open creates problems when the DNS servers are deployed in an anycast environment.
数据包时，名称服务器返回截断的响应，此时客户端可以使用TCP重试。TCP上的DNS查询不受此长度限制，但TCP在名称服务器上的每次查询开销明显高于UDP。同样的情况是，部署的防火墙中的策略常常会通过TCP阻止DNS，因此使用TCP实际上可能不是一种选择。当DNS服务器部署在选播环境中时，TCP流打开时路由的更改也会产生问题，这也有风险（尽管可能很小）。
The DNS protocol is intended to be extensible to support new kinds of data. This section examines the various ways in which this sort of extension can be accomplished.
DNS协议旨在扩展以支持新类型的数据。本节将探讨实现这种扩展的各种方法。
For a given query name, one might choose to have a single RRSet (all Resource Records sharing the same {owner, class, type} triple) shared by multiple applications, and have the different applications use selectors within the Resource Record data (RDATA) to determine which records are intended for which applications. This sort of selector mechanism is usually referred to "subtyping", because it is in effect creating an additional type subsystem within a single DNS Resource Record Type.
对于给定的查询名称，可以选择由多个应用程序共享单个RRSet（共享相同{owner，class，type}triple的所有资源记录），并让不同的应用程序使用资源记录数据（RDATA）中的选择器来确定哪些记录用于哪些应用程序。这种选择器机制通常被称为“子类型”，因为它实际上是在单个DNS资源记录类型中创建一个附加类型子系统。
Examples of subtyping include NAPTR Resource Records [RFC3761] and the original DNSSEC KEY Resource Record Type [RFC2535] (which was later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033 [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]).
子类型化的示例包括NAPTR资源记录[RFC3761]和原始DNSSEC密钥资源记录类型[RFC2535]（随后由RFC 3445[RFC3445]更新，并由RFC 4033[RFC4033]、RFC 4034[RFC4034]和RFC 4035[RFC4035]淘汰）。
All DNS subtyping schemes share a common weakness: with subtyping schemes, it is impossible for a client to query for just the data it wants. Instead, the client must fetch the entire RRSet, then select the Resource Records in which it is interested. Furthermore, since DNSSEC signatures operate on complete RRSets, the entire RRSet must be re-signed if any Resource Record in it changes. As a result, each application that uses a subtyped Resource Record incurs higher overhead than any of the applications would have incurred had they not been using a subtyping scheme. The fact the RRSet is always passed around as an indivisible unit increases the risk the RRSet will not fit in a UDP packet, which in turn increases the risk that the client will have to retry the query with TCP, which substantially increases the load on the name server. More precisely: having one query fail over to TCP is not a big deal, but since the typical ratio
所有DNS子类型方案都有一个共同的弱点：使用子类型方案，客户端不可能只查询它想要的数据。相反，客户端必须获取整个RRSet，然后选择它感兴趣的资源记录。此外，由于DNSSEC签名在完整的RRSet上运行，因此如果其中的任何资源记录发生更改，则必须对整个RRSet重新签名。因此，使用子类型资源记录的每个应用程序所产生的开销都比不使用子类型方案的任何应用程序所产生的开销都要高。RRSet始终作为一个不可分割的单元传递的事实增加了RRSet不适合UDP数据包的风险，这反过来又增加了客户端必须使用TCP重试查询的风险，这大大增加了名称服务器上的负载。更准确地说：将一个查询故障转移到TCP并不是什么大问题，但因为典型的比率
of clients to servers in today's deployed DNS is very high, having a substantial number of DNS messages fail over to TCP may cause the queried name servers to be overloaded by TCP overhead.
在当今部署的DNS中，客户端到服务器的数量非常高，将大量DNS消息故障转移到TCP可能会导致查询的名称服务器因TCP开销而过载。
Because of the size limitations, using a subtyping scheme to list a large number of services for a single domain name risks triggering truncation and fallback to TCP, which may in turn force the zone administrator to announce only a subset of available services.
由于大小限制，使用子类型方案列出单个域名的大量服务可能会触发截断和回退到TCP，这反过来可能会迫使区域管理员仅宣布可用服务的子集。
By adding an application-specific prefix to a domain name, we get a different {owner, class, type} triple, and therefore a different RRSet. One problem with adding prefixes has to do with wildcards, especially if one has records like:
通过向域名添加特定于应用程序的前缀，我们可以得到不同的{owner，class，type}三元组，从而得到不同的RRSet。添加前缀的一个问题与通配符有关，特别是如果有以下记录：
*.example.com. IN MX 1 mail.example.com.
*.example.com。在MX 1 mail.example.com中。
and one wants records tied to those names. Suppose one creates the prefix "_mail". One would then have to say something like:
人们希望记录与这些名字联系在一起。假设有人创建了前缀“\u mail”。然后，人们不得不说：
_mail.*.example.com. IN X-FOO A B C D
_邮件。*.example.com。在X-FOO中A B C D
but DNS wildcards only work with the "*" as the leftmost token in the domain name (see also RFC 4592 [RFC4592]).
但是DNS通配符只使用“*”作为域名中最左边的标记（另请参见RFC 4592[RFC4592]）。
There have been proposals to deal with the problem that DNS wildcards are always terminal records. These proposals introduce an additional set of trade-offs that would need to be taken into account when assessing which extension mechanism to choose. Aspects of extra response time needed to perform the extra queries, costs of pre-calculation of possible answers, or the costs induced to the system as a whole come to mind. At the time of writing, none of these proposals has been published as Standards Track RFCs.
有人建议解决DNS通配符始终是终端记录的问题。这些建议引入了一系列额外的权衡，在评估选择哪种扩展机制时需要考虑这些权衡。执行额外查询所需的额外响应时间、预先计算可能答案的成本，或整个系统的成本。在撰写本文时，这些提案均未作为标准跟踪RFC发布。
Even when a specific prefix is chosen, the data will still have to be stored in some Resource Record Type. This Resource Record Type can be either a new Resource Record Type or an existing Resource Record Type that has an appropriate format to store the data. One also might need some other selection mechanism, such as the ability to distinguish between the records in an RRSet, given they have the same Resource Record Type. Because of this, one needs to both register a unique prefix and define what Resource Record Type is to be used for this specific service.
即使选择了特定的前缀，数据仍必须存储在某些资源记录类型中。此资源记录类型可以是新的资源记录类型，也可以是具有适当格式来存储数据的现有资源记录类型。人们还可能需要一些其他的选择机制，例如，如果RRSet中的记录具有相同的资源记录类型，则能够区分它们。因此，需要注册一个唯一的前缀，并定义此特定服务要使用的资源记录类型。
If the record has some relationship with another record in the zone, the fact that the two records can be in different zones might have implications on the trust the application has in the records. For example:
如果该记录与区域中的另一条记录存在某种关系，那么这两条记录可能位于不同的区域这一事实可能会影响应用程序对这些记录的信任。例如：
example.com. IN MX 10 mail.example.com. _foo.example.com. IN X-BAR "metadata for the mail service"
example.com。在MX 10 mail.example.com中_foo.example.com。在X-BAR“邮件服务元数据”中
In this example, the two records might be in two different zones, and as a result might be administered by two different organizations, and signed by two different entities when using DNSSEC. For these two reasons, using a prefix has recently become a very interesting solution for many protocol designers. In some cases, e.g., DomainKeys Identified Mail Signatures [RFC4871], TXT records have been used. In others, such as SRV, entirely new Resource Record Types have been added.
在本例中，这两个记录可能位于两个不同的区域，因此可能由两个不同的组织管理，并在使用DNSSEC时由两个不同的实体签名。出于这两个原因，使用前缀最近已成为许多协议设计者非常感兴趣的解决方案。在某些情况下，例如，已使用域密钥标识的邮件签名[RFC4871]，TXT记录。在其他情况下，如SRV，添加了全新的资源记录类型。
Adding a suffix to a domain name changes the {owner, class, type} triple, and therefore the RRSet. In this case, since the query name can be set to exactly the data one wants, the size of the RRSet is minimized. The problem with adding a suffix is that it creates a parallel tree within the IN class. Further, there is no technical mechanism to ensure that the delegation for "example.com" and "example.com._bar" are made to the same organization. Furthermore, data associated with a single entity will now be stored in two different zones, such as "example.com" and "example.com._bar", which, depending on who controls "_bar", can create new synchronization and update authorization issues.
向域名添加后缀会更改{owner，class，type}三元组，从而更改RRSet。在这种情况下，由于可以将查询名称完全设置为所需的数据，因此RRSet的大小被最小化。添加后缀的问题在于，它会在类内创建一个并行树。此外，没有技术机制来确保“example.com”和“example.com.\u bar”的委托是向同一组织进行的。此外，与单个实体相关联的数据现在将存储在两个不同的区域中，例如“example.com”和“example.com.\u-bar”，这取决于谁控制了“\u-bar”，可以创建新的同步和更新授权问题。
One way of solving the administrative issues is by using the DNAME Resource Record Type specified in RFC 2672 [RFC2672].
解决管理问题的一种方法是使用RFC 2672[RFC2672]中指定的DNAME资源记录类型。
Even when using a different name, the data will still have to be stored in some Resource Record Type that has an appropriate format to store the data. This implies that one might have to mix the prefix based selection mechanism with some other mechanism so that the right Resource Record can be found out of many in a potential larger RRSet.
即使使用不同的名称，数据仍必须存储在某种资源记录类型中，该类型具有适当的格式来存储数据。这意味着可能必须将基于前缀的选择机制与其他机制混合使用，以便在潜在的更大的资源集中的许多资源记录中找到正确的资源记录。
In RFC 2163 [RFC2163] an infix token is inserted directly below the Top-Level Domain (TLD), but the result is equivalent to adding a suffix to the owner name (instead of creating a TLD, one is creating a second level domain).
在RFC 2163[RFC2163]中，中缀令牌直接插入顶级域（TLD）下方，但其结果相当于在所有者名称中添加后缀（不是创建TLD，而是创建第二级域）。
DNS zones are class-specific in the sense that all the records in that zone share the same class as the zone's SOA record and the existence of a zone in one class does not guarantee the existence of the zone in any other class. In practice, only the IN class has ever seen widespread deployment, and the administrative overhead of deploying an additional class would almost certainly be prohibitive.
DNS区域是特定于类的，因为该区域中的所有记录与区域的SOA记录共享同一类，并且一个类中存在区域并不保证该区域在任何其他类中存在。在实践中，只有类内的类被广泛部署，并且部署额外类的管理开销几乎肯定是禁止的。
Nevertheless, one could, in theory, use the DNS class mechanism to distinguish between different kinds of data. However, since the DNS delegation tree (represented by NS Resource Records) is itself tied to a specific class, attempting to resolve a query by crossing a class boundary may produce unexpected results because there is no guarantee that the name servers for the zone in the new class will be the same as the name servers in the IN class. The MIT Hesiod system [Dyer87] used a scheme like this for storing data in the HS class, but only on a very small scale (within a single institution), and with an administrative fiat requiring that the delegation trees for the IN and HS trees be identical. The use of the HS class for such storage of non-sensitive data was, over time, replaced by use of the Lightweight Directory Access Protocol (LDAP) [RFC4511].
然而，理论上可以使用DNS类机制来区分不同类型的数据。但是，由于DNS委派树（由NS资源记录表示）本身绑定到特定类，因此尝试通过跨越类边界来解析查询可能会产生意外结果，因为无法保证新类中区域的名称服务器与类中的名称服务器相同。麻省理工学院Hesiod系统[Dyer87]使用类似的方案在HS类中存储数据，但仅在非常小的范围内（在单个机构内），并且管理法规要求in和HS树的委托树是相同的。随着时间的推移，将HS类用于此类非敏感数据的存储被轻量级目录访问协议（LDAP）[RFC4511]的使用所取代。
Even when using a different class, the data will still have to be stored in some Resource Record Type that has an appropriate format.
即使在使用不同的类时，数据仍必须存储在某种具有适当格式的资源记录类型中。
When adding a new Resource Record Type to the system, entities in four different roles have to be able to handle the new Type:
向系统添加新的资源记录类型时，具有四种不同角色的实体必须能够处理新类型：
1. There must be a way to insert the new Resource Records into the zone at the Primary Master name server. For some server implementations, the user interface only accepts Resource Record Types that it understands (perhaps so that the implementation can attempt to validate the data). Other implementations allow the zone administrator to enter an integer for the Resource Record Type code and the RDATA in Base64 or hexadecimal encoding (or even as raw data). RFC 3597 [RFC3597] specifies a standard generic encoding for this purpose.
1. 必须有办法将新资源记录插入主主机名服务器的区域。对于某些服务器实现，用户界面只接受它理解的资源记录类型（也许这样实现就可以尝试验证数据）。其他实现允许区域管理员以Base64或十六进制编码（甚至作为原始数据）为资源记录类型代码和RDATA输入整数。RFC 3597[RFC3597]为此目的指定了标准通用编码。
2. A slave authoritative name server must be able to do a zone transfer, receive the data from some other authoritative name server, and serve data from the zone even though the zone includes records of unknown Resource Record Types. Historically, some implementations have had problems parsing stored copies of the zone file after restarting, but those problems have not been seen for a few years. Some implementations use an alternate
2. 从属权威名称服务器必须能够执行区域传输，从其他权威名称服务器接收数据，并提供来自区域的数据，即使该区域包含未知资源记录类型的记录。历史上，一些实现在重新启动后解析区域文件的存储副本时遇到问题，但这些问题已经好几年没有出现了。一些实现使用了一种替代方法
mechanism (e.g., LDAP) to transfer Resource Records in a zone, and are primarily used within corporate environments; in this case, name servers must be able to transfer new Resource Record Types using whatever mechanism is used. However, today this alternative mechanism may not support unknown Resource Record Types. Hence, in Internet environments, unknown Resource Record Types are supported, but in corporate environments they are problematic.
在区域中传输资源记录的机制（如LDAP），主要用于公司环境；在这种情况下，名称服务器必须能够使用所使用的任何机制传输新的资源记录类型。但是，今天这种替代机制可能不支持未知的资源记录类型。因此，在Internet环境中，支持未知的资源记录类型，但在公司环境中，它们是有问题的。
3. A caching resolver (most commonly a recursive name server) will cache the records that are responses to queries. As mentioned in RFC 3597 [RFC3597], there are various pitfalls where a recursive name server might end up having problems.
3. 缓存解析器（通常是递归名称服务器）将缓存作为查询响应的记录。如RFC33597[RFC3597]中所述，递归名称服务器可能会出现各种问题。
4. The application must be able to get the RRSet with a new Resource Record Type. The application itself may understand the RDATA, but the resolver library might not. Support for a generic interface for retrieving arbitrary DNS Resource Record Types has been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]). Some stub resolver library implementations neglect to provide this functionality and cannot handle unknown Resource Record Types, but implementation of a new stub resolver library is not particularly difficult, and open source libraries that already provide this functionality are available.
4. 应用程序必须能够获取具有新资源记录类型的RRSet。应用程序本身可能理解RDATA，但解析器库可能不理解。自1989年以来，一直要求支持检索任意DNS资源记录类型的通用接口（见[RFC1123]第6.1.4.2节）。一些存根解析器库实现忽略了提供此功能，无法处理未知的资源记录类型，但实现新的存根解析器库并不特别困难，已经提供此功能的开源库也可用。
Historically, adding a new Resource Record Type has been very problematic. The review process has been cumbersome, DNS servers have not been able to handle new Resource Record Types, and firewalls have dropped queries or responses with Resource Record Types that are unknown to the firewall. This is, for example, one of the reasons the ENUM standard reuses the NAPTR Resource Record, a decision that today might have gone to creating a new Resource Record Type instead.
从历史上看，添加新的资源记录类型一直是一个非常棘手的问题。审查过程非常繁琐，DNS服务器无法处理新的资源记录类型，防火墙丢弃了具有防火墙未知的资源记录类型的查询或响应。例如，这就是ENUM标准重用NAPTR资源记录的原因之一，今天的决策可能是创建新的资源记录类型。
Today, there is a requirement that DNS software handle unknown Resource Record Types, and investigations have shown that software that is deployed, in general, does support it, except in some alternate mechanisms for transferring Resource Records such as LDAP, as noted above. Also, the approval process for new Resource Record Types has been updated [RFC5395] so the effort that is needed for various Resource Record Types is more predictable.
今天，DNS软件需要处理未知的资源记录类型，调查表明，部署的软件通常都支持它，但上面提到的用于传输资源记录的一些替代机制（如LDAP）除外。此外，新资源记录类型的审批流程已更新[RFC5395]，因此各种资源记录类型所需的工作更具可预测性。
Regardless of the possible choices above, we have seen a number of cases where the application made assumptions about the structure of the namespace and the location where specific information resides. We take a small sidestep to argue against such approaches.
不管上面有哪些可能的选择，我们已经看到了许多应用程序对名称空间的结构和特定信息所在的位置进行假设的情况。我们采取了一小步来反对这种做法。
The DNS namespace is a hierarchy, technically speaking. However, this only refers to the way names are built from multiple labels. DNS hierarchy neither follows nor implies administrative hierarchy. Because of that, it cannot be assumed that data attached to a node in the DNS tree is valid for the whole subtree. Technically, there are zone boundaries partitioning the namespace, and administrative boundaries (or policy boundaries) may even exist elsewhere.
从技术上讲，DNS名称空间是一个层次结构。但是，这仅指从多个标签生成名称的方式。DNS层次结构既不遵循也不暗示管理层次结构。因此，不能假设附加到DNS树中节点的数据对整个子树有效。从技术上讲，存在分区命名空间的区域边界，管理边界（或策略边界）甚至可能存在于其他地方。
The false assumption has lead to an approach called "tree climbing", where a query that does not receive a positive response (either the requested RRSet was missing or the name did not exist) is retried by repeatedly stripping off the leftmost label (climbing towards the root) until the root domain is reached. Sometimes these proposals try to avoid the query for the root or the TLD level, but still this approach has severe drawbacks:
错误的假设导致了一种称为“爬树”的方法，在这种方法中，通过反复剥离最左边的标签（向根爬升），直到到达根域，从而重试未收到肯定响应（请求的RRSet丢失或名称不存在）的查询。有时，这些建议试图避免查询根或TLD级别，但这种方法仍有严重的缺点：
o Technically, the DNS was built as a query-response tool without any search capability [RFC3467]. Adding the search mechanism imposes additional burden on the technical infrastructure, in the worst case on TLD and root name servers.
o 从技术上讲，DNS是作为查询响应工具构建的，没有任何搜索功能[RFC3467]。添加搜索机制会给技术基础架构带来额外负担，最坏的情况是TLD和根名称服务器。
o For reasons similar to those outlined in RFC 1535 [RFC1535], querying for information in a domain outside the control of the intended entity may lead to incorrect results and may also put security at risk. Finding the exact policy boundary is impossible without an explicit marker, which does not exist at present. At best, software can detect zone boundaries (e.g., by looking for SOA Resource Records), but some TLD registries register names starting at the second level (e.g., CO.UK), and there are various other "registry" types at second, third, or other level domains that cannot be identified as such without policy knowledge external to the DNS.
o 出于与RFC 1535[RFC1535]中概述的原因类似的原因，查询目标实体无法控制的域中的信息可能会导致错误的结果，也可能会使安全面临风险。如果没有一个明确的标记（目前还不存在），就不可能找到确切的政策边界。充其量，软件可以检测区域边界（例如，通过查找SOA资源记录），但一些TLD注册中心从第二级开始注册名称（例如，CO.UK），并且在第二级、第三级或其他级别的域中存在各种其他“注册中心”类型，如果没有DNS外部的策略知识，这些类型无法识别。
To restate, the zone boundary is purely a boundary that exists in the DNS for administrative purposes, and applications should be careful not to draw unwarranted conclusions from zone boundaries. A different way of stating this is that the DNS does not support inheritance, e.g., an MX RRSet for a TLD will not be valid for any subdomain of that particular TLD.
重申一下，区域边界纯粹是出于管理目的而存在于DNS中的边界，应用程序应小心不要从区域边界得出不必要的结论。另一种说法是DNS不支持继承，例如，TLD的MX RRSet对于该特定TLD的任何子域都无效。
By now, the astute reader might be wondering what conclusions to draw from the issues presented so far. We will now attempt to clear up the reader's confusion by following the thought processes of a typical application designer who wishes to store data in the DNS. We'll show how such a designer almost inevitably hits upon the idea of just using a TXT Resource Record, why this is a bad thing, and why
到目前为止，精明的读者可能想知道从目前提出的问题中得出什么结论。现在，我们将尝试通过遵循希望在DNS中存储数据的典型应用程序设计师的思维过程来澄清读者的困惑。我们将展示这样一个设计师是如何几乎不可避免地想到只使用TXT资源记录的，为什么这是一件坏事，为什么
a new Resource Record Type should be allocated instead. We'll also explain how the reuse of an existing Resource Record, including TXT, can be made less harmful.
应改为分配新的资源记录类型。我们还将解释如何使现有资源记录（包括TXT）的重用危害更小。
The overall problem with most solutions has to do with two main issues:
大多数解决方案的总体问题与两个主要问题有关：
o No semantics to prevent collision with other use
o 没有防止与其他用途冲突的语义
o Space considerations in the DNS message
o DNS消息中的空间注意事项
A typical application designer is not interested in the DNS for its own sake, but rather regards it as a distributed database in which application data can be stored. As a result, the designer of a new application is usually looking for the easiest way to add whatever new data the application needs to the DNS in a way that naturally associates the data with a DNS name and does not require major changes to DNS servers.
典型的应用程序设计人员对DNS本身不感兴趣，而是将其视为可以存储应用程序数据的分布式数据库。因此，新应用程序的设计者通常会寻找最简单的方法将应用程序需要的任何新数据添加到DNS中，这种方法自然会将数据与DNS名称关联起来，并且不需要对DNS服务器进行重大更改。
As explained in Section 3.4, using the DNS class system as an extension mechanism is not really an option, and in fact, most users of the system don't even realize that the mechanism exists. As a practical matter, therefore any extension is likely to be within the IN class.
如第3.4节所述，使用DNS类系统作为扩展机制实际上不是一种选择，事实上，系统的大多数用户甚至没有意识到该机制的存在。因此，作为一个实际问题，任何扩展都可能在类内。
Adding a new Resource Record Type is the technically correct answer from the DNS protocol standpoint (more on this below), but doing so requires some DNS expertise, due to the issues listed in Section 3.5. Consequently, this option is often rejected. Note that according to RFC 5395 [RFC5395], some Types require IETF Consensus, while others only require a specification.
从DNS协议的角度来看，添加一个新的资源记录类型在技术上是正确的答案（下文将对此进行详细介绍），但由于第3.5节列出的问题，这样做需要一些DNS专业知识。因此，这一选择常常被拒绝。注意，根据RFC 5395[RFC5395]，某些类型需要IETF共识，而其他类型只需要规范。
There is a drawback to defining new RR types that is worth mentioning. The Resource Record Type (RRTYPE) is a 16-bit value and hence is a limited resource. In order to prevent hoarding the registry has a review-based allocation policy [RFC5395]; however, this may not be sufficient if extension of the DNS by addition of new RR types takes up significantly and the registry starts nearing completion. In that case, the trade-offs with respect to choosing an extension mechanism may need to change.
定义新的RR类型有一个缺点值得一提。资源记录类型（RRTYPE）是一个16位的值，因此是一个有限的资源。为了防止囤积，注册处有一个基于审查的分配政策[RFC5395]；但是，如果通过添加新的RR类型来扩展DNS占用大量时间，并且注册表开始接近完成，则这可能是不够的。在这种情况下，在选择扩展机制方面的权衡可能需要改变。
The application designer is thus left with the prospect of reusing some existing DNS Types within the IN class, but when the designer looks at the existing Types, almost all of them have well-defined semantics, none of which quite match the needs of the new application. This has not completely prevented proposals from
因此，应用程序设计人员可以重用类内的一些现有DNS类型，但是当设计人员查看现有类型时，几乎所有类型都具有定义良好的语义，其中没有一个完全符合新应用程序的需要。这并没有完全阻止提案的通过
reusing existing Resource Record Types in ways incompatible with their defined semantics, but it does tend to steer application designers away from this approach.
以与其定义的语义不兼容的方式重用现有的资源记录类型，但它确实倾向于引导应用程序设计者远离这种方法。
For example, Resource Record Type 40 was registered for the SINK Resource Record Type. This Resource Record Type was discussed in the DNSIND working group of the IETF, and it was decided at the 46th IETF to not move the I-D forward to become an RFC because of the risk of encouraging application designers to use the SINK Resource Record Type instead of registering a new Resource Record Type, which would result in infeasibly large SINK RRsets.
例如，为接收器资源记录类型注册了资源记录类型40。IETF的DNSIND工作组讨论了该资源记录类型，并在第46届IETF上决定不将I-D向前移动以成为RFC，因为存在鼓励应用程序设计者使用接收器资源记录类型而不是注册新资源记录类型的风险，这将导致不可行的大型水槽RRSET。
Eliminating all of the above leaves the TXT Resource Record Type in the IN class. The TXT RDATA format is free form text, and there are no existing semantics to get in the way. Some attempts have been made, for example, in [DNSEXT-DNS-SD], to specify a structured format for TXT Resource Record Types, but no such attempt has reached RFC status. Furthermore, the TXT Resource Record can obviously just be used as a bucket in which to carry around data to be used by some higher-level parser, perhaps in some human-readable programming or markup language. Thus, for many applications, TXT Resource Records are the "obvious" choice. Unfortunately, this conclusion, while understandable, is also problematic, for several reasons.
删除所有上述内容后，TXT资源记录类型将保留在类中。TXT RDATA格式是自由格式的文本，没有任何现有的语义可以阻挡。例如，已在[DNSEXT-DNS-SD]中尝试为TXT资源记录类型指定结构化格式，但尚未达到RFC状态。此外，TXT资源记录显然可以用作一个存储桶，在其中携带数据供更高级别的解析器使用，可能是在某些人类可读的编程或标记语言中。因此，对于许多应用程序，TXT资源记录是“明显的”选择。不幸的是，这一结论虽然可以理解，但也有问题，原因有几个。
The first reason why TXT Resource Records are not well suited to such use is precisely what makes them so attractive: the lack of pre-defined common syntax or structure. As a result, each application that uses them creates its own syntax/structure, and that makes it difficult to reliably distinguish one application's record from others, and for its parser to avoid problems when it encounters other TXT records.
TXT资源记录不适合这种使用的第一个原因正是它们如此吸引人的原因：缺少预定义的通用语法或结构。因此，使用它们的每个应用程序都会创建自己的语法/结构，这使得很难可靠地将一个应用程序的记录与其他应用程序的记录区分开来，并且使其解析器在遇到其他TXT记录时避免出现问题。
Arguably, the TXT Resource Record is misnamed, and should have been called the Local Container record, because a TXT Resource Record means only what the data producer says it means. This is fine, so long as TXT Resource Records are being used by human beings or by private agreement between data producer and data consumer. However, it becomes a problem once one starts using them for standardized protocols in which there is no prior relationship between data producer and data consumer. If TXT records are used without one of the naming modifications discussed earlier (and in some cases even if one uses such naming mechanisms), there is nothing to prevent collisions with some other incompatible use of TXT Resource Records.
可以说，TXT资源记录的名称有误，应该被称为本地容器记录，因为TXT资源记录仅表示数据生产者所说的含义。这很好，只要TXT资源记录由人类使用，或者由数据生产者和数据消费者之间的私人协议使用。然而，一旦人们开始将它们用于标准化协议（在这些协议中，数据生产者和数据消费者之间没有优先关系），它就会成为一个问题。如果使用TXT记录时未进行前面讨论的命名修改（在某些情况下，即使使用了此类命名机制），则无法防止与TXT资源记录的其他不兼容使用发生冲突。
This is even worse than the general subtyping problem described in Section 3.1 because TXT Resource Records don't even have a standardized selector field in which to store the subtype. RFC 1464 [RFC1464] tried, but it was not a success. At best, a definition of
这比第3.1节中描述的一般子类型问题更糟糕，因为TXT资源记录甚至没有用于存储子类型的标准化选择器字段。RFC1464[RFC1464]尝试过，但没有成功。充其量只是一个定义
a subtype is reduced to hoping that whatever scheme one has come up with will not accidently conflict with somebody else's subtyping scheme, and that it will not be possible to mis-parse one application's use of TXT Resource Records as data intended for a different application. Any attempt to impose a standardized format within the TXT Resource Record format would be at least fifteen years too late, even if it were put into effect immediately; at best, one can restrict the syntax that a particular application uses within a TXT Resource Record and accept the risk that unrelated TXT Resource Record uses will collide with it.
子类型被简化为希望自己提出的任何方案都不会意外地与其他人的子类型方案冲突，并且不可能将一个应用程序对TXT资源记录的使用错误地解析为用于不同应用程序的数据。任何在TXT资源记录格式中强加标准格式的尝试都将至少晚15年，即使它立即生效；在最好的情况下，可以限制特定应用程序在TXT资源记录中使用的语法，并接受不相关的TXT资源记录使用将与其冲突的风险。
Using one of the naming modifications discussed in Section 3.2 and Section 3.3 would address the subtyping problem, (and have been used in combinations with reuse of TXT record, such as for the dns/txt lookup mechanism in Domain Keys Identified Mail (DKIM)) but each of these approaches brings in new problems of its own. The prefix approach (that for example SRV Resource Records use) does not work well with wildcards, which is a particular problem for mail-related applications, since MX Resource Records are probably the most common use of DNS wildcards. The suffix approach doesn't have wildcard issues, but, as noted previously, it does have synchronization and update authorization issues, since it works by creating a second subtree in a different part of the global DNS namespace.
使用第3.2节和第3.3节中讨论的命名修改之一可以解决子类型问题（并与TXT记录的重用结合使用，例如用于域密钥标识邮件（DKIM）中的dns/TXT查找机制），但每种方法都会带来自身的新问题。前缀方法（例如SRV资源记录使用的方法）不能很好地处理通配符，这对于邮件相关应用程序来说是一个特殊问题，因为MX资源记录可能是DNS通配符最常用的用法。后缀方法没有通配符问题，但如前所述，它确实存在同步和更新授权问题，因为它通过在全局DNS命名空间的不同部分创建第二个子树来工作。
The next reason why TXT Resource Records are not well suited to protocol use has to do with the limited data space available in a DNS message. As alluded to briefly in Section 3.1, typical DNS query traffic patterns involve a very large number of DNS clients sending queries to a relatively small number of DNS servers. Normal path MTU discovery schemes do little good here because, from the server's perspective, there isn't enough repeat traffic from any one client for it to be worth retaining state. UDP-based DNS is an idempotent query, whereas TCP-based DNS requires the server to keep state (in the form of TCP connection state, usually in the server's kernel) and roughly triples the traffic load. Thus, 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.
TXT资源记录不适合协议使用的第二个原因与DNS消息中可用的有限数据空间有关。正如第3.1节中简要提到的，典型的DNS查询流量模式涉及大量DNS客户端向相对较少的DNS服务器发送查询。正常路径MTU发现方案在这里没有什么好处，因为从服务器的角度来看，任何一个客户端都没有足够的重复通信量，因此不值得保留该状态。基于UDP的DNS是一个幂等查询，而基于TCP的DNS要求服务器保持状态（以TCP连接状态的形式，通常在服务器的内核中），并使流量负载大约增加三倍。因此，保持DNS消息足够短以适合UDP数据报是一个强烈的动机，最好是UDP数据报足够短以不需要IP碎片。
Subtyping schemes are therefore again problematic because they produce larger Resource RRSets than necessary, but verbose text encodings of data are also wasteful since the data they hold can usually be represented more compactly in a Resource Record designed specifically to support the application's particular data needs. If the data that need to be carried are so large that there is no way to make them fit comfortably into the DNS regardless of encoding, it is probably better to move the data somewhere else, and just use the DNS as a pointer to the data, as with NAPTR.
因此，子类型化方案再次出现问题，因为它们产生的资源集比必要的资源集大，但是数据的详细文本编码也是浪费的，因为它们所持有的数据通常可以在专门为支持应用程序的特定数据需要而设计的资源记录中更紧凑地表示。如果需要携带的数据太大，无论编码如何，都无法让它们舒适地放入DNS，那么最好将数据移动到其他地方，并使用DNS作为指向数据的指针，就像NAPTR一样。
Given the problems detailed in Section 5, it is worth reexamining the oft-jumped-to conclusion that specifying a new Resource Record Type is hard. Historically, this was indeed the case, but recent surveys suggest that support for unknown Resource Record Types [RFC3597] is now widespread in the public Internet, and because of that, the DNS infrastructure can handle new Resource Record Types. The lack of support for unknown Types remains an issue for relatively old provisioning software and in corporate environments.
考虑到第5节中详述的问题，有必要重新检查oft得出的结论，即指定新的资源记录类型很难。从历史上看，情况确实如此，但最近的调查表明，对未知资源记录类型[RFC3597]的支持现在在公共互联网上广泛存在，因此，DNS基础设施可以处理新的资源记录类型。对于相对较旧的资源调配软件和公司环境，缺少对未知类型的支持仍然是一个问题。
Of all the issues detailed in Section 3.5, provisioning the data is in some respects the most difficult. Investigations with zone transfers show that the problem is less difficult for the authoritative name servers themselves than the front-end systems used to enter (and perhaps validate) the data. Hand editing does not work well for maintenance of large zones, so some sort of tool is necessary, and the tool may not be tightly coupled to the name server implementation itself. Note, however, that this provisioning problem exists to some degree with any new form of data to be stored in the DNS, regardless of data format, Resource Record type (even if TXT Resource Record Types are in use), or naming scheme. Adapting front-end systems to support a new Resource Record Type may be a bit more difficult than reusing an existing type, but this appears to be a minor difference in degree rather than a difference in kind.
在第3.5节中详细介绍的所有问题中，提供数据在某些方面是最困难的。对区域传输的调查表明，与用于输入（或者验证）数据的前端系统相比，对于权威名称服务器本身来说，这个问题不那么困难。手动编辑对于大型区域的维护不起作用，因此需要某种工具，并且该工具可能与名称服务器实现本身没有紧密耦合。但是，请注意，无论数据格式、资源记录类型（即使使用TXT资源记录类型）或命名方案如何，要存储在DNS中的任何新形式的数据在某种程度上都存在此配置问题。调整前端系统以支持新的资源记录类型可能比重用现有类型要困难一些，但这似乎是程度上的细微差别，而不是种类上的差别。
Given the various issues described in this note, we believe that:
鉴于本说明所述的各种问题，我们认为：
o there is no magic solution that allows a completely painless addition of new data to the DNS, but
o 没有一个神奇的解决方案可以让DNS完全无痛地添加新数据，但是
o on the whole, the best solution is still to use the DNS Resource Record Type mechanism designed for precisely this purpose, whenever possible, and
o 总的来说，最好的解决方案仍然是尽可能使用专门为此目的设计的DNS资源记录类型机制，以及
o of all the alternate solutions, the "obvious" approach of using TXT Resource Records for arbitrary names is almost certainly the worst, especially for the two reasons outlined above (lack of semantics and its implementations, and size leading to the need to use TCP).
o 在所有备选解决方案中，对任意名称使用TXT资源记录的“明显”方法几乎肯定是最糟糕的，特别是出于上述两个原因（缺乏语义及其实现，以及导致需要使用TCP的大小）。
The process for creating a new Resource Record Type is specified in RFC 5395 [RFC5395].
RFC 5395[RFC5395]中指定了创建新资源记录类型的过程。
DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly necessary for any application mechanism that stores authorization data in the DNS. DNSSEC signatures significantly increase the size of the messages transported, and because of this, the DNS message size issues discussed in Sections 3.1 and 5 are more serious than they might at first appear.
可以使用DNSSEC对DNS RRSET进行签名。对于在DNS中存储授权数据的任何应用程序机制，DNSSEC几乎肯定是必需的。DNSSEC签名显著增加了传输的消息的大小，因此，第3.1节和第5节中讨论的DNS消息大小问题比最初出现的问题更严重。
Adding new Resource Record Types (as discussed in Section 3.5) can create two different kinds of problems: in the DNS software and in applications. In the DNS software, it might conceivably trigger bugs and other bad behavior in software that is not compliant with RFC 3597 [RFC3597], but most such DNS software is old enough and insecure enough that it should be updated for other reasons in any case. In applications and provisioning software, the changes for the new features that need the new data in the DNS can be updated to understand the structure of the new data format (regardless of whether a new Resource Record Type is used or some other mechanism is chosen). Basic API support for retrieving arbitrary Resource Record Types has been a requirement since 1989 [RFC1123].
添加新的资源记录类型（如第3.5节所述）可能会产生两种不同类型的问题：在DNS软件中和在应用程序中。在DNS软件中，它可能会在不符合RFC 3597[RFC3597]的软件中触发错误和其他不良行为，但大多数此类DNS软件已经足够旧且不安全，因此在任何情况下都应出于其他原因进行更新。在应用程序和配置软件中，可以更新DNS中需要新数据的新功能的更改，以了解新数据格式的结构（无论是使用新的资源记录类型还是选择其他机制）。自1989年以来，检索任意资源记录类型的基本API支持一直是一项要求[RFC1123]。
Any new protocol that proposes to use the DNS to store data used to make authorization decisions would be well advised not only to use DNSSEC but also to encourage upgrades to DNS server software recent enough not to be riddled with well-known exploitable bugs.
任何提议使用DNS来存储用于做出授权决策的数据的新协议都会得到很好的建议，不仅要使用DNSSEC，还要鼓励更新DNS服务器软件，使其不会被众所周知的可利用漏洞所困扰。
This document has been created over a number of years, with input from many people. The question on how to expand and use the DNS is sensitive, and a document like this can not please everyone. The goal is instead to describe the architecture and tradeoffs, and make some recommendations about best practices.
本文件是经过多年创作的，有许多人的参与。关于如何扩展和使用DNS的问题是敏感的，像这样的文档不能让每个人都满意。我们的目标是描述体系结构和权衡，并就最佳实践提出一些建议。
People that have helped include: Dean Anderson, Mark Andrews, John Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies, Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg, Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.
帮助过的人包括：迪安·安德森、马克·安德鲁斯、约翰·安杰尔莫、罗伊·巴达米、丹·伯恩斯坦、亚历克斯·布莱、纳撒尼尔·博伦斯坦、斯蒂芬·博茨迈耶、布莱恩·卡彭特、莱斯利·戴格尔、艾尔温·戴维斯、马克·德拉尼、理查德·德拉维斯、马丁·杜尔斯、唐纳德·伊斯特莱克、罗伯特·埃尔兹、吉姆·芬顿、托尼·芬奇、吉姆·吉尔罗伊、奥拉弗·古德蒙森、埃里克·霍尔、，菲利普·哈拉姆·贝克、特德·哈迪、鲍勃·辛登、保罗·霍夫曼、杰夫·休斯顿、克里斯蒂安·惠特马、约翰·伊伦、约翰·克莱辛、本·劳里、威廉·莱布松、约翰·莱文、爱德华·刘易斯、大卫·麦奎格、艾利森·曼金、比尔·曼宁、大卫·迈耶、佩卡·尼坎德、曼斯·尼尔森、马萨塔卡·奥塔、道格拉斯·奥蒂斯、迈克尔·巴顿、乔纳森·罗森伯格、安德·朗德格伦、，米里亚姆·萨皮罗、卡斯滕·斯特罗特曼、佩卡·萨沃拉、奇普·夏普、詹姆斯·斯内尔、迈克尔·托马斯、保罗·维克西、山姆·韦勒、弗洛里安·魏默、伯特·维宁和丹·温。
Loa Andersson Gonzalo Camarillo Stuart Cheshire Russ Housley Olaf Kolkman Gregory Lebovitz Barry Leiba Kurtis Lindqvist Andrew Malis Danny McPherson David Oran Dave Thaler Lixia Zhang
Loa Andersson Gonzalo Camarillo Stuart Cheshire Russ Housley Olaf Kolkman Gregory Lebovitz Barry Leiba Kurtis Lindqvist Andrew Malis Danny McPherson David Oran Dave Thaler Lixia Zhang
[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月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[RFC5395] Eastlake, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 5395, November 2008.
[RFC5395]Eastlake，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 53952008年11月。
[DNSEXT-DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, September 2008.
[DNSEXT-DNS-SD]Cheshire，S.和M.Krochmal，“基于DNS的服务发现”，正在进行的工作，2008年9月。
[Dyer87] Dyer, S. and F. Hsu, "Hesiod, Project Athena Technical Plan - Name Service", Version 1.9, April 1987.
[Dyer87]Dyer，S.和F.Hsu，“赫西奥德，雅典娜项目技术计划-名称服务”，1987年4月第1.9版。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, October 1993.
[RFC1535]Gavron，E.，“广泛部署DNS软件的安全问题和建议纠正”，RFC 1535，1993年10月。
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)", RFC 2163, January 1998.
[RFC2163]Allocchio，C.，“使用Internet DNS分发符合混频器的全局地址映射（MCGAM）”，RFC 2163，1998年1月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]克劳福德，M.，“非终端DNS名称重定向”，RFC 26721999年8月。
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3445]Massey，D.和S.Rose，“限制关键资源记录（RR）的范围”，RFC 34452002年12月。
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003.
[RFC3467]Klensin，J.，“域名系统（DNS）的作用”，RFC 3467，2003年2月。
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3761]Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[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月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.
[RFC4592]Lewis，E.，“通配符在域名系统中的作用”，RFC4592，2006年7月。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
Authors' Addresses
作者地址
Internet Architecture Board
互联网架构委员会
EMail: iab@iab.org
EMail: iab@iab.org
Patrik Faltstrom (editor)
帕特里克·法特斯特罗姆（编辑）
EMail: paf@cisco.com
EMail: paf@cisco.com
Rob Austein (editor)
罗伯·奥斯汀（编辑）
EMail: sra@isc.org
EMail: sra@isc.org
Peter Koch (editor)
彼得·科赫（编辑）
EMail: pk@denic.de
EMail: pk@denic.de