There are two RFCs that specify DLV:
RFC 4431 [RFC 4431] specifies the DLV resource record.
RFC 5074 [RFC 5074] specifies the DLV mechanism for publishing trust anchors outside the DNS delegation chain and how validators can use them to validate DNSSEC-signed data.
This document moves both RFC 4431
] and RFC 5074
] to Historic status. This is a clear signal to implementers that the DLV resource record and the DLV mechanism SHOULD NOT
be implemented or deployed.
The RFCs being moved to Historic status are referenced by a couple of other RFCs. The sections below describe the changes to those documents due to the DLV RFCs being reclassified as Historic.
One RFC makes reference to RFC 4431 [RFC 4431
("DNSSEC Lookaside Validation (DLV)") [RFC 5074
] describes the DLV mechanism itself. This document moves RFC 5074
] to Historic status as well.
("The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA") [RFC 6698
DNSSEC forms certificates (the binding of an identity to a key) by combining a DNSKEY, DS, or DLV resource record with an associated RRSIG record. These records then form a signing chain extending from the client's trust anchors to the RR of interest.
This document updates RFC 6698
] to exclude the DLV resource record from certificates.
("Clarifications and Implementation Notes for DNS Security (DNSSEC)") [RFC 6840
] states that when trust anchors come from different sources, a validator may choose between them based on the perceived reliability of those sources. But in reality, this does not happen in validators (both BIND 9 and Unbound have an option for a DLV trust anchor that can be used solely as a fallback).
This document updates RFC 6840
] to exclude the DLV registries from the trust anchor selection.
("Aggressive Use of DNSSEC-Validated Cache") [RFC 8198
] only references RFC 5074
] because aggressive negative caching was first proposed there.