Network Working Group S. Weiler
Internet-Draft SPARTA, Inc.
Expires: August 29, 2006 February 25, 2006
DNSSEC Lookaside Validation (DLV)
draft-weiler-dnssec-dlv-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not
be created.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
DNSSEC Lookaside Validation (DLV) is a mechanism for publishing
DNSSEC trust anchors outside of the DNS delegation chain. It allows
resolvers to validate DNSSEC-signed data from zones whose ancestors
either aren't signed or refuse to publish DS records for their
children.
Weiler Expires August 29, 2006 [Page 1]
Internet-Draft DLV February 2006
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 describes a way to publish trust anchors in the DNS but
outside of the normal delegation chain.
Some design trade-offs leading to the mechanism presented here are
described in [8].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
2. Architecture
DNSSEC Lookaside Validation allows a set of well-known domains,
called "DLV domains", to publish secure entry points for zones that
are not their own children.
With DNSSEC, validators may expect a zone to be secure when they have
one of two things: a preconfigured trust anchor for the zone or a
validated DS for the zone in its parent (which presumes a
preconfigured trust anchor for the parent or another ancestor). DLV
adds a third mechanism: a validated entry in a DLV domain (which
presumes a preconfigured trust anchor for the DLV domain). Whenever
a DLV domain publishes a DLV RRset for a zone, a resolver may expect
the named zone to be signed. Absence of a DLV RRset for a zone does
not necessarily mean that the zone should be expected to be insecure;
if the resolver has another reason to believe the zone should be
secured, validation of that zone's data should still be attempted.
3. DLV Domains
A DLV domain includes trust statements about descendants of a single
zone, called the 'target' zone. For example, the DLV domain
trustbroker.example.com could target the .org zone and the DLV domain
bar.example.com could target the root.
A DLV domain contains one or more DLV records [5] for each of the
target's descendant zones that have registered security information
with it. For a given zone, the corresponding name in the DLV domain
is formed by replacing the target zone name with the DLV domain name.
Weiler Expires August 29, 2006 [Page 2]
Internet-Draft DLV February 2006
For example, assuming the DLV domain trustbroker.example.com targets
the .org zone, any DLV records corresponding to the zone example.org
can be found at example.trustbroker.example.com. DLV records
corresponding to the org zone can be found at the apex of
trustbroker.example.com.
As another example, assuming the DLV domain bar.example.com targets
the root zone, DLV records corresponding to the zone example.org can
be found at example.org.bar.example.com. DLV records corresponding
to the org zone can be found at org.bar.example.com. And DLV records
corresponding to the zone zone itself can be found at the apex of
bar.example.com.
A DLV domain SHOULD NOT contain data other than DLV records,
appropriate DNSSEC records validating that data, the apex NS and SOA
records, and, optionally, delegations.
To gain full benefit from aggressive negative caching, described in
section X, a DLV domain SHOULD NOT use minimally-covering NSEC
records, as described in [6], and it SHOULD NOT use NSEC3 records, as
described in [7]
4. Overview of Resolver Behavior
To minimize load on the DLV domain's authoritative servers as well as
query response time, a resolver SHOULD first attempt validation using
any applicable (non-DLV) trust anchors. If the validation succeeds
(with a result of Secure), DLV processing need not occur.
When configured with a trust anchor for a DLV domain, a resolver
SHOULD attempt to validate all queries at and below the target of
that DLV domain.
To do validation using DLV, a resolver looks for a (validated) DLV
RRset applicable to the query, as described in the following section,
and uses it as though it were a DS RRset to validate the answer using
the normal procedures in RFC4035 Section 5.
For each query, the resolver attempts validation using the "closest
enclosing" DLV RRset, which is the DLV RRset with the longest name
that matches the query or could be an ancestor of the QNAME. For
example, assuming the DLV domain trustbroker.example.com targets the
.org zone, and there exist DLV RRsets named trustbroker.example.com
(applicable to .org), example.trustbroker.example.com (applicable to
example.org, and sub.example.trustbroker.example.com (applicable to
sub.example.org), a resolver would use the
sub.example.trustbroker.example.com DLV RRset for validating queries
Weiler Expires August 29, 2006 [Page 3]
Internet-Draft DLV February 2006
for sub.example.org.
This policy is slightly different than the one discussed in previous
versions of this document. More detailed discussion of this policy
and other possible choices can be found in [8].
5. Resolver Behavior
As above, to minimize load on the DLV domain's authoritative servers
as well as query response time, a resolver SHOULD first attempt
validation using any applicable (non-DLV) trust anchors. If the
validation succeeds (with a result of Secure), DLV processing need
not occur.
To find the closest enclosing DLV RRset for a given query, the
resolver starts by looking for a DLV RRset corresponding to the
QNAME. If it doesn't find a DLV RRset for that name (as confirmed by
the presence of a validated NSEC record) and that name is not the
apex of the DLV domain, the resolver removes the leading label from
the name and tries again. This process is repeated until a DLV RRset
is found or it is proved that there is no enclosing DLV RRset
applicable to the QNAME. In all cases, a resolver SHOULD check its
cache for the desired DLV RRset before issuing a query. Section 8
discusses a slight optimization to this strategy.
Having found the closest enclosing DLV RRset or received a proof that
no applicable DLV RRset exists, the resolver MUST validate that RRset
or non-existence proof using the normal procedures in Section 5 of
RFC4035. In particular, any delegations within the DLV domain need
to be followed, with normal DNSSEC validation applied. If validation
of the DLV RRset leads to a result of Bogus, then it SHOULD NOT be
used and the validation result for the original query SHOULD be
Bogus, also. If validation of the DLV RRset leads to a result of
Insecure (the DLV record is in an unsecured portion of the DLV tree),
then it SHOULD NOT be used and the validation result for the original
query SHOULD be Insecure, also. If the validation of the DLV RRset
leads to a result of Secure, then resolver then treats that DLV RRset
as though it were a DS RRset for the applicable zone and attempts
validation using the procedures described in RFC4035 Section 5.
To avoid confusing authors of resolvers and protocol specifications,
a resolver SHOULD NOT attempt to validate data from a DLV domain
using DLV.
6. Aggressive Negative Caching
Weiler Expires August 29, 2006 [Page 4]
Internet-Draft DLV February 2006
To minimize load on authoritative servers for DLV domains,
particularly those with few entries, DLV resolvers SHOULD implement
aggressive negative caching, as defined in this section.
Previously, cached negative responses were indexed by QNAME, QCLASS,
QTYPE, and the setting of the CD bit (see RFC4035 section 4.7) and
only queries matching the index would be answered from the cache.
With aggressive negative caching, the resolver, in addition to
checking to see if the answer is in its cache before sending a query,
checks to see whether any cached and validated NSEC record denies the
existence of the sought record(s).
Using aggressive negative caching, a resolver will not make queries
for any name covered by a cached and validated NSEC record.
Furthermore, a resolver answering queries from clients will
synthesize a negative answer whenever it has an applicable validated
NSEC in its cache unless the CD bit was set on the incoming query.
7. Overlapping DLV Domains
It is possible to have multiple DLV domains targeting overlapping
portion of the DNS hierarchy. For example, two DLV domains, perhaps
operated by different parties, might target the same zone, or one DLV
domain might target the root while another targets .org.
If a resolver supports multiple DLV domains, the choice of precedence
in case of overlap is left up to the implementation and SHOULD be
exposed as a configuration option to the user. As a default, it is
suggested that the most specific DLV domain be given precedence.
8. Optimization
This section proposes an immature and untested proposed optimization
to further reduce query load on DLV servers and improve resolver
response time. This is not intended to be an optional extension --
if included in the final DLV specification, it must be supported by
all DLV-aware name servers and resolvers.
Authoritative servers, when processing a query for a DLV RRset,
should include all DLV RRsets potentially applicable to a query in
the Additional section of the response as well as NSEC records
proving the non-existence of any other applicable DLV records in the
DLV domain.
Resolvers still seek out of the closest enclosing DLV RRset first.
Should they receive any data about other DLV RRsets in the zone, they
Weiler Expires August 29, 2006 [Page 5]
Internet-Draft DLV February 2006
may cache and use it (assuming that it validates), thus avoiding
further round-trips to the DLV domain's authoritative servers.
This optimization may preclude the use the delegations within a DLV
domain.
9. Security Considerations
Resolvers MUST NOT use a DLV record unless it has been successfully
authenticated. Normally, resolvers will have a trust anchor for the
DLV domain and use DNSSEC to validate the data in it.
Aggressive negative caching increases the need for resolvers do some
basic validation of incoming NSEC records before caching them. In
particular, the 'next name' field in the NSEC record must be within
the zone that generated (and signed) the NSEC. Otherwise, a
malicious zone operator could generate an NSEC that reaches out of
its zone -- into its ancestor zones, even up into the root zone --
and use that NSEC to spoof away any name that sorts after the name of
the NSEC. We call these overreaching NSECs. More insidiously, an
attacker could use an overreaching NSEC in combination with a signed
wildcard record to substitute a signed positive answer in place of
the real data. This checking is not a new requirement -- these
attacks are a risk even without aggressive negative caching.
However, aggressive negative caching makes the checking more
important. Before aggressive negative caching, NSECs were cached
only as metadata associated with a particular query. An overreaching
NSEC that resulted from a broken zone signing tool or some
misconfiguration would only be used by a cache for those queries that
it had specifically made before. Only an overreaching NSEC actively
served by an attacker could cause misbehavior. With aggressive
negative caching, an overreaching NSEC can cause more broader
problems even in the absence of an active attacker. This threat can
be easily mitigated by checking the bounds on the NSEC.
As a reminder, resolvers MUST NOT use the mere presence of an RRSIG
or apex DNSKEY RRset as a trigger for doing validation, whether
through the normal DNSSEC hierarchy or DLV. Otherwise, an attacker
might perpetrate a downgrade attack by stripping off those RRSIGs or
DNSKEYs.
RFC4034 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
Weiler Expires August 29, 2006 [Page 6]
Internet-Draft DLV February 2006
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
RFC4033, RFC4034, and RFC4035.
10. IANA Considerations
IANA is asked to create a DLV registry, published at dlv.iana.org or
another suitable domain name chosen at its own discretion, targeting
the root and include in that zone entries for any TLDs that wish to
have DLV records published. IANA is instructed to use its own best
practices for authenticating TLD operators' requests to insert,
modify, and delete DLV entries. This DLV registry should itself be
signed with DNSSEC.
DLV makes use of the DLV resource record previously assigned by IANA.
11. References
11.1. 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Andrews, M. and S. Weiler, "The DNSSEC Lookaside Validation
(DLV) DNS Resource Record", RFC 4431, February 2006.
11.2. Informative References
[6] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and
DNSSEC On-line Signing",
draft-ietf-dnsext-dnssec-online-signing-02 (work in progress),
January 2006.
Weiler Expires August 29, 2006 [Page 7]
Internet-Draft DLV February 2006
[7] Laurie, B., "DNSSEC Hash Authenticated Denial of Existence",
draft-ietf-dnsext-nsec3-03 (work in progress), October 2005.
[8] Weiler, S., "Deploying DNSSEC Without a Signed Root", Technical
Report 1999-19, Information Networking Institute, Carnegie
Mellon University, April 2004.
Paul Vixie, Suzanne Woolf, and Johan Ihren contributed significantly
to the exploration of possible resolver algorithms that led to this
design. More about those explorations is documented in [8].
Johan Ihren and the editor share the blame for aggressive negative
caching.
Thanks to David B. Johnson of Rice University and Marvin Sirbu of
Carnegie Mellon University for their patient review of [8] which led
to this specification being far more complete.
Appendix B. Changes from pre00 to 00
The primary difference between earlier versions of this draft
(circulated privately) and the present one is the resolver policy for
choosing DLV entries from one DLV domain, which could have a
tremendous impact on load at the DLV domain's authoritative servers.
This document describes a policy of "Closest Encloser Trumps", as
described in Section 3.2.2 of [8]. The previous version described a
policy of "Accept Any Success".
Weiler Expires August 29, 2006 [Page 8]
Internet-Draft DLV February 2006
Author's Address
Samuel Weiler
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, Maryland 21046
US
Email: weiler@tislabs.com
Weiler Expires August 29, 2006 [Page 9]
Internet-Draft DLV February 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Weiler Expires August 29, 2006 [Page 10]
