diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4431.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4431.txt')
-rw-r--r-- | doc/rfc/rfc4431.txt | 227 |
1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc4431.txt b/doc/rfc/rfc4431.txt new file mode 100644 index 0000000..8b38872 --- /dev/null +++ b/doc/rfc/rfc4431.txt @@ -0,0 +1,227 @@ + + + + + + +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] + |