Network Working Group M. Andrews
Request for Comments: 4431 Internet Systems Consortium
Category: Informational S. Weiler
SPARTA, Inc.
February 2006
Network Working Group M. Andrews
Request for Comments: 4431 Internet Systems Consortium
Category: Informational S. Weiler
SPARTA, Inc.
February 2006
The DNSSEC Lookaside Validation (DLV) DNS Resource Record
DNSSEC查找验证（DLV）DNS资源记录
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines a new DNS resource record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain.
本文档定义了一个新的DNS资源记录，称为DNSSEC Lookaside Validation（DLV）RR，用于在DNS委派链之外发布DNSSEC信任锚。
DNSSEC [1] [2] [3] authenticates DNS data by building public-key signature chains along the DNS delegation chain from a trust anchor, ideally a trust anchor for the DNS root.
DNSSEC[1][2][3]通过从信任锚点（理想情况下是DNS根的信任锚点）沿DNS委派链构建公钥签名链来验证DNS数据。
This document defines a new resource record for publishing such trust anchors outside of the DNS's normal delegation chain. Use of these records by DNSSEC validators is outside the scope of this document, but it is expected that these records will help resolvers validate DNSSEC-signed data from zones whose ancestors either aren't signed or refuse to publish delegation signer (DS) records for their children.
此文档定义了一个新的资源记录，用于在DNS的正常委托链之外发布此类信任锚。DNSSEC验证器对这些记录的使用超出了本文档的范围，但预计这些记录将帮助解析程序验证来自其祖先未签名或拒绝为其子代发布委派签名者（DS）记录的区域的DNSSEC签名数据。
The DLV resource record has exactly the same wire and presentation formats as the DS resource record, defined in RFC 4034, Section 5. It uses the same IANA-assigned values in the algorithm and digest type fields as the DS record. (Those IANA registries are known as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm Numbers" registries.)
DLV资源记录与RFC 4034第5节中定义的DS资源记录具有完全相同的连线和表示格式。它在算法和摘要类型字段中使用与DS记录相同的IANA赋值。（这些IANA注册表称为“DNS安全算法编号”和“DS RR类型算法编号”注册表。）
The DLV record is a normal DNS record type without any special processing requirements. In particular, the DLV record does not inherit any of the special processing or handling requirements of the DS record type (described in Section 3.1.4.1 of RFC 4035). Unlike the DS record, the DLV record may not appear on the parent's side of a zone cut. A DLV record may, however, appear at the apex of a zone.
DLV记录是一种正常的DNS记录类型，没有任何特殊的处理要求。特别是，DLV记录不继承DS记录类型的任何特殊处理或处理要求（如RFC 4035第3.1.4.1节所述）。与DS记录不同，DLV记录可能不会出现在分区切割的父侧。然而，DLV记录可能出现在分区的顶点。
For authoritative servers and resolvers that do not attempt to use DLV RRs as part of DNSSEC validation, there are no particular security concerns -- DLV RRs are just like any other DNS data.
对于不尝试将DLV RRs用作DNSSEC验证的一部分的权威服务器和解析程序，没有特别的安全问题--DLV RRs与任何其他DNS数据一样。
Software using DLV RRs as part of DNSSEC validation will almost certainly want to impose constraints on their use, but those constraints are best left to be described by the documents that more fully describe the particulars of how the records are used. At a minimum, it would be unwise to use the records without some sort of cryptographic authentication. More likely than not, DNSSEC itself will be used to authenticate the DLV RRs. Depending on how a DLV RR is used, failure to properly authenticate it could lead to significant additional security problems including failure to detect spoofed DNS data.
使用DLV RRs作为DNSSEC验证的一部分的软件几乎肯定会对其使用施加限制，但这些限制最好留待更全面地描述记录使用细节的文档来描述。至少，在没有某种加密身份验证的情况下使用这些记录是不明智的。更有可能的是，DNSSEC本身将用于验证DLV RRs。根据DLV RR的使用方式，未能正确对其进行身份验证可能会导致严重的其他安全问题，包括无法检测伪造的DNS数据。
RFC 4034, Section 8, describes security considerations specific to the DS RR. Those considerations are equally applicable to DLV RRs. Of particular note, the key tag field is used to help select DNSKEY RRs efficiently, but it does not uniquely identify a single DNSKEY RR. It is possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm type, and the same key tag. An implementation that uses only the key tag to select a DNSKEY RR might select the wrong public key in some circumstances.
RFC 4034第8节描述了特定于DS RR的安全注意事项。这些注意事项同样适用于DLV RRs。需要特别注意的是，key tag字段用于帮助有效选择DNSKEY RR，但它不能唯一标识单个DNSKEY RR。两个不同的DNSKEY RRs可能具有相同的所有者名称、相同的算法类型和相同的密钥标记。在某些情况下，仅使用key标记选择DNSKEY RR的实现可能会选择错误的公钥。
For further discussion of the security implications of DNSSEC, see RFC 4033, RFC 4034, and RFC 4035.
有关DNSSEC安全含义的进一步讨论，请参阅RFC 4033、RFC 4034和RFC 4035。
IANA has assigned DNS type code 32769 to the DLV resource record from the Specification Required portion of the DNS Resource Record Type registry, as defined in [4].
IANA已将DNS类型代码32769从DNS资源记录类型注册表的规范要求部分分配给DLV资源记录，如[4]中所定义。
The DLV resource record reuses the same algorithm and digest type registries already used for the DS resource record, currently known as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm Numbers" registries.
DLV资源记录重用已用于DS资源记录的相同算法和摘要类型注册表，当前称为“DNS安全算法编号”和“DS RR类型算法编号”注册表。
[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] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[4] Eastlake，D.，Brunner Williams，E.和B.Manning，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 29292000年9月。
Authors' Addresses
作者地址
Mark Andrews Internet Systems Consortium 950 Charter St. Redwood City, CA 94063 US
马克·安德鲁斯互联网系统联合会950美国加利福尼亚州红木市查特街94063号
EMail: Mark_Andrews@isc.org
EMail: Mark_Andrews@isc.org
Samuel Weiler SPARTA, Inc. 7075 Samuel Morse Drive Columbia, Maryland 21046 US
塞缪尔·韦勒·斯巴达公司，美国马里兰州哥伦比亚塞缪尔·莫尔斯大道7075号，邮编：21046
EMail: weiler@tislabs.com
EMail: weiler@tislabs.com
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）提供。