DNSSEC Lookaside Validation (DLV)
RFC 5074
Document | Type |
RFC - Historic
(November 2007; No errata)
Status changed by status-change-dlv-to-historic
Was draft-weiler-dnssec-dlv (individual in sec area)
|
|
---|---|---|---|
Author | Samuel Weiler | ||
Last updated | 2020-03-26 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5074 (Historic) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
Network Working Group S. Weiler Request for Comments: 5074 SPARTA, Inc. Category: Informational November 2007 DNSSEC Lookaside Validation (DLV) 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. Abstract DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain. It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publish Delegation Signer (DS) records for their children. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. DLV Domains . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview of Validator Behavior . . . . . . . . . . . . . . . . 3 5. Details of Validator Behavior . . . . . . . . . . . . . . . . . 4 6. Aggressive Negative Caching . . . . . . . . . . . . . . . . . . 5 6.1. Implementation Notes . . . . . . . . . . . . . . . . . . . 5 7. Overlapping DLV Domains . . . . . . . . . . . . . . . . . . . . 6 8. Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . .10 Weiler Informational [Page 1] RFC 5074 DLV November 2007 1. Introduction DNSSEC [RFC4033] [RFC4034] [RFC4035] authenticates DNS data by building public-key signature chains along the DNS delegation chain from a trust anchor. In the present world, with the DNS root and many key top level domains unsigned, the only way for a validating resolver ("validator") to validate the many DNSSEC-signed zones is to maintain a sizable collection of preconfigured trust anchors. Maintaining multiple preconfigured trust anchors in each DNSSEC-aware validator presents a significant management challenge. This document describes a way to publish trust anchors in the DNS outside of the normal delegation chain, as a way to easily configure many validators within an organization or to "outsource" trust anchor management. Some design trade-offs leading to the mechanism presented here are described in [INI1999-19]. 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 [RFC2119]. 2. Architecture DNSSEC Lookaside Validation allows a set of 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 validators have one of two things: a preconfigured trust anchor for the zone or a validated Delegation Signer (DS) record for the zone in the zone's 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 contains a DLV RRset for a zone, a validator 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 validator has another reason to believe the zone should be secured, validation of that zone's data should still be attempted. Weiler Informational [Page 2] RFC 5074 DLV November 2007 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 [RFC4431] 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. For example, assuming the DLV domain trustbroker.example.com targets the org zone, any DLV records corresponding to the zone example.orgShow full document text