Network Working Group D. Eastlake
Request for Comments: 2535 IBM
Obsoletes: 2065 March 1999
Updates: 2181, 1035, 1034
Category: Standards Track
Network Working Group D. Eastlake
Request for Comments: 2535 IBM
Obsoletes: 2065 March 1999
Updates: 2181, 1035, 1034
Category: Standards Track
Domain Name System Security Extensions
域名系统安全扩展
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases.
描述了域名系统（DNS）的扩展，该扩展通过使用加密数字签名向具有安全意识的解析器和应用程序提供数据完整性和身份验证。这些数字签名作为资源记录包含在安全区域中。在某些情况下，还可以通过无安全意识的DNS服务器提供安全性。
The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
扩展用于在DNS中存储经过身份验证的公钥。这种密钥存储可以支持通用公钥分发服务以及DNS安全性。存储的密钥使安全感知解析程序能够学习除初始配置区域外的区域的身份验证密钥。可以检索与DNS名称关联的密钥以支持其他协议。规定了各种密钥类型和算法。
In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.
此外，安全扩展还提供了DNS协议事务和请求的可选身份验证。
This document incorporates feedback on RFC 2065 from early implementers and potential users.
本文档包含了早期实施者和潜在用户对RFC 2065的反馈。
Acknowledgments
致谢
The significant contributions and suggestions of the following persons (in alphabetic order) to DNS security are gratefully acknowledged:
感谢以下人员（按字母顺序）对DNS安全的重要贡献和建议：
James M. Galvin John Gilmore Olafur Gudmundsson Charlie Kaufman Edward Lewis Thomas Narten Radia J. Perlman Jeffrey I. Schiller Steven (Xunhua) Wang Brian Wellington
詹姆斯·M·加尔文·约翰·吉尔莫·奥拉福尔·古德蒙德森·查理·考夫曼·爱德华·刘易斯·托马斯·纳腾·拉迪亚·J·帕尔曼·杰弗里·席勒·史蒂文（循化）王布莱恩·惠灵顿
Table of Contents
目录
Abstract...................................................1
Acknowledgments............................................2
1. Overview of Contents....................................4
2. Overview of the DNS Extensions..........................5
2.1 Services Not Provided..................................5
2.2 Key Distribution.......................................5
2.3 Data Origin Authentication and Integrity...............6
2.3.1 The SIG Resource Record..............................7
2.3.2 Authenticating Name and Type Non-existence...........7
2.3.3 Special Considerations With Time-to-Live.............7
2.3.4 Special Considerations at Delegation Points..........8
2.3.5 Special Considerations with CNAME....................8
2.3.6 Signers Other Than The Zone..........................9
2.4 DNS Transaction and Request Authentication.............9
3. The KEY Resource Record................................10
3.1 KEY RDATA format......................................10
3.1.1 Object Types, DNS Names, and Keys...................11
3.1.2 The KEY RR Flag Field...............................11
3.1.3 The Protocol Octet..................................13
3.2 The KEY Algorithm Number Specification................14
3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
3.4 Determination of Zone Secure/Unsecured Status.........15
3.5 KEY RRs in the Construction of Responses..............17
4. The SIG Resource Record................................17
4.1 SIG RDATA Format......................................17
4.1.1 Type Covered Field..................................18
4.1.2 Algorithm Number Field..............................18
4.1.3 Labels Field........................................18
4.1.4 Original TTL Field..................................19
Abstract...................................................1
Acknowledgments............................................2
1. Overview of Contents....................................4
2. Overview of the DNS Extensions..........................5
2.1 Services Not Provided..................................5
2.2 Key Distribution.......................................5
2.3 Data Origin Authentication and Integrity...............6
2.3.1 The SIG Resource Record..............................7
2.3.2 Authenticating Name and Type Non-existence...........7
2.3.3 Special Considerations With Time-to-Live.............7
2.3.4 Special Considerations at Delegation Points..........8
2.3.5 Special Considerations with CNAME....................8
2.3.6 Signers Other Than The Zone..........................9
2.4 DNS Transaction and Request Authentication.............9
3. The KEY Resource Record................................10
3.1 KEY RDATA format......................................10
3.1.1 Object Types, DNS Names, and Keys...................11
3.1.2 The KEY RR Flag Field...............................11
3.1.3 The Protocol Octet..................................13
3.2 The KEY Algorithm Number Specification................14
3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
3.4 Determination of Zone Secure/Unsecured Status.........15
3.5 KEY RRs in the Construction of Responses..............17
4. The SIG Resource Record................................17
4.1 SIG RDATA Format......................................17
4.1.1 Type Covered Field..................................18
4.1.2 Algorithm Number Field..............................18
4.1.3 Labels Field........................................18
4.1.4 Original TTL Field..................................19
4.1.5 Signature Expiration and Inception Fields...........19
4.1.6 Key Tag Field.......................................20
4.1.7 Signer's Name Field.................................20
4.1.8 Signature Field.....................................20
4.1.8.1 Calculating Transaction and Request SIGs..........21
4.2 SIG RRs in the Construction of Responses..............21
4.3 Processing Responses and SIG RRs......................22
4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
5. Non-existent Names and Types...........................24
5.1 The NXT Resource Record...............................24
5.2 NXT RDATA Format......................................25
5.3 Additional Complexity Due to Wildcards................26
5.4 Example...............................................26
5.5 Special Considerations at Delegation Points...........27
5.6 Zone Transfers........................................27
5.6.1 Full Zone Transfers.................................28
5.6.2 Incremental Zone Transfers..........................28
6. How to Resolve Securely and the AD and CD Bits.........29
6.1 The AD and CD Header Bits.............................29
6.2 Staticly Configured Keys..............................31
6.3 Chaining Through The DNS..............................31
6.3.1 Chaining Through KEYs...............................31
6.3.2 Conflicting Data....................................33
6.4 Secure Time...........................................33
7. ASCII Representation of Security RRs...................34
7.1 Presentation of KEY RRs...............................34
7.2 Presentation of SIG RRs...............................35
7.3 Presentation of NXT RRs...............................36
8. Canonical Form and Order of Resource Records...........36
8.1 Canonical RR Form.....................................36
8.2 Canonical DNS Name Order..............................37
8.3 Canonical RR Ordering Within An RRset.................37
8.4 Canonical Ordering of RR Types........................37
9. Conformance............................................37
9.1 Server Conformance....................................37
9.2 Resolver Conformance..................................38
10. Security Considerations...............................38
11. IANA Considerations...................................39
References................................................39
Author's Address..........................................41
Appendix A: Base 64 Encoding..............................42
Appendix B: Changes from RFC 2065.........................44
Appendix C: Key Tag Calculation...........................46
Full Copyright Statement..................................47
4.1.5 Signature Expiration and Inception Fields...........19
4.1.6 Key Tag Field.......................................20
4.1.7 Signer's Name Field.................................20
4.1.8 Signature Field.....................................20
4.1.8.1 Calculating Transaction and Request SIGs..........21
4.2 SIG RRs in the Construction of Responses..............21
4.3 Processing Responses and SIG RRs......................22
4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
5. Non-existent Names and Types...........................24
5.1 The NXT Resource Record...............................24
5.2 NXT RDATA Format......................................25
5.3 Additional Complexity Due to Wildcards................26
5.4 Example...............................................26
5.5 Special Considerations at Delegation Points...........27
5.6 Zone Transfers........................................27
5.6.1 Full Zone Transfers.................................28
5.6.2 Incremental Zone Transfers..........................28
6. How to Resolve Securely and the AD and CD Bits.........29
6.1 The AD and CD Header Bits.............................29
6.2 Staticly Configured Keys..............................31
6.3 Chaining Through The DNS..............................31
6.3.1 Chaining Through KEYs...............................31
6.3.2 Conflicting Data....................................33
6.4 Secure Time...........................................33
7. ASCII Representation of Security RRs...................34
7.1 Presentation of KEY RRs...............................34
7.2 Presentation of SIG RRs...............................35
7.3 Presentation of NXT RRs...............................36
8. Canonical Form and Order of Resource Records...........36
8.1 Canonical RR Form.....................................36
8.2 Canonical DNS Name Order..............................37
8.3 Canonical RR Ordering Within An RRset.................37
8.4 Canonical Ordering of RR Types........................37
9. Conformance............................................37
9.1 Server Conformance....................................37
9.2 Resolver Conformance..................................38
10. Security Considerations...............................38
11. IANA Considerations...................................39
References................................................39
Author's Address..........................................41
Appendix A: Base 64 Encoding..............................42
Appendix B: Changes from RFC 2065.........................44
Appendix C: Key Tag Calculation...........................46
Full Copyright Statement..................................47
This document standardizes extensions of the Domain Name System (DNS) protocol to support DNS security and public key distribution. It assumes that the reader is familiar with the Domain Name System, particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An earlier version of these extensions appears in RFC 2065. This replacement for that RFC incorporates early implementation experience and requests from potential users.
本文档标准化了域名系统（DNS）协议的扩展，以支持DNS安全和公钥分发。它假设读者熟悉域名系统，特别是如RFCs 1033、1034、1035和更高版本RFCs中所述。这些扩展的早期版本出现在RFC2065中。该RFC的替代品结合了早期实施经验和潜在用户的请求。
Section 2 provides an overview of the extensions and the key distribution, data origin authentication, and transaction and request security they provide.
第2节概述了扩展及其提供的密钥分发、数据源身份验证以及事务和请求安全性。
Section 3 discusses the KEY resource record, its structure, and use in DNS responses. These resource records represent the public keys of entities named in the DNS and are used for key distribution.
第3节讨论了密钥资源记录、其结构以及在DNS响应中的使用。这些资源记录表示DNS中命名的实体的公钥，用于密钥分发。
Section 4 discusses the SIG digital signature resource record, its structure, and use in DNS responses. These resource records are used to authenticate other resource records in the DNS and optionally to authenticate DNS transactions and requests.
第4节讨论SIG数字签名资源记录、其结构以及在DNS响应中的使用。这些资源记录用于验证DNS中的其他资源记录，并可选地验证DNS事务和请求。
Section 5 discusses the NXT resource record (RR) and its use in DNS responses including full and incremental zone transfers. The NXT RR permits authenticated denial of the existence of a name or of an RR type for an existing name.
第5节讨论了NXT资源记录（RR）及其在DNS响应中的使用，包括完整和增量区域传输。NXT RR允许通过身份验证拒绝存在名称或现有名称的RR类型。
Section 6 discusses how a resolver can be configured with a starting key or keys and proceed to securely resolve DNS requests. Interactions between resolvers and servers are discussed for various combinations of security aware and security non-aware. Two additional DNS header bits are defined for signaling between resolvers and servers.
第6节讨论如何使用一个或多个启动密钥配置解析器，并继续安全地解析DNS请求。针对安全感知和安全非感知的各种组合，讨论了解析器和服务器之间的交互。为解析程序和服务器之间的信令定义了两个额外的DNS头位。
Section 7 describes the ASCII representation of the security resource records for use in master files and elsewhere.
第7节描述了在主文件和其他地方使用的安全资源记录的ASCII表示。
Section 8 defines the canonical form and order of RRs for DNS security purposes.
第8节定义了用于DNS安全目的的RRs的规范形式和顺序。
Section 9 defines levels of conformance for resolvers and servers.
第9节定义了解析程序和服务器的一致性级别。
Section 10 provides a few paragraphs on overall security considerations.
第10节提供了关于总体安全考虑的几个段落。
Section 11 specified IANA considerations for allocation of additional values of paramters defined in this document.
第11节规定了本文件中定义的参数附加值分配的IANA注意事项。
Appendix A gives details of base 64 encoding which is used in the file representation of some RRs defined in this document.
附录A给出了在本文件中定义的一些RRs的文件表示中使用的base 64编码的详细信息。
Appendix B summarizes changes between this memo and RFC 2065.
附录B总结了本备忘录与RFC 2065之间的变更。
Appendix C specified how to calculate the simple checksum used as a key tag in most SIG RRs.
附录C规定了如何计算大多数SIG RRs中用作键标记的简单校验和。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The Domain Name System (DNS) protocol security extensions provide three distinct services: key distribution as described in Section 2.2 below, data origin authentication as described in Section 2.3 below, and transaction and request authentication, described in Section 2.4 below.
域名系统（DNS）协议安全扩展提供三种不同的服务：下文第2.2节所述的密钥分发、下文第2.3节所述的数据源身份验证以及下文第2.4节所述的交易和请求身份验证。
Special considerations related to "time to live", CNAMEs, and delegation points are also discussed in Section 2.3.
第2.3节还讨论了与“生存时间”、CNAMEs和授权点相关的特殊注意事项。
It is part of the design philosophy of the DNS that the data in it is public and that the DNS gives the same answers to all inquirers. Following this philosophy, no attempt has been made to include any sort of access control lists or other means to differentiate inquirers.
DNS设计理念的一部分是，其中的数据是公开的，并且DNS向所有查询者提供相同的答案。遵循这一理念，没有试图包括任何类型的访问控制列表或其他方式来区分查询者。
No effort has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC [RFC 2401], TLS, or other security protocols.)
未做出任何努力为查询或回复提供任何保密。（此服务可通过IPSEC[RFC 2401]、TLS或其他安全协议提供。）
Protection is not provided against denial of service.
未提供针对拒绝服务的保护。
A resource record format is defined to associate keys with DNS names. This permits the DNS to be used as a public key distribution mechanism in support of DNS security itself and other protocols.
资源记录格式定义为将密钥与DNS名称关联。这允许DNS用作公钥分发机制，以支持DNS安全本身和其他协议。
The syntax of a KEY resource record (RR) is described in Section 3. It includes an algorithm identifier, the actual public key parameter(s), and a variety of flags including those indicating the type of entity the key is associated with and/or asserting that there is no key associated with that entity.
第3节描述了密钥资源记录（RR）的语法。它包括算法标识符、实际公钥参数和各种标志，包括指示密钥关联的实体类型和/或断言没有与该实体关联的密钥的标志。
Under conditions described in Section 3.5, security aware DNS servers will automatically attempt to return KEY resources as additional information, along with those resource records actually requested, to minimize the number of queries needed.
在第3.5节所述的条件下，安全感知DNS服务器将自动尝试返回关键资源作为附加信息，以及实际请求的资源记录，以尽量减少所需的查询数量。
Authentication is provided by associating with resource record sets (RRsets [RFC 2181]) in the DNS cryptographically generated digital signatures. Commonly, there will be a single private key that authenticates an entire zone but there might be multiple keys for different algorithms, signers, etc. If a security aware resolver reliably learns a public key of the zone, it can authenticate, for signed data read from that zone, that it is properly authorized. The most secure implementation is for the zone private key(s) to be kept off-line and used to re-sign all of the records in the zone periodically. However, there are cases, for example dynamic update [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC 2541].
通过与DNS加密生成的数字签名中的资源记录集（RRsets[RFC 2181]）关联来提供身份验证。通常，将有一个单独的私钥对整个区域进行身份验证，但可能有多个密钥用于不同的算法、签名者等。如果安全感知解析器可靠地学习到该区域的公钥，则它可以对从该区域读取的签名数据进行身份验证，以确保其得到正确授权。最安全的实现是使区域私钥保持脱机状态，并用于定期对区域中的所有记录进行重新签名。然而，在某些情况下，例如动态更新[RFCs 2136、2137]，DNS私钥需要在线[RFC 2541]。
The data origin authentication key(s) are associated with the zone and not with the servers that store copies of the data. That means compromise of a secondary server or, if the key(s) are kept off line, even the primary server for a zone, will not necessarily affect the degree of assurance that a resolver has that it can determine whether data is genuine.
数据源身份验证密钥与区域关联，而不是与存储数据副本的服务器关联。这意味着，如果密钥处于脱机状态，即使是区域的主服务器，也不一定会影响解析程序确定数据是否真实的保证程度。
A resolver could learn a public key of a zone either by reading it from the DNS or by having it staticly configured. To reliably learn a public key by reading it from the DNS, the key itself must be signed with a key the resolver trusts. The resolver must be configured with at least a public key which authenticates one zone as a starting point. From there, it can securely read public keys of other zones, if the intervening zones in the DNS tree are secure and their signed keys accessible.
解析程序可以通过从DNS读取或静态配置区域公钥来学习该区域的公钥。要通过从DNS读取公钥来可靠地学习公钥，必须使用解析程序信任的密钥对密钥本身进行签名。冲突解决程序必须至少配置一个公钥，该公钥将一个区域作为起点进行身份验证。从那里，它可以安全地读取其他区域的公钥，前提是DNS树中的中间区域是安全的，并且可以访问它们的签名密钥。
Adding data origin authentication and integrity requires no change to the "on-the-wire" DNS protocol beyond the addition of the signature resource type and the key resource type needed for key distribution. (Data non-existence authentication also requires the NXT RR as described in 2.3.2.) This service can be supported by existing resolver and caching server implementations so long as they can support the additional resource types (see Section 9). The one exception is that CNAME referrals in a secure zone can not be authenticated if they are from non-security aware servers (see Section 2.3.5).
除了添加密钥分发所需的签名资源类型和密钥资源类型之外，添加数据源身份验证和完整性不需要更改“在线”DNS协议。（数据不存在身份验证也需要NXT RR，如2.3.2所述。）现有的解析器和缓存服务器实现可以支持此服务，只要它们能够支持其他资源类型（请参阅第9节）。一个例外是，如果安全区域中的CNAME引用来自无安全意识的服务器，则无法对其进行身份验证（请参阅第2.3.5节）。
If signatures are separately retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. Security aware servers mitigate that degradation by attempting to send the signature(s) needed (see Section 4.2).
如果在检索签名所验证的信息时单独检索和验证签名，则会有更多到服务器的行程，性能也会受到影响。安全感知服务器通过尝试发送所需的签名（见第4.2节）来缓解这种降级。
The syntax of a SIG resource record (signature) is described in Section 4. It cryptographicly binds the RRset being signed to the signer and a validity interval.
第4节描述了SIG资源记录（签名）的语法。它以加密方式将正在签名的RRset绑定到签名者和有效期间隔。
Every name in a secured zone will have associated with it at least one SIG resource record for each resource type under that name except for glue address RRs and delegation point NS RRs. A security aware server will attempt to return, with RRs retrieved, the corresponding SIGs. If a server is not security aware, the resolver must retrieve all the SIG records for a name and select the one or ones that sign the resource record set(s) that resolver is interested in.
安全区域中的每个名称都将与该名称下每个资源类型的至少一个SIG资源记录关联，但粘合地址RRs和委派点NS RRs除外。安全感知服务器将尝试返回相应的SIG，并检索RRs。如果服务器不具备安全意识，则解析程序必须检索名称的所有SIG记录，并选择一个或多个对解析程序感兴趣的资源记录集进行签名的记录。
The above security mechanism only provides a way to sign existing RRsets in a zone. "Data origin" authentication is not obviously provided for the non-existence of a domain name in a zone or the non-existence of a type for an existing name. This gap is filled by the NXT RR which authenticatably asserts a range of non-existent names in a zone and the non-existence of types for the existing name just before that range.
上述安全机制仅提供一种对区域中现有RRSET进行签名的方法。对于区域中不存在域名或现有名称不存在类型，显然不提供“数据源”身份验证。NXT RR填补了这一空白，它以可验证的方式断言一个区域中不存在的名称范围以及该范围之前不存在的现有名称类型。
Section 5 below covers the NXT RR.
下文第5节介绍了NXT RR。
A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the signature is verified. This conflicts with our desire to have the time-to-live (TTL) field of resource records tick down while they are cached.
数字签名将无法验证从最初签名到验证签名之间的数据是否发生了任何更改。这与我们希望资源记录的生存时间（TTL）字段在缓存时被勾选的愿望相冲突。
This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous servers to set arbitrarily long TTL values undetected. Instead, we include the "original" TTL in the signature and communicate that data along with the current TTL. Unscrupulous servers under this scheme can manipulate the TTL but a security aware resolver will bound the TTL value it uses at the original signed value. Separately, signatures include a signature inception time and a signature expiration time. A
这可以通过让数字签名留有生存时间来避免，但这将允许不道德的服务器设置任意长的TTL值而不被发现。相反，我们在签名中包含“原始”TTL，并将该数据与当前TTL一起通信。此方案下的恶意服务器可以操纵TTL，但安全感知解析器会将其使用的TTL值绑定为原始签名值。另外，签名包括签名起始时间和签名到期时间。A.
resolver that knows the absolute time can determine securely whether a signature is in effect. It is not possible to rely solely on the signature expiration as a substitute for the TTL, however, since the TTL is primarily a database consistency mechanism and non-security aware servers that depend on TTL must still be supported.
知道绝对时间的解析器可以安全地确定签名是否有效。但是，不可能仅仅依靠签名过期来替代TTL，因为TTL主要是一种数据库一致性机制，必须仍然支持依赖TTL的非安全感知服务器。
DNS security would like to view each zone as a unit of data completely under the control of the zone owner with each entry (RRset) signed by a special private key held by the zone manager. But the DNS protocol views the leaf nodes in a zone, which are also the apex nodes of a subzone (i.e., delegation points), as "really" belonging to the subzone. These nodes occur in two master files and might have RRs signed by both the upper and lower zone's keys. A retrieval could get a mixture of these RRs and SIGs, especially since one server could be serving both the zone above and below a delegation point. [RFC 2181]
DNS security希望将每个区域视为完全受区域所有者控制的数据单元，每个条目（RRset）都由区域管理器持有的特殊私钥签名。但是DNS协议将区域中的叶节点（也是子区域的顶点节点（即，委托点））视为“真正”属于子区域。这些节点出现在两个主文件中，并且可能具有由上部和下部区域的密钥签名的RRs。检索可能会混合使用这些RRs和SIG，特别是因为一台服务器可以同时为委托点上方和下方的区域提供服务。[RFC2181]
There MUST be a zone KEY RR, signed by its superzone, for every subzone if the superzone is secure. This will normally appear in the subzone and may also be included in the superzone. But, in the case of an unsecured subzone which can not or will not be modified to add any security RRs, a KEY declaring the subzone to be unsecured MUST appear with the superzone signature in the superzone, if the superzone is secure. For all but one other RR type the data from the subzone is more authoritative so only the subzone KEY RR should be signed in the superzone if it appears there. The NS and any glue address RRs SHOULD only be signed in the subzone. The SOA and any other RRs that have the zone name as owner should appear only in the subzone and thus are signed only there. The NXT RR type is the exceptional case that will always appear differently and authoritatively in both the superzone and subzone, if both are secure, as described in Section 5.
如果超区域是安全的，则每个子区域都必须有一个由其超区域签名的区域密钥RR。这通常会出现在分区中，也可能包含在超分区中。但是，如果某个不安全的子区域不能或不会被修改以添加任何安全RRs，则如果该超区域是安全的，则声明该子区域为不安全的密钥必须与超区域签名一起出现在超区域中。对于除一个其他RR类型之外的所有其他RR类型，来自子区域的数据更具权威性，因此，如果子区域键RR出现在超区域中，则仅应对其进行签名。NS和任何粘合地址RRs只能在子区域中签名。以区域名称作为所有者的SOA和任何其他RRs应仅出现在子区域中，因此仅在子区域中签名。NXT RR类型是一种例外情况，如第5节所述，如果超级区和子区都是安全的，则它们在超级区和子区中总是以不同的方式出现。
There is a problem when security related RRs with the same owner name as a CNAME RR are retrieved from a non-security-aware server. In particular, an initial retrieval for the CNAME or any other type may not retrieve any associated SIG, KEY, or NXT RR. For retrieved types other than CNAME, it will retrieve that type at the target name of the CNAME (or chain of CNAMEs) and will also return the CNAME. In particular, a specific retrieval for type SIG will not get the SIG, if any, at the original CNAME domain name but rather a SIG at the target name.
当从无安全意识的服务器检索与CNAME RR具有相同所有者名称的安全相关RRs时，会出现问题。特别是，CNAME或任何其他类型的初始检索可能无法检索任何相关的SIG、KEY或NXT RR。对于检索到的CNAME以外的类型，它将在CNAME（或CNAME链）的目标名称处检索该类型，并将返回CNAME。特别是，对SIG类型的特定检索不会在原始CNAME域名处获取SIG（如果有），而是在目标名称处获取SIG。
Security aware servers must be used to securely CNAME in DNS. Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along with CNAME RRs, (2) suppress CNAME processing on retrieval of these types as well as on retrieval of the type CNAME, and (3) automatically return SIG RRs authenticating the CNAME or CNAMEs encountered in resolving a query. This is a change from the previous DNS standard [RFCs 1034/1035] which prohibited any other RR type at a node where a CNAME RR was present.
必须使用具有安全意识的服务器在DNS中安全地创建CNAME。安全感知服务器必须（1）允许密钥、SIG和NXT RRs以及CNAME RRs，（2）在检索这些类型以及CNAME类型时禁止CNAME处理，以及（3）自动返回SIG RRs，以验证解析查询时遇到的CNAME或CNAME。这是对先前DNS标准[RFCs 1034/1035]的更改，该标准禁止在存在CNAME RR的节点上使用任何其他RR类型。
There are cases where the signer in a SIG resource record is other than one of the private key(s) used to authenticate a zone.
在某些情况下，SIG资源记录中的签名者不是用于验证区域的私钥之一。
One is for support of dynamic update [RFC 2136] (or future requests which require secure authentication) where an entity is permitted to authenticate/update its records [RFC 2137] and the zone is operating in a mode where the zone key is not on line. The public key of the entity must be present in the DNS and be signed by a zone level key but the other RR(s) may be signed with the entity's key.
一种是支持动态更新[RFC 2136]（或需要安全认证的未来请求），其中允许实体认证/更新其记录[RFC 2137]，并且区域在区域密钥不在线的模式下运行。该实体的公钥必须存在于DNS中，并由区域级密钥签名，但其他RR可由该实体的密钥签名。
A second case is support of transaction and request authentication as described in Section 2.4.
第二种情况是支持第2.4节所述的事务和请求身份验证。
In additions, signatures can be included on resource records within the DNS for use by applications other than DNS. DNS related signatures authenticate that data originated with the authority of a zone owner or that a request or transaction originated with the relevant entity. Other signatures can provide other types of assurances.
此外，签名可以包含在DNS内的资源记录上，供DNS以外的应用程序使用。DNS相关签名验证数据是否源自区域所有者的授权，或请求或交易是否源自相关实体。其他签名可以提供其他类型的保证。
The data origin authentication service described above protects retrieved resource records and the non-existence of resource records but provides no protection for DNS requests or for message headers.
上述数据源身份验证服务保护检索到的资源记录和不存在的资源记录，但不对DNS请求或消息头提供保护。
If header bits are falsely set by a bad server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is at least getting messages from the server it thinks it queried and that the response is from the query it sent (i.e., that these messages have not been diddled in transit). This is accomplished by optionally adding a special SIG resource record at the end of the reply which digitally signs the concatenation of the server's response and the resolver's query.
如果错误的服务器错误地设置了报头位，那么就没有什么可以做的了。但是，可以添加事务身份验证。这种身份验证意味着冲突解决程序可以确保它至少从它认为查询的服务器获取消息，并且响应来自它发送的查询（即，这些消息在传输过程中没有被欺骗）。这是通过在回复的末尾选择性地添加一个特殊的SIG资源记录来实现的，该记录对服务器响应和解析器查询的连接进行数字签名。
Requests can also be authenticated by including a special SIG RR at the end of the request. Authenticating requests serves no function in older DNS servers and requests with a non-empty additional information section produce error returns or may even be ignored by many of them. However, this syntax for signing requests is defined as a way of authenticating secure dynamic update requests [RFC 2137] or future requests requiring authentication.
还可以通过在请求末尾包含特殊的SIG RR来验证请求。身份验证请求在较旧的DNS服务器中不起作用，具有非空附加信息部分的请求会产生错误返回，甚至可能被许多DNS服务器忽略。但是，此签名请求的语法定义为验证安全动态更新请求[RFC 2137]或需要验证的未来请求的方法。
The private keys used in transaction security belong to the entity composing the reply, not to the zone involved. Request authentication may also involve the private key of the host or other entity composing the request or other private keys depending on the request authority it is sought to establish. The corresponding public key(s) are normally stored in and retrieved from the DNS for verification.
事务安全性中使用的私钥属于组成回复的实体，而不属于涉及的区域。请求认证还可能涉及构成请求的主机或其他实体的私钥或其他私钥，具体取决于请求认证试图建立的请求权限。相应的公钥通常存储在DNS中并从DNS中检索以进行验证。
Because requests and replies are highly variable, message authentication SIGs can not be pre-calculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware.
由于请求和回复高度可变，因此无法预先计算消息身份验证sig。因此，有必要保持私钥在线，例如在软件或直接连接的硬件中。
The KEY resource record (RR) is used to store a public key that is associated with a Domain Name System (DNS) name. This can be the public key of a zone, a user, or a host or other end entity. Security aware DNS implementations MUST be designed to handle at least two simultaneously valid keys of the same type associated with the same name.
密钥资源记录（RR）用于存储与域名系统（DNS）名称关联的公钥。这可以是区域、用户、主机或其他终端实体的公钥。具有安全意识的DNS实现必须设计为处理至少两个与相同名称关联的相同类型的同时有效密钥。
The type number for the KEY RR is 25.
键RR的类型号为25。
A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs must be signed by a zone level key.
密钥RR与任何其他RR一样，由SIG RR进行身份验证。密钥RRs必须由区域级密钥签名。
The RDATA for a KEY RR consists of flags, a protocol octet, the algorithm number octet, and the public key itself. The format is as follows:
密钥RR的RDATA由标志、协议八位字节、算法编号八位字节和公钥本身组成。格式如下:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The KEY RR is not intended for storage of certificates and a separate certificate RR has been developed for that purpose, defined in [RFC 2538].
密钥RR不用于存储证书，已为此目的开发了一个单独的证书RR，定义见[RFC 2538]。
The meaning of the KEY RR owner name, flags, and protocol octet are described in Sections 3.1.1 through 3.1.5 below. The flags and algorithm must be examined before any data following the algorithm octet as they control the existence and format of any following data. The algorithm and public key fields are described in Section 3.2. The format of the public key is algorithm dependent.
密钥RR所有者名称、标志和协议八位字节的含义见下文第3.1.1节至第3.1.5节。在算法八位字节之后的任何数据之前，必须检查标志和算法，因为它们控制任何后续数据的存在和格式。第3.2节描述了算法和公钥字段。公钥的格式取决于算法。
KEY RRs do not specify their validity period but their authenticating SIG RR(s) do as described in Section 4 below.
密钥RR未指定其有效期，但其认证SIG RR如下文第4节所述。
The public key in a KEY RR is for the object named in the owner name.
密钥RR中的公钥用于所有者名称中命名的对象。
A DNS name may refer to three different categories of things. For example, foo.host.example could be (1) a zone, (2) a host or other end entity , or (3) the mapping into a DNS name of the user or account foo@host.example. Thus, there are flag bits, as described below, in the KEY RR to indicate with which of these roles the owner name and public key are associated. Note that an appropriate zone KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs occur only at delegation points.
DNS名称可能指三种不同类别的事物。例如，foo.host.example可以是（1）区域，（2）主机或其他终端实体，或者（3）映射到用户或帐户的DNS名称foo@host.example. 因此，在密钥RR中存在如下所述的标志位，以指示所有者名称和公钥与这些角色中的哪些角色相关联。请注意，适当的区域密钥RR必须出现在安全区域的顶点节点，并且区域密钥RR仅出现在委派点。
In the "flags" field:
在“标志”字段中：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bit 0 and 1 are the key "type" bits whose values have the following meanings:
位0和1是键“类型”位，其值具有以下含义：
10: Use of the key is prohibited for authentication. 01: Use of the key is prohibited for confidentiality. 00: Use of the key for authentication and/or confidentiality is permitted. Note that DNS security makes use of keys for authentication only. Confidentiality use flagging is provided for use of keys in other protocols. Implementations not intended to support key distribution for confidentiality MAY require that the confidentiality use prohibited bit be on for keys they serve. 11: If both bits are one, the "no key" value, there is no key information and the RR stops after the algorithm octet. By the use of this "no key" value, a signed KEY RR can authenticatably assert that, for example, a zone is not secured. See section 3.4 below.
10：禁止使用密钥进行身份验证。01：出于保密目的，禁止使用密钥。00：允许使用密钥进行身份验证和/或保密。请注意，DNS安全性仅将密钥用于身份验证。为在其他协议中使用密钥提供保密性使用标记。不支持密钥分发以实现机密性的实现可能要求为其服务的密钥启用机密性使用禁止位。11：如果两个位都是“无键”值，则没有键信息，RR在算法八位字节后停止。通过使用此“无密钥”值，签名密钥RR可以通过身份验证断言，例如，某个区域不安全。见下文第3.4节。
Bits 2 is reserved and must be zero.
位2是保留的，必须为零。
Bits 3 is reserved as a flag extension bit. If it is a one, a second 16 bit flag field is added after the algorithm octet and before the key data. This bit MUST NOT be set unless one or more such additional bits have been defined and are non-zero.
位3保留为标志扩展位。如果是1，则在算法八位字节之后和密钥数据之前添加第二个16位标志字段。除非定义了一个或多个此类附加位且为非零，否则不得设置该位。
Bits 4-5 are reserved and must be zero.
位4-5是保留的，必须为零。
Bits 6 and 7 form a field that encodes the name type. Field values have the following meanings:
第6位和第7位形成一个对名称类型进行编码的字段。字段值具有以下含义：
00: indicates that this is a key associated with a "user" or "account" at an end entity, usually a host. The coding of the owner name is that used for the responsible individual mailbox in the SOA and RP RRs: The owner name is the user name as the name of a node under the entity name. For example, "j_random_user" on host.subdomain.example could have a public key associated through a KEY RR with name j_random_user.host.subdomain.example. It could be used in a security protocol where authentication of a user was desired. This key might be useful in IP or other security for a user level service such a telnet, ftp, rlogin, etc. 01: indicates that this is a zone key for the zone whose name is the KEY RR owner name. This is the public key used for the primary DNS security feature of data origin authentication. Zone KEY RRs occur only at delegation points. 10: indicates that this is a key associated with the non-zone "entity" whose name is the RR owner name. This will commonly be a host but could, in some parts of the DNS
00：表示这是与终端实体（通常是主机）的“用户”或“帐户”关联的密钥。所有者名称的编码用于SOA和RP RRs中负责的单个邮箱：所有者名称是用户名，作为实体名称下的节点名称。例如，host.subdomain.example上的“j_random_user”可以通过名为j_random_user.host.subdomain.example的密钥RR关联公钥。它可以用于需要用户身份验证的安全协议中。此密钥在IP或用户级服务（如telnet、ftp、rlogin等）的其他安全性中可能很有用。01：表示这是区域的区域密钥，其名称为密钥所有者名称。这是用于数据源身份验证的主要DNS安全功能的公钥。区域密钥RRs仅在委派点发生。10：表示这是与名称为RR所有者名称的非区域“实体”关联的密钥。这通常是一个主机，但在DNS的某些部分可能是
tree, be some other type of entity such as a telephone number [RFC 1530] or numeric IP address. This is the public key used in connection with DNS request and transaction authentication services. It could also be used in an IP-security protocol where authentication at the host, rather than user, level was desired, such as routing, NTP, etc. 11: reserved.
树，可以是其他类型的实体，例如电话号码[RFC 1530]或数字IP地址。这是用于DNS请求和事务身份验证服务的公钥。它还可以用于IP安全协议，其中需要在主机而不是用户级别进行身份验证，例如路由、NTP等。11：保留。
Bits 8-11 are reserved and must be zero.
位8-11是保留的，必须为零。
Bits 12-15 are the "signatory" field. If non-zero, they indicate that the key can validly sign things as specified in DNS dynamic update [RFC 2137]. Note that zone keys (see bits 6 and 7 above) always have authority to sign any RRs in the zone regardless of the value of the signatory field.
第12-15位为“签字人”字段。如果非零，则表示密钥可以按照DNS动态更新[RFC 2137]中的指定对内容进行有效签名。请注意，区域密钥（见上文第6位和第7位）始终有权签署区域内的任何RRs，无论签名人字段的值如何。
It is anticipated that keys stored in DNS will be used in conjunction with a variety of Internet protocols. It is intended that the protocol octet and possibly some of the currently unused (must be zero) bits in the KEY RR flags as specified in the future will be used to indicate a key's validity for different protocols.
预计DNS中存储的密钥将与各种互联网协议结合使用。协议八位字节和将来指定的密钥RR标志中当前未使用（必须为零）的一些位将用于指示密钥对不同协议的有效性。
The following values of the Protocol Octet are reserved as indicated:
如图所示，保留协议八位字节的以下值：
VALUE Protocol
价值协议
0 -reserved 1 TLS 2 email 3 dnssec 4 IPSEC 5-254 - available for assignment by IANA 255 All
0-保留1 TLS 2电子邮件3 dnssec 4 IPSEC 5-254-可由IANA 255 All分配
In more detail: 1 is reserved for use in connection with TLS. 2 is reserved for use in connection with email. 3 is used for DNS security. The protocol field SHOULD be set to this value for zone keys and other keys used in DNS security. Implementations that can determine that a key is a DNS security key by the fact that flags label it a zone key or the signatory flag field is non-zero are NOT REQUIRED to check the protocol field. 4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol and indicates that this key is valid for use in conjunction
更详细地说：1保留用于TLS。2保留用于电子邮件。3用于DNS安全。对于DNS安全中使用的区域密钥和其他密钥，应将协议字段设置为此值。无需检查协议字段，即可通过标志将密钥标记为区域密钥或签名标志字段为非零来确定密钥是否为DNS安全密钥的实现。保留4以引用Oakley/IPSEC[RFC 2401]协议，并指示此密钥可结合使用
with that security standard. This key could be used in connection with secured communication on behalf of an end entity or user whose name is the owner name of the KEY RR if the entity or user flag bits are set. The presence of a KEY resource with this protocol value is an assertion that the host speaks Oakley/IPSEC. 255 indicates that the key can be used in connection with any protocol for which KEY RR protocol octet values have been defined. The use of this value is discouraged and the use of different keys for different protocols is encouraged.
有了这个安全标准。如果设置了实体或用户标志位，则可以代表其名称为密钥RR的所有者名称的终端实体或用户，将该密钥与安全通信结合使用。具有此协议值的密钥资源的存在是主机说Oakley/IPSEC的断言。255表示密钥可与任何已定义密钥RR协议八位字节值的协议结合使用。不鼓励使用此值，并鼓励对不同协议使用不同的密钥。
This octet is the key algorithm parallel to the same field for the SIG resource as described in Section 4.1. The following values are assigned:
该八位组是与第4.1节所述SIG资源相同字段并行的关键算法。将指定以下值：
VALUE Algorithm
值算法
0 - reserved, see Section 11 1 RSA/MD5 [RFC 2537] - recommended 2 Diffie-Hellman [RFC 2539] - optional, key only 3 DSA [RFC 2536] - MANDATORY 4 reserved for elliptic curve crypto 5-251 - available, see Section 11 252 reserved for indirect keys 253 private - domain name (see below) 254 private - OID (see below) 255 - reserved, see Section 11
0-保留，参见第11节1 RSA/MD5[RFC 2537]-推荐2 Diffie Hellman[RFC 2539]-可选，仅密钥3 DSA[RFC 2536]-强制4保留用于椭圆曲线加密5-251-可用，参见第11节252保留用于间接密钥253私有-域名（见下文）254私有-OID（见下文）255-保留，参见第11节
Algorithm specific formats and procedures are given in separate documents. The mandatory to implement for interoperability algorithm is number 3, DSA. It is recommended that the RSA/MD5 algorithm, number 1, also be implemented. Algorithm 2 is used to indicate Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
算法特定的格式和程序在单独的文档中给出。互操作性算法必须实现的是3号DSA。建议还实现RSA/MD5算法（编号1）。算法2用于指示Diffie-Hellman密钥，算法4保留用于椭圆曲线。
Algorithm number 252 indicates an indirect key format where the actual key material is elsewhere. This format is to be defined in a separate document.
算法编号252表示一种间接密钥格式，其中实际密钥材料位于其他位置。此格式将在单独的文件中定义。
Algorithm numbers 253 and 254 are reserved for private use and will never be assigned a specific algorithm. For number 253, the public key area and the signature begin with a wire encoded domain name. Only local domain name compression is permitted. The domain name indicates the private algorithm to use and the remainder of the public key area is whatever is required by that algorithm. For number 254, the public key area for the KEY RR and the signature begin with an unsigned length byte followed by a BER encoded Object
算法编号253和254保留供私人使用，永远不会分配特定的算法。对于数字253，公钥区域和签名以有线编码的域名开始。只允许本地域名压缩。域名表示要使用的私有算法，公钥区域的其余部分是该算法所需的内容。对于数字254，密钥RR和签名的公钥区域以一个无符号长度字节开始，后跟一个BER编码的对象
Identifier (ISO OID) of that length. The OID indicates the private algorithm in use and the remainder of the area is whatever is required by that algorithm. Entities should only use domain names and OIDs they control to designate their private algorithms.
该长度的标识符（ISO OID）。OID表示正在使用的私有算法，该区域的剩余部分是该算法所需的部分。实体应仅使用其控制的域名和OID来指定其私有算法。
Values 0 and 255 are reserved but the value 0 is used in the algorithm field when that field is not used. An example is in a KEY RR with the top two flag bits on, the "no-key" value, where no key is present.
值0和255是保留的，但如果不使用该字段，则在算法字段中使用值0。例如，在键RR中，最上面的两个标志位为“无键”值，其中不存在键。
Various combinations of the no-key type flags, algorithm byte, protocol byte, and any future assigned protocol indicating flags are possible. The meaning of these combinations is indicated below:
无密钥类型标志、算法字节、协议字节和任何未来指定的协议指示标志的各种组合都是可能的。这些组合的含义如下所示：
NK = no key type (flags bits 0 and 1 on) AL = algorithm byte PR = protocols indicated by protocol byte or future assigned flags
NK=无密钥类型（标志位0和1打开）AL=算法字节PR=由协议字节或未来分配的标志指示的协议
x represents any valid non-zero value(s).
x表示任何有效的非零值。
AL PR NK Meaning 0 0 0 Illegal, claims key but has bad algorithm field. 0 0 1 Specifies total lack of security for owner zone. 0 x 0 Illegal, claims key but has bad algorithm field. 0 x 1 Specified protocols unsecured, others may be secure. x 0 0 Gives key but no protocols to use it. x 0 1 Denies key for specific algorithm. x x 0 Specifies key for protocols. x x 1 Algorithm not understood for protocol.
AL PR NK表示0非法，声明密钥但具有错误的算法字段。0 1指定所有者区域完全缺乏安全性。0 x 0非法，声明密钥，但具有错误的算法字段。0 x 1指定的协议不安全，其他协议可能安全。X0 0提供密钥，但没有使用它的协议。x 0 1拒绝特定算法的密钥。x0指定协议的密钥。协议未理解x 1算法。
A zone KEY RR with the "no-key" type field value (both key type flag bits 0 and 1 on) indicates that the zone named is unsecured while a zone KEY RR with a key present indicates that the zone named is secure. The secured versus unsecured status of a zone may vary with different cryptographic algorithms. Even for the same algorithm, conflicting zone KEY RRs may be present.
具有“无密钥”类型字段值（密钥类型标志位0和1均为on）的区域密钥RR表示名为的区域不安全，而具有密钥的区域密钥RR表示名为的区域安全。区域的安全与非安全状态可能因不同的加密算法而异。即使对于相同的算法，也可能存在冲突的区域密钥RRs。
Zone KEY RRs, like all RRs, are only trusted if they are authenticated by a SIG RR whose signer field is a signer for which the resolver has a public key they trust and where resolver policy permits that signer to sign for the KEY owner name. Untrusted zone KEY RRs MUST be ignored in determining the security status of the zone. However, there can be multiple sets of trusted zone KEY RRs for a zone with different algorithms, signers, etc.
与所有RRs一样，区域密钥RRs只有在经过SIG RR的身份验证时才受信任，SIG RR的签名者字段是解析程序信任的公钥的签名者，并且解析程序策略允许该签名者为密钥所有者名称签名。在确定区域的安全状态时，必须忽略不受信任的区域密钥RRs。但是，对于一个具有不同算法、签名者等的区域，可以有多组可信区域密钥RRs。
For any particular algorithm, zones can be (1) secure, indicating that any retrieved RR must be authenticated by a SIG RR or it will be discarded as bogus, (2) unsecured, indicating that SIG RRs are not expected or required for RRs retrieved from the zone, or (3) experimentally secure, which indicates that SIG RRs might or might not be present but must be checked if found. The status of a zone is determined as follows:
对于任何特定算法，区域可以是（1）安全的，表示任何检索到的RR必须由SIG RR进行身份验证，否则将被视为伪造而丢弃，（2）不安全的，表示从区域检索到的RRs不需要SIG RRs，或（3）实验上安全的，这表明SIG RRs可能存在也可能不存在，但如果发现，则必须进行检查。分区的状态确定如下：
1. If, for a zone and algorithm, every trusted zone KEY RR for the zone says there is no key for that zone, it is unsecured for that algorithm.
1. 如果对于区域和算法，该区域的每个受信任区域密钥RR都表示该区域没有密钥，则该算法是不安全的。
2. If, there is at least one trusted no-key zone KEY RR and one trusted key specifying zone KEY RR, then that zone is only experimentally secure for the algorithm. Both authenticated and non-authenticated RRs for it should be accepted by the resolver.
2. 如果至少有一个可信无密钥区域密钥RR和一个指定区域密钥RR的可信密钥，则该区域仅在实验上对算法是安全的。冲突解决程序应接受其已验证和未验证的RRs。
3. If every trusted zone KEY RR that the zone and algorithm has is key specifying, then it is secure for that algorithm and only authenticated RRs from it will be accepted.
3. 如果区域和算法拥有的每个可信区域密钥RR都是指定密钥的，则该算法是安全的，并且只接受来自该算法的经过身份验证的RRs。
Examples:
示例：
(1) A resolver initially trusts only signatures by the superzone of zone Z within the DNS hierarchy. Thus it will look only at the KEY RRs that are signed by the superzone. If it finds only no-key KEY RRs, it will assume the zone is not secure. If it finds only key specifying KEY RRs, it will assume the zone is secure and reject any unsigned responses. If it finds both, it will assume the zone is experimentally secure
(1) 解析程序最初只信任DNS层次结构中Z区的超区的签名。因此，它将只查看由superzone签名的密钥RRs。如果它只发现没有密钥RRs，它将假定该区域不安全。如果它只找到指定密钥RRs的密钥，它将假定该区域是安全的，并拒绝任何未签名的响应。如果它同时发现了这两个区域，它将假定该区域在实验上是安全的
(2) A resolver trusts the superzone of zone Z (to which it got securely from its local zone) and a third party, cert-auth.example. When considering data from zone Z, it may be signed by the superzone of Z, by cert-auth.example, by both, or by neither. The following table indicates whether zone Z will be considered secure, experimentally secure, or unsecured, depending on the signed zone KEY RRs for Z;
(2) 解析程序信任区域Z的超区域（它从其本地区域安全地到达该超区域）和第三方cert-auth.example。当考虑来自Z区的数据时，可以由Z区的超区、cert-auth.example、两者或两者都签名。下表表明，根据Z的签名区域密钥RRs，Z区域将被视为安全、实验安全还是不安全；
c e r t - a u t h . e x a m p l e
c e r t-a u t h。e x a m p l e
KEY RRs| None | NoKeys | Mixed | Keys |
S --+-----------+-----------+----------+----------+
u None | illegal | unsecured | experim. | secure |
p --+-----------+-----------+----------+----------+
e NoKeys | unsecured | unsecured | experim. | secure |
r --+-----------+-----------+----------+----------+
Z Mixed | experim. | experim. | experim. | secure |
KEY RRs| None | NoKeys | Mixed | Keys |
S --+-----------+-----------+----------+----------+
u None | illegal | unsecured | experim. | secure |
p --+-----------+-----------+----------+----------+
e NoKeys | unsecured | unsecured | experim. | secure |
r --+-----------+-----------+----------+----------+
Z Mixed | experim. | experim. | experim. | secure |
o --+-----------+-----------+----------+----------+
n Keys | secure | secure | secure | secure |
e +-----------+-----------+----------+----------+
o --+-----------+-----------+----------+----------+
n Keys | secure | secure | secure | secure |
e +-----------+-----------+----------+----------+
An explicit request for KEY RRs does not cause any special additional information processing except, of course, for the corresponding SIG RR from a security aware server (see Section 4.2).
对密钥RRs的明确请求不会导致任何特殊的附加信息处理，当然，来自安全感知服务器的相应SIG RR除外（参见第4.2节）。
Security aware DNS servers include KEY RRs as additional information in responses, where a KEY is available, in the following cases:
在以下情况下，具有安全意识的DNS服务器在响应中包括密钥RRs作为附加信息，其中密钥可用：
(1) On the retrieval of SOA or NS RRs, the KEY RRset with the same name (perhaps just a zone key) SHOULD be included as additional information if space is available. If not all additional information will fit, type A and AAAA glue RRs have higher priority than KEY RR(s).
(1) 在检索SOA或NS RRs时，如果空间可用，则应包含具有相同名称的密钥RRset（可能只是一个区域密钥）作为附加信息。如果不是所有附加信息都适合，A型和AAAA型胶水RRs的优先级高于键RR。
(2) On retrieval of type A or AAAA RRs, the KEY RRset with the same name (usually just a host RR and NOT the zone key (which usually would have a different name)) SHOULD be included if space is available. On inclusion of A or AAAA RRs as additional information, the KEY RRset with the same name should also be included but with lower priority than the A or AAAA RRs.
(2) 在检索类型A或AAAA RRs时，如果空间可用，则应包括具有相同名称的密钥RRset（通常只是主机RR，而不是区域密钥（通常具有不同的名称））。在包含A或AAAA RRs作为附加信息时，还应包含具有相同名称的密钥RRs集，但优先级低于A或AAAA RRs。
The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure Domain Name System (DNS). As such it is the heart of the security provided.
SIG或“签名”资源记录（RR）是在安全域名系统（DNS）中对数据进行身份验证的基本方式。因此，它是所提供安全的核心。
The SIG RR unforgably authenticates an RRset [RFC 2181] of a particular type, class, and name and binds it to a time interval and the signer's domain name. This is done using cryptographic techniques and the signer's private key. The signer is frequently the owner of the zone from which the RR originated.
SIG-RR不可原谅地对特定类型、类和名称的RRset[RFC 2181]进行身份验证，并将其绑定到时间间隔和签名者的域名。这是使用加密技术和签名者的私钥完成的。签名者通常是RR来源区域的所有者。
The type number for the SIG RR type is 24.
SIG RR类型的类型编号为24。
The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information is protected by the signature field.
SIG RR的RDATA部分如下所示。RDATA信息的完整性受签名字段保护。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name +
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ /
/ signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name +
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
/ /
/ signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "type covered" is the type of the other RRs covered by this SIG.
“涵盖类型”是指本SIG涵盖的其他RRs的类型。
This octet is as described in section 3.2.
该八位组如第3.2节所述。
The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. This field makes it easy to determine the original form.
“labels”八位组是原始SIG RR所有者名称中有多少标签的无符号计数，不计算根的空标签，也不计算通配符的任何初始“*”。如果安全检索是通配符替换的结果，则解析程序必须使用名称的原始形式来验证数字签名。通过此字段可以轻松确定原始形式。
If, on retrieval, the RR appears to have a longer name than indicated by "labels", the resolver can tell it is the result of wildcard substitution. If the RR owner name appears to be shorter than the labels count, the SIG RR must be considered corrupt and ignored. The maximum number of labels allowed in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. The following table gives some examples. The value of "labels" is at the top, the retrieved owner name on the left, and the table entry is the name to use in signature verification except that "bad" means the RR is corrupt.
如果在检索时，RR的名称似乎比“标签”指示的名称长，则解析程序可以判断它是通配符替换的结果。如果RR所有者名称似乎短于标签计数，则必须将SIG RR视为已损坏并忽略。当前DNS中允许的最大标签数为127，但保留了整个八位字节，如果DNS名称扩展到255个标签，则需要保留整个八位字节。下表给出了一些示例。“labels”的值位于顶部，检索到的所有者名称位于左侧，表条目是签名验证中使用的名称，但“bad”表示RR已损坏。
labels= | 0 | 1 | 2 | 3 | 4 |
--------+-----+------+--------+----------+----------+
.| . | bad | bad | bad | bad |
d.| *. | d. | bad | bad | bad |
c.d.| *. | *.d. | c.d. | bad | bad |
b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad |
a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
labels= | 0 | 1 | 2 | 3 | 4 |
--------+-----+------+--------+----------+----------+
.| . | bad | bad | bad | bad |
d.| *. | d. | bad | bad | bad |
c.d.| *. | *.d. | c.d. | bad | bad |
b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad |
a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
The "original TTL" field is included in the RDATA portion to avoid (1) authentication problems that caching servers would otherwise cause by decrementing the real TTL field and (2) security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the current TTL field is not.
“原始TTL”字段包含在RDATA部分中，以避免（1）缓存服务器通过减少真实TTL字段可能导致的身份验证问题，以及（2）不道德服务器通过操纵真实TTL字段可能导致的安全问题。此原始TTL受签名保护，而当前TTL字段不受保护。
NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified (see Section 8). This generaly implies that all RRs for a particular type, name, and class, that is, all the RRs in any particular RRset, must have the same TTL to start with.
注：验证签名后，“原始TTL”必须恢复到覆盖RRs中（见第8节）。这通常意味着特定类型、名称和类的所有RRs，即任何特定RRs集中的所有RRs，必须以相同的TTL开头。
The SIG is valid from the "signature inception" time until the "signature expiration" time. Both are unsigned numbers of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. (See also Section 4.4.) Ring arithmetic is used as for DNS SOA serial numbers [RFC 1982] which means that these times can never be more than about 68 years in the past or the future. This means that these times are ambiguous modulo ~136.09 years. However there is no security flaw because keys are required to be changed to new random keys by [RFC 2541] at least every five years. This means that the probability that the same key is in use N*136.09 years later should be the same as the probability that a random guess will work.
SIG从“签名起始”时间到“签名到期”时间有效。两者都是自1970年1月1日格林尼治标准时间开始以来的无符号秒数，忽略闰秒。（另请参见第4.4节）对于DNS SOA序列号[RFC 1982]使用了环形算法，这意味着这些时间在过去或未来永远不会超过68年。这意味着这些时间是模棱两可的模~136.09年。但是，由于[RFC 2541]要求至少每五年将密钥更改为新的随机密钥，因此不存在安全漏洞。这意味着相同密钥在N*136.09年后被使用的概率应与随机猜测有效的概率相同。
A SIG RR may have an expiration time numerically less than the inception time if the expiration time is near the 32 bit wrap around point and/or the signature is long lived.
如果到期时间接近32位环绕点和/或签名是长寿命的，则SIG-RR的到期时间在数字上可能小于起始时间。
(To prevent misordering of network requests to update a zone dynamically, monotonically increasing "signature inception" times may be necessary.)
（为了防止动态更新区域的网络请求顺序错误，可能需要单调增加“签名起始”时间。）
A secure zone must be considered changed for SOA serial number purposes not only when its data is updated but also when new SIG RRs are inserted (ie, the zone or any part of it is re-signed).
出于SOA序列号的目的，必须考虑更改安全区域，不仅是在更新其数据时，而且在插入新的SIG RRs时（即，重新签名该区域或其任何部分）。
The "key Tag" is a two octet quantity that is used to efficiently select between multiple keys which may be applicable and thus check that a public key about to be used for the computationally expensive effort to check the signature is possibly valid. For algorithm 1 (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the least significant 24 bits of the modulus in network (big endian) order. For all other algorithms, including private algorithms, it is calculated as a simple checksum of the KEY RR as described in Appendix C.
“密钥标签”是两个八位组的数量，用于在多个密钥之间有效地选择可能适用的密钥，从而检查将用于检查签名的计算代价高昂的工作的公钥是否可能有效。对于[RFC 2537]中定义的算法1（MD5/RSA），它是解码签名字段所需的公钥模的下两个八位字节。也就是说，网络（大端）阶模的最低有效24位中的最高有效16位。对于所有其他算法，包括私有算法，它被计算为密钥RR的简单校验和，如附录C所述。
The "signer's name" field is the domain name of the signer generating the SIG RR. This is the owner name of the public KEY RR that can be used to verify the signature. It is frequently the zone which contained the RRset being authenticated. Which signers should be authorized to sign what is a significant resolver policy question as discussed in Section 6. The signer's name may be compressed with standard DNS name compression when being transmitted over the network.
“签名者名称”字段是生成SIG RR的签名者的域名。这是可用于验证签名的公钥RR的所有者名称。它通常是包含正在验证的RRset的区域。应授权哪些签署人签署第6节中讨论的重要解决者政策问题。当通过网络传输时，签名者的名称可以使用标准DNS名称压缩进行压缩。
The actual signature portion of the SIG RR binds the other RDATA fields to the RRset of the "type covered" RRs with that owner name and class. This covered RRset is thereby authenticated. To accomplish this, a data sequence is constructed as follows:
SIG RR的实际签名部分将其他RDATA字段绑定到具有该所有者名称和类的“类型覆盖”RRs的RRset。该覆盖RRset因此被认证。为此，数据序列的构造如下：
data = RDATA | RR(s)...
数据=RDATA | RR（s）。。。
where "|" is concatenation,
其中“|”是串联，
RDATA is the wire format of all the RDATA fields in the SIG RR itself (including the canonical form of the signer's name) before but not including the signature, and
RDATA是签名之前（但不包括签名）SIG RR本身中所有RDATA字段（包括签名者姓名的规范形式）的有线格式，以及
RR(s) is the RRset of the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order as defined in Section 8.
RR（s）是第8节中定义的具有与SIG RR相同的所有者名称和类别的RR（s）类型的RRset，其规范形式和顺序如下。
How this data sequence is processed into the signature is algorithm dependent. These algorithm dependent formats and procedures are described in separate documents (Section 3.2).
如何将该数据序列处理为签名取决于算法。这些算法相关的格式和程序在单独的文件中进行了描述（第3.2节）。
SIGs SHOULD NOT be included in a zone for any "meta-type" such as ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
SIG不应包含在任何“元类型”的区域中，如any、AXFR等（但有关IXFR，请参见第5.6.2节）。
A response message from a security aware server may optionally contain a special SIG at the end of the additional information section to authenticate the transaction.
来自安全感知服务器的响应消息可以选择性地在附加信息部分的末尾包含特殊SIG，以验证事务。
This SIG has a "type covered" field of zero, which is not a valid RR type. It is calculated by using a "data" (see Section 4.1.8) of the entire preceding DNS reply message, including DNS header but not the IP header and before the reply RR counts have been adjusted for the inclusion of any transaction SIG, concatenated with the entire DNS query message that produced this response, including the query's DNS header and any request SIGs but not its IP header. That is
此SIG的“类型覆盖”字段为零，这不是有效的RR类型。通过使用前面整个DNS回复消息的“数据”（见第4.1.8节）进行计算，包括DNS报头，但不包括IP报头，并且在调整回复RR计数以包含任何事务SIG之前，与生成此响应的整个DNS查询消息连接，包括查询的DNS头和任何请求SIGs，但不包括其IP头。就是
data = full response (less transaction SIG) | full query
数据=完整响应（更少事务信号）|完整查询
Verification of the transaction SIG (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit, that the response corresponds to the intended query, and that the response comes from the queried server.
请求解析程序对事务SIG（由服务器主机密钥而非区域密钥签名）的验证表明，查询和响应在传输过程中未被篡改，响应与预期查询相对应，并且响应来自被查询的服务器。
A DNS request may be optionally signed by including one or more SIGs at the end of the query. Such SIGs are identified by having a "type covered" field of zero. They sign the preceding DNS request message including DNS header but not including the IP header or any request SIGs at the end and before the request RR counts have been adjusted for the inclusions of any request SIG(s).
DNS请求可以通过在查询末尾包括一个或多个SIG来选择性地签名。此类SIG通过“类型覆盖”字段为零来识别。他们在结束时以及在为包含任何请求SIG而调整请求RR计数之前，对前面的DNS请求消息进行签名，该消息包括DNS报头，但不包括IP报头或任何请求SIG。
WARNING: Request SIGs are unnecessary for any currently defined request other than update [RFC 2136, 2137] and will cause some old DNS servers to give an error return or ignore a query. However, such SIGs may in the future be needed for other requests.
警告：除了更新[RFC 2136，2137]之外，任何当前定义的请求都不需要请求SIG，这将导致一些旧DNS服务器返回错误或忽略查询。然而，将来其他请求可能需要此类SIG。
Except where needed to authenticate an update or similar privileged request, servers are not required to check request SIGs.
除非需要验证更新或类似特权请求，否则服务器不需要检查请求SIG。
Security aware DNS servers SHOULD, for every authenticated RRset the query will return, attempt to send the available SIG RRs which authenticate the requested RRset. The following rules apply to the inclusion of SIG RRs in responses:
对于查询将返回的每个经过身份验证的RRset，具有安全意识的DNS服务器应尝试发送对请求的RRset进行身份验证的可用SIG RRs。以下规则适用于在响应中包含SIG RRs：
1. when an RRset is placed in a response, its SIG RR has a higher priority for inclusion than additional RRs that may need to be included. If space does not permit its inclusion, the response MUST be considered truncated except as provided in 2 below.
1. 在响应中放置RRset时，其SIG RR的包含优先级高于可能需要包含的其他RRs。如果空间不允许将其包含在内，则必须将响应视为截断，除非下文第2条另有规定。
2. When a SIG RR is present in the zone for an additional information section RR, the response MUST NOT be considered truncated merely because space does not permit the inclusion of the SIG RR with the additional information.
2. 当附加信息部分RR的区域中存在SIG RR时，不得仅因为空间不允许包含附加信息的SIG RR而认为响应被截断。
3. SIGs to authenticate glue records and NS RRs for subzones at a delegation point are unnecessary and MUST NOT be sent.
3. 在委派点对子区域的粘合记录和NS RRs进行身份验证的SIG是不必要的，不得发送。
4. If a SIG covers any RR that would be in the answer section of the response, its automatic inclusion MUST be in the answer section. If it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST appear in the additional information section. This is a change in the existing standard [RFCs 1034, 1035] which contemplates only NS and SOA RRs in the authority section.
4. 如果SIG包含响应的应答部分中的任何RR，则其自动包含必须包含在应答部分中。如果它包含将出现在授权部分中的RR，则其自动包含必须在授权部分中。如果它包含将出现在附加信息部分的RR，则它必须出现在附加信息部分。这是对现有标准[RFCs 1034、1035]的更改，该标准在授权部分仅考虑NS和SOA RRs。
5. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section (Section 4.1.8.1). Such SIG RRs are signed by the DNS server originating the response. Although the signer field MUST be a name of the originating server host, the owner name, class, TTL, and original TTL, are meaningless. The class and TTL fields SHOULD be zero. To conserve space, the owner name SHOULD be root (a single zero octet). If transaction authentication is desired, that SIG RR must be considered the highest priority for inclusion.
5. 可选地，DNS事务可在附加信息部分（第4.1.8.1节）的响应结束时由SIG RR进行身份验证。此类SIG RRs由发起响应的DNS服务器签名。尽管签名者字段必须是原始服务器主机的名称，但所有者名称、类、TTL和原始TTL没有意义。类和TTL字段应为零。为节省空间，所有者名称应为root（单个零八位字节）。如果需要事务身份验证，则必须将该SIG RR视为包含的最高优先级。
The following rules apply to the processing of SIG RRs included in a response:
以下规则适用于响应中包含的SIG RRs的处理：
1. A security aware resolver that receives a response from a security aware server via a secure communication with the AD bit (see Section 6.1) set, MAY choose to accept the RRs as received without verifying the zone SIG RRs.
1. 通过与AD位（见第6.1节）设置的安全通信从安全感知服务器接收响应的安全感知解析器可以选择在不验证区域SIG RRs的情况下接收RRs。
2. In other cases, a security aware resolver SHOULD verify the SIG RRs for the RRs of interest. This may involve initiating additional queries for SIG or KEY RRs, especially in the case of
2. 在其他情况下，具有安全意识的解析器应验证感兴趣的RRs的SIG RRs。这可能涉及启动SIG或密钥RRs的额外查询，尤其是在以下情况下：
getting a response from a server that does not implement security. (As explained in 2.3.5 above, it will not be possible to secure CNAMEs being served up by non-secure resolvers.)
从未实现安全性的服务器获取响应。（如上文2.3.5所述，不可能保护由非安全解析器提供的CNAMEs。）
NOTE: Implementers might expect the above SHOULD to be a MUST. However, local policy or the calling application may not require the security services.
注意：实现者可能认为上述内容是必须的。但是，本地策略或呼叫应用程序可能不需要安全服务。
3. If SIG RRs are received in response to a user query explicitly specifying the SIG type, no special processing is required.
3. 如果收到SIG RRs是为了响应明确指定SIG类型的用户查询，则无需特殊处理。
If the message does not pass integrity checks or the SIG does not check against the signed RRs, the SIG RR is invalid and should be ignored. If all of the SIG RR(s) purporting to authenticate an RRset are invalid, then the RRset is not authenticated.
如果消息未通过完整性检查或SIG未根据已签名的RRs进行检查，则SIG RR无效，应忽略。如果声称对RRset进行身份验证的所有SIG RR无效，则该RRset未经身份验证。
If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the response and the query that produced the response. It MAY be optionally checked and the message rejected if the checks fail. But even if the checks succeed, such a transaction authentication SIG does NOT directly authenticate any RRs in the message. Only a proper SIG RR signed by the zone or a key tracing its authority to the zone or to static resolver configuration can directly authenticate RRs, depending on resolver policy (see Section 6). If a resolver does not implement transaction and/or request SIGs, it MUST ignore them without error.
如果SIG RR是附加信息部分中响应中的最后一个RR，并且包含的类型为零，则它是响应和生成响应的查询的事务签名。如果检查失败，可以选择对其进行检查并拒绝消息。但是，即使检查成功，这样的事务身份验证SIG也不会直接对消息中的任何RRs进行身份验证。根据解析程序策略，只有由区域签名的正确SIG RR或跟踪其权限到区域或静态解析程序配置的密钥才能直接对RRs进行身份验证（参见第6节）。如果解析器未实现事务和/或请求SIG，则必须忽略它们而不会出错。
If all checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated.
如果所有检查均表明SIG RR有效，则由其验证的RRs应视为已验证。
Security aware servers MUST NOT consider SIG RRs to authenticate anything before their signature inception or after its expiration time (see also Section 6). Security aware servers MUST NOT consider any RR to be authenticated after all its signatures have expired. When a secure server caches authenticated data, if the TTL would expire at a time further in the future than the authentication expiration time, the server SHOULD trim the TTL in the cache entry not to extent beyond the authentication expiration time. Within these constraints, servers should continue to follow DNS TTL aging. Thus authoritative servers should continue to follow the zone refresh and expire parameters and a non-authoritative server should count down the TTL and discard RRs when the TTL is zero (even for a SIG that has not yet reached its authentication expiration time). In addition, when RRs are transmitted in a query response, the TTL
安全意识服务器在签名开始之前或过期后不能考虑SIG RRS来认证任何东西（也见第6节）。在所有签名都已过期后，安全感知服务器不应考虑任何RR进行身份验证。当安全服务器缓存经过身份验证的数据时，如果TTL将在比身份验证过期时间更远的时间过期，则服务器应修剪缓存项中的TTL，使其不会超出身份验证过期时间。在这些限制条件下，服务器应继续遵循DNS TTL老化。因此，权威服务器应继续遵循区域刷新和过期参数，非权威服务器应在TTL为零时倒计时TTL并丢弃RRs（即使对于尚未达到其身份验证过期时间的SIG）。此外，当在查询响应中传输RRs时，TTL
should be trimmed so that current time plus the TTL does not extend beyond the authentication expiration time. Thus, in general, the TTL on a transmitted RR would be
应进行修剪，以便当前时间加上TTL不会超过身份验证到期时间。因此，一般来说，发送的RR上的TTL是
min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
When signatures are generated, signature expiration times should be set far enough in the future that it is quite certain that new signatures can be generated before the old ones expire. However, setting expiration too far into the future could mean a long time to flush any bad data or signatures that may have been generated.
在生成签名时，签名过期时间应设置得足够长，以便在旧签名过期之前可以生成新签名。但是，将到期时间设置得太晚可能意味着需要很长时间来清除可能已生成的任何错误数据或签名。
It is recommended that signature lifetime be a small multiple of the TTL (ie, 4 to 16 times the TTL) but not less than a reasonable maximum re-signing interval and not less than the zone expiry time.
建议签名寿命为TTL的小倍数（即TTL的4到16倍），但不小于合理的最大重新签名间隔，也不小于区域到期时间。
The SIG RR mechanism described in Section 4 above provides strong authentication of RRs that exist in a zone. But it is not clear above how to verifiably deny the existence of a name in a zone or a type for an existent name.
上文第4节中描述的SIG RR机制为区域中存在的RRs提供了强身份验证。但上面还不清楚如何以可验证的方式拒绝区域中的名称或现有名称的类型的存在。
The nonexistence of a name in a zone is indicated by the NXT ("next") RR for a name interval containing the nonexistent name. An NXT RR or RRs and its or their SIG(s) are returned in the authority section, along with the error, if the server is security aware. The same is true for a non-existent type under an existing name except that there is no error indication other than an empty answer section accompanying the NXT(s). This is a change in the existing standard [RFCs 1034/1035] which contemplates only NS and SOA RRs in the authority section. NXT RRs will also be returned if an explicit query is made for the NXT type.
区域中名称的不存在由包含不存在名称的名称间隔的NXT（“next”）RR表示。如果服务器具有安全意识，则NXT RR或RRs及其SIG将与错误一起返回到授权部分。对于现有名称下不存在的类型也是如此，除了NXT附带的空应答部分之外，没有其他错误指示。这是对现有标准[RFCs 1034/1035]的更改，该标准在授权部分仅考虑NS和SOA RRs。如果对NXT类型进行显式查询，也将返回NXT RRs。
The existence of a complete set of NXT records in a zone means that any query for any name and any type to a security aware server serving the zone will result in an reply containing at least one signed RR unless it is a query for delegation point NS or glue A or AAAA RRs.
区域中存在一组完整的NXT记录意味着对服务于该区域的安全感知服务器的任何名称和任何类型的查询将导致至少包含一个已签名RR的回复，除非它是对委派点NS或粘合a或AAAA RRs的查询。
The NXT resource record is used to securely indicate that RRs with an owner name in a certain name interval do not exist in a zone and to indicate what RR types are present for an existing name.
NXT资源记录用于安全地指示区域中不存在所有者名称在特定名称间隔内的RR，并指示现有名称的RR类型。
The owner name of the NXT RR is an existing name in the zone. It's RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone create a chain of all of the literal owner names in that zone, including unexpanded wildcards but omitting the owner name of glue address records unless they would otherwise be included. This implies a canonical ordering of all domain names in a zone as described in Section 8. The presence of the NXT RR means that no name between its owner name and the name in its RDATA area exists and that no other types exist under its owner name.
NXT RR的所有者名称是区域中的现有名称。它的RDATA是“下一个”名称和类型位图。因此，区域中的NXT RRs创建该区域中所有文字所有者名称的链，包括未扩展的通配符，但省略粘合地址记录的所有者名称，除非它们将被包括在内。这意味着区域中所有域名的规范排序，如第8节所述。NXT RR的存在意味着其所有者名称与其RDATA区域中的名称之间不存在任何名称，并且其所有者名称下不存在其他类型。
There is a potential problem with the last NXT in a zone as it wants to have an owner name which is the last existing name in canonical order, which is easy, but it is not obvious what name to put in its RDATA to indicate the entire remainder of the name space. This is handled by treating the name space as circular and putting the zone name in the RDATA of the last NXT in a zone.
区域中的最后一个NXT存在一个潜在问题，因为它希望拥有一个所有者名称，该名称是规范顺序中的最后一个现有名称，这很容易，但在其RDATA中输入什么名称来指示名称空间的整个剩余部分并不明显。这是通过将名称空间视为循环并将区域名称放在区域中最后一个NXT的RDATA中来处理的。
The NXT RRs for a zone SHOULD be automatically calculated and added to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed the zone minimum TTL.
当添加SIG时，应自动计算区域的NXT RRs并将其添加到区域中。NXT RR的TTL不应超过区域最小TTL。
The type number for the NXT RR is 30.
NXT RR的类型编号为30。
NXT RRs are only signed by zone level keys.
NXT RRs仅由区域级密钥签名。
The RDATA for an NXT RR consists simply of a domain name followed by a bit map, as shown below.
NXT RR的RDATA仅由域名和位图组成，如下所示。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next domain name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type bit map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next domain name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type bit map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NXT RR type bit map format currently defined is one bit per RR type present for the owner name. A one bit indicates that at least one RR of that type is present for the owner name. A zero indicates that no such RR is present. All bits not specified because they are beyond the end of the bit map are assumed to be zero. Note that bit 30, for NXT, will always be on so the minimum bit map length is actually four octets. Trailing zero octets are prohibited in this format. The first bit represents RR type zero (an illegal type which can not be present) and so will be zero in this format. This format is not used if there exists an RR with a type number greater than
当前定义的NXT RR类型位映射格式为所有者名称的每个RR类型一位。一位表示所有者名称至少存在一个该类型的RR。零表示不存在此类RR。由于超出位图末尾而未指定的所有位均假定为零。请注意，对于NXT，位30将始终打开，因此最小位图长度实际上是四个八位字节。此格式中禁止尾随零八位字节。第一位表示RR类型零（一种不存在的非法类型），因此在该格式中为零。如果存在类型号大于的RR，则不使用此格式
127. If the zero bit of the type bit map is a one, it indicates that a different format is being used which will always be the case if a type number greater than 127 is present.
127如果类型位映射的零位为1，则表示正在使用不同的格式，如果存在大于127的类型号，则始终如此。
The domain name may be compressed with standard DNS name compression when being transmitted over the network. The size of the bit map can be inferred from the RDLENGTH and the length of the next domain name.
当通过网络传输域名时，可以使用标准DNS名称压缩来压缩域名。位图的大小可以从RDLENGTH和下一个域名的长度推断出来。
Proving that a non-existent name response is correct or that a wildcard expansion response is correct makes things a little more complex.
证明一个不存在的名称响应是正确的，或者一个通配符扩展响应是正确的，这会使事情更加复杂。
In particular, when a non-existent name response is returned, an NXT must be returned showing that the exact name queried did not exist and, in general, one or more additional NXT's need to be returned to also prove that there wasn't a wildcard whose expansion should have been returned. (There is no need to return multiple copies of the same NXT.) These NXTs, if any, are returned in the authority section of the response.
特别是，当返回一个不存在的名称响应时，必须返回一个NXT，表明所查询的确切名称不存在，并且通常还需要返回一个或多个额外的NXT，以证明不存在应返回其扩展名的通配符。（不需要返回同一NXT的多个副本。）这些NXT（如果有）将在响应的授权部分中返回。
Furthermore, if a wildcard expansion is returned in a response, in general one or more NXTs needs to also be returned in the authority section to prove that no more specific name (including possibly more specific wildcards in the zone) existed on which the response should have been based.
此外，如果在响应中返回通配符扩展，通常还需要在授权部分中返回一个或多个NXT，以证明不存在响应应基于的更具体的名称（可能包括区域中更具体的通配符）。
Assume zone foo.nil has entries for
假设zone foo.nil中有
big.foo.nil, medium.foo.nil. small.foo.nil. tiny.foo.nil.
大，无，中，无。small.foo.nil。tiny.foo.nil。
Then a query to a security aware server for huge.foo.nil would produce an error reply with an RCODE of NXDOMAIN and the authority section data including something like the following:
然后，对具有安全意识的服务器进行的查询（针对巨人.foo.nil）将生成一个错误回复，其RCODE为NXDOMAIN，权限部分数据包括以下内容：
foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 19970102030405 ;signature expiration 19961211100908 ;signature inception 2143 ;key identifier foo.nil. ;signer AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) ) big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 19970102030405 ;signature expiration 19961211100908 ;signature inception 2143 ;key identifier foo.nil. ;signer MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) ) Note that this response implies that big.foo.nil is an existing name in the zone and thus has other RR types associated with it than NXT. However, only the NXT (and its SIG) RR appear in the response to this query for huge.foo.nil, which is a non-existent name.
零。NXT big.foo.nil NS KEY SOA NXT；证明没有*.foo.nil foo.nil。SIG NXT 1 2（；type cov=NXT，alg=1，labels=2 1997010203405；签名过期19961211100908；签名起始2143；密钥标识符foo.nil；签名者AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfbeh1efhffelxbvkowmvjdtc fiy2x+8xpfjjwich398kzmklxovpz2fnctm=；签名（640位））big.foo.nil。NXT medium.foo.nil。MX-SIG-NXT；证明没有大的。foo.nil大的。foo.nil。SIG NXT 1 3（；type cov=NXT，alg=1，labels=3 1997010203405；签名过期19961211100908；签名起始2143；密钥标识符foo.nil；签名者MxFcby9k/yvedmfqgkzhhh5er0mu/vilz45ikskcefcegiwcn/gxhai6vauhaonuz4you 1tvfscsqyn6//11U6Nld80jEeC8aTrO+kkmay=；签名（640位））请注意，此响应意味着big.foo.nil是区域中的现有名称，因此与它关联的RR类型不是NXT。但是，只有NXT（及其SIG）RR出现在对这个查询的响应中，它是一个不存在的名称。
A name (other than root) which is the head of a zone also appears as the leaf in a superzone. If both are secure, there will always be two different NXT RRs with the same name. They can be easily distinguished by their signers, the next domain name fields, the presence of the SOA type bit, etc. Security aware servers should return the correct NXT automatically when required to authenticate the non-existence of a name and both NXTs, if available, on explicit query for type NXT.
作为分区头部的名称（而不是根）也会显示为超级分区中的叶。如果两者都是安全的，则始终会有两个名称相同的不同NXT RRs。可以通过签名者、下一个域名字段、是否存在SOA类型位等轻松区分它们。当需要验证名称不存在时，安全感知服务器应自动返回正确的NXT，如果NXT可用，则在显式查询NXT类型时，同时返回两个NXT。
Non-security aware servers will never automatically return an NXT and some old implementations may only return the NXT from the subzone on explicit queries.
无安全意识的服务器永远不会自动返回NXT，一些旧的实现可能只会在显式查询时从子区域返回NXT。
The subsections below describe how full and incremental zone transfers are secured.
下面的小节描述了完整和增量区域传输的安全性。
SIG RRs secure all authoritative RRs transferred for both full and incremental [RFC 1995] zone transfers. NXT RRs are an essential element in secure zone transfers and assure that every authoritative name and type will be present; however, if there are multiple SIGs with the same name and type covered, a subset of the SIGs could be
SIG RRs保护所有传输的权威RRs，用于完整和增量[RFC 1995]区域传输。NXT RRs是安全区域传输中的一个基本元素，确保每个权威名称和类型都会出现；但是，如果有多个包含相同名称和类型的SIG，则可以使用SIG的子集
sent as long as at least one is present and, in the case of unsigned delegation point NS or glue A or AAAA RRs a subset of these RRs or simply a modified set could be sent as long as at least one of each type is included.
只要至少有一个存在，就可以发送，如果是未签名的委托点NS或粘合A或AAAA RRs，则可以发送这些RRs的子集或只是一个修改集，只要每个类型中至少包含一个。
When an incremental or full zone transfer request is received with the same or newer version number than that of the server's copy of the zone, it is replied to with just the SOA RR of the server's current version and the SIG RRset verifying that SOA RR.
当接收到的增量或完整区域传输请求的版本号与服务器的区域副本的版本号相同或更新时，将仅使用服务器当前版本的SOA RR和验证SOA RR的SIG RRset来响应该请求。
The complete NXT chains specified in this document enable a resolver to obtain, by successive queries chaining through NXTs, all of the names in a zone even if zone transfers are prohibited. Different format NXTs may be specified in the future to avoid this.
本文档中指定的完整NXT链使解析器能够通过NXT链接的连续查询获得区域中的所有名称，即使区域传输被禁止。为了避免这种情况，将来可能会指定不同格式的NXT。
To provide server authentication that a complete transfer has occurred, transaction authentication SHOULD be used on full zone transfers. This provides strong server based protection for the entire zone in transit.
要提供已发生完全传输的服务器身份验证，应在完整区域传输上使用事务身份验证。这为传输中的整个区域提供了强大的基于服务器的保护。
Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be verified in the same way as for a full zone transfer and the integrity of the NXT name chain and correctness of the NXT type bits for the zone after the incremental RR deletes and adds can check each disjoint area of the zone updated. But the completeness of an incremental transfer can not be confirmed because usually neither the deleted RR section nor the added RR section has a compete zone NXT chain. As a result, a server which securely supports IXFR must handle IXFR SIG RRs for each incremental transfer set that it maintains.
增量（IXFR）传输[RFC 1995]中的单个RRs可通过与完整区域传输相同的方式进行验证，增量RR删除和添加后，NXT名称链的完整性和区域NXT类型位的正确性可检查更新区域的每个不相交区域。但无法确认增量传输的完整性，因为通常删除的RR段和添加的RR段都没有竞争区NXT链。因此，安全支持IXFR的服务器必须为其维护的每个增量传输集处理IXFR SIG RRs。
The IXFR SIG is calculated over the incremental zone update collection of RRs in the order in which it is transmitted: old SOA, then deleted RRs, then new SOA and added RRs. Within each section, RRs must be ordered as specified in Section 8. If condensation of adjacent incremental update sets is done by the zone owner, the original IXFR SIG for each set included in the condensation must be discarded and a new on IXFR SIG calculated to cover the resulting condensed set.
IXFR SIG按照传输顺序在RRs的增量区域更新集合上计算：旧SOA、删除的RRs、新SOA和添加的RRs。在每个章节中，必须按照第8节的规定订购RRs。如果相邻增量更新集的压缩由区域所有者完成，则必须丢弃压缩中包含的每个集的原始IXFR SIG，并计算一个新的on IXFR SIG以覆盖生成的压缩集。
The IXFR SIG really belongs to the zone as a whole, not to the zone name. Although it SHOULD be correct for the zone name, the labels field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only sent as part of an incremental zone transfer. After validation of
IXFR SIG实际上属于整个区域，而不是区域名称。尽管区域名称应该正确，但IXFR SIG的标签字段在其他方面没有意义。IXFR SIG仅作为增量区域传输的一部分发送。验证后
the IXFR SIG, the transferred RRs MAY be considered valid without verification of the internal SIGs if such trust in the server conforms to local policy.
如果服务器中的这种信任符合本地策略，则在不验证内部SIG的情况下，可以认为IXFR SIG、传输的RRs是有效的。
Retrieving or resolving secure data from the Domain Name System (DNS) involves starting with one or more trusted public keys that have been staticly configured at the resolver. With starting trusted keys, a resolver willing to perform cryptography can progress securely through the secure DNS structure to the zone of interest as described in Section 6.3. Such trusted public keys would normally be configured in a manner similar to that described in Section 6.2. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as if it were staticly configured.
从域名系统（DNS）检索或解析安全数据涉及从一个或多个已在解析程序中静态配置的受信任公钥开始。启动受信任密钥后，愿意执行加密的解析器可以安全地通过安全DNS结构进入第6.3节所述的关注区域。此类受信任公钥的配置方式通常与第6.2节所述方式类似。但是，实际上，即使未使用任何密钥进行配置，但安全感知解析器仍会对其返回的结果获得一定的信任，就像静态配置一样，信任从本地知名服务器获得的结果。
Data stored at a security aware server needs to be internally categorized as Authenticated, Pending, or Insecure. There is also a fourth transient state of Bad which indicates that all SIG checks have explicitly failed on the data. Such Bad data is not retained at a security aware server. Authenticated means that the data has a valid SIG under a KEY traceable via a chain of zero or more SIG and KEY RRs allowed by the resolvers policies to a KEY staticly configured at the resolver. Pending data has no authenticated SIGs and at least one additional SIG the resolver is still trying to authenticate. Insecure data is data which it is known can never be either Authenticated or found Bad in the zone where it was found because it is in or has been reached via a unsecured zone or because it is unsigned glue address or delegation point NS data. Behavior in terms of control of and flagging based on such data labels is described in Section 6.1.
存储在安全感知服务器上的数据需要在内部分类为已验证、挂起或不安全。还有第四个瞬态Bad，表示所有SIG检查在数据上都显式失败。此类不良数据不会保留在具有安全意识的服务器上。认证意味着数据在密钥下具有有效的SIG，该密钥可通过冲突解决程序策略允许的零个或多个SIG和密钥RRs链追踪到在冲突解决程序静态配置的密钥。挂起数据没有经过身份验证的SIG，冲突解决程序至少还有一个SIG仍在尝试进行身份验证。不安全数据是指已知的数据，因为它位于或已通过不安全区域到达，或者因为它是未签名的粘合地址或委派点NS数据，所以在发现它的区域中永远无法进行身份验证或发现它不正确。第6.1节描述了基于此类数据标签的控制和标记行为。
The proper validation of signatures requires a reasonably secure shared opinion of the absolute time between resolvers and servers as described in Section 6.4.
如第6.4节所述，签名的正确验证需要对解析程序和服务器之间的绝对时间进行合理安全的共享意见。
Two previously unused bits are allocated out of the DNS query/response format header. The AD (authentic data) bit indicates in a response that all the data included in the answer and authority portion of the response has been authenticated by the server according to the policies of that server. The CD (checking disabled) bit indicates in a query that Pending (non-authenticated) data is acceptable to the resolver sending the query.
从DNS查询/响应格式标头中分配两个以前未使用的位。AD（真实数据）位在响应中指示响应的应答和授权部分中包括的所有数据已经由服务器根据该服务器的策略进行了身份验证。CD（检查禁用）位表示查询中发送查询的解析程序可以接受挂起（未经身份验证）数据。
These bits are allocated from the previously must-be-zero Z field as follows:
这些位是从之前必须为零的Z字段分配的，如下所示：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These bits are zero in old servers and resolvers. Thus the responses of old servers are not flagged as authenticated to security aware resolvers and queries from non-security aware resolvers do not assert the checking disabled bit and thus will be answered by security aware servers only with Authenticated or Insecure data. Security aware resolvers MUST NOT trust the AD bit unless they trust the server they are talking to and either have a secure path to it or use DNS transaction security.
这些位在旧服务器和解析器中为零。因此，旧服务器的响应不会被标记为对安全感知的解析程序进行了身份验证，而来自非安全感知的解析程序的查询不会断言检查禁用位，因此安全感知的服务器只会使用经过身份验证或不安全的数据来回答。具有安全意识的解析程序不得信任AD位，除非它们信任与之对话的服务器，并且具有到该服务器的安全路径或使用DNS事务安全性。
Any security aware resolver willing to do cryptography SHOULD assert the CD bit on all queries to permit it to impose its own policies and to reduce DNS latency time by allowing security aware servers to answer with Pending data.
任何愿意进行加密的具有安全意识的解析器都应该在所有查询上声明CD位，以允许其实施自己的策略，并通过允许具有安全意识的服务器使用挂起的数据进行应答来减少DNS延迟时间。
Security aware servers MUST NOT return Bad data. For non-security aware resolvers or security aware resolvers requesting service by having the CD bit clear, security aware servers MUST return only Authenticated or Insecure data in the answer and authority sections with the AD bit set in the response. Security aware servers SHOULD return Pending data, with the AD bit clear in the response, to security aware resolvers requesting this service by asserting the CD bit in their request. The AD bit MUST NOT be set on a response unless all of the RRs in the answer and authority sections of the response are either Authenticated or Insecure. The AD bit does not cover the additional information section.
具有安全意识的服务器不得返回错误数据。对于非安全感知的解析程序或通过清除CD位请求服务的安全感知解析程序，安全感知服务器必须在应答和授权部分仅返回经过身份验证或不安全的数据，并在应答中设置AD位。安全感知服务器应通过在其请求中声明CD位，向请求此服务的安全感知解析程序返回挂起数据，并在响应中清除AD位。除非响应的应答和授权部分中的所有RRs都经过身份验证或不安全，否则不得在响应上设置AD位。AD位不包括附加信息部分。
The public key to authenticate a zone SHOULD be defined in local configuration files before that zone is loaded at the primary server so the zone can be authenticated.
在主服务器上加载区域之前，应该在本地配置文件中定义用于验证区域的公钥，以便对该区域进行身份验证。
While it might seem logical for everyone to start with a public key associated with the root zone and staticly configure this in every resolver, this has problems. The logistics of updating every DNS resolver in the world should this key ever change would be severe. Furthermore, many organizations will explicitly wish their "interior" DNS implementations to completely trust only their own DNS servers. Interior resolvers of such organizations can then go through the organization's zone servers to access data outside the organization's domain and need not be configured with keys above the organization's DNS apex.
对于每个人来说，从与根区域关联的公钥开始并在每个解析器中静态地配置它似乎是合乎逻辑的，但这有问题。如果这个密钥发生变化，更新世界上每一个DNS解析器的后勤工作将非常艰巨。此外，许多组织明确希望其“内部”DNS实现只完全信任自己的DNS服务器。然后，此类组织的内部解析程序可以通过组织的区域服务器访问组织域之外的数据，而无需使用组织DNS顶点上方的密钥进行配置。
Host resolvers that are not part of a larger organization may be configured with a key for the domain of their local ISP whose recursive secure DNS caching server they use.
不属于较大组织的主机解析程序可能配置有其本地ISP域的密钥，该ISP使用递归安全DNS缓存服务器。
Starting with one or more trusted keys for any zone, it should be possible to retrieve signed keys for that zone's subzones which have a key. A secure sub-zone is indicated by a KEY RR with non-null key information appearing with the NS RRs in the sub-zone and which may also be present in the parent. These make it possible to descend within the tree of zones.
从任何区域的一个或多个受信任密钥开始，应该可以检索该区域具有密钥的子区域的签名密钥。安全子区域由密钥RR表示，其中非空密钥信息与子区域中的NS RRs一起出现，并且也可能出现在父区域中。这使得在区域树内下降成为可能。
In general, some RRset that you wish to validate in the secure DNS will be signed by one or more SIG RRs. Each of these SIG RRs has a signer under whose name is stored the public KEY to use in authenticating the SIG. Each of those KEYs will, generally, also be signed with a SIG. And those SIGs will have signer names also referring to KEYs. And so on. As a result, authentication leads to chains of alternating SIG and KEY RRs with the first SIG signing the original data whose authenticity is to be shown and the final KEY being some trusted key staticly configured at the resolver performing the authentication.
通常，您希望在安全DNS中验证的某些RRset将由一个或多个SIG RRs签名。这些SIG RRs中的每一个都有一个签名者，签名者的姓名下存储了用于验证SIG的公钥。通常，这些密钥中的每一个都将使用SIG进行签名。这些SIG将有签名者的名字，也指密钥。等等因此，身份验证导致交替SIG和密钥RRs链，第一个SIG对原始数据进行签名，原始数据的真实性将被显示，最终密钥是在执行身份验证的解析程序中静态配置的某个可信密钥。
In testing such a chain, the validity periods of the SIGs encountered must be intersected to determine the validity period of the authentication of the data, a purely algorithmic process. In addition, the validation of each SIG over the data with reference to a KEY must meet the objective cryptographic test implied by the
在测试这样一个链时，遇到的SIG的有效期必须相交，以确定数据认证的有效期，这是一个纯粹的算法过程。此外，针对密钥对数据的每个SIG的验证必须满足
cryptographic algorithm used (although even here the resolver may have policies as to trusted algorithms and key lengths). Finally, the judgement that a SIG with a particular signer name can authenticate data (possibly a KEY RRset) with a particular owner name, is primarily a policy question. Ultimately, this is a policy local to the resolver and any clients that depend on that resolver's decisions. It is, however, recommended, that the policy below be adopted:
使用的加密算法（尽管即使在这里，解析器也可能有关于可信算法和密钥长度的策略）。最后，判断具有特定签名者名称的SIG可以使用特定所有者名称对数据（可能是密钥RRset）进行身份验证，这主要是一个策略问题。最终，这是冲突解决程序和依赖于该冲突解决程序决策的任何客户端的本地策略。但是，建议采取以下政策：
Let A < B mean that A is a shorter domain name than B formed by dropping one or more whole labels from the left end of B, i.e., A is a direct or indirect superdomain of B. Let A = B mean that A and B are the same domain name (i.e., are identical after letter case canonicalization). Let A > B mean that A is a longer domain name than B formed by adding one or more whole labels on the left end of B, i.e., A is a direct or indirect subdomain of B
设A<B表示A是比B短的域名，B是从B的左端删除一个或多个完整标签形成的，即A是B的直接或间接超域。设A=B表示A和B是相同的域名（即，在字母大小写规范化后相同）。设A>B表示A是比B更长的域名，B是通过在B的左端添加一个或多个完整标签形成的，即A是B的直接或间接子域
Let Static be the owner names of the set of staticly configured trusted keys at a resolver.
让Static成为解析程序中静态配置的受信任密钥集的所有者名称。
Then Signer is a valid signer name for a SIG authenticating an RRset (possibly a KEY RRset) with owner name Owner at the resolver if any of the following three rules apply:
然后，Signer是SIG的有效签名者名称，如果以下三条规则中的任何一条适用，则Signer在解析程序中使用所有者名称owner对RRset（可能是密钥RRset）进行身份验证：
(1) Owner > or = Signer (except that if Signer is root, Owner must be root or a top level domain name). That is, Owner is the same as or a subdomain of Signer.
(1) 所有者>或=签名者（除非签名者是root，所有者必须是root或顶级域名）。也就是说，所有者与签名者相同或是签名者的子域。
(2) ( Owner < Signer ) and ( Signer > or = some Static ). That is, Owner is a superdomain of Signer and Signer is staticly configured or a subdomain of a staticly configured key.
(2) （所有者<签名者）和（签名者>或=某些静态）。也就是说，所有者是签名者的超域，而签名者是静态配置的，或者是静态配置密钥的子域。
(3) Signer = some Static. That is, the signer is exactly some staticly configured key.
(3) 签名者=一些静态的。也就是说，签名者就是某个静态配置的密钥。
Rule 1 is the rule for descending the DNS tree and includes a special prohibition on the root zone key due to the restriction that the root zone be only one label deep. This is the most fundamental rule.
规则1是用于降低DNS树的规则，包括对根区域密钥的特殊禁止，因为限制根区域只有一个标签深度。这是最基本的规则。
Rule 2 is the rule for ascending the DNS tree from one or more staticly configured keys. Rule 2 has no effect if only root zone keys are staticly configured.
规则2是从一个或多个静态配置的密钥提升DNS树的规则。如果仅静态配置根区域键，则规则2无效。
Rule 3 is a rule permitting direct cross certification. Rule 3 has no effect if only root zone keys are staticly configured.
规则3是允许直接交叉认证的规则。如果仅静态配置根区域键，则规则3无效。
Great care should be taken that the consequences have been fully considered before making any local policy adjustments to these rules (other than dispensing with rules 2 and 3 if only root zone keys are staticly configured).
在对这些规则进行任何本地策略调整之前，应特别注意充分考虑后果（如果仅静态配置根区域密钥，则不使用规则2和3）。
It is possible that there will be multiple SIG-KEY chains that appear to authenticate conflicting RRset answers to the same query. A resolver should choose only the most reliable answer to return and discard other data. This choice of most reliable is a matter of local policy which could take into account differing trust in algorithms, key sizes, staticly configured keys, zones traversed, etc. The technique given below is recommended for taking into account SIG-KEY chain length.
可能会有多个SIG-KEY链对同一查询的冲突RRset答案进行身份验证。解析程序应该只选择最可靠的答案来返回和丢弃其他数据。最可靠的选择取决于本地策略，该策略可以考虑算法、密钥大小、静态配置的密钥、遍历的区域等方面的不同信任。建议使用下面给出的技术来考虑SIG-key链长度。
A resolver should keep track of the number of successive secure zones traversed from a staticly configured key starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Staticly configured data should be given a distance number of zero. If a query encounters different Authenticated data for the same query with different distance values, that with a larger value should be ignored unless some other local policy covers the case.
冲突解决程序应该跟踪从静态配置的密钥起点到它可以到达的任何安全区域的连续安全区域的数量。一般来说，距离数越小，数据的可信度越高。静态配置数据的距离数应为零。如果查询遇到具有不同距离值的同一查询的不同身份验证数据，则应忽略具有较大值的数据，除非其他本地策略涵盖此情况。
A security conscious resolver should completely refuse to step from a secure zone into a unsecured zone unless the unsecured zone is certified to be non-secure by the presence of an authenticated KEY RR for the unsecured zone with the no-key type value. Otherwise the resolver is getting bogus or spoofed data.
具有安全意识的冲突解决程序应完全拒绝从安全区域跨入不安全区域，除非不安全区域通过无密钥类型值的不安全区域的已验证密钥RR的存在被证明为不安全。否则，解析程序将获取伪造或伪造的数据。
If legitimate unsecured zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the unsecured zone data could have been spoofed, the "secure" zone reached via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 256 or more as this exceeds the largest possible distance through secure zones in the DNS.
如果在遍历DNS树时遇到合法的不安全区域，则任何区域都不能被信任为安全区域，只能通过来自此类不安全区域的信息访问这些区域。由于不安全区域数据可能是伪造的，因此通过它到达的“安全”区域可能是伪造的。与此类区域中的数据或通过此类区域到达的区域的“距离”可以设置为256或更多，因为这超过了通过DNS中安全区域的最大可能距离。
Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions.
SIG RRs中时间字段的协调解释要求实现DNS安全扩展的主机具有合理一致的可用时间。
A variety of time synchronization protocols exist including the Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are used, they MUST be used securely so that time can not be spoofed.
存在多种时间同步协议，包括网络时间协议（NTP[RFC 13052030]）。如果使用此类协议，则必须安全地使用这些协议，以便时间不会被欺骗。
Otherwise, for example, a host could get its clock turned back and might then believe old SIG RRs, and the data they authenticate, which were valid but are no longer.
否则，例如，主机可能会将其时钟调回，然后可能会相信旧的SIG RRs以及它们验证的数据，这些数据是有效的，但不再有效。
This section discusses the format for master file and other ASCII presentation of the three DNS security resource records.
本节讨论三个DNS安全资源记录的主文件格式和其他ASCII表示形式。
The algorithm field in KEY and SIG RRs can be represented as either an unsigned integer or symbolicly. The following initial symbols are defined as indicated:
KEY和SIG RRs中的算法字段可以表示为无符号整数或符号。以下初始符号的定义如图所示：
Value Symbol
价值符号
001 RSAMD5 002 DH 003 DSA 004 ECC 252 INDIRECT 253 PRIVATEDNS 254 PRIVATEOID
001 RSAMD5 002 DH 003 DSA 004 ECC 252间接253私有DNS 254私有类
KEY RRs may appear as single logical lines in a zone data master file [RFC 1033].
密钥RRs可能在区域数据主文件[RFC 1033]中显示为单个逻辑行。
The flag field is represented as an unsigned integer or a sequence of mnemonics as follows separated by instances of the verticle bar ("|") character:
标志字段表示为无符号整数或助记符序列，如下所示，由垂直条（“|”）字符的实例分隔：
BIT Mnemonic Explanation 0-1 key type NOCONF =1 confidentiality use prohibited NOAUTH =2 authentication use prohibited NOKEY =3 no key present 2 FLAG2 - reserved 3 EXTEND flags extension 4 FLAG4 - reserved 5 FLAG5 - reserved 6-7 name type USER =0 (default, may be omitted) ZONE =1 HOST =2 (host or other end entity) NTYP3 - reserved 8 FLAG8 - reserved 9 FLAG9 - reserved
位助记符解释0-1密钥类型NOCONF=1机密性使用禁止的NOAUTH=2身份验证使用禁止的NOKEY=3不存在密钥2标志2-保留3扩展标志扩展4标志4-保留5标志5-保留6-7名称类型用户=0（默认，可省略）区域=1主机=2（主机或其他终端实体）NTYP3-保留8个标志8-保留9个标志9-保留
10 FLAG10 - reserved 11 FLAG11 - reserved 12-15 signatory field, values 0 to 15 can be represented by SIG0, SIG1, ... SIG15
10-FLAG10-保留11-FLAG11-保留12-15签名字段，值0到15可由SIG0、SIG1、。。。信号15
No flag mnemonic need be present if the bit or field it represents is zero.
如果标志助记符所代表的位或字段为零，则不需要出现标志助记符。
The protocol octet can be represented as either an unsigned integer or symbolicly. The following initial symbols are defined:
协议八位字节可以表示为无符号整数或符号。定义了以下初始符号：
000 NONE 001 TLS 002 EMAIL 003 DNSSEC 004 IPSEC 255 ALL
000无001 TLS 002电子邮件003 DNSSEC 004 IPSEC 255全部
Note that if the type flags field has the NOKEY value, nothing appears after the algorithm octet.
请注意，如果type flags字段具有NOKEY值，则算法八位字节后不会显示任何内容。
The remaining public key portion is represented in base 64 (see Appendix A) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can span lines using the standard parenthesis.
剩余的公钥部分以基数64表示（见附录A），并可分成任意数量的空格分隔的子串，直至单个基数64位，这些子串被连接以获得完整签名。这些子字符串可以使用标准括号跨行。
Note that the public key may have internal sub-fields but these do not appear in the master file representation. For example, with algorithm 1 there is a public exponent size, then a public exponent, and then a modulus. With algorithm 254, there will be an OID size, an OID, and algorithm dependent information. But in both cases only a single logical base 64 string will appear in the master file.
请注意，公钥可能有内部子字段，但这些子字段不会出现在主文件表示中。例如，对于算法1，有一个公共指数大小，然后是一个公共指数，然后是一个模。对于算法254，将有OID大小、OID和与算法相关的信息。但在这两种情况下，主文件中只会出现一个逻辑基64字符串。
A data SIG RR may be represented as a single logical line in a zone data file [RFC 1033] but there are some special considerations as described below. (It does not make sense to include a transaction or request authenticating SIG RR in a file as they are a transient authentication that covers data including an ephemeral transaction number and so must be calculated in real time.)
数据SIG RR可以表示为区域数据文件[RFC 1033]中的单个逻辑线，但有一些特殊注意事项，如下所述。（在文件中包含对SIG RR进行身份验证的事务或请求是没有意义的，因为它们是一种临时身份验证，涵盖了包括临时事务编号在内的数据，因此必须实时计算。）
There is no particular problem with the signer, covered type, and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59).
签名者、覆盖类型和时间没有特别的问题。时间字段以YYYYMMDDHMMSS的形式出现，其中YYYY是年，第一个MM是月号（01-12），DD是月的一天（01-31），HH是以24小时表示的小时（00-23），第二个MM是分钟（00-59），SS是第二个（00-59）。
The original TTL field appears as an unsigned integer.
原始TTL字段显示为无符号整数。
If the original TTL, which applies to the type signed, is the same as the TTL of the SIG RR itself, it may be omitted. The date field which follows it is larger than the maximum possible TTL so there is no ambiguity.
如果应用于已签名类型的原始TTL与SIG RR本身的TTL相同，则可以省略它。它后面的日期字段大于最大可能TTL，因此不存在歧义。
The "labels" field appears as an unsigned integer.
“标签”字段显示为无符号整数。
The key tag appears as an unsigned number.
键标记显示为无符号数字。
However, the signature itself can be very long. It is the last data field and is represented in base 64 (see Appendix A) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can be split between lines using the standard parenthesis.
但是，签名本身可能很长。它是最后一个数据字段，以基数64表示（见附录A），可分为任意数量的空格分隔的子字符串，下至单个基数64位，这些子字符串被连接以获得完整签名。可以使用标准括号在行之间拆分这些子字符串。
NXT RRs do not appear in original unsigned zone master files since they should be derived from the zone as it is being signed. If a signed file with NXTs added is printed or NXTs are printed by debugging code, they appear as the next domain name followed by the RR type present bits as an unsigned interger or sequence of RR mnemonics.
NXT RRs不会出现在原始的未签名区域主文件中，因为它们应该在被签名的区域中派生出来。如果打印添加了NXT的已签名文件，或者通过调试代码打印了NXT，则它们将显示为下一个域名，后跟RR类型present位，作为无符号整数或RR助记符序列。
This section specifies, for purposes of domain name system (DNS) security, the canonical form of resource records (RRs), their name order, and their overall order. A canonical name order is necessary to construct the NXT name chain. A canonical form and ordering within an RRset is necessary in consistently constructing and verifying SIG RRs. A canonical ordering of types within a name is required in connection with incremental transfer (Section 5.6.2).
出于域名系统（DNS）安全的目的，本节规定了资源记录（RRs）的规范形式、名称顺序和总体顺序。构造NXT名称链需要规范的名称顺序。在一致构造和验证SIG RRs时，RRs集中的规范形式和顺序是必要的。在增量传输中，需要对名称中的类型进行规范化排序（第5.6.2节）。
For purposes of DNS security, the canonical form for an RR is the wire format of the RR with domain names (1) fully expanded (no name compression via pointers), (2) all domain name letters set to lower case, (3) owner name wild cards in master file form (no substitution made for *), and (4) the original TTL substituted for the current TTL.
出于DNS安全的目的，RR的标准格式是RR的有线格式，域名（1）完全扩展（没有通过指针进行名称压缩），（2）所有域名字母设置为小写，（3）主文件形式的所有者名称通配符（没有替换*），以及（4）原始TTL替换当前TTL。
For purposes of DNS security, the canonical ordering of owner names is to sort individual labels as unsigned left justified octet strings where the absence of a octet sorts before a zero value octet and upper case letters are treated as lower case letters. Names in a zone are sorted by sorting on the highest level label and then, within those names with the same highest level label by the next lower label, etc. down to leaf node labels. Within a zone, the zone name itself always exists and all other names are the zone name with some prefix of lower level labels. Thus the zone name itself always sorts first.
出于DNS安全的目的，所有者名称的规范排序是将单个标签排序为无符号左对齐八位字节字符串，其中缺少八位字节的情况在零值八位字节之前排序，大写字母被视为小写字母。分区中的名称按最高级别标签排序，然后在具有相同最高级别标签的名称中按下一个较低的标签排序，依此类推到叶节点标签。在分区内，分区名称本身始终存在，而所有其他名称都是带有较低级别标签前缀的分区名称。因此，区域名称本身总是先排序。
Example: foo.example a.foo.example yljkjljk.a.foo.example Z.a.foo.example zABC.a.FOO.EXAMPLE z.foo.example *.z.foo.example \200.z.foo.example
示例：foo.Example a.foo.Example yljkjljk.a.foo.Example Z.a.foo.Example zABC.a.foo.Example Z.foo.Example*.Z.foo.Example\200.Z.foo.Example
Within any particular owner name and type, RRs are sorted by RDATA as a left justified unsigned octet sequence where the absence of an octet sorts before the zero octet.
在任何特定的所有者名称和类型中，RRs按RDATA排序为左对齐的无符号八位组序列，其中缺少八位组排序在零八位组之前。
When RRs of the same name but different types must be ordered, they are ordered by type, considering the type to be an unsigned integer, except that SIG RRs are placed immediately after the type they cover. Thus, for example, an A record would be put before an MX record because A is type 1 and MX is type 15 but if both were signed, the order would be A < SIG(A) < MX < SIG(MX).
如果必须对名称相同但类型不同的RRs进行排序，则会按类型对其进行排序，将类型视为无符号整数，但SIG RRs紧跟在其覆盖的类型之后。因此，例如，A记录将放在MX记录之前，因为A是类型1，MX是类型15，但如果两者都已签名，则顺序将是A<SIG（A）<MX<SIG（MX）。
Levels of server and resolver conformance are defined below.
服务器和解析器的一致性级别定义如下。
Two levels of server conformance for DNS security are defined as follows:
DNS安全的两个服务器一致性级别定义如下：
BASIC: Basic server compliance is the ability to store and retrieve (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or caching server for a secure zone MUST have at least basic compliance and even then some things, such as secure CNAMEs, will not work without full compliance.
基本：基本服务器遵从性是存储和检索（包括区域传输）SIG、KEY和NXT RRs的能力。安全区域的任何辅助服务器或缓存服务器必须至少具有基本的法规遵从性，即使如此，如果没有完全的法规遵从性，某些东西（如安全CNAMEs）也无法工作。
FULL: Full server compliance adds the following to basic compliance: (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) ability, given a zone file and private key, to add appropriate SIG and NXT RRs, possibly via a separate application, (3) proper automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) suppression of CNAME following on retrieval of the security type RRs, (5) recognize the CD query header bit and set the AD query header bit, as appropriate, and (6) proper handling of the two NXT RRs at delegation points. Primary servers for secure zones MUST be fully compliant and for complete secure operation, all secondary, caching, and other servers handling the zone SHOULD be fully compliant as well.
完全：完全服务器合规性在基本合规性的基础上增加了以下功能：（1）能够读取区域文件中的SIG、密钥和NXT RRs，（2）能够在给定区域文件和私钥的情况下，添加适当的SIG和NXT RRs，可能通过单独的应用程序，（3）在响应中正确自动包含SIG、密钥和NXT RRs，（4）在检索安全类型RRs后抑制CNAME，（5）识别CD查询头位并设置AD查询头位（视情况而定），以及（6）在委派点正确处理两个NXT RRs。安全区域的主服务器必须完全兼容，为了实现完全的安全操作，处理该区域的所有辅助服务器、缓存服务器和其他服务器也应完全兼容。
Two levels of resolver compliance (including the resolver portion of a server) are defined for DNS Security:
DNS安全性定义了两个级别的冲突解决程序符合性（包括服务器的冲突解决程序部分）：
BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs when they are explicitly requested.
基本：当显式请求SIG、KEY和NXT RRs时，基本遵从性解析器可以处理它们。
FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT RRs including verification of SIGs at least for the mandatory algorithm, (2) maintains appropriate information in its local caches and database to indicate which RRs have been authenticated and to what extent they have been authenticated, (3) performs additional queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when needed, (4) normally sets the CD query header bit on its queries.
完整：完全兼容的解析器（1）了解密钥、SIG和NXT RRs，包括至少针对强制算法的SIG验证，（2）在其本地缓存和数据库中维护适当的信息，以指示哪些RRs已通过身份验证，以及它们已通过身份验证的程度，（3）根据需要执行其他查询，以在需要时尝试获取密钥、SIG或NXT RRs，（4）通常在其查询上设置CD查询头位。
This document specifies extensions to the Domain Name System (DNS) protocol to provide data integrity and data origin authentication, public key distribution, and optional transaction and request security.
本文档指定了域名系统（DNS）协议的扩展，以提供数据完整性和数据源身份验证、公钥分发以及可选的事务和请求安全性。
It should be noted that, at most, these extensions guarantee the validity of resource records, including KEY resource records, retrieved from the DNS. They do not magically solve other security problems. For example, using secure DNS you can have high confidence in the IP address you retrieve for a host name; however, this does not stop someone for substituting an unauthorized host at that
应该注意的是，这些扩展最多只能保证从DNS检索到的资源记录（包括关键资源记录）的有效性。它们不能神奇地解决其他安全问题。例如，使用安全DNS，您可以对为主机名检索的IP地址有很高的信心；但是，这并不能阻止有人在此时替换未经授权的主机
address or capturing packets sent to that address and falsely responding with packets apparently from that address. Any reasonably complete security system will require the protection of many additional facets of the Internet beyond DNS.
地址或捕获发送到该地址的数据包，并使用明显来自该地址的数据包进行错误响应。任何合理完整的安全系统都需要对DNS之外的互联网的许多其他方面进行保护。
The implementation of NXT RRs as described herein enables a resolver to determine all the names in a zone even if zone transfers are prohibited (section 5.6). This is an active area of work and may change.
本文所述的NXT RRs的实现使解析器能够确定区域中的所有名称，即使区域传输被禁止（第5.6节）。这是一个活跃的工作领域，可能会发生变化。
A number of precautions in DNS implementation have evolved over the years to harden the insecure DNS against spoofing. These precautions should not be abandoned but should be considered to provide additional protection in case of key compromise in secure DNS.
多年来，DNS实现中的许多预防措施已经发展起来，以加强不安全DNS的防欺骗能力。不应放弃这些预防措施，但应考虑在安全DNS中出现密钥泄露时提供额外保护。
KEY RR flag bits 2 and 8-11 and all flag extension field bits can be assigned by IETF consensus as defined in RFC 2434. The remaining values of the NAMTYP flag field and flag bits 4 and 5 (which could conceivably become an extension of the NAMTYP field) can only be assigned by an IETF Standards Action [RFC 2434].
密钥RR标志位2和8-11以及所有标志扩展字段位可由IETF一致分配，如RFC 2434中所定义。NAMTYP标志字段的剩余值以及标志位4和5（可能成为NAMTYP字段的扩展）只能由IETF标准行动[RFC 2434]分配。
Algorithm numbers 5 through 251 are available for assignment should sufficient reason arise. However, the designation of a new algorithm could have a major impact on interoperability and requires an IETF Standards Action [RFC 2434]. The existence of the private algorithm types 253 and 254 should satify most needs for private or proprietary algorithms.
如果有足够的理由，算法编号5到251可用于分配。然而，新算法的指定可能对互操作性产生重大影响，需要IETF标准行动[RFC 2434]。私有算法类型253和254的存在应满足私有或专有算法的大多数需求。
Additional values of the Protocol Octet (5-254) can be assigned by IETF Consensus [RFC 2434].
协议八位字节（5-254）的附加值可由IETF协商一致[RFC 2434]分配。
The meaning of the first bit of the NXT RR "type bit map" being a one can only be assigned by a standards action.
NXT RR“类型位图”的第一位的含义只能由标准操作指定。
References
工具书类
[RFC 1033] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, November 1987.
[RFC 1033]洛托，M.，“域管理员操作指南”，RFC 1033，1987年11月。
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC 1035]Mockapetris，P.，“域名-实施和规范”，STD 13，RFC 1035，1987年11月。
[RFC 1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, March 1992.
[RFC 1305]Mills，D.，“网络时间协议（v3）”，RFC 1305，1992年3月。
[RFC 1530] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", RFC 1530, October 1993.
[RFC 1530]Malamud，C.和M.Rose，“TPC.INT子域的操作原则：一般原则和政策”，RFC 1530，1993年10月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC 2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, September 1996.
[RFC 1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年9月。
[RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC 1995]Ohta，M.“DNS中的增量区域转移”，RFC 1995，1996年8月。
[RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC 2030]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC 2065]Eastlake，D.和C.Kaufman，“域名系统安全扩展”，RFC 2065，1997年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC 2136]Vixie，P.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，1997年4月。
[RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC 2137]Eastlake，D.，“安全域名系统动态更新”，RFC 2137，1997年4月。
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC 2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，1997年7月。
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC 2434]Narten，T.和H.Alvestrand，“在RFC中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999.
[RFC 2537]Eastlake，D.，“域名系统（DNS）中的RSA/MD5密钥和SIG”，RFC 2537，1999年3月。
[RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999.
[RFC 2539]伊斯特莱克，D.，“域名系统（DNS）中Diffie-Hellman密钥的存储”，RFC 2539，1999年3月。
[RFC 2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC 2536]Eastlake，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 2536，1999年3月。
[RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System", RFC 2538, March 1999.
[RFC 2538]Eastlake，D.和O.Gudmundsson，“在域名系统中存储证书”，RFC 2538，1999年3月。
[RFC 2541] Eastlake, D., "DNS Operational Security Considerations", RFC 2541, March 1999.
[RFC 2541]Eastlake，D.，“DNS操作安全考虑”，RFC 25411999年3月。
[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
[RSA常见问题解答]-RSADSI常见问题定期发布。
Author's Address
作者地址
Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road RR #1 Carmel, NY 10512
Donald E.Eastlake 3rd IBM纽约州卡梅尔新德干山路65号RR#1 10512
Phone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
Fax: +1-914-784-3833 (w-fax)
EMail: dee3@us.ibm.com
Phone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
Fax: +1-914-784-3833 (w-fax)
EMail: dee3@us.ibm.com
Appendix A: Base 64 Encoding
附录A：基本64编码
The following encoding technique is taken from [RFC 2045] by N. Borenstein and N. Freed. It is reproduced here in an edited form for convenience.
以下编码技术由N.Borenstein和N.Freed摘自[RFC 2045]。为了方便起见，这里以编辑过的形式复制了它。
A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.)
使用US-ASCII的65个字符子集，使每个可打印字符能够表示6位。（额外的第65个字符“=”用于表示特殊处理功能。）
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the base 64 alphabet.
编码过程将输入位的24位组表示为4个编码字符的输出字符串。从左到右，通过连接3个8位输入组形成24位输入组。然后，这24位被视为4个串联的6位组，每个组被转换为64位字母表中的一个数字。
Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string.
每个6位组用作64个可打印字符数组的索引。索引引用的字符被放置在输出字符串中。
Table 1: The Base 64 Alphabet
表1：基本64字母表
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y
数值编码数值编码数值编码数值编码数值编码0a17r34i51z1b18s35j520c19t36k531d20u37l542e21v21v21v38m5535f22w39n5646g23x40o577h24y41p5868i25z42q597j26a43r60810k27b6111l28t62+12m29d46u63/13n30e47v31f48w（pad）=15 P 32 g 49 x 16 Q 33 h 50 y
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a quantity. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Padding at the end of the data is performed using the '=' character. Since all base 64 input is an integral number of octets, only the following cases
如果在编码的数据末尾可用的位少于24位，则执行特殊处理。一个完整的编码量总是在一个量的末尾完成。当一个输入组中可用的输入位少于24位时，将添加零位（右侧）以形成整数个6位组。数据末尾的填充使用“=”字符执行。由于所有base 64输入都是八位字节的整数，因此只有以下情况
can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
可能出现：（1）编码输入的最终量是24位的整数倍；这里，编码输出的最终单位将是4个字符的整数倍，没有“=”填充，（2）编码输入的最终量正好是8位；这里，编码输出的最终单位将是两个字符后跟两个“=”填充字符，或者（3）编码输入的最终量正好是16位；这里，编码输出的最终单位是三个字符，后跟一个“=”填充字符。
Appendix B: Changes from RFC 2065
附录B:RFC 2065的变更
This section summarizes the most important changes that have been made since RFC 2065.
本节总结了自RFC 2065以来所做的最重要的更改。
1. Most of Section 7 of [RFC 2065] called "Operational Considerations", has been removed and may be made into a separate document [RFC 2541].
1. [RFC 2065]第7节中称为“操作注意事项”的大部分内容已被删除，并可能编入单独的文件[RFC 2541]。
2. The KEY RR has been changed by (2a) eliminating the "experimental" flag as unnecessary, (2b) reserving a flag bit for flags expansion, (2c) more compactly encoding a number of bit fields in such a way as to leave unchanged bits actually used by the limited code currently deployed, (2d) eliminating the IPSEC and email flag bits which are replaced by values of the protocol field and adding a protocol field value for DNS security itself, (2e) adding material to indicate that zone KEY RRs occur only at delegation points, and (2f) removing the description of the RSA/MD5 algorithm to a separate document [RFC 2537]. Section 3.4 describing the meaning of various combinations of "no-key" and key present KEY RRs has been added and the secure / unsecure status of a zone has been clarified as being per algorithm.
2. 通过（2a）消除不必要的“实验性”标志，（2b）为标志扩展保留标志位，（2c）以使当前部署的有限代码实际使用的位保持不变的方式更紧凑地编码多个位字段，从而改变了密钥RR。（2d）消除被协议字段值替换的IPSEC和电子邮件标志位，并为DNS安全本身添加协议字段值，（2e）添加材料以表明区域密钥RRs仅出现在委派点，以及（2f）将RSA/MD5算法的描述删除到单独的文档中[RFC 2537]。第3.4节描述了“无密钥”和密钥存在密钥RRs的各种组合的含义，并根据算法澄清了区域的安全/不安全状态。
3. The SIG RR has been changed by (3a) renaming the "time signed" field to be the "signature inception" field, (3b) clarifying that signature expiration and inception use serial number ring arithmetic, (3c) changing the definition of the key footprint/tag for algorithms other than 1 and adding Appendix C to specify its calculation. In addition, the SIG covering type AXFR has been eliminated while one covering IXFR [RFC 1995] has been added (see section 5.6).
3. 通过（3a）将“时间签名”字段重命名为“签名起始”字段，（3b）澄清签名到期和起始使用序列号环算法，（3c）更改除1以外的算法的密钥封装/标记定义，并添加附录C以指定其计算，从而改变了SIG RR。此外，取消了覆盖AXFR类型的SIG，同时增加了覆盖IXFR[RFC 1995]的SIG（见第5.6节）。
4. Algorithm 3, the DSA algorithm, is now designated as the mandatory to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is now a recommended option. Algorithm 2 and 4 are designated as the Diffie-Hellman key and elliptic cryptography algorithms respectively, all to be defined in separate documents. Algorithm code point 252 is designated to indicate "indirect" keys, to be defined in a separate document, where the actual key is elsewhere. Both the KEY and SIG RR definitions have been simplified by eliminating the "null" algorithm 253 as defined in [RFC 2065]. That algorithm had been included because at the time it was thought it might be useful in DNS dynamic update [RFC 2136]. It was in fact not so used and it is dropped to simplify DNS security. Howver, that algorithm number has been re-used to indicate private algorithms where a domain name specifies the algorithm.
4. 算法3，即DSA算法，现在被指定为强制实现算法。算法1，即RSA/MD5算法，现在是推荐的选项。算法2和4分别被指定为Diffie-Hellman密钥算法和椭圆密码算法，它们都将在单独的文档中定义。算法代码点252被指定为指示“间接”密钥，将在单独的文档中定义，其中实际密钥在别处。通过消除[RFC 2065]中定义的“空”算法253，密钥和SIG RR定义都得到了简化。该算法被包括在内，因为当时人们认为它在DNS动态更新[RFC2136]中可能有用。事实上，它并没有被如此使用，为了简化DNS安全性，它被删除了。然而，该算法编号已被重新用于表示域名指定算法的私有算法。
5. The NXT RR has been changed so that (5a) the NXT RRs in a zone cover all names, including wildcards as literal names without expansion, except for glue address records whose names would not otherwise appear, (5b) all NXT bit map areas whose first octet has bit zero set have been reserved for future definition, (5c) the number of and circumstances under which an NXT must be returned in connection with wildcard names has been extended, and (5d) in connection with the bit map, references to the WKS RR have been removed and verticle bars ("|") have been added between the RR type mnemonics in the ASCII representation.
5. NXT RR已更改，以便（5a）区域中的NXT RRs覆盖所有名称，包括作为文字名称的通配符，而不进行扩展，但名称不会以其他方式出现的粘合地址记录除外，（5b）第一个八位字节已设置为零位的所有NXT位图区域已保留用于将来的定义，（5c）与通配符名称相关的NXT必须返回的数量和情况已经扩展，（5d）与位图相关的WKS RR参考已经删除，并且在ASCII表示的RR类型助记符之间添加了垂直条（“|”）。
6. Information on the canonical form and ordering of RRs has been moved into a separate Section 8.
6. 关于RRs规范形式和排序的信息已移至单独的第8节。
7. A subsection covering incremental and full zone transfer has been added in Section 5.
7. 第5节增加了一个涵盖增量和全区域转移的小节。
8. Concerning DNS chaining: Further specification and policy recommendations on secure resolution have been added, primarily in Section 6.3.1. It is now clearly stated that authenticated data has a validity period of the intersection of the validity periods of the SIG RRs in its authentication chain. The requirement to staticly configure a superzone's key signed by a zone in all of the zone's authoritative servers has been removed. The recommendation to continue DNS security checks in a secure island of DNS data that is separated from other parts of the DNS tree by insecure zones and does not contain a zone for which a key has been staticly configured was dropped.
8. 关于DNS链接：增加了关于安全解析的进一步规范和政策建议，主要在第6.3.1节中。现在明确指出，已认证数据的有效期为其认证链中SIG RRs有效期的交叉点。已删除静态配置超级区域的密钥的要求，该密钥由区域的所有权威服务器中的区域签名。建议在DNS数据的安全岛中继续DNS安全检查，该数据岛由不安全区域与DNS树的其他部分隔开，并且不包含已静态配置密钥的区域，但已删除。
9. It was clarified that the presence of the AD bit in a response does not apply to the additional information section or to glue address or delegation point NS RRs. The AD bit only indicates that the answer and authority sections of the response are authoritative.
9. 经澄清，响应中存在的AD位不适用于附加信息部分或粘合地址或委托点NS RRs。AD位仅表示响应的应答和授权部分具有权威性。
10. It is now required that KEY RRs and NXT RRs be signed only with zone-level keys.
10. 现在要求密钥RRs和NXT RRs仅使用区域级密钥签名。
11. Add IANA Considerations section and references to RFC 2434.
11. 添加IANA注意事项部分和RFC 2434的参考。
Appendix C: Key Tag Calculation
附录C：关键标签计算
The key tag field in the SIG RR is just a means of more efficiently selecting the correct KEY RR to use when there is more than one KEY RR candidate available, for example, in verifying a signature. It is possible for more than one candidate key to have the same tag, in which case each must be tried until one works or all fail. The following reference implementation of how to calculate the Key Tag, for all algorithms other than algorithm 1, is in ANSI C. It is coded for clarity, not efficiency. (See section 4.1.6 for how to determine the Key Tag of an algorithm 1 key.)
SIG-RR中的密钥标签字段只是在存在多个密钥RR候选时（例如，在验证签名时）更有效地选择要使用的正确密钥RR的手段。多个候选密钥可能具有相同的标记，在这种情况下，必须尝试每个候选密钥，直到其中一个有效或全部失败。对于除算法1以外的所有算法，以下关于如何计算密钥标记的参考实现均采用ANSI C。其编码是为了清晰，而不是效率。（有关如何确定算法1密钥的密钥标签，请参见第4.1.6节。）
/* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return
value
second byte of the key tag is the least significant byte of
return value
*/
/* assumes int is at least 16 bits
first byte of the key tag is the most significant byte of return
value
second byte of the key tag is the least significant byte of
return value
*/
int keytag (
int键标记(
unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */
)
{
long int ac; /* assumed to be 32 bits or larger */
unsigned char key[], /* the RDATA part of the KEY RR */
unsigned int keysize, /* the RDLENGTH */
)
{
long int ac; /* assumed to be 32 bits or larger */
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i&1) ? key[i] : key[i]<<8;
ac += (ac>>16) & 0xFFFF;
return ac & 0xFFFF;
}
for ( ac = 0, i = 0; i < keysize; ++i )
ac += (i&1) ? key[i] : key[i]<<8;
ac += (ac>>16) & 0xFFFF;
return ac & 0xFFFF;
}
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。