Network Working Group R. Arends
Request for Comments: 4033 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
Network Working Group R. Arends
Request for Comments: 4033 Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein
3755, 3757, 3845 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson
3007, 3597, 3226 VeriSign
Category: Standards Track D. Massey
Colorado State University
S. Rose
NIST
March 2005
DNS Security Introduction and Requirements
DNS安全介绍和要求
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.
域名系统安全扩展（DNSSEC）将数据源身份验证和数据完整性添加到域名系统。本文档介绍了这些扩展，并描述了它们的功能和局限性。本文档还讨论DNS安全扩展提供和不提供的服务。最后，本文件描述了共同描述DNSSEC的文件之间的相互关系。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3
3. Services Provided by DNS Security . . . . . . . . . . . . . 7
3.1. Data Origin Authentication and Data Integrity . . . . 7
3.2. Authenticating Name and Type Non-Existence . . . . . . 9
4. Services Not Provided by DNS Security . . . . . . . . . . . 9
5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9
6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10
7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11
8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12
8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13
8.2. New Temporal Dependency Issues for Zones . . . . . . . 13
9. Name Server Considerations . . . . . . . . . . . . . . . . . 13
10. DNS Security Document Family . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3
3. Services Provided by DNS Security . . . . . . . . . . . . . 7
3.1. Data Origin Authentication and Data Integrity . . . . 7
3.2. Authenticating Name and Type Non-Existence . . . . . . 9
4. Services Not Provided by DNS Security . . . . . . . . . . . 9
5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9
6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10
7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11
8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12
8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13
8.2. New Temporal Dependency Issues for Zones . . . . . . . 13
9. Name Server Considerations . . . . . . . . . . . . . . . . . 13
10. DNS Security Document Family . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21
This document introduces the Domain Name System Security Extensions (DNSSEC). This document and its two companion documents ([RFC4034] and [RFC4035]) update, clarify, and refine the security extensions defined in [RFC2535] and its predecessors. These security extensions consist of a set of new resource record types and modifications to the existing DNS protocol ([RFC1035]). The new records and protocol modifications are not fully described in this document, but are described in a family of documents outlined in Section 10. Sections 3 and 4 describe the capabilities and limitations of the security extensions in greater detail. Section 5 discusses the scope of the document set. Sections 6, 7, 8, and 9 discuss the effect that these security extensions will have on resolvers, stub resolvers, zones, and name servers.
本文档介绍域名系统安全扩展（DNSSEC）。本文档及其两个附带文档（[RFC4034]和[RFC4035]）更新、澄清和完善了[RFC2535]及其前身中定义的安全扩展。这些安全扩展包括一组新的资源记录类型和对现有DNS协议（[RFC1035]）的修改。新记录和协议修改未在本文件中完全描述，但在第10节概述的一系列文件中进行了描述。第3节和第4节更详细地描述了安全扩展的功能和限制。第5节讨论文档集的范围。第6、7、8和9节讨论了这些安全扩展对解析程序、存根解析程序、区域和名称服务器的影响。
This document and its two companions obsolete [RFC2535], [RFC3008],
[RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
[RFC3845]. This document set also updates but does not obsolete
[RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
[RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
DNSSEC.
This document and its two companions obsolete [RFC2535], [RFC3008],
[RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
[RFC3845]. This document set also updates but does not obsolete
[RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
[RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
DNSSEC.
The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key distribution. These extensions do not provide confidentiality.
DNS安全扩展为DNS数据提供源身份验证和完整性保护，以及公钥分发的方法。这些扩展不提供机密性。
This section defines a number of terms used in this document set. Because this is intended to be useful as a reference while reading the rest of the document set, first-time readers may wish to skim this section quickly, read the rest of this document, and then come back to this section.
本节定义了本文档集中使用的许多术语。因为这是为了在阅读文档集的其余部分时用作参考，初次阅读的读者可能希望快速浏览本节，阅读本文档的其余部分，然后返回本节。
Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of signed data, with each link in the chain vouching for the next. A DNSKEY RR is used to verify the signature covering a DS RR and allows the DS RR to be authenticated. The DS RR contains a hash of another DNSKEY RR and this new DNSKEY RR is authenticated by matching the hash in the DS RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in this set may be used to authenticate another DS RR, and so forth until the chain finally ends with a DNSKEY RR whose corresponding private key signs the desired DNS data. For example, the root DNSKEY RRset can be used to authenticate the DS RRset for "example." The "example." DS RRset contains a hash that matches some "example." DNSKEY, and this DNSKEY's corresponding private key signs the "example." DNSKEY RRset. Private key counterparts of the "example." DNSKEY RRset sign data records such as "www.example." and DS RRs for delegations such as "subzone.example."
身份验证链：DNS公钥（DNSKEY）RRSET和委托签名者（DS）RRSET的交替序列形成一个签名数据链，链中的每个链接为下一个链接提供担保。DNSKEY RR用于验证覆盖DS RR的签名，并允许对DS RR进行身份验证。DS RR包含另一个DNSKEY RR的哈希，此新DNSKEY RR通过匹配DS RR中的哈希进行身份验证。这个新的DNSKEY RR反过来认证另一个DNSKEY RR集，并且反过来，该集中的一些DNSKEY RR可用于认证另一个DS RR，依此类推，直到链最终以DNSKEY RR结束，该DNSKEY RR的对应私钥对所需的DNS数据进行签名。例如，根DNSKEY RRset可用于验证“example”的DS RRset。“example.”DS RRset包含一个与某个“example.”DNSKEY匹配的哈希，该DNSKEY对应的私钥对“example.”DNSKEY RRset进行签名。“example.”的私钥对应方DNSKEY RRset签署数据记录，如“www.example.”和代表团DS RRs，如“subzone.example.”
Authentication Key: A public key that a security-aware resolver has verified and can therefore use to authenticate data. A security-aware resolver can obtain authentication keys in three ways. First, the resolver is generally configured to know about at least one public key; this configured data is usually either the public key itself or a hash of the public key as found in the DS RR (see "trust anchor"). Second, the resolver may use an authenticated public key to verify a DS RR and the DNSKEY RR to which the DS RR refers. Third, the resolver may be able to determine that a new public key has been signed by the private key corresponding to another public key that the resolver has verified. Note that the resolver must always be guided by local policy when deciding whether to authenticate a new public key, even if the local policy is simply to authenticate any new public key for which the resolver is able verify the signature.
身份验证密钥：具有安全意识的解析器已验证的公钥，因此可用于对数据进行身份验证。具有安全意识的解析器可以通过三种方式获取身份验证密钥。首先，解析器通常被配置为知道至少一个公钥；此配置数据通常是公钥本身或DS RR中的公钥散列（请参阅“信任锚”）。第二，解析器可以使用经过身份验证的公钥来验证DS RR和DS RR引用的DNSKEY RR。第三，解析程序可能能够确定新公钥已由与解析程序已验证的另一公钥相对应的私钥签名。请注意，在决定是否对新公钥进行身份验证时，解析程序必须始终遵循本地策略，即使本地策略只是对解析程序能够验证签名的任何新公钥进行身份验证。
Authoritative RRset: Within the context of a particular zone, an RRset is "authoritative" if and only if the owner name of the RRset lies within the subset of the name space that is at or below the zone apex and at or above the cuts that separate the zone from its children, if any. All RRsets at the zone apex are authoritative, except for certain RRsets at this domain name that, if present, belong to this zone's parent. These RRset could include a DS RRset, the NSEC RRset referencing this DS RRset (the "parental NSEC"), and RRSIG RRs associated with these RRsets, all of which are authoritative in the parent zone. Similarly, if this zone contains any delegation points, only the parental NSEC RRset, DS RRsets, and any RRSIG RRs associated with these RRsets are authoritative for this zone.
权威RRset：在特定区域的上下文中，当且仅当RRset的所有者名称位于名称空间的子集内时，RRset才是“权威的”，该名称空间位于区域顶点或其下方，位于将区域与其子区域（如有）分隔的切口或其上方。区域顶点处的所有RRSET都是权威的，但该域名处的某些RRSET（如果存在）属于该区域的父级。这些RRset可以包括DS RRset、引用该DS RRset的NSEC RRset（“父NSEC”）以及与这些RRset关联的RRSIG RRs，所有这些RRset在父区域中都是权威的。类似地，如果此区域包含任何委派点，则只有父NSEC RRset、DS RRset和与这些RRset关联的任何RRSIG RRs对此区域具有权威性。
Delegation Point: Term used to describe the name at the parental side of a zone cut. That is, the delegation point for "foo.example" would be the foo.example node in the "example" zone (as opposed to the zone apex of the "foo.example" zone). See also zone apex.
委托点：用于描述分区切割母边名称的术语。也就是说，“foo.example”的委托点将是“example”区域中的foo.example节点（与“foo.example”区域的区域顶点相反）。另见区域顶点。
Island of Security: Term used to describe a signed, delegated zone that does not have an authentication chain from its delegating parent. That is, there is no DS RR containing a hash of a DNSKEY RR for the island in its delegating parent zone (see [RFC4034]). An island of security is served by security-aware name servers and may provide authentication chains to any delegated child zones. Responses from an island of security or its descendents can only be authenticated if its authentication keys can be authenticated by some trusted means out of band from the DNS protocol.
安全岛：用于描述已签名、已委派区域的术语，该区域没有来自其委派父级的身份验证链。也就是说，在其委托父区域中不存在包含岛的DNSKEY RR哈希的DS RR（请参见[RFC4034]）。安全岛由具有安全意识的名称服务器提供服务，可以向任何委托的子区域提供身份验证链。来自安全岛或其后代的响应只有在其身份验证密钥可以通过DNS协议带外的某种可信方式进行身份验证时才能进行身份验证。
Key Signing Key (KSK): An authentication key that corresponds to a private key used to sign one or more other authentication keys for a given zone. Typically, the private key corresponding to a key signing key will sign a zone signing key, which in turn has a corresponding private key that will sign other zone data. Local policy may require that the zone signing key be changed frequently, while the key signing key may have a longer validity period in order to provide a more stable secure entry point into the zone. Designating an authentication key as a key signing key is purely an operational issue: DNSSEC validation does not distinguish between key signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key. Key signing keys are discussed in more detail in [RFC3757]. Also see zone signing key.
密钥签名密钥（KSK）：与私钥相对应的身份验证密钥，用于为给定区域的一个或多个其他身份验证密钥签名。通常，与密钥签名密钥对应的私钥将对区域签名密钥进行签名，区域签名密钥又具有将对其他区域数据进行签名的对应私钥。本地策略可能要求频繁更改区域签名密钥，而密钥签名密钥可能具有更长的有效期，以便向区域提供更稳定的安全入口点。将身份验证密钥指定为密钥签名密钥纯粹是一个操作问题：DNSSEC验证不区分密钥签名密钥和其他DNSSEC身份验证密钥，并且可以使用单个密钥作为密钥签名密钥和区域签名密钥。[RFC3757]中详细讨论了密钥签名密钥。另请参见区域签名密钥。
Non-Validating Security-Aware Stub Resolver: A security-aware stub resolver that trusts one or more security-aware recursive name servers to perform most of the tasks discussed in this document set on its behalf. In particular, a non-validating security-aware stub resolver is an entity that sends DNS queries, receives DNS responses, and is capable of establishing an appropriately secured channel to a security-aware recursive name server that will provide these services on behalf of the security-aware stub resolver. See also security-aware stub resolver, validating security-aware stub resolver.
非验证安全感知存根解析程序：一种安全感知存根解析程序，它信任一个或多个安全感知递归名称服务器代表其执行本文档集中讨论的大多数任务。具体而言，非验证性安全感知存根解析程序是发送DNS查询、接收DNS响应并能够建立到安全感知递归名称服务器的适当安全通道的实体，该服务器将代表安全感知存根解析程序提供这些服务。另请参见安全感知存根解析器，验证安全感知存根解析器。
Non-Validating Stub Resolver: A less tedious term for a non-validating security-aware stub resolver.
非验证存根解析器：非验证安全感知存根解析器的一个不那么冗长的术语。
Security-Aware Name Server: An entity acting in the role of a name server (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set. In particular, a security-aware name server is an entity that receives DNS queries, sends DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and supports the RR types and message header bits defined in this document set.
安全感知名称服务器：作为名称服务器（定义见[RFC1034]第2.4节）的实体，该实体了解本文档集中定义的DNS安全扩展。具体而言，安全感知名称服务器是一个实体，它接收DNS查询，发送DNS响应，支持EDNS0（[RFC2671]）消息大小扩展和DO位（[RFC3225]），并支持此文档集中定义的RR类型和消息头位。
Security-Aware Recursive Name Server: An entity that acts in both the security-aware name server and security-aware resolver roles. A more cumbersome but equivalent phrase would be "a security-aware name server that offers recursive service".
安全感知递归名称服务器：在安全感知名称服务器和安全感知冲突解决程序角色中起作用的实体。一个更麻烦但等效的短语是“提供递归服务的具有安全意识的名称服务器”。
Security-Aware Resolver: An entity acting in the role of a resolver (defined in section 2.4 of [RFC1034]) that understands the DNS security extensions defined in this document set. In particular, a security-aware resolver is an entity that sends DNS queries, receives DNS responses, supports the EDNS0 ([RFC2671]) message size extension and the DO bit ([RFC3225]), and is capable of using the RR types and message header bits defined in this document set to provide DNSSEC services.
安全感知解析程序：以解析程序（在[RFC1034]第2.4节中定义）的角色行事的实体，该解析程序理解本文档集中定义的DNS安全扩展。具体而言，安全感知解析程序是一种实体，它发送DNS查询、接收DNS响应、支持EDNS0（[RFC2671]）消息大小扩展和DO位（[RFC3225]），并且能够使用此文档集中定义的RR类型和消息头位来提供DNSSEC服务。
Security-Aware Stub Resolver: An entity acting in the role of a stub resolver (defined in section 5.3.1 of [RFC1034]) that has enough of an understanding the DNS security extensions defined in this document set to provide additional services not available from a security-oblivious stub resolver. Security-aware stub resolvers may be either "validating" or "non-validating", depending on whether the stub resolver attempts to verify DNSSEC signatures on its own or trusts a friendly security-aware name server to do so. See also validating stub resolver, non-validating stub resolver.
具有安全意识的存根解析程序：作为存根解析程序（定义见[RFC1034]第5.3.1节）的实体，该实体充分了解本文档集定义的DNS安全扩展，以提供不具有安全意识的存根解析程序无法提供的附加服务。安全感知的存根解析程序可以是“验证”或“非验证”，这取决于存根解析程序是尝试自己验证DNSSEC签名，还是信任友好的安全感知名称服务器来验证DNSSEC签名。另请参见验证存根解析器、非验证存根解析器。
Security-Oblivious <anything>: An <anything> that is not "security-aware".
无安全意识的<anything>：一种没有“安全意识”的<anything>。
Signed Zone: A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records.
已签名区域：其RRSET已签名且包含正确构造的DNSKEY、资源记录签名（RRSIG）、下一安全（NSEC）和（可选）DS记录的区域。
Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. In general, a validating resolver will have to obtain the initial values of its trust anchors via some secure or trusted means outside the DNS protocol. Presence of a trust anchor also implies that the resolver should expect the zone to which the trust anchor points to be signed.
信任锚点：DNSKEY RR的已配置DNSKEY RR或DS RR哈希。具有验证安全意识的解析器使用此公钥或哈希作为起点，以构建签名DNS响应的身份验证链。通常，验证解析程序必须通过DNS协议之外的一些安全或受信任的方式获得其信任锚的初始值。信任锚的存在还意味着解析器应该期望信任锚指向的区域被签名。
Unsigned Zone: A zone that is not signed.
未签名区域：未签名的区域。
Validating Security-Aware Stub Resolver: A security-aware resolver that sends queries in recursive mode but that performs signature validation on its own rather than just blindly trusting an upstream security-aware recursive name server. See also security-aware stub resolver, non-validating security-aware stub resolver.
验证安全感知的存根解析器：一种安全感知的解析器，以递归模式发送查询，但它自己执行签名验证，而不是盲目信任上游安全感知的递归名称服务器。另请参见安全感知存根解析器，非验证安全感知存根解析器。
Validating Stub Resolver: A less tedious term for a validating security-aware stub resolver.
验证存根解析器：用于验证安全性感知存根解析器的一个不那么繁琐的术语。
Zone Apex: Term used to describe the name at the child's side of a zone cut. See also delegation point.
分区顶点：用于描述分区切割中孩子一侧的名称的术语。另见授权点。
Zone Signing Key (ZSK): An authentication key that corresponds to a private key used to sign a zone. Typically, a zone signing key will be part of the same DNSKEY RRset as the key signing key whose corresponding private key signs this DNSKEY RRset, but the zone signing key is used for a slightly different purpose and may differ from the key signing key in other ways, such as validity lifetime. Designating an authentication key as a zone signing key is purely an operational issue; DNSSEC validation does not distinguish between zone signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key. See also key signing key.
区域签名密钥（ZSK）：与用于对区域进行签名的私钥相对应的身份验证密钥。通常，区域签名密钥与密钥签名密钥（其对应的私钥对该DNSKEY RRset进行签名）是同一DNSKEY RRset的一部分，但区域签名密钥用于稍有不同的目的，并且可能在其他方面不同于密钥签名密钥，如有效期。将认证密钥指定为区域签名密钥纯粹是操作问题；DNSSEC验证不区分区域签名密钥和其他DNSSEC身份验证密钥，并且可以使用单个密钥作为密钥签名密钥和区域签名密钥。另请参见密钥签名密钥。
The Domain Name System (DNS) security extensions provide origin authentication and integrity assurance services for DNS data, including mechanisms for authenticated denial of existence of DNS data. These mechanisms are described below.
域名系统（DNS）安全扩展为DNS数据提供原始身份验证和完整性保证服务，包括通过身份验证拒绝存在DNS数据的机制。这些机制如下所述。
These mechanisms require changes to the DNS protocol. DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). It also adds two new message header bits: Checking Disabled (CD) and Authenticated Data (AD). In order to support the larger DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a security-aware resolver can indicate in its queries that it wishes to receive DNSSEC RRs in response messages.
这些机制需要更改DNS协议。DNSSEC添加了四种新的资源记录类型：资源记录签名（RRSIG）、DNS公钥（DNSKEY）、委托签名者（DS）和下一个安全（NSEC）。它还添加了两个新的消息头位：检查禁用（CD）和身份验证数据（AD）。为了支持由于添加DNSSEC RRs而产生的较大DNS消息大小，DNSSEC还需要EDNS0支持（[RFC2671]）。最后，DNSSEC需要对DNSSEC OK（DO）EDNS头位（[RFC3225]）的支持，以便安全感知解析器可以在其查询中指示其希望在响应消息中接收DNSSEC RRs。
These services protect against most of the threats to the Domain Name System described in [RFC3833]. Please see Section 12 for a discussion of the limitations of these extensions.
这些服务可以抵御[RFC3833]中描述的域名系统的大部分威胁。有关这些扩展的限制的讨论，请参见第12节。
DNSSEC provides authentication by associating cryptographically generated digital signatures with DNS RRsets. These digital signatures are stored in a new resource record, the RRSIG record. Typically, there will be a single private key that signs a zone's data, but multiple keys are possible. For example, there may be keys for each of several different digital signature algorithms. If a security-aware resolver reliably learns a zone's public key, it can authenticate that zone's signed data. An important DNSSEC concept is that the key that signs a zone's data is associated with the zone itself and not with the zone's authoritative name servers. (Public keys for DNS transaction authentication mechanisms may also appear in zones, as described in [RFC2931], but DNSSEC itself is concerned with object security of DNS data, not channel security of DNS transactions. The keys associated with transaction security may be stored in different RR types. See [RFC3755] for details.)
DNSSEC通过将加密生成的数字签名与DNS RRSET相关联来提供身份验证。这些数字签名存储在新的资源记录RRSIG记录中。通常，将有一个私钥对区域的数据进行签名，但也可以有多个密钥。例如，对于几个不同的数字签名算法中的每一个，可能都有密钥。如果具有安全意识的解析器可靠地学习了区域的公钥，则它可以对该区域的签名数据进行身份验证。DNSSEC的一个重要概念是，签署区域数据的密钥与区域本身关联，而不是与区域的权威名称服务器关联。（DNS交易身份验证机制的公钥也可能出现在区域中，如[RFC2931]所述，但DNSSEC本身关注的是DNS数据的对象安全性，而不是DNS交易的通道安全性。与交易安全性相关的密钥可能存储在不同的RR类型中。有关详细信息，请参阅[RFC3755]）
A security-aware resolver can learn a zone's public key either by having a trust anchor configured into the resolver or by normal DNS resolution. To allow the latter, public keys are stored in a new type of resource record, the DNSKEY RR. Note that the private keys used to sign zone data must be kept secure and should be stored offline when practical. To discover a public key reliably via DNS resolution, the target key itself has to be signed by either a configured authentication key or another key that has been
具有安全意识的解析程序可以通过在解析程序中配置信任锚点或通过正常DNS解析来学习区域的公钥。为了允许后者，公钥存储在一种新类型的资源记录中，即DNSKEY RR。请注意，用于签署区域数据的私钥必须保持安全，并且在可行时应脱机存储。要通过DNS解析可靠地发现公钥，目标密钥本身必须由已配置的身份验证密钥或已配置的其他密钥签名
authenticated previously. Security-aware resolvers authenticate zone information by forming an authentication chain from a newly learned public key back to a previously known authentication public key, which in turn either has been configured into the resolver or must have been learned and verified previously. Therefore, the resolver must be configured with at least one trust anchor.
已经过验证。具有安全意识的冲突解决程序通过形成从新学到的公钥到先前已知的身份验证公钥的身份验证链来验证区域信息，而先前已知的身份验证公钥又被配置到冲突解决程序中，或者之前必须已经学习和验证。因此，解析程序必须至少配置一个信任锚点。
If the configured trust anchor is a zone signing key, then it will authenticate the associated zone; if the configured key is a key signing key, it will authenticate a zone signing key. If the configured trust anchor is the hash of a key rather than the key itself, the resolver may have to obtain the key via a DNS query. To help security-aware resolvers establish this authentication chain, security-aware name servers attempt to send the signature(s) needed to authenticate a zone's public key(s) in the DNS reply message along with the public key itself, provided that there is space available in the message.
如果配置的信任锚是区域签名密钥，则它将对关联区域进行身份验证；如果配置的密钥是密钥签名密钥，它将对区域签名密钥进行身份验证。如果配置的信任锚是密钥的散列，而不是密钥本身，则解析程序可能必须通过DNS查询获取密钥。为了帮助安全意识强的解析程序建立此身份验证链，安全意识强的名称服务器尝试在DNS回复消息中发送验证区域公钥所需的签名以及公钥本身，前提是消息中有可用空间。
The Delegation Signer (DS) RR type simplifies some of the administrative tasks involved in signing delegations across organizational boundaries. The DS RRset resides at a delegation point in a parent zone and indicates the public key(s) corresponding to the private key(s) used to self-sign the DNSKEY RRset at the delegated child zone's apex. The administrator of the child zone, in turn, uses the private key(s) corresponding to one or more of the public keys in this DNSKEY RRset to sign the child zone's data. The typical authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more complex authentication chains, such as additional layers of DNSKEY RRs signing other DNSKEY RRs within a zone.
委派签署者（DS）RR类型简化了跨组织边界签署委派所涉及的一些管理任务。DS RRset位于父区域中的委派点，并指示与用于在委派子区域顶点对DNSKEY RRset进行自签名的私钥相对应的公钥。子区域的管理员依次使用与此DNSKEY RRset中的一个或多个公钥相对应的私钥对子区域的数据进行签名。因此，典型的身份验证链是DNSKEY->[DS->DNSKEY]*->RRset，其中“*”表示零个或多个DS->DNSKEY子链。DNSSEC允许更复杂的身份验证链，例如在区域内签署其他DNSKEY RRs的附加DNSKEY RRs层。
A security-aware resolver normally constructs this authentication chain from the root of the DNS hierarchy down to the leaf zones based on configured knowledge of the public key for the root. Local policy, however, may also allow a security-aware resolver to use one or more configured public keys (or hashes of public keys) other than the root public key, may not provide configured knowledge of the root public key, or may prevent the resolver from using particular public keys for arbitrary reasons, even if those public keys are properly signed with verifiable signatures. DNSSEC provides mechanisms by which a security-aware resolver can determine whether an RRset's signature is "valid" within the meaning of DNSSEC. In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set. See Section 5 for further discussion.
具有安全意识的解析器通常基于根的公钥配置知识，从DNS层次结构的根到叶区域构造此身份验证链。然而，本地策略也可能允许安全感知解析程序使用根公钥以外的一个或多个配置公钥（或公钥散列），可能不提供根公钥的配置知识，或者可能防止解析程序出于任意原因使用特定公钥，即使这些公钥使用可验证的签名进行了正确签名。DNSSEC提供了一些机制，通过这些机制，具有安全意识的解析器可以确定RRset的签名是否在DNSSEC意义下“有效”。但是，归根结底，对DNS密钥和数据进行身份验证是本地策略的问题，这可能会扩展甚至覆盖此文档集中定义的协议扩展。进一步讨论见第5节。
The security mechanism described in Section 3.1 only provides a way to sign existing RRsets in a zone. The problem of providing negative responses with the same level of authentication and integrity requires the use of another new resource record type, the NSEC record. The NSEC record allows a security-aware resolver to authenticate a negative reply for either name or type non-existence with the same mechanisms used to authenticate other DNS replies. Use of NSEC records requires a canonical representation and ordering for domain names in zones. Chains of NSEC records explicitly describe the gaps, or "empty space", between domain names in a zone and list the types of RRsets present at existing names. Each NSEC record is signed and authenticated using the mechanisms described in Section 3.1.
第3.1节中描述的安全机制仅提供了对区域中现有RRSET进行签名的方法。提供具有相同身份验证和完整性级别的否定响应的问题需要使用另一种新的资源记录类型，NSEC记录。NSEC记录允许具有安全意识的解析器使用用于验证其他DNS响应的相同机制，对名称或类型不存在的否定响应进行验证。使用NSEC记录需要域名在区域中的规范表示和排序。NSEC记录链明确描述了区域中域名之间的间隔或“空白”，并列出了现有名称中存在的RRSET类型。使用第3.1节中描述的机制对每个NSEC记录进行签名和认证。
DNS was originally designed with the assumptions that the DNS will return the same answer to any given query regardless of who may have issued the query, and that all data in the DNS is thus visible. Accordingly, DNSSEC is not designed to provide confidentiality, access control lists, or other means of differentiating between inquirers.
DNS最初的设计假设是，无论是谁发出了查询，DNS都会对任何给定查询返回相同的答案，因此DNS中的所有数据都是可见的。因此，DNSSEC的设计目的不是提供机密性、访问控制列表或其他区分查询者的方法。
DNSSEC provides no protection against denial of service attacks. Security-aware resolvers and security-aware name servers are vulnerable to an additional class of denial of service attacks based on cryptographic operations. Please see Section 12 for details.
DNSSEC不提供针对拒绝服务攻击的保护。具有安全意识的解析程序和具有安全意识的名称服务器容易受到另一类基于加密操作的拒绝服务攻击。详情请参见第12节。
The DNS security extensions provide data and origin authentication for DNS data. The mechanisms outlined above are not designed to protect operations such as zone transfers and dynamic update ([RFC2136], [RFC3007]). Message authentication schemes described in [RFC2845] and [RFC2931] address security operations that pertain to these transactions.
DNS安全扩展为DNS数据提供数据和源身份验证。上述机制不是为保护区域传输和动态更新等操作而设计的（[RFC2136]、[RFC3007]）。[RFC2845]和[RFC2931]中描述的消息身份验证方案解决了与这些事务相关的安全操作。
The specification in this document set defines the behavior for zone signers and security-aware name servers and resolvers in such a way that the validating entities can unambiguously determine the state of the data.
此文档集中的规范定义了区域签名者、安全感知名称服务器和解析程序的行为，以便验证实体能够明确地确定数据的状态。
A validating resolver can determine the following 4 states:
验证解析器可以确定以下4种状态：
Secure: The validating resolver has a trust anchor, has a chain of trust, and is able to verify all the signatures in the response.
安全：验证解析程序有一个信任锚点，有一个信任链，并且能够验证响应中的所有签名。
Insecure: The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure. A validating resolver may have a local policy to mark parts of the domain space as insecure.
不安全：验证解析程序有一个信任锚点、一个信任链，并且在某个委托点上有DS记录不存在的签名证明。这表明树中的后续分支是不安全的。验证解析程序可能有一个本地策略，将域空间的某些部分标记为不安全。
Bogus: The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth.
伪造：验证解析程序有一个信任锚点和一个安全委托，指示子数据已签名，但由于某些原因，响应无法验证：签名缺失、签名过期、算法不受支持的签名、相关NSEC RR表示应该存在的数据缺失，等等。
Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode.
不确定：没有表示树的特定部分是安全的信任锚。这是默认的操作模式。
This specification only defines how security-aware name servers can signal non-validating stub resolvers that data was found to be bogus (using RCODE=2, "Server Failure"; see [RFC4035]).
本规范仅定义了安全感知名称服务器如何向非验证存根解析程序发出发现数据为伪造数据的信号（使用RCODE=2，“服务器故障”；请参阅[RFC4035]）。
There is a mechanism for security-aware name servers to signal security-aware stub resolvers that data was found to be secure (using the AD bit; see [RFC4035]).
安全感知名称服务器有一种机制，用于向安全感知存根解析器发出信号，表明发现数据是安全的（使用AD位；请参阅[RFC4035]）。
This specification does not define a format for communicating why responses were found to be bogus or marked as insecure. The current signaling mechanism does not distinguish between indeterminate and insecure states.
本规范未定义一种格式，用于传达为什么发现响应是虚假的或标记为不安全的。当前的信号机制不区分不确定状态和不安全状态。
A method for signaling advanced error codes and policy between a security-aware stub resolver and security-aware recursive nameservers is a topic for future work, as is the interface between a security-aware resolver and the applications that use it. Note, however, that the lack of the specification of such communication does not prohibit deployment of signed zones or the deployment of security aware recursive name servers that prohibit propagation of bogus data to the applications.
在具有安全意识的存根解析程序和具有安全意识的递归名称服务器之间发送高级错误代码和策略的方法，以及具有安全意识的解析程序和使用它的应用程序之间的接口，是未来工作的主题。但是，请注意，缺乏此类通信的规范并不禁止部署签名区域或部署安全感知递归名称服务器，这些服务器禁止向应用程序传播虚假数据。
A security-aware resolver has to be able to perform cryptographic functions necessary to verify digital signatures using at least the mandatory-to-implement algorithm(s). Security-aware resolvers must also be capable of forming an authentication chain from a newly learned zone back to an authentication key, as described above. This process might require additional queries to intermediate DNS zones to
具有安全意识的解析器必须能够执行验证数字签名所需的加密功能，至少使用强制实现算法。如上所述，具有安全意识的解析器还必须能够形成从新学到的区域到身份验证密钥的身份验证链。此过程可能需要对中间DNS区域进行其他查询，以
obtain necessary DNSKEY, DS, and RRSIG records. A security-aware resolver should be configured with at least one trust anchor as the starting point from which it will attempt to establish authentication chains.
获取必要的DNSKEY、DS和RRSIG记录。安全感知冲突解决程序应至少配置一个信任锚点，作为其尝试建立身份验证链的起点。
If a security-aware resolver is separated from the relevant authoritative name servers by a recursive name server or by any sort of intermediary device that acts as a proxy for DNS, and if the recursive name server or intermediary device is not security-aware, the security-aware resolver may not be capable of operating in a secure mode. For example, if a security-aware resolver's packets are routed through a network address translation (NAT) device that includes a DNS proxy that is not security-aware, the security-aware resolver may find it difficult or impossible to obtain or validate signed DNS data. The security-aware resolver may have a particularly difficult time obtaining DS RRs in such a case, as DS RRs do not follow the usual DNS rules for ownership of RRs at zone cuts. Note that this problem is not specific to NATs: any security-oblivious DNS software of any kind between the security-aware resolver and the authoritative name servers will interfere with DNSSEC.
如果安全感知解析程序通过递归名称服务器或充当DNS代理的任何种类的中间设备与相关权威名称服务器分离，并且如果递归名称服务器或中间设备不安全感知，则安全感知解析程序可能无法在安全模式下运行。例如，如果安全感知解析器的分组通过包括不安全感知的DNS代理的网络地址转换（NAT）设备路由，则安全感知解析器可能发现难以或不可能获得或验证签名DNS数据。在这种情况下，具有安全意识的解析器在获取DS RRs时可能特别困难，因为DS RRs在区域切割时不遵循RRs所有权的常规DNS规则。请注意，此问题并非特定于NAT：安全感知解析程序和权威名称服务器之间的任何类型的安全无关DNS软件都将干扰DNSSEC。
If a security-aware resolver must rely on an unsigned zone or a name server that is not security aware, the resolver may not be able to validate DNS responses and will need a local policy on whether to accept unverified responses.
如果具有安全意识的冲突解决程序必须依赖未签名的区域或不具有安全意识的名称服务器，则冲突解决程序可能无法验证DNS响应，并且需要本地策略来确定是否接受未验证的响应。
A security-aware resolver should take a signature's validation period into consideration when determining the TTL of data in its cache, to avoid caching signed data beyond the validity period of the signature. However, it should also allow for the possibility that the security-aware resolver's own clock is wrong. Thus, a security-aware resolver that is part of a security-aware recursive name server will have to pay careful attention to the DNSSEC "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid blocking valid signatures from getting through to other security-aware resolvers that are clients of this recursive name server. See [RFC4035] for how a secure recursive server handles queries with the CD bit set.
安全感知解析器在确定其缓存中数据的TTL时应考虑签名的验证期，以避免缓存签名数据超过签名的有效期。但是，它还应该考虑到安全感知解析器自己的时钟错误的可能性。因此，作为安全感知递归名称服务器一部分的安全感知解析器必须仔细注意DNSSEC“检查禁用”（CD）位（[RFC4034]）。这是为了避免阻止有效签名通过作为此递归名称服务器客户端的其他安全感知解析程序。请参阅[RFC4035]，了解安全递归服务器如何使用CD位集处理查询。
Although not strictly required to do so by the protocol, most DNS queries originate from stub resolvers. Stub resolvers, by definition, are minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server. Given the widespread use of stub resolvers, the DNSSEC
尽管协议没有严格要求这样做，但大多数DNS查询都源自存根解析程序。根据定义，存根解析程序是最小的DNS解析程序，使用递归查询模式将DNS解析的大部分工作卸载到递归名称服务器。鉴于存根解析器的广泛使用，DNSSEC
architecture has to take stub resolvers into account, but the security features needed in a stub resolver differ in some respects from those needed in a security-aware iterative resolver.
体系结构必须考虑存根解析器，但存根解析器所需的安全特性在某些方面与安全感知迭代解析器所需的安全特性有所不同。
Even a security-oblivious stub resolver may benefit from DNSSEC if the recursive name servers it uses are security-aware, but for the stub resolver to place any real reliance on DNSSEC services, the stub resolver must trust both the recursive name servers in question and the communication channels between itself and those name servers. The first of these issues is a local policy issue: in essence, a security-oblivious stub resolver has no choice but to place itself at the mercy of the recursive name servers that it uses, as it does not perform DNSSEC validity checks on its own. The second issue requires some kind of channel security mechanism; proper use of DNS transaction authentication mechanisms such as SIG(0) ([RFC2931]) or TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec. Particular implementations may have other choices available, such as operating system specific interprocess communication mechanisms. Confidentiality is not needed for this channel, but data integrity and message authentication are.
如果存根解析程序使用的递归名称服务器具有安全意识，则即使是不考虑安全性的存根解析程序也可能受益于DNSSEC，但为了使存根解析程序真正依赖于DNSSEC服务，存根解析程序必须信任相关的递归名称服务器以及自身与这些名称服务器之间的通信通道。这些问题中的第一个是本地策略问题：本质上，不考虑安全性的存根解析器别无选择，只能将自己置于它所使用的递归名称服务器的支配之下，因为它自己不执行DNSSEC有效性检查。第二个问题需要某种渠道安全机制；正确使用DNS事务身份验证机制（如SIG（0）（[RFC2931]）或TSIG（[RFC2845]）就足够了，适当使用IPsec也足够了。特定的实现可能有其他可用的选择，例如特定于操作系统的进程间通信机制。此通道不需要保密性，但需要数据完整性和消息身份验证。
A security-aware stub resolver that does trust both its recursive name servers and its communication channel to them may choose to examine the setting of the Authenticated Data (AD) bit in the message header of the response messages it receives. The stub resolver can use this flag bit as a hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response.
信任其递归名称服务器及其通信通道的安全感知存根解析器可以选择检查其接收的响应消息的消息头中的身份验证数据（AD）位的设置。存根解析器可以使用此标志位作为提示，以确定递归名称服务器是否能够验证响应的应答和授权部分中所有数据的签名。
There is one more step that a security-aware stub resolver can take if, for whatever reason, it is not able to establish a useful trust relationship with the recursive name servers that it uses: it can perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages. A validating stub resolver is thus able to treat the DNSSEC signatures as trust relationships between the zone administrators and the stub resolver itself.
如果出于任何原因，安全感知存根解析器无法与它使用的递归名称服务器建立有用的信任关系，那么它还可以采取另一个步骤：它可以通过在查询消息中设置Checking Disabled（CD）位来执行自己的签名验证。因此，验证存根解析程序能够将DNSSEC签名视为区域管理员和存根解析程序本身之间的信任关系。
There are several differences between signed and unsigned zones. A signed zone will contain additional security-related records (RRSIG, DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be generated by a signing process prior to serving the zone. The RRSIG records that accompany zone data have defined inception and expiration times that establish a validity period for the signatures and the zone data the signatures cover.
有符号区域和无符号区域之间存在一些差异。签名区域将包含其他安全相关记录（RRSIG、DNSKEY、DS和NSEC记录）。RRSIG和NSEC记录可以在为区域服务之前通过签名过程生成。区域数据附带的RRSIG记录定义了起始时间和到期时间，为签名和签名覆盖的区域数据建立了有效期。
It is important to note the distinction between a RRset's TTL value and the signature validity period specified by the RRSIG RR covering that RRset. DNSSEC does not change the definition or function of the TTL value, which is intended to maintain database coherency in caches. A caching resolver purges RRsets from its cache no later than the end of the time period specified by the TTL fields of those RRsets, regardless of whether the resolver is security-aware.
必须注意RRset的TTL值与覆盖该RRset的RRSIG RR指定的签名有效期之间的区别。DNSSEC不会更改TTL值的定义或功能，TTL值旨在维护缓存中的数据库一致性。缓存冲突解决程序在不晚于由这些RRSET的TTL字段指定的时间段结束之前从其缓存中清除RRSET，而不管冲突解决程序是否具有安全意识。
The inception and expiration fields in the RRSIG RR ([RFC4034]), on the other hand, specify the time period during which the signature can be used to validate the covered RRset. The signatures associated with signed zone data are only valid for the time period specified by these fields in the RRSIG RRs in question. TTL values cannot extend the validity period of signed RRsets in a resolver's cache, but the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL of the signed RRset and its associated RRSIG RR in the resolver's cache.
另一方面，RRSIG RR（[RFC4034]）中的起始和到期字段指定了签名可用于验证覆盖RRset的时间段。与签名区域数据相关联的签名仅在相关RRSIG RRs中这些字段指定的时间段内有效。TTL值无法延长冲突解决程序缓存中已签名RRset的有效期，但冲突解决程序可以使用已签名RRset的签名有效期到期前的剩余时间作为已签名RRset的TTL以及冲突解决程序缓存中与其关联的RRSIG RR的上限。
Information in a signed zone has a temporal dependency that did not exist in the original DNS protocol. A signed zone requires regular maintenance to ensure that each RRset in the zone has a current valid RRSIG RR. The signature validity period of an RRSIG RR is an interval during which the signature for one particular signed RRset can be considered valid, and the signatures of different RRsets in a zone may expire at different times. Re-signing one or more RRsets in a zone will change one or more RRSIG RRs, which will in turn require incrementing the zone's SOA serial number to indicate that a zone change has occurred and re-signing the SOA RRset itself. Thus, re-signing any RRset in a zone may also trigger DNS NOTIFY messages and zone transfer operations.
签名区域中的信息具有原始DNS协议中不存在的临时依赖关系。签名区域需要定期维护，以确保区域中的每个RRset都具有当前有效的RRSIG RR。RRSIG RR的签名有效期是一个间隔，在此期间，一个特定签名RRset的签名可以被视为有效，并且一个区域中不同RRset的签名可能在不同的时间过期。对一个区域中的一个或多个RRset重新签名将更改一个或多个RRSIG RRs，这反过来需要增加该区域的SOA序列号，以指示发生了区域更改，并对SOA RRset本身重新签名。因此，对区域中的任何RRset重新签名也可能触发DNS NOTIFY消息和区域传输操作。
A security-aware name server should include the appropriate DNSSEC records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries from resolvers that have signaled their willingness to receive such records via use of the DO bit in the EDNS header, subject to message size limitations. Because inclusion of these DNSSEC RRs could easily cause UDP message truncation and fallback to TCP, a security-aware name server must also support the EDNS "sender's UDP payload" mechanism.
具有安全意识的名称服务器应在对来自解析程序的查询的所有响应中包含适当的DNSSEC记录（RRSIG、DNSKEY、DS和NSEC），这些解析程序已表示愿意通过使用EDNS标头中的DO位接收此类记录，但要遵守消息大小限制。由于包含这些DNSSEC RRs很容易导致UDP消息截断并回退到TCP，因此具有安全意识的名称服务器还必须支持EDNS“发送方的UDP有效负载”机制。
If possible, the private half of each DNSSEC key pair should be kept offline, but this will not be possible for a zone for which DNS dynamic update has been enabled. In the dynamic update case, the primary master server for the zone will have to re-sign the zone when it is updated, so the private key corresponding to the zone signing key will have to be kept online. This is an example of a situation in which the ability to separate the zone's DNSKEY RRset into zone signing key(s) and key signing key(s) may be useful, as the key signing key(s) in such a case can still be kept offline and may have a longer useful lifetime than the zone signing key(s).
如果可能，每个DNSSEC密钥对的私有部分应保持脱机，但对于已启用DNS动态更新的区域，这将不可能。在动态更新情况下，区域的主主服务器必须在更新区域时对其重新签名，因此与区域签名密钥对应的私钥必须保持在线。这是将区域的DNSKEY RRset分离为区域签名密钥和密钥签名密钥的能力可能有用的情况的示例，因为在这种情况下，密钥签名密钥仍然可以保持脱机状态，并且可能比区域签名密钥具有更长的使用寿命。
By itself, DNSSEC is not enough to protect the integrity of an entire zone during zone transfer operations, as even a signed zone contains some unsigned, nonauthoritative data if the zone has any children. Therefore, zone maintenance operations will require some additional mechanisms (most likely some form of channel security, such as TSIG, SIG(0), or IPsec).
DNSSEC本身不足以在区域传输操作期间保护整个区域的完整性，因为即使是已签名的区域也包含一些未签名的非授权数据（如果该区域有任何子级）。因此，区域维护操作将需要一些额外的机制（很可能是某种形式的通道安全性，如TSIG、SIG（0）或IPsec）。
The DNSSEC document set can be partitioned into several main groups, under the larger umbrella of the DNS base protocol documents.
DNSSEC文档集可以在DNS基本协议文档的大范围下划分为几个主要组。
The "DNSSEC protocol document set" refers to the three documents that form the core of the DNS security extensions:
“DNSSEC协议文档集”是指构成DNS安全扩展核心的三个文档：
1. DNS Security Introduction and Requirements (this document)
1. DNS安全介绍和要求（本文档）
2. Resource Records for DNS Security Extensions [RFC4034]
2. DNS安全扩展的资源记录[RFC4034]
3. Protocol Modifications for the DNS Security Extensions [RFC4035]
3. DNS安全扩展的协议修改[RFC4035]
Additionally, any document that would add to or change the core DNS Security extensions would fall into this category. This includes any future work on the communication between security-aware stub resolvers and upstream security-aware recursive name servers.
此外，任何添加或更改核心DNS安全扩展的文档都属于此类别。这包括将来关于安全感知存根解析器和上游安全感知递归名称服务器之间通信的任何工作。
The "Digital Signature Algorithm Specification" document set refers to the group of documents that describe how specific digital signature algorithms should be implemented to fit the DNSSEC resource record format. Each document in this set deals with a specific digital signature algorithm. Please see the appendix on "DNSSEC Algorithm and Digest Types" in [RFC4034] for a list of the algorithms that were defined when this core specification was written.
“数字签名算法规范”文档集是指一组文档，这些文档描述了应如何实现特定的数字签名算法以适应DNSSEC资源记录格式。此集合中的每个文档都处理特定的数字签名算法。请参阅[RFC4034]中关于“DNSSEC算法和摘要类型”的附录，了解编写本核心规范时定义的算法列表。
The "Transaction Authentication Protocol" document set refers to the group of documents that deal with DNS message authentication, including secret key establishment and verification. Although not
“事务认证协议”文档集是指处理DNS消息认证的一组文档，包括密钥建立和验证。虽然不是
strictly part of the DNSSEC specification as defined in this set of documents, this group is noted because of its relationship to DNSSEC.
严格地说，这是本套文件中定义的DNSSEC规范的一部分，由于其与DNSSEC的关系，该组被注明。
The final document set, "New Security Uses", refers to documents that seek to use proposed DNS Security extensions for other security related purposes. DNSSEC does not provide any direct security for these new uses but may be used to support them. Documents that fall in this category include those describing the use of DNS in the storage and distribution of certificates ([RFC2538]).
最后一个文档集“New Security Uses”（新安全使用）指的是寻求将建议的DNS安全扩展用于其他安全相关目的的文档。DNSSEC不为这些新用途提供任何直接安全性，但可用于支持这些用途。属于这一类别的文档包括描述在证书的存储和分发中使用DNS的文档（[RFC2538]）。
This overview document introduces no new IANA considerations. Please see [RFC4034] for a complete review of the IANA considerations introduced by DNSSEC.
本概述文档没有介绍新的IANA注意事项。请参阅[RFC4034]以了解DNSSEC引入的IANA注意事项的完整审查。
This document introduces DNS security extensions and describes the document set that contains the new security records and DNS protocol modifications. The extensions provide data origin authentication and data integrity using digital signatures over resource record sets. This section discusses the limitations of these extensions.
本文档介绍DNS安全扩展，并描述包含新安全记录和DNS协议修改的文档集。这些扩展使用资源记录集上的数字签名提供数据源身份验证和数据完整性。本节讨论这些扩展的局限性。
In order for a security-aware resolver to validate a DNS response, all zones along the path from the trusted starting point to the zone containing the response zones must be signed, and all name servers and resolvers involved in the resolution process must be security-aware, as defined in this document set. A security-aware resolver cannot verify responses originating from an unsigned zone, from a zone not served by a security-aware name server, or for any DNS data that the resolver is only able to obtain through a recursive name server that is not security-aware. If there is a break in the authentication chain such that a security-aware resolver cannot obtain and validate the authentication keys it needs, then the security-aware resolver cannot validate the affected DNS data.
为了使具有安全意识的解析程序验证DNS响应，必须对从受信任起点到包含响应区域的区域的路径上的所有区域进行签名，并且解析过程中涉及的所有名称服务器和解析程序都必须具有安全意识，如本文档集中所定义。安全感知冲突解决程序无法验证来自未签名区域、来自未由安全感知名称服务器提供服务的区域的响应，或者对于冲突解决程序只能通过不安全感知的递归名称服务器获取的任何DNS数据的响应。如果身份验证链中出现中断，导致安全感知解析器无法获取和验证其所需的身份验证密钥，则安全感知解析器无法验证受影响的DNS数据。
This document briefly discusses other methods of adding security to a DNS query, such as using a channel secured by IPsec or using a DNS transaction authentication mechanism such as TSIG ([RFC2845]) or SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC per se.
本文档简要讨论了向DNS查询添加安全性的其他方法，例如使用IPsec保护的通道或使用DNS事务身份验证机制，如TSIG（[RFC2845]）或SIG（0）（[RFC2931]），但事务安全性本身不是DNSSEC的一部分。
A non-validating security-aware stub resolver, by definition, does not perform DNSSEC signature validation on its own and thus is vulnerable both to attacks on (and by) the security-aware recursive name servers that perform these checks on its behalf and to attacks on its communication with those security-aware recursive name
根据定义，非验证性安全感知的存根解析器本身不执行DNSSEC签名验证，因此容易受到代表其执行这些检查的安全感知递归名称服务器（和由其）上的攻击以及与这些安全感知递归名称的通信上的攻击
servers. Non-validating security-aware stub resolvers should use some form of channel security to defend against the latter threat. The only known defense against the former threat would be for the security-aware stub resolver to perform its own signature validation, at which point, again by definition, it would no longer be a non-validating security-aware stub resolver.
服务器。非验证安全感知的存根解析器应该使用某种形式的通道安全来防御后一种威胁。针对前一种威胁的唯一已知防御措施是安全感知存根解析器执行自己的签名验证，在这一点上，根据定义，它将不再是非验证安全感知存根解析器。
DNSSEC does not protect against denial of service attacks. DNSSEC makes DNS vulnerable to a new class of denial of service attacks based on cryptographic operations against security-aware resolvers and security-aware name servers, as an attacker can attempt to use DNSSEC mechanisms to consume a victim's resources. This class of attacks takes at least two forms. An attacker may be able to consume resources in a security-aware resolver's signature validation code by tampering with RRSIG RRs in response messages or by constructing needlessly complex signature chains. An attacker may also be able to consume resources in a security-aware name server that supports DNS dynamic update, by sending a stream of update messages that force the security-aware name server to re-sign some RRsets in the zone more frequently than would otherwise be necessary.
DNSSEC不针对拒绝服务攻击提供保护。DNSSEC使DNS容易受到基于针对安全感知解析程序和安全感知名称服务器的加密操作的一类新的拒绝服务攻击，因为攻击者可以尝试使用DNSSEC机制来消耗受害者的资源。这类攻击至少有两种形式。攻击者可以通过篡改响应消息中的RRSIG RRs或通过构造不必要的复杂签名链来消耗安全感知解析器签名验证代码中的资源。攻击者还可以通过发送更新消息流来消耗支持DNS动态更新的安全感知名称服务器中的资源，这些更新消息流迫使安全感知名称服务器比其他情况下更频繁地重新签署区域中的某些RRSET。
Due to a deliberate design choice, DNSSEC does not provide confidentiality.
由于有意选择设计，DNSSEC不提供保密信息。
DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to obtain all the names in a zone. Although this is not an attack on the DNS itself, it could allow an attacker to map network hosts or other resources by enumerating the contents of a zone.
DNSSEC引入了敌对方通过遵循NSEC链枚举区域中所有名称的能力。NSEC RRs通过沿区域内所有名称的规范顺序从现有名称链接到现有名称来断言区域中不存在的名称。因此，攻击者可以按顺序查询这些NSEC RRs，以获取区域中的所有名称。虽然这不是对DNS本身的攻击，但它可能允许攻击者通过枚举区域的内容来映射网络主机或其他资源。
DNSSEC introduces significant additional complexity to the DNS and thus introduces many new opportunities for implementation bugs and misconfigured zones. In particular, enabling DNSSEC signature validation in a resolver may cause entire legitimate zones to become effectively unreachable due to DNSSEC configuration errors or bugs.
DNSSEC为DNS带来了显著的额外复杂性，从而为实现错误和错误配置区域带来了许多新机会。特别是，在解析器中启用DNSSEC签名验证可能会由于DNSSEC配置错误或bug而导致整个合法区域实际上无法访问。
DNSSEC does not protect against tampering with unsigned zone data. Non-authoritative data at zone cuts (glue and NS RRs in the parent zone) are not signed. This does not pose a problem when validating the authentication chain, but it does mean that the non-authoritative data itself is vulnerable to tampering during zone transfer operations. Thus, while DNSSEC can provide data origin authentication and data integrity for RRsets, it cannot do so for zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be used to protect zone transfer operations.
DNSSEC不能防止篡改未签名区域数据。区域切割处的非权威数据（父区域中的粘合和NS RRs）未签名。这在验证身份验证链时不会造成问题，但它确实意味着非权威数据本身在区域传输操作期间容易受到篡改。因此，虽然DNSSEC可以为RRSET提供数据源身份验证和数据完整性，但不能为区域提供数据源身份验证和数据完整性，必须使用其他机制（如TSIG、SIG（0）或IPsec）来保护区域传输操作。
Please see [RFC4034] and [RFC4035] for additional security considerations.
有关其他安全注意事项，请参阅[RFC4034]和[RFC4035]。
This document was created from the input and ideas of the members of the DNS Extensions Working Group. Although explicitly listing everyone who has contributed during the decade in which DNSSEC has been under development would be impossible, the editors would particularly like to thank the following people for their contributions to and comments on this document set: Jaap Akkerhuis, Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and Suzanne Woolf.
本文档是根据DNS扩展工作组成员的输入和想法创建的。虽然不可能明确列出在DNSSEC开发的十年中做出贡献的所有人，但编辑们特别要感谢以下人士对本文件集的贡献和评论：雅普·阿克胡伊斯、马克·安德鲁斯、德里克·阿特金斯、罗伊·巴达米、艾伦·巴雷特、，丹·伯恩斯坦、大卫·布莱克、伦·布德尼、兰迪·布什、弗朗西斯·杜邦、唐纳德·伊斯特莱克、罗伯特·埃尔兹、米克·吉本、迈克尔·格拉夫、奥拉弗尔·古德蒙德森、吉勒斯·盖特、安德烈亚斯·古斯塔夫松、伊藤俊一郎·哈吉诺、菲利普·哈拉姆·贝克、鲍勃·哈雷、泰德·哈迪、沃尔特·霍华德、格雷格·哈德森、克里斯蒂安·惠特马、约翰·伊伦、斯蒂芬·雅各布、杰尔特·詹森、，西蒙·约瑟夫森、安德里斯·卡尔诺佐尔斯、彼得·科赫、奥拉夫·科尔克曼、马克·科斯特斯、苏雷什·克里希纳斯瓦米、本·劳里、大卫·劳伦斯、特德·莱蒙、埃德·刘易斯、特德·林德格林、乔什·利特菲尔德、里普·卢米斯、比尔·曼宁、罗斯·蒙迪、托马斯·纳顿、曼斯·尼尔森、马萨塔卡·奥塔、迈克·巴顿、罗布·佩恩、吉姆·里德、迈克尔·理查森、埃里克·罗森达尔、马科斯·桑兹、，佩卡·萨沃拉、雅各布·施莱特、迈克·斯特约翰斯、保罗·维克西、萨姆·韦勒、布赖恩·惠灵顿和苏珊娜·伍尔夫。
No doubt the above list is incomplete. We apologize to anyone we left out.
毫无疑问，上述清单是不完整的。我们向遗漏的任何人道歉。
[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月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]Conrad，D.“指示DNSSEC的分解器支持”，RFC 3225，2001年12月。
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
[RFC3226]Gudmundsson，O.，“DNSSEC和IPv6 A6感知服务器/解析器消息大小要求”，RFC 3226，2001年12月。
[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月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for 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月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2538]Eastlake 3rd，D.和O.Gudmundsson，“在域名系统（DNS）中存储证书”，RFC 2538，1999年3月。
[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月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake 3rd，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000.
[RFC3008]惠灵顿，B.，“域名系统安全（DNSSEC）签名机构”，RFC3008，2000年11月。
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.
[RFC3090]Lewis，E.“关于区域状态的DNS安全扩展澄清”，RFC 3090，2001年3月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3655]Wellington，B.和O.Gudmundsson，“DNS认证数据（AD）位的重新定义”，RFC 3655，2003年11月。
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[RFC3658]Gudmundsson，O.“委托签署人（DS）资源记录（RR）”，RFC3658，2003年12月。
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[RFC3755]Weiler，S.“委托签名者（DS）的传统解析器兼容性”，RFC 3755，2004年5月。
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, April 2004.
[RFC3757]Kolkman，O.，Schlyter，J.，和E.Lewis，“域名系统密钥（DNSKEY）资源记录（RR）安全入口点（SEP）标志”，RFC 3757，2004年4月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format", RFC 3845, August 2004.
[RFC3845]Schlyter，J.，“DNS安全（DNSSEC）下一代安全（NSEC）RDATA格式”，RFC 38452004年8月。
Authors' Addresses
作者地址
Roy Arends Telematica Instituut Brouwerijstraat 1 7523 XC Enschede NL
Roy Arends远程信息处理研究所Brouwerijstraat 1 7523 XC Enschede NL
EMail: roy.arends@telin.nl
EMail: roy.arends@telin.nl
Rob Austein Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
Rob Austein互联网系统联合会950 Charter Street Redwood City，加利福尼亚州94063
EMail: sra@isc.org
EMail: sra@isc.org
Matt Larson VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Matt Larson VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: mlarson@verisign.com
EMail: mlarson@verisign.com
Dan Massey Colorado State University Department of Computer Science Fort Collins, CO 80523-1873
Dan Massey科罗拉多州立大学计算机科学系科罗拉多州科林斯堡80523-1873
EMail: massey@cs.colostate.edu
EMail: massey@cs.colostate.edu
Scott Rose National Institute for Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899-8920 USA
斯科特·罗斯国家标准与技术研究所美国马里兰州盖瑟斯堡100号局道20899-8920
EMail: scott.rose@nist.gov
EMail: scott.rose@nist.gov
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。