Internet Engineering Task Force (IETF) S. Crocker
Request for Comments: 6975 Shinkuro Inc.
Category: Standards Track S. Rose
ISSN: 2070-1721 NIST
July 2013
Internet Engineering Task Force (IETF) S. Crocker
Request for Comments: 6975 Shinkuro Inc.
Category: Standards Track S. Rose
ISSN: 2070-1721 NIST
July 2013
Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)
DNS安全扩展（DNSSEC）中的信令加密算法理解
Abstract
摘要
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.
开发DNS安全扩展（DNSSEC）是为了通过使用数字签名为DNS数据提供源身份验证和完整性保护。这些数字签名可以使用不同的算法生成。本文档指定了一种验证终端系统解析器的方法，以向服务器发送其支持的数字签名和哈希算法的信号。这些扩展允许在客户端代码中发送新算法的信号，以允许区域管理员知道何时可以在DNSSEC签名的区域中完成算法滚动。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6975.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6975.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
3. Signaling DNSSEC Algorithm Understood (DAU), DS Hash
Understood (DHU), and NSEC3 Hash Understood (N3U) Using EDNS . 4
4. Client Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . . 5
4.1.2. Non-validating Stub Resolvers . . . . . . . . . . . . . 6
4.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 6
4.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 6
5. Intermediate System Considerations . . . . . . . . . . . . . . 6
6. Server Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Traffic Analysis Considerations . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
3. Signaling DNSSEC Algorithm Understood (DAU), DS Hash
Understood (DHU), and NSEC3 Hash Understood (N3U) Using EDNS . 4
4. Client Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . . 5
4.1.2. Non-validating Stub Resolvers . . . . . . . . . . . . . 6
4.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 6
4.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 6
5. Intermediate System Considerations . . . . . . . . . . . . . . 6
6. Server Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Traffic Analysis Considerations . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
The DNS Security Extensions (DNSSEC), [RFC4033], [RFC4034], and [RFC4035], were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. Each digital signature (RRSIG) Resource Record (RR) contains an algorithm code number that corresponds to a DNSSEC public key (DNSKEY) RR. These algorithm codes tell validators which cryptographic algorithm was used to generate the digital signature.
DNS安全扩展（DNSSEC），[RFC4033]、[RFC4034]和[RFC4035]的开发目的是通过使用数字签名为DNS数据提供源身份验证和完整性保护。每个数字签名（RRSIG）资源记录（RR）包含一个与DNSSEC公钥（DNSKEY）RR相对应的算法代码。这些算法代码告诉验证器用于生成数字签名的加密算法。
Likewise, the Delegation Signer (DS) RRs and Hashed Authenticated Denial of Existence (NSEC3) RRs use a hashed value as part of their resource record data (RDATA) and, like digital signature algorithms, these hash algorithms have code numbers. All three algorithm codes (RRSIG/DNSKEY, DS, and NSEC3) are maintained in unique IANA registries.
类似地，委托签名者（DS）RRs和哈希认证拒绝存在（NSEC3）RRs使用哈希值作为其资源记录数据（RDATA）的一部分，并且与数字签名算法一样，这些哈希算法具有代码号。所有三个算法代码（RRSIG/DNSKEY、DS和NSEC3）都保存在唯一的IANA注册表中。
This document sets specifies a way for validating end-system resolvers to tell a server in a DNS query which digital signature and/or hash algorithms they support. This is done using the new Extension Mechanisms for DNS (EDNS0) options specified below in Section 2 for use in the OPT meta-RR [RFC6891]. These three new EDNS0 option codes are all OPTIONAL to implement and use.
此文档集指定了验证最终系统解析程序的方法，以便在DNS查询中告知服务器它们支持哪些数字签名和/或哈希算法。这是使用下面第2节中指定的用于OPT meta RR[RFC6891]的DNS（EDNS0）选项的新扩展机制完成的。这三个新的EDNS0选项代码都是可选的，可以实施和使用。
These proposed EDNS0 options serve to measure the acceptance and use of new digital signing algorithms. These signaling options can be used by zone administrators as a gauge to measure the successful deployment of code that implements the newly deployed digital signature algorithm, DS hash, and the NSEC3 hash algorithm used with DNSSEC. A zone administrator is able to determine when to stop signing with a superseded algorithm when the server sees that a significant number of its clients signal that they are able to accept the new algorithm. Note that this survey may be conducted over a period of years before a tipping point is seen.
这些建议的EDNS0选项用于衡量新数字签名算法的接受程度和使用情况。区域管理员可以将这些信令选项用作衡量实现新部署的数字签名算法DS哈希和与DNSSEC一起使用的NSEC3哈希算法的代码成功部署的标准。当服务器看到大量客户机表示他们能够接受新算法时，区域管理员可以确定何时停止使用替代算法进行签名。请注意，这项调查可能在看到临界点之前的几年内进行。
This document does not seek to introduce another process for including new algorithms for use with DNSSEC. It also does not address the question of which algorithms are to be included in any official list of mandatory or recommended cryptographic algorithms for use with DNSSEC. Rather, this document specifies a means by which a client query can signal the set of algorithms and hashes that it implements.
本文件并不试图介绍另一个包含用于DNSSEC的新算法的过程。它也没有解决将哪些算法包括在DNSSEC使用的强制性或推荐加密算法的任何官方列表中的问题。相反，本文指定了一种方法，客户机查询可以通过该方法向它实现的一组算法和散列发送信号。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
3. Signaling DNSSEC Algorithm Understood (DAU), DS Hash Understood (DHU), and NSEC3 Hash Understood (N3U) Using EDNS
3. 使用EDN发送已理解DNSSEC算法（DAU）、已理解DS哈希（DHU）和已理解NSEC3哈希（N3U）的信号
The EDNS0 specification outlined in [RFC6891] defines a way to include new options using a standardized mechanism. These options are contained in the RDATA of the OPT meta-RR. This document defines three new EDNS0 options for a client to signal which digital signature and/or hash algorithms the client supports. These options can be used independently of each other and MAY appear in any order in the OPT RR. Each option code can appear only once in an OPT RR.
[RFC6891]中概述的EDNS0规范定义了使用标准化机制包括新选项的方法。这些选项包含在OPT meta RR的RDATA中。本文档为客户端定义了三个新的EDNS0选项，以指示客户端支持哪些数字签名和/或哈希算法。这些选项可以相互独立使用，并且可以在OPT RR中以任何顺序出现。每个选项代码在OPT RR中只能出现一次。
The figure below shows how each option is defined in the RDATA of the OPT RR specified in [RFC6891]:
下图显示了如何在[RFC6891]中指定的OPT RR的RDATA中定义每个选项：
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LIST-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ALG-CODE | ... /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| LIST-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ALG-CODE | ... /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
OPTION-CODE is the code for the given signaling option. The options are:
OPTION-CODE是给定信令选项的代码。这些选择包括：
o DNSSEC Algorithm Understood (DAU) option for DNSSEC digital signing algorithms. Its value is fixed at 5.
o DNSSEC数字签名算法的DNSSEC算法理解（DAU）选项。它的值固定为5。
o DS Hash Understood (DHU) option for DS RR hash algorithms. Its value is fixed at 6.
o DS RR哈希算法的DS哈希理解（DHU）选项。它的值固定为6。
o NSEC3 Hash Understood (N3U) option for NSEC3 hash algorithms. Its value is fixed at 7.
o NSEC3哈希算法的NSEC3哈希理解（N3U）选项。它的值固定为7。
LIST-LENGTH is the length of the list of digital signatures or hash algorithm codes in octets. Each algorithm code occupies a single octet.
LIST-LENGTH是以八位字节为单位的数字签名或哈希算法代码列表的长度。每个算法代码占用一个八位字节。
ALG-CODE is the list of assigned values of DNSSEC zone signing algorithms, DS hash algorithms, or NSEC3 hash algorithms (depending on the OPTION-CODE in use) that the client declares to be supported. The order of the code values can be arbitrary and MUST NOT be used to infer preference.
ALG-CODE是客户端声明支持的DNSSEC区域签名算法、DS哈希算法或NSEC3哈希算法（取决于使用的选项代码）的赋值列表。代码值的顺序可以是任意的，不能用于推断偏好。
If all three options are included in the OPT RR, there is a potential for the OPT RR to take up considerable size in the DNS message. However, in practical terms, including all three options is likely to take up 22-32 octets (average of 6-10 digital signature algorithms, 3-5 DS hash algorithms, and 1-5 NSEC3 hash algorithms) including the EDNS0 option codes and option lengths in potential future examples.
如果这三个选项都包含在OPT-RR中，则OPT-RR可能会在DNS消息中占据相当大的空间。然而，在实际应用中，包括所有三个选项可能会占用22-32个八位字节（6-10个数字签名算法、3-5个DS哈希算法和1-5个NSEC3哈希算法的平均值），包括未来潜在示例中的EDNS0选项代码和选项长度。
A validating end-system resolver sets the DAU, DHU, and/or N3U option, or combination thereof, in the OPT meta-RR when sending a query. The validating end-system resolver MUST also set the DNSSEC OK bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response.
验证终端系统解析器在发送查询时，在OPT meta RR中设置DAU、DHU和/或N3U选项或其组合。验证终端系统解析器还必须设置DNSSEC OK位[RFC4035]，以指示其希望在响应中接收DNSSEC RRs。
Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital signature codes both cover a potentially wide range of algorithms and are likely not useful to a server. There is no compelling reason for a client to include these codes in its list of the DAU. Likewise, clients MUST NOT include RESERVED codes in any of the options. Additionally, a client is under no obligation to list every algorithm it implements and MAY choose to only list algorithms the client wishes to signal as understood.
请注意，PRIVATEDNS（253）和/或PRIVATEOID（254）数字签名代码都涵盖了可能广泛的算法，并且可能对服务器没有用处。客户并没有令人信服的理由将这些代码包括在其DAU列表中。同样，客户端不得在任何选项中包含保留代码。此外，客户机没有义务列出其实现的每个算法，并且可以选择仅列出客户机希望发出信号的算法。
Since the DAU, DHU, and/or N3U options are only set in the query, if a client sees these options in the response, no action needs to be taken and the client MUST ignore the option values.
由于DAU、DHU和/或N3U选项仅在查询中设置，因此如果客户端在响应中看到这些选项，则无需采取任何操作，客户端必须忽略选项值。
Typically, stub resolvers rely on an upstream recursive server (or cache) to provide a response. So optimal setting of the DAU, DSU, and N3U options depends on whether the stub resolver elects to perform its own validation.
通常，存根解析器依赖于上游递归服务器（或缓存）来提供响应。因此，DAU、DSU和N3U选项的最佳设置取决于存根解析器是否选择执行自己的验证。
A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4035] to indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG RRs) in the response. Such validating resolvers SHOULD include the DAU, DHU, and/or the N3U option(s) in the OPT RR when sending a query.
验证存根解析器设置DNSSEC OK（DO）位[RFC4035]，以指示其希望在响应中接收额外的DNSSEC RRs（即RRSIG RRs）。发送查询时，此类验证解析器应在OPT RR中包含DAU、DHU和/或N3U选项。
The DAU, DHU, and N3U EDNS0 options MUST NOT be included by non-validating stub resolvers.
非验证存根解析器不得包含DAU、DHU和N3U EDNS0选项。
A validating recursive resolver sets the DAU, DHU, and/or N3U option(s) when performing recursion based on its list of algorithms and any DAU, DHU, and/or N3U option lists in the stub client query. When the recursive server receives a query with one or more of the options set, the recursive server MUST set the algorithm list for any outgoing iterative queries for that resolution chain to a union of the stub client's list and the validating recursive resolver's list. For example, if the recursive resolver's algorithm list for the DAU option is (3, 5, 7) and the stub's algorithm list is (7, 8), the final DAU algorithm list would be (3, 5, 7, 8).
验证递归解析器在基于其算法列表和存根客户端查询中的任何DAU、DHU和/或N3U选项列表执行递归时设置DAU、DHU和/或N3U选项。当递归服务器接收到设置了一个或多个选项的查询时，递归服务器必须将该解析链的任何传出迭代查询的算法列表设置为存根客户端列表和验证递归解析程序列表的并集。例如，如果DAU选项的递归解析器的算法列表为（3,5,7），而存根的算法列表为（7,8），则最终的DAU算法列表将为（3,5,7,8）。
If the client included the DO and Checking Disabled (CD) bits, but did not include the DAU, DHU, and/or N3U option(s) in the query, the validating recursive resolver MAY include the option(s) with its own list in full. If one or more of the options are missing, the validating recursive resolver MAY include the missing options with its own list in full.
如果客户端包含DO和Checking Disabled（CD）位，但在查询中未包含DAU、DHU和/或N3U选项，则验证递归解析器可能会包含该选项及其自己的完整列表。如果缺少一个或多个选项，验证递归解析器可能会将缺少的选项包含在自己的完整列表中。
Validating recursive resolvers MUST NOT set the DAU, DHU, and/or N3U option(s) in the final response to the stub client.
验证递归解析器不得在对存根客户端的最终响应中设置DAU、DHU和/或N3U选项。
Recursive resolvers that do not do validation MUST copy the DAU, DHU, and/or N3U option(s) seen in received queries as they represent the wishes of the validating downstream resolver that issued the original query.
不进行验证的递归解析器必须复制接收到的查询中的DAU、DHU和/或N3U选项，因为它们代表发出原始查询的验证下游解析器的意愿。
Intermediate proxies (see Section 4.4.2 of [RFC5625]) that understand DNS are RECOMMENDED to behave like a comparable recursive resolver when dealing with the DAU, DHU, and N3U options.
在处理DAU、DHU和N3U选项时，建议理解DNS的中间代理（参见[RFC5625]第4.4.2节）的行为类似于可比较的递归解析器。
When an authoritative server sees the DAU, DHU, and/or N3U option(s) in the OPT meta-RR in a request, the normal algorithm for servicing requests is followed. The options MUST NOT trigger any special processing (e.g., RRSIG filtering in responses) on the server side.
当权威服务器在请求的OPT meta RR中看到DAU、DHU和/或N3U选项时，将遵循正常的请求服务算法。这些选项不得触发服务器端的任何特殊处理（例如，响应中的RRSIG过滤）。
If the options are present but the DO bit is not set, the server does not do any DNSSEC processing, which includes any recording of the option(s).
如果存在选项，但未设置DO位，则服务器不会执行任何DNSSEC处理，其中包括对选项的任何记录。
If the server sees one (or more) of the options set with RESERVED values, the server MAY ignore recoding of those values.
如果服务器看到一个（或多个）带有保留值的选项集，则服务器可能会忽略这些值的重新编码。
Authoritative servers MUST NOT set the DAU, DHU, and/or N3U option(s) on any responses. These values are only set in queries.
权威服务器不得在任何响应上设置DAU、DHU和/或N3U选项。这些值仅在查询中设置。
Zone administrators that are planning or are in the process of a cryptographic algorithm rollover operation should monitor DNS query traffic and record the number of queries, the presence of the OPT RR in queries, and the values of the DAU/DHU/N3U option(s) (if present). This monitoring can be used to measure the deployment of client code that implements (and signals) specific algorithms. A description of the techniques used to capture DNS traffic and measure new algorithm adoption is beyond the scope of this document.
正在规划或正在进行加密算法滚动操作的区域管理员应监控DNS查询流量，并记录查询数量、OPT RR in查询的存在以及DAU/DHU/N3U选项（如果存在）的值。此监视可用于测量实现（并发出信号）特定算法的客户端代码的部署。对用于捕获DNS流量和测量新算法采用情况的技术的描述超出了本文档的范围。
Zone administrators that need to comply with changes to their organization's security policy (with regards to cryptographic algorithm use) can use this data to set milestone dates for performing an algorithm rollover. For example, zone administrators can use the data to determine when older algorithms can be phased out without disrupting a significant number of clients. In order to keep this disruption to a minimum, zone administrators should wait to complete an algorithm rollover until a large majority of clients signal that they recognize the new algorithm. This may be in the order of years rather than months.
需要遵守组织安全策略更改（关于加密算法使用）的区域管理员可以使用此数据设置执行算法滚动的里程碑日期。例如，区域管理员可以使用数据来确定何时可以在不中断大量客户端的情况下淘汰旧算法。为了将这种中断保持在最低限度，区域管理员应该等待完成算法滚动，直到绝大多数客户端发出信号表示他们识别新算法。这可能是以年为单位，而不是以月为单位。
Note that clients that do not implement these options are likely to be older implementations that would also not implement any newly deployed algorithm.
请注意，未实现这些选项的客户端可能是较旧的实现，也不会实现任何新部署的算法。
The algorithm codes used to identify DNSSEC algorithms, DS RR hash algorithms, and NSEC3 hash algorithms have already been established by IANA. This document does not seek to alter that registry in any way.
IANA已经建立了用于识别DNSSEC算法、DS RR哈希算法和NSEC3哈希算法的算法代码。本文件不寻求以任何方式改变该注册。
IANA has allocated option codes 5, 6, and 7 for the DAU, DHU, and N3U options, respectively, in the "DNS EDNS0 Option Codes (OPT)" registry. The three options have a status of "standard".
IANA在“DNS EDNS0选项代码（OPT）”注册表中分别为DAU、DHU和N3U选项分配了选项代码5、6和7。这三个选项的状态为“标准”。
This document specifies a way for a client to signal its digital signature and hash algorithm knowledge to a cache or server. It is not meant to be a discussion on algorithm superiority. The signals are optional codes contained in the OPT meta-RR used with EDNS. The goal of these options is to signal new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.
本文档指定了客户端向缓存或服务器发送其数字签名和哈希算法知识信号的方法。这并不是要讨论算法的优越性。信号是包含在与EDN一起使用的OPT meta RR中的可选代码。这些选项的目标是在客户端代码中显示新算法的使用，以便区域管理员知道何时可以在DNSSEC签名的区域中完成算法滚动。
There is a possibility that an eavesdropper or server could infer the validator in use by a client by the presence of the AU options and/or algorithm code list. This information leakage in itself is not very useful to a potential attacker, but it could be used to identify the validator or narrow down the possible validator implementations in use by a client, which could have a known vulnerability that could be exploited by the attacker.
窃听者或服务器有可能通过AU选项和/或算法代码列表推断出客户端正在使用的验证器。这种信息泄漏本身对潜在的攻击者不是很有用，但它可用于识别验证程序或缩小客户端可能使用的验证程序实现的范围，客户端可能具有攻击者可能利用的已知漏洞。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 56252009年8月。
[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月。
Authors' Addresses
作者地址
Steve Crocker Shinkuro Inc. 5110 Edgemoor Lane Bethesda, MD 20814 USA
Steve Crocker Shinkuro Inc.美国马里兰州贝塞斯达埃杰莫尔巷5110号，邮编20814
EMail: steve@shinkuro.com
EMail: steve@shinkuro.com
Scott Rose NIST 100 Bureau Dr. Gaithersburg, MD 20899 USA
斯科特·罗斯NIST 100局盖瑟斯堡博士，美国马里兰州20899
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com