Network Working Group S. Weiler
Request for Comments: 4470 SPARTA, Inc.
Updates: 4035, 4034 J. Ihren
Category: Standards Track Autonomica AB
April 2006
Network Working Group S. Weiler
Request for Comments: 4470 SPARTA, Inc.
Updates: 4035, 4034 J. Ihren
Category: Standards Track Autonomica AB
April 2006
Minimally Covering NSEC Records and DNSSEC On-line Signing
最低限度地覆盖NSEC记录和DNSSEC在线签名
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone.
本文档描述了如何构造DNSSEC NSEC资源记录，这些记录覆盖的名称范围小于RFC 4034所要求的范围。通过按需生成和签署这些记录，权威名称服务器可以有效地阻止区域内容的泄露，否则就可能通过在已签署区域中遍历NSEC记录链来实现。
Table of Contents
目录
1. Introduction ....................................................1
2. Applicability of This Technique .................................2
3. Minimally Covering NSEC Records .................................2
4. Better Epsilon Functions ........................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. Normative References ............................................6
1. Introduction ....................................................1
2. Applicability of This Technique .................................2
3. Minimally Covering NSEC Records .................................2
4. Better Epsilon Functions ........................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. Normative References ............................................6
With DNSSEC [1], an NSEC record lists the next instantiated name in its zone, proving that no names exist in the "span" between the NSEC's owner name and the name in the "next name" field. In this document, an NSEC record is said to "cover" the names between its owner name and next name.
对于DNSSEC[1]，NSEC记录列出其区域中的下一个实例化名称，证明NSEC所有者名称和“下一个名称”字段中的名称之间的“范围”中不存在任何名称。在本文档中，NSEC记录被称为“覆盖”其所有者名称和下一个名称之间的名称。
Through repeated queries that return NSEC records, it is possible to retrieve all of the names in the zone, a process commonly called "walking" the zone. Some zone owners have policies forbidding zone transfers by arbitrary clients; this side effect of the NSEC architecture subverts those policies.
通过返回NSEC记录的重复查询，可以检索区域中的所有名称，这一过程通常称为“漫游”区域。一些区域所有者有禁止任意客户进行区域转移的政策；NSEC架构的这种副作用颠覆了这些策略。
This document presents a way to prevent zone walking by constructing NSEC records that cover fewer names. These records can make zone walking take approximately as many queries as simply asking for all possible names in a zone, making zone walking impractical. Some of these records must be created and signed on demand, which requires on-line private keys. Anyone contemplating use of this technique is strongly encouraged to review the discussion of the risks of on-line signing in Section 5.
本文档介绍了一种通过构造覆盖较少名称的NSEC记录来防止区域漫游的方法。这些记录可以使区域漫游所需的查询量与简单地询问区域中所有可能的名称所需的查询量大致相同，从而使区域漫游变得不切实际。其中一些记录必须按需创建和签名，这需要在线私钥。强烈鼓励任何打算使用此技术的人回顾第5节中关于在线签名风险的讨论。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
The technique presented here may be useful to a zone owner that wants to use DNSSEC, is concerned about exposure of its zone contents via zone walking, and is willing to bear the costs of on-line signing.
这里介绍的技术可能对想要使用DNSSEC的区域所有者有用，担心通过区域行走暴露其区域内容，并且愿意承担在线签名的费用。
As discussed in Section 5, on-line signing has several security risks, including an increased likelihood of private keys being disclosed and an increased risk of denial of service attack. Anyone contemplating use of this technique is strongly encouraged to review the discussion of the risks of on-line signing in Section 5.
如第5节所述，在线签名存在多个安全风险，包括私钥被泄露的可能性增加和拒绝服务攻击的风险增加。强烈鼓励任何打算使用此技术的人回顾第5节中关于在线签名风险的讨论。
Furthermore, at the time this document was published, the DNSEXT working group was actively working on a mechanism to prevent zone walking that does not require on-line signing (tentatively called NSEC3). The new mechanism is likely to expose slightly more information about the zone than this technique (e.g., the number of instantiated names), but it may be preferable to this technique.
此外，在本文件发布时，DNSEXT工作组正在积极研究一种机制，以防止不需要在线签名的区域行走（暂定为NSEC3）。新机制可能会比此技术公开更多关于区域的信息（例如，实例化名称的数量），但它可能比此技术更可取。
This mechanism involves changes to NSEC records for instantiated names, which can still be generated and signed in advance, as well as the on-demand generation and signing of new NSEC records whenever a name must be proven not to exist.
该机制涉及对实例化名称的NSEC记录进行更改，这些更改仍然可以提前生成和签名，以及在必须证明名称不存在时按需生成和签名新的NSEC记录。
In the "next name" field of instantiated names' NSEC records, rather than list the next instantiated name in the zone, list any name that falls lexically after the NSEC's owner name and before the next instantiated name in the zone, according to the ordering function in RFC 4034 [2] Section 6.1. This relaxes the requirement in Section 4.1.1 of RFC 4034 that the "next name" field contains the next owner name in the zone. This change is expected to be fully compatible with all existing DNSSEC validators. These NSEC records are returned whenever proving something specifically about the owner name (e.g., that no resource records of a given type appear at that name).
根据RFC 4034[2]第6.1节中的排序功能，在实例化名称的NSEC记录的“下一个名称”字段中，不要列出区域中的下一个实例化名称，而是列出在NSEC所有者名称之后、区域中下一个实例化名称之前的任何名称。这放宽了RFC 4034第4.1.1节中“下一个名称”字段包含区域中下一个所有者名称的要求。此更改预计将与所有现有DNSSEC验证器完全兼容。只要证明所有者名称的某些特定信息（例如，该名称处未出现给定类型的资源记录），就会返回这些NSEC记录。
Whenever an NSEC record is needed to prove the non-existence of a name, a new NSEC record is dynamically produced and signed. The new NSEC record has an owner name lexically before the QNAME but lexically following any existing name and a "next name" lexically following the QNAME but before any existing name.
每当需要NSEC记录来证明名称不存在时，就会动态生成一个新的NSEC记录并进行签名。新的NSEC记录的所有者名称在词汇上位于QNAME之前，但在词汇上位于任何现有名称之后，而“下一个名称”在词汇上位于QNAME之后，但在任何现有名称之前。
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC bits set and SHOULD NOT have any other bits set. This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at names that did not exist before the zone was signed.
生成的NSEC记录的类型位图必须设置RRSIG和NSEC位，并且不应设置任何其他位。这放宽了RFC4035第2.3节的要求，即NSEC RRs不得出现在签署区域之前不存在的名称上。
The functions to generate the lexically following and proceeding names need not be perfect or consistent, but the generated NSEC records must not cover any existing names. Furthermore, this technique works best when the generated NSEC records cover as few names as possible. In this document, the functions that generate the nearby names are called "epsilon" functions, a reference to the mathematical convention of using the greek letter epsilon to represent small deviations.
生成词汇性后续和后续名称的函数不需要完美或一致，但生成的NSEC记录不得涵盖任何现有名称。此外，当生成的NSEC记录覆盖尽可能少的名称时，此技术效果最佳。在本文档中，生成附近名称的函数称为“epsilon”函数，它引用了使用希腊字母epsilon表示小偏差的数学约定。
An NSEC record denying the existence of a wildcard may be generated in the same way. Since the NSEC record covering a non-existent wildcard is likely to be used in response to many queries, authoritative name servers using the techniques described here may want to pregenerate or cache that record and its corresponding RRSIG.
可以以相同的方式生成否认存在通配符的NSEC记录。由于覆盖不存在通配符的NSEC记录可能用于响应许多查询，因此使用本文所述技术的权威名称服务器可能希望预生成或缓存该记录及其相应的RRSIG。
For example, a query for an A record at the non-instantiated name example.com might produce the following two NSEC records, the first denying the existence of the name example.com and the second denying the existence of a wildcard:
例如，在未实例化的name example.com上查询a记录可能会生成以下两个NSEC记录，第一个否认name example.com的存在，第二个否认通配符的存在：
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
NSEC示例-.com中的exampld.com 3600（RRSIG NSEC）
\).com 3600 IN NSEC +.com ( RRSIG NSEC )
\)NSEC+.com中的.com 3600（RRSIG NSEC）
Before answering a query with these records, an authoritative server must test for the existence of names between these endpoints. If the generated NSEC would cover existing names (e.g., exampldd.com or *bizarre.example.com), a better epsilon function may be used or the covered name closest to the QNAME could be used as the NSEC owner name or next name, as appropriate. If an existing name is used as the NSEC owner name, that name's real NSEC record MUST be returned. Using the same example, assuming an exampldd.com delegation exists, this record might be returned from the parent:
在使用这些记录回答查询之前，权威服务器必须测试这些端点之间是否存在名称。如果生成的NSEC将覆盖现有名称（例如exampldd.com或*bizarre.example.com），则可以使用更好的epsilon函数，或者最接近QNAME的覆盖名称可以用作NSEC所有者名称或下一个名称（视情况而定）。如果现有名称用作NSEC所有者名称，则必须返回该名称的真实NSEC记录。使用相同的示例，假设exampldd.com委托存在，则可能会从父级返回此记录：
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
NSEC示例-.com中的exampldd.com 3600（NS DS RRSIG NSEC）
Like every authoritative record in the zone, each generated NSEC record MUST have corresponding RRSIGs generated using each algorithm (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as described in RFC 4035 [3] Section 2.2. To minimize the number of signatures that must be generated, a zone may wish to limit the number of algorithms in its DNSKEY RRset.
如RFC 4035[3]第2.2节所述，与区域中的每个权威记录一样，每个生成的NSEC记录必须具有使用区域的DNSKEY RRset中的每个算法（但不一定是每个DNSKEY）生成的相应RRSIG。为了尽量减少必须生成的签名数量，区域可能希望限制其DNSKEY RRset中的算法数量。
Section 6.1 of RFC 4034 defines a strict ordering of DNS names. Working backward from that definition, it should be possible to define epsilon functions that generate the immediately following and preceding names, respectively. This document does not define such functions. Instead, this section presents functions that come reasonably close to the perfect ones. As described above, an authoritative server should still ensure than no generated NSEC covers any existing name.
RFC 4034第6.1节定义了DNS名称的严格顺序。从该定义向后工作，应该可以定义分别生成紧跟其后和前面名称的epsilon函数。本文件未定义此类功能。相反，本节介绍的功能相当接近完美功能。如上所述，权威服务器仍应确保生成的NSEC不会覆盖任何现有名称。
To increment a name, add a leading label with a single null (zero-value) octet.
要增加名称，请添加一个带有单个空（零值）八位字节的前导标签。
To decrement a name, decrement the last character of the leftmost label, then fill that label to a length of 63 octets with octets of value 255. To decrement a null (zero-value) octet, remove the octet -- if an empty label is left, remove the label. Defining this function numerically: fill the leftmost label to its maximum length with zeros (numeric, not ASCII zeros) and subtract one.
若要减小名称，请减小最左侧标签的最后一个字符，然后用值255的八位字节将该标签填充为63个八位字节。要减少空（零值）八位字节，请删除该八位字节——如果留下空标签，请删除该标签。以数字方式定义此函数：用零（数字，而不是ASCII零）将最左边的标签填充到其最大长度，然后减去一。
In response to a query for the non-existent name foo.example.com, these functions produce NSEC records of the following:
为了响应对不存在的名称foo.example.com的查询，这些函数生成以下NSEC记录：
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255.example.com
\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255.example.com中的NSEC\000.*.example.com 3600（NSEC RRSIG）
The first of these NSEC RRs proves that no exact match for foo.example.com exists, and the second proves that there is no wildcard in example.com.
第一个NSEC RRs证明foo.example.com不存在精确匹配，第二个证明example.com中不存在通配符。
Both of these functions are imperfect: they do not take into account constraints on number of labels in a name nor total length of a name. As noted in the previous section, though, this technique does not depend on the use of perfect epsilon functions: it is sufficient to test whether any instantiated names fall into the span covered by the generated NSEC and, if so, substitute those instantiated owner names for the NSEC owner name or next name, as appropriate.
这两个函数都是不完美的：它们既没有考虑名称中标签数量的限制，也没有考虑名称总长度的限制。但是，如前一节所述，该技术并不依赖于使用完美的epsilon函数：测试任何实例化名称是否属于生成的NSEC所涵盖的范围就足够了，如果是，则用这些实例化的所有者名称替换NSEC所有者名称或下一个名称（视情况而定）。
This approach requires on-demand generation of RRSIG records. This creates several new vulnerabilities.
这种方法需要按需生成RRSIG记录。这会产生几个新的漏洞。
First, on-demand signing requires that a zone's authoritative servers have access to its private keys. Storing private keys on well-known Internet-accessible servers may make them more vulnerable to unintended disclosure.
首先，按需签名要求区域的权威服务器可以访问其私钥。将私钥存储在知名的可访问互联网的服务器上可能会使它们更容易被无意中泄露。
Second, since generation of digital signatures tends to be computationally demanding, the requirement for on-demand signing makes authoritative servers vulnerable to a denial of service attack.
其次，由于数字签名的生成往往需要计算，按需签名的要求使得权威服务器容易受到拒绝服务攻击。
Last, if the epsilon functions are predictable, on-demand signing may enable a chosen-plaintext attack on a zone's private keys. Zones using this approach should attempt to use cryptographic algorithms that are resistant to chosen-plaintext attacks. It is worth noting that although DNSSEC has a "mandatory to implement" algorithm, that is a requirement on resolvers and validators -- there is no requirement that a zone be signed with any given algorithm.
最后，如果epsilon函数是可预测的，则按需签名可能会对区域的私钥启用选定的明文攻击。使用此方法的区域应尝试使用能够抵抗选定明文攻击的加密算法。值得注意的是，尽管DNSSEC有一个“强制实现”算法，这是对解析器和验证器的要求——但不要求使用任何给定算法对区域进行签名。
The success of using minimally covering NSEC records to prevent zone walking depends greatly on the quality of the epsilon functions
使用最小覆盖NSEC记录来防止区域行走的成功在很大程度上取决于ε函数的质量
chosen. An increment function that chooses a name obviously derived from the next instantiated name may be easily reverse engineered, destroying the value of this technique. An increment function that always returns a name close to the next instantiated name is likewise a poor choice. Good choices of epsilon functions are the ones that produce the immediately following and preceding names, respectively, though zone administrators may wish to use less perfect functions that return more human-friendly names than the functions described in Section 4 above.
被选中的。选择显然来自下一个实例化名称的名称的增量函数可能很容易被反向工程，从而破坏了该技术的价值。增量函数总是返回一个接近下一个实例化名称的名称，这同样是一个糟糕的选择。epsilon函数的好选择是分别产生紧跟其后的名称和前面的名称的函数，尽管区域管理员可能希望使用不太完美的函数，这些函数返回的名称比上面第4节中描述的函数更人性化。
Another obvious but misguided concern is the danger from synthesized NSEC records being replayed. It is possible for an attacker to replay an old but still validly signed NSEC record after a new name has been added in the span covered by that NSEC, incorrectly proving that there is no record at that name. This danger exists with DNSSEC as defined in [3]. The techniques described here actually decrease the danger, since the span covered by any NSEC record is smaller than before. Choosing better epsilon functions will further reduce this danger.
另一个明显但被误导的担忧是合成的NSEC记录被重放的危险。在NSEC覆盖的范围内添加新名称后，攻击者有可能重播旧的但仍然有效签名的NSEC记录，从而错误地证明该名称处没有记录。[3]中定义的DNSSEC存在这种危险。这里描述的技术实际上减少了危险，因为任何NSEC记录覆盖的范围都比以前小。选择更好的ε函数将进一步减少这种危险。
Many individuals contributed to this design. They include, in addition to the authors of this document, Olaf Kolkman, Ed Lewis, Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, Jakob Schlyter, Bill Manning, and Joao Damas.
许多人对这一设计做出了贡献。除本文件作者外，他们还包括奥拉夫·科尔克曼、埃德·刘易斯、彼得·科赫、马特·拉森、大卫·布莱克、苏珊娜·伍尔夫、雅普·阿克赫斯、雅各布·施莱特、比尔·曼宁和乔·达马斯。
In addition, the editors would like to thank Ed Lewis, Scott Rose, and David Blacka for their careful review of the document.
此外，编辑们还要感谢Ed Lewis、Scott Rose和David Black对该文件的仔细审阅。
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[1] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[2] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[3] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, Maryland 21046 US
塞缪尔·韦勒·斯巴达公司，美国马里兰州哥伦比亚塞缪尔·莫尔斯大道7075号，邮编：21046
EMail: weiler@tislabs.com
EMail: weiler@tislabs.com
Johan Ihren Autonomica AB Bellmansgatan 30 Stockholm SE-118 47 Sweden
瑞典斯德哥尔摩SE-118 47号贝尔曼斯加坦30号约翰·伊赫伦自治酒店
EMail: johani@autonomica.se
EMail: johani@autonomica.se
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。