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]
+