Network Working Group D. Blacka
Request for Comments: 4955 VeriSign, Inc.
Category: Standards Track July 2007
Network Working Group D. Blacka
Request for Comments: 4955 VeriSign, Inc.
Category: Standards Track July 2007
DNS Security (DNSSEC) Experiments
DNS安全（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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC.
本文档描述了一种以实验方式部署备用的、不向后兼容的DNS安全（DNSSEC）方法，而不会中断标准DNSSEC的部署。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Historically, experimentation with DNSSEC alternatives has been a problematic endeavor. There has typically been a desire to both introduce non-backwards-compatible changes to DNSSEC and to try these changes on real zones in the public DNS. This creates a problem when the change to DNSSEC would make all or part of the zone using those changes appear bogus (bad) or otherwise broken to existing security-aware resolvers.
从历史上看，DNSSEC替代品的试验一直是一个有问题的尝试。人们通常希望对DNSSEC引入不向后兼容的更改，并在公共DNS的真实区域上尝试这些更改。当对DNSSEC的更改会使使用这些更改的所有或部分区域对现有的安全感知解析程序显示为虚假（错误）或损坏时，这会产生问题。
This document describes a standard methodology for setting up DNSSEC experiments. This methodology addresses the issue of coexistence with standard DNSSEC and DNS by using unknown algorithm identifiers to hide the experimental DNSSEC protocol modifications from standard security-aware resolvers.
本文件描述了建立DNSSEC实验的标准方法。该方法通过使用未知的算法标识符对标准安全感知解析器隐藏实验性DNSSEC协议修改，解决了与标准DNSSEC和DNS共存的问题。
Throughout this document, familiarity with the DNS system (RFC 1035 [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and RFC 4035 [4]) is assumed.
在本文档中，假设熟悉DNS系统（RFC 1035[5]）和DNS安全扩展（RFC 4033[2]、RFC 4034[3]和RFC 4035[4]）。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
When discussing DNSSEC experiments, it is necessary to classify these experiments into two broad categories:
在讨论DNSSEC实验时，有必要将这些实验分为两大类：
Backwards-Compatible: describes experimental changes that, while not strictly adhering to the DNSSEC standard, are nonetheless interoperable with clients and servers that do implement the DNSSEC standard.
向后兼容：描述了一些实验性更改，这些更改虽然不严格遵守DNSSEC标准，但可以与实现DNSSEC标准的客户端和服务器进行互操作。
Non-Backwards-Compatible: describes experiments that would cause a standard security-aware resolver to (incorrectly) determine that all or part of a zone is bogus, or to otherwise not interoperate with standard DNSSEC clients and servers.
非向后兼容：描述会导致标准安全感知解析器（错误地）确定某个区域的全部或部分是伪造的，或者无法与标准DNSSEC客户端和服务器互操作的实验。
Not included in these terms are experiments with the core DNS protocol itself.
这些术语中不包括核心DNS协议本身的实验。
The methodology described in this document is not necessary for backwards-compatible experiments, although it certainly may be used if desired.
本文件中描述的方法对于向后兼容的实验不是必需的，但如果需要，当然可以使用。
The core of the methodology is the use of strictly unknown algorithm identifiers when signing the experimental zone, and more importantly, having only unknown algorithm identifiers in the DS records for the delegation to the zone at the parent.
该方法的核心是在对实验区进行签名时使用严格未知的算法标识符，更重要的是，在DS记录中只有未知的算法标识符，以便在父级授权给该区。
This technique works because of the way DNSSEC-compliant validators are expected to work in the presence of a DS set with only unknown algorithm identifiers. From RFC 4035 [4], Section 5.2:
这种技术之所以有效，是因为符合DNSSEC的验证器在只有未知算法标识符的DS集存在时的工作方式。根据RFC 4035[4]，第5.2节：
If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above.
如果验证器不支持经过身份验证的DS RRset中列出的任何算法，则解析程序没有受支持的从父级到子级的身份验证路径。如上所述，冲突解决程序应将此情况视为已验证的NSEC RRset证明不存在DS RRset的情况。
And further:
此外：
If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned.
如果冲突解决程序不支持经过身份验证的DS RRset中列出的任何算法，则冲突解决程序将无法验证到子区域的身份验证路径。在这种情况下，解析程序应将子区域视为未签名。
Although this behavior isn't strictly mandatory (as marked by MUST), it is unlikely for a validator to implement a substantially different behavior. Essentially, if the validator does not have a usable chain of trust to a child zone, then it can only do one of two things: treat responses from the zone as insecure (the recommended behavior), or treat the responses as bogus. If the validator chooses the latter, this will both violate the expectation of the zone owner and defeat the purpose of the above rule. However, with local policy, it is within the right of a validator to refuse to trust certain zones based on any criteria, including the use of unknown signing algorithms.
虽然这种行为不是严格强制的（如MUST所示），但验证器不太可能实现完全不同的行为。本质上，如果验证器对子区域没有可用的信任链，那么它只能做两件事中的一件：将来自该区域的响应视为不安全（建议的行为），或者将响应视为伪造。如果验证器选择后者，这将违反区域所有者的期望，并破坏上述规则的目的。但是，对于本地策略，验证器有权基于任何标准拒绝信任某些区域，包括使用未知的签名算法。
Because we are talking about experiments, it is RECOMMENDED that private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1. Note that secure handling of private algorithms requires special handing by the validator logic. See "Clarifications and Implementation Notes for DNSSECbis" [6] for further details.) Normally, instead of actually inventing new signing algorithms, the recommended path is to create alternate algorithm identifiers that are aliases for the existing, known algorithms. While, strictly speaking, it is only necessary to create an alternate identifier for the mandatory algorithms, it is suggested that all optional defined algorithms be aliased as well.
由于我们讨论的是实验，因此建议使用私有算法编号（参见RFC 4034[3]，附录A.1.1。注意，私有算法的安全处理需要验证器逻辑进行特殊处理。有关更多详细信息，请参见“DNSSECbis的澄清和实施说明”[6]），建议的方法不是真正发明新的签名算法，而是创建替代算法标识符，这些标识符是现有已知算法的别名。严格来说，只需要为强制算法创建一个备用标识符，但建议所有可选定义的算法也使用别名。
It is RECOMMENDED that for a particular DNSSEC experiment, a particular domain name base is chosen for all new algorithms, then the algorithm number (or name) is prepended to it. For example, for experiment A, the base name of "dnssec-experiment-a.example.com" is chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-experiment-a.example.com". However, any unique identifier will suffice.
建议对于特定的DNSSEC实验，为所有新算法选择特定的域名库，然后在其前面添加算法编号（或名称）。例如，对于实验A，选择基本名称“dnssec-experience-A.example.com”。然后，算法3（DSA）和算法5（RSASHA1）的别名被定义为“3.dnssec-experience-a.example.com”和“5.dnssec-experience-a.example.com”。但是，任何唯一标识符都已足够。
Using this method, resolvers (or, more specifically, DNSSEC validators) essentially indicate their ability to understand the DNSSEC experiment's semantics by understanding what the new algorithm identifiers signify.
使用这种方法，解析器（或者更具体地说，DNSSEC验证器）基本上通过理解新算法标识符的含义来表示其理解DNSSEC实验语义的能力。
This method creates two classes of security-aware servers and resolvers: servers and resolvers that are aware of the experiment (and thus recognize the experiment's algorithm identifiers and experimental semantics), and servers and resolvers that are unaware of the experiment.
此方法创建两类安全感知服务器和解析器：感知实验的服务器和解析器（从而识别实验的算法标识符和实验语义），以及不感知实验的服务器和解析器。
This method also precludes any zone from being both in an experiment and in a classic DNSSEC island of security. That is, a zone is either in an experiment and only possible to validate experimentally, or it is not.
该方法还排除了实验和经典DNSSEC安全岛中的任何区域。也就是说，一个区域要么在实验中，只能通过实验进行验证，要么不是。
The DNSSEC experiment MUST define the particular set of (previously unknown) algorithm identifiers that identify the experiment and define what each unknown algorithm identifier means. Typically, unless the experiment is actually experimenting with a new DNSSEC algorithm, this will be a mapping of private algorithm identifiers to existing, known algorithms.
DNSSEC实验必须定义一组特定的（以前未知的）算法标识符，用于识别实验并定义每个未知算法标识符的含义。通常，除非实验实际上是在试验新的DNSSEC算法，否则这将是私有算法标识符到现有已知算法的映射。
Normally the experiment will choose a DNS name as the algorithm identifier base. This DNS name SHOULD be under the control of the authors of the experiment. Then the experiment will define a mapping between known mandatory and optional algorithms into this private algorithm identifier space. Alternately, the experiment MAY use the Object Identifier (OID) private algorithm space instead (using algorithm number 254), or MAY choose non-private algorithm numbers, although this would require an IANA allocation.
通常，实验将选择一个DNS名称作为算法标识符基础。此DNS名称应由实验作者控制。然后，实验将定义已知强制算法和可选算法之间的映射，映射到这个私有算法标识符空间。或者，实验可以使用对象标识符（OID）私有算法空间（使用算法编号254），或者可以选择非私有算法编号，尽管这需要IANA分配。
For example, an experiment might specify in its description the DNS name "dnssec-experiment-a.example.com" as the base name, and declare that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an alias of DNSSEC algorithm 5 (RSASHA1).
例如，实验可能在其描述中指定DNS名称“dnssec-experience-a.example.com”作为基本名称，并声明“3.dnssec-experience-a.example.com”是dnssec算法3（DSA）的别名，“5.dnssec-experiment-a.example.com”是dnssec算法5（RSASHA1）的别名。
Resolvers MUST only recognize the experiment's semantics when present in a zone signed by one or more of these algorithm identifiers. This is necessary to isolate the semantics of one experiment from any others that the resolver might understand.
解析程序必须仅在由一个或多个算法标识符签名的区域中识别实验的语义。这对于将一个实验的语义从解析器可能理解的任何其他实验中分离出来是必要的。
In general, resolvers involved in the experiment are expected to understand both standard DNSSEC and the defined experimental DNSSEC protocol, although this isn't required.
一般来说，参与实验的解析器需要理解标准DNSSEC和定义的实验DNSSEC协议，尽管这不是必需的。
There are a number of considerations with using this methodology.
使用这种方法有许多考虑因素。
1. If an unaware validator does not correctly follow the rules laid out in RFC 4035 (e.g., the validator interprets a DNSSEC record prior to validating it), or if the experiment is broader in scope that just modifying the DNSSEC semantics, the experiment may not be sufficiently masked by this technique. This may cause unintended resolution failures.
1. 如果未意识到的验证器没有正确遵循RFC 4035中规定的规则（例如，验证器在验证DNSSEC记录之前对其进行解释），或者如果实验范围更广，仅修改DNSSEC语义，则该技术可能无法充分掩盖实验。这可能会导致意外的解决失败。
2. It will not be possible for security-aware resolvers unaware of the experiment to build a chain of trust through an experimental zone.
2. 对于不知道实验的安全感知解析器来说，通过实验区域建立信任链是不可能的。
This general methodology MAY be used for non-backwards compatible DNSSEC protocol changes that start out as or become standards. In this case:
此通用方法可用于不向后兼容的DNSSEC协议更改，这些更改最初作为标准或成为标准。在这种情况下：
o The protocol change SHOULD use public IANA allocated algorithm identifiers instead of private algorithm identifiers. This will help identify the protocol change as a standard, rather than an experiment.
o 协议更改应使用公共IANA分配的算法标识符，而不是私有算法标识符。这将有助于将协议变更确定为标准，而不是实验。
o Resolvers MAY recognize the protocol change in zones not signed (or not solely signed) using the new algorithm identifiers.
o 解析程序可以使用新的算法标识符识别未签名（或未单独签名）区域中的协议更改。
Zones using this methodology will be considered insecure by all resolvers except those aware of the experiment. It is not generally possible to create a secure delegation from an experimental zone that will be followed by resolvers unaware of the experiment.
使用此方法的区域将被所有解析器视为不安全区域，但知道该实验的解析器除外。通常不可能从实验区域创建一个安全的委托，该委托后面会有不知道实验的解析器。
Implementers should take into account any security issues that may result from environments being configured to trust both experimental and non-experimental zones. If the experimental zone is more
实现者应该考虑到由于将环境配置为信任实验区和非实验区而可能导致的任何安全问题。如果实验区更大
vulnerable to attacks, it could, for example, be used to promote trust in zones not part of the experiment, possibly under the control of an attacker.
易受攻击，例如，它可用于在非实验区域（可能在攻击者的控制下）促进信任。
[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] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[2] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[3] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[4] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[5] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[5] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[6] Weiler, S. and R. Austein, "Clarifications and Implementation Notes for DNSSECbis", Work in Progress, March 2007.
[6] Weiler，S.和R.Austein，“DNSSECbis的澄清和实施说明”，进展中的工作，2007年3月。
Author's Address
作者地址
David Blacka VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
David Blacka VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21355，邮编20166
Phone: +1 703 948 3200
EMail: davidb@verisign.com
URI: http://www.verisignlabs.com
Phone: +1 703 948 3200
EMail: davidb@verisign.com
URI: http://www.verisignlabs.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。