DNSSEC Lookaside Validation (DLV)
RFC 5074

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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.org