diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc4431.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4431.txt | 227 |
1 files changed, 0 insertions, 227 deletions
diff --git a/contrib/bind9/doc/rfc/rfc4431.txt b/contrib/bind9/doc/rfc/rfc4431.txt deleted file mode 100644 index 8b38872..0000000 --- a/contrib/bind9/doc/rfc/rfc4431.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - |
