228 lines
7.7 KiB
Plaintext
228 lines
7.7 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|