Network Working Group J. Schlyter, Ed.
Request for Comments: 3845 August 2004
Updates: 3755, 2535
Category: Standards Track
Network Working Group J. Schlyter, Ed.
Request for Comments: 3845 August 2004
Updates: 3755, 2535
Category: Standards Track
DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
DNS安全（DNSSEC）下一安全（NSEC）RDATA格式
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space.
本文档重新定义DNS NextSECure（NSEC）资源记录RDATA格式中“类型位图”字段的连线格式，以覆盖整个资源记录（RR）类型空间。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 2
2.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . 3
2.1.1. The Next Domain Name Field . . . . . . . . . . . 3
2.1.2. The List of Type Bit Map(s) Field . . . . . . . 3
2.1.3. Inclusion of Wildcard Names in NSEC RDATA . . . 4
2.2. The NSEC RR Presentation Format . . . . . . . . . . . . 4
2.3. NSEC RR Example . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 2
2.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . 3
2.1.1. The Next Domain Name Field . . . . . . . . . . . 3
2.1.2. The List of Type Bit Map(s) Field . . . . . . . 3
2.1.3. Inclusion of Wildcard Names in NSEC RDATA . . . 4
2.2. The NSEC RR Presentation Format . . . . . . . . . . . . 4
2.3. NSEC RR Example . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
The DNS [6][7] NSEC [5] Resource Record (RR) is used for authenticated proof of the non-existence of DNS owner names and types. The NSEC RR is based on the NXT RR as described in RFC 2535 [2], and is similar except for the name and typecode. The RDATA format for the NXT RR has the limitation in that the RDATA could only carry information about the existence of the first 127 types. RFC 2535 did reserve a bit to specify an extension mechanism, but the mechanism was never actually defined.
DNS[6][7]NSEC[5]资源记录（RR）用于验证DNS所有者名称和类型是否不存在。NSEC RR基于RFC 2535[2]中所述的NXT RR，除名称和类型代码外，与之类似。NXT RR的RDATA格式有一个限制，即RDATA只能携带关于前127种类型存在的信息。RFC2535确实保留了一个位来指定扩展机制，但该机制从未实际定义过。
In order to avoid needing to develop an extension mechanism into a deployed base of DNSSEC aware servers and resolvers once the first 127 type codes are allocated, this document redefines the wire format of the "Type Bit Map" field in the NSEC RDATA to cover the full RR type space.
为了避免在分配前127个类型代码后，需要将扩展机制开发为部署的DNSSEC感知服务器和解析器库，本文档重新定义了NSEC RDATA中“类型位图”字段的有线格式，以覆盖整个RR类型空间。
This document introduces a new format for the type bit map. The properties of the type bit map format are that it can cover the full possible range of typecodes, that it is relatively economical in the amount of space it uses for the common case of a few types with an owner name, that it can represent owner names with all possible types present in packets of approximately 8.5 kilobytes, and that the representation is simple to implement. Efficient searching of the type bitmap for the presence of certain types is not a requirement.
本文档介绍了类型位图的新格式。类型位图格式的特性是，它可以覆盖所有可能的类型代码，它在一些具有所有者名称的类型的常见情况下使用的空间量相对经济，它可以用大约8.5 KB的数据包中存在的所有可能类型表示所有者名称，并且表示法易于实现。不要求在类型位图中高效搜索是否存在某些类型。
For convenience and completeness, this document presents the syntax and semantics for the NSEC RR based on the specification in RFC 2535 [2] and as updated by RFC 3755 [5], thereby not introducing changes except for the syntax of the type bit map.
为方便和完整起见，本文件根据RFC 2535[2]中的规范以及RFC 3755[5]的更新，给出了NSEC RR的语法和语义，因此除了类型位图的语法外，没有引入任何更改。
This document updates RFC 2535 [2] and RFC 3755 [5].
本文件更新了RFC 2535[2]和RFC 3755[5]。
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 BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The NSEC resource record lists two separate things: the owner name of the next RRset in the canonical ordering of the zone, and the set of RR types present at the NSEC RR's owner name. The complete set of NSEC RRs in a zone indicate which RRsets exist in a zone, and form a chain of owner names in the zone. This information is used to provide authenticated denial of existence for DNS data, as described in RFC 2535 [2].
NSEC资源记录列出了两个独立的内容：区域规范顺序中下一个RRset的所有者名称，以及NSEC RR所有者名称中存在的RR类型集。区域中的完整NSEC RRs集表示区域中存在哪些RRs集，并在区域中形成所有者名称链。如RFC 2535[2]所述，该信息用于提供DNS数据的认证拒绝存在。
The type value for the NSEC RR is 47.
NSEC RR的类型值为47。
The NSEC RR RDATA format is class independent and defined for all classes.
NSEC RR RDATA格式与类无关，并为所有类定义。
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [8].
NSEC RR应具有与SOA最小TTL字段相同的TTL值。这符合负缓存的精神[8]。
The RDATA of the NSEC RR is as shown below:
NSEC 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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ List of Type Bit Map(s) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ List of Type Bit Map(s) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Next Domain Name field contains the owner name of the next RR in the canonical ordering of the zone. The value of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR).
“下一个域名”字段包含区域规范顺序中下一个RR的所有者名称。区域中最后一条NSEC记录中的下一个域名字段的值是区域顶点的名称（区域的SOA RR的所有者名称）。
A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR.
在传输NSEC RR时，发送方不得在下一个域名字段上使用DNS名称压缩。
Owner names of RRsets that are not authoritative for the given zone (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name.
除非在同一所有者名称下至少存在一个权威RRset，否则不得在下一个域名中列出给定区域的非权威RRset的所有者名称（如胶水记录）。
The RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block that has at least one active RR type is encoded using a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) indicating the number of octets used for the window block's bitmap, and up to 32 octets (256 bits) of bitmap.
RR类型空间被分割为256个窗口块，每个窗口块表示16位RR类型空间的低位8位。每个具有至少一个活动RR类型的块都使用单个八位字节窗口编号（从0到255）、单个八位字节位图长度（从1到32）进行编码，该长度指示用于窗口块位图的八位字节数，以及最多32个八位字节（256位）的位图。
Window blocks are present in the NSEC RR RDATA in increasing numerical order.
窗口块以递增的数字顺序出现在NSEC RR RDATA中。
"|" denotes concatenation
“|”表示串联
Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1 corresponds to RR type 257, and bit 2 to RR type 258. If a bit is set to 1, it indicates that an RRset of that type is present for the NSEC RR's owner name. If a bit is set to 0, it indicates that no RRset of that type is present for the NSEC RR's owner name.
每个位图以网络位顺序对窗口块内RR类型的低位8位进行编码。第一位是位0。对于窗口块0，位1对应于RR类型1（A），位2对应于RR类型2（NS），依此类推。对于窗口块1，位1对应于RR类型257，位2对应于RR类型258。如果位设置为1，则表示NSEC RR的所有者名称存在该类型的RRset。如果位设置为0，则表示NSEC RR的所有者名称不存在该类型的RRset。
Since bit 0 in window block 0 refers to the non-existing RR type 0, it MUST be set to 0. After verification, the validator MUST ignore the value of bit 0 in window block 0.
由于窗口块0中的位0引用不存在的RR类型0，因此必须将其设置为0。验证后，验证器必须忽略窗口块0中位0的值。
Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3] (section 3.1), or within the range reserved for assignment only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in zone data. If encountered, they must be ignored upon reading.
RFC 2929[3]（第3.1节）中规定的表示元类型或QT类型的位，或仅为分配给QT类型和元类型而保留的范围内的位，必须设置为0，因为它们不会出现在区域数据中。如果遇到，阅读时必须忽略它们。
Blocks with no types present MUST NOT be included. Trailing zero octets in the bitmap MUST be omitted. The length of each block's bitmap is determined by the type code with the largest numerical value within that block, among the set of RR types present at the NSEC RR's owner name. Trailing zero octets not specified MUST be interpreted as zero octets.
不包括不存在类型的块。位图中尾随的零八位字节必须省略。每个块位图的长度由该块中具有最大数值的类型代码决定，该类型代码位于NSEC RR所有者名称中的RR类型集合中。未指定的尾随零八位字节必须解释为零八位字节。
If a wildcard owner name appears in a zone, the wildcard label ("*") is treated as a literal symbol and is treated the same as any other owner name for purposes of generating NSEC RRs. Wildcard owner names appear in the Next Domain Name field without any wildcard expansion. RFC 2535 [2] describes the impact of wildcards on authenticated denial of existence.
如果区域中出现通配符所有者名称，则通配符标签（“*”）将被视为文字符号，并被视为与生成NSEC RRs的任何其他所有者名称相同。通配符所有者名称显示在下一个域名字段中，没有任何通配符扩展。RFC 2535[2]描述了通配符对经过身份验证的拒绝存在的影响。
The presentation format of the RDATA portion is as follows:
RDATA部分的表示格式如下所示：
The Next Domain Name field is represented as a domain name.
下一个域名字段表示为域名。
The List of Type Bit Map(s) Field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation as described in RFC 3597 [4] (section 5) MUST be used.
类型位图字段列表表示为RR类型助记符序列。当助记符未知时，必须使用RFC 3597[4]（第5节）中所述的类型表示法。
The following NSEC RR identifies the RRsets associated with alfa.example.com. and the next authoritative name after alfa.example.com.
以下NSEC RR确定了与alfa.example.com相关的RRSET。以及alfa.example.com之后的下一个权威名称。
alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234
alfa.example.com。NSEC host.example.com上的86400。MX RRSIG NSEC类型1234
The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets associated with the name alfa.example.com.
前四个文本字段指定名称、TTL、类和RR类型（NSEC）。条目host.example.com。是alfa.example.com之后的下一个权威名称。按照规范的顺序。A、MX、RRSIG、NSEC和TYPE1234助记符表示存在与名称alfa.example.com关联的A、MX、RRSIG、NSEC和TYPE1234 rrset。
The RDATA section of the NSEC RR above would be encoded as:
上述NSEC RR的RDATA部分将编码为：
0x04 'h' 'o' 's' 't' 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 0x03 'c' 'o' 'm' 0x00 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20
0x04“h”o“s”t“0x07”e“x”a“m”p“l”e“0x03”c“o”m“0x00 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x00 0x00 0x03 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20
Assuming that the resolver can authenticate this NSEC record, it could be used to prove that beta.example.com does not exist, or could be used to prove that there is no AAAA record associated with alfa.example.com. Authenticated denial of existence is discussed in RFC 2535 [2].
假设冲突解决程序可以验证此NSEC记录，它可以用来证明beta.example.com不存在，或者可以用来证明没有与alfa.example.com相关的AAAA记录。RFC 2535[2]中讨论了经验证的拒绝存在。
This document introduces no new IANA considerations, because all of the protocol parameters used in this document have already been assigned by RFC 3755 [5].
本文档没有引入新的IANA注意事项，因为本文档中使用的所有协议参数都已由RFC 3755分配[5]。
The update of the RDATA format and encoding does not affect the security of the use of NSEC RRs.
RDATA格式和编码的更新不会影响NSEC RRs使用的安全性。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[2] Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
[3] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[3] Eastlake 3rd，D.，Brunner Williams，E.和B.Manning，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 29292000年9月。
[4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[4] Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[5] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
[5] Weiler，S.，“委托签名者（DS）的传统解析器兼容性”，RFC 3755，2004年5月。
[6] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[6] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[7] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[8] Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
The encoding described in this document was initially proposed by Mark Andrews. Other encodings where proposed by David Blacka and Michael Graff.
本文档中描述的编码最初由Mark Andrews提出。由David Blacka和Michael Graff提出的其他编码。
Jakob Schlyter (editor) NIC-SE Box 5774 Stockholm SE-114 87 Sweden
雅各布·施莱特（编辑）NIC-SE信箱5774斯德哥尔摩SE-114 87瑞典
EMail: jakob@nic.se
URI: http://www.nic.se/
EMail: jakob@nic.se
URI: http://www.nic.se/
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。