--- /dev/null
+
+
+
+
+
+
+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
+
+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).
+
+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.
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+2. DLV Resource Record
+
+ 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.)
+
+
+
+
+
+Andrews & Weiler Informational [Page 1]
+\f
+RFC 4431 DLV Resource Record February 2006
+
+
+ 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.
+
+3. Security Considerations
+
+ 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.
+
+ 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.
+
+ 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.
+
+ For further discussion of the security implications of DNSSEC, see
+ RFC 4033, RFC 4034, and RFC 4035.
+
+4. IANA Considerations
+
+ 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].
+
+ 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.
+
+
+
+
+
+Andrews & Weiler Informational [Page 2]
+\f
+RFC 4431 DLV Resource Record February 2006
+
+
+5. Normative References
+
+ [1] 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., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [4] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
+ System (DNS) IANA Considerations", BCP 42, RFC 2929,
+ September 2000.
+
+Authors' Addresses
+
+ Mark Andrews
+ Internet Systems Consortium
+ 950 Charter St.
+ Redwood City, CA 94063
+ US
+
+ EMail: Mark_Andrews@isc.org
+
+
+ Samuel Weiler
+ SPARTA, Inc.
+ 7075 Samuel Morse Drive
+ Columbia, Maryland 21046
+ US
+
+ EMail: weiler@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews & Weiler Informational [Page 3]
+\f
+RFC 4431 DLV Resource Record February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Andrews & Weiler Informational [Page 4]
+\f
projects / thirdparty / bind9.git / commitdiff
