Summary

  • RFC 5074, authored by Sam Weiler, described a third DNSSEC validation path for signed zones whose parent did not provide the ordinary DS connection.
  • DLV did not remove the need for trust: a resolver first needed a configured trust anchor for the separate DLV domain, whose validated records could then stand in for DS records.
  • ISC removed DLV registry entries in 2017 but kept a signed empty zone for older resolvers; RFC 8749 retired the mechanism in 2020 as ordinary parent-to-root delegation became more complete.

The chain stopped at the parent

A zone can publish DNSSEC signatures and still be difficult for a resolver to validate. In the normal path, a parent zone publishes a Delegation Signer (DS) record that connects the child’s DNSKEY to the parent’s signed data. If an ancestor is unsigned, or a registrar does not accept the child’s DS record, the cryptographic chain cannot simply continue upward. That was a practical barrier during DNSSEC’s early deployment, when the root and many top-level domains were not yet signed.

DNSSEC Lookaside Validation added another route. RFC 5074 describes DLV records published in a separately signed DLV domain. A DLV domain could hold an authenticated entry for a zone below a chosen target, even when the zone was not its own child. A validating resolver could use a validated DLV record in the way it would use a DS record, then continue checking signatures in the zone. RFC 4431 specifies the DLV record type, 32769; Mark Andrews and Sam Weiler co-authored that record specification. Weiler authored RFC 5074, which documents the resolver behavior and the broader mechanism.

The important limit is in the name “trust anchor.” DLV did not make the resolver trust an unfamiliar registry automatically. An operator first had to configure a trust anchor for the DLV domain. The system therefore exchanged one blocked link in the parent chain for a different trust source that the resolver operator chose to accept. RFC 5074 also says ordinary applicable trust anchors should be tried first; if normal validation succeeds, DLV processing need not occur. Where multiple DLV domains overlapped, the RFC left precedence to implementations and recommended exposing that choice to operators.

The transition needed a controlled end

ISC says its DLV Registry began operating in 2006 as a temporary aid to DNSSEC adoption. As the root became signed and parent-to-child DS paths spread, that additional route became less useful. RFC 8749, published in 2020 by W. Mekking and Dan Mahoney, says the root was signed in July 2010 and 1,389 of 1,531 top-level domains had a secure delegation from it by May 2019. The RFC moved RFCs 4431 and 5074 to Historic status.

The retirement was not only a standards label. ISC removed DLV records on 30 September 2017 but kept dlv.isc.org as a signed empty zone. ISC reported that completely removing the zone could make older BIND resolvers still configured to use DLV return SERVFAIL for many client queries. The empty zone let those stale configurations resolve without finding an obsolete DLV record, while the registry stopped making validation claims.

RFC 8749 gives the trade-offs directly: DLV could reduce pressure on parent zones to sign and registrars to accept DS records, and it added validation code. The authors reported implementation in BIND 9 and Unbound and no known private-enterprise use. Those statements describe the publication-era record, not a current count of deployed resolvers. The evidence supports a bounded conclusion: DLV was a transitional trust path whose usefulness declined as the ordinary chain improved, and whose operators planned a compatibility period for old configurations.

Heng Lu’s Note 64 is used only as an editorial lens: it asks whether a common mechanism stays narrow and whether changes follow working adoption. It is not evidence about Weiler or DLV.

Sources