Zusammenfassung

  • RFC 5074, verfasst von Sam Weiler, beschreibt DNSSEC Lookaside Validation (DLV) für signierte Zonen, deren Elternzone keinen gewöhnlichen DS-Eintrag bereitstellt.
  • DLV machte Vertrauen nicht überflüssig: Ein Resolver musste zuerst einen Vertrauensanker für eine separate DLV-Domain einrichten und konnte deren authentisierte Einträge anschließend wie DS-Daten für die Zielzone verwenden.
  • ISC entfernte 2017 die Registry-Einträge, hielt aber für alte Resolver eine signierte leere Zone vor. RFC 8749 stufte DLV 2020 als Historic ein, nachdem sich die gewöhnliche DNSSEC-Delegation weitgehend etabliert hatte und zusätzlicher Prüfcode seinen Nutzen verlor.

Wenn die Delegationskette an der Elternzone endet

Eine Zone kann DNSSEC-Signaturen veröffentlichen, ohne dass ein Resolver sie bis zu einem bekannten Vertrauensanker prüfen kann. Im üblichen Verfahren veröffentlicht die Elternzone einen Delegation Signer (DS)-Eintrag. Er verknüpft den DNSKEY der Kindzone mit den signierten Daten der Elternzone. Ist ein Vorfahr nicht signiert oder nimmt der Registrar den DS-Eintrag der Kindzone nicht an, fehlt ein Glied der Vertrauenskette. In der frühen Verbreitungsphase von DNSSEC war das praktisch relevant, weil die Rootzone und viele Top-Level-Domains noch keine Signaturen trugen.

DLV eröffnete einen weiteren Einstieg. RFC 5074 erlaubt einer separat signierten DLV-Domain, authentisierte Einträge für darunterliegende Zonen zu veröffentlichen, auch wenn diese keine direkten Kinder der DLV-Domain sind. Ein Resolver kann einen erfolgreich geprüften DLV-Eintrag wie einen DS-Eintrag behandeln und anschließend DNSKEY und Signaturen der Zielzone prüfen. RFC 4431 definiert den DLV-Ressourceneintrag mit Typ 32769; Mark Andrews und Sam Weiler verfassten diese Spezifikation gemeinsam. Weiler verfasste RFC 5074, der die Resolverlogik und das Verfahren beschreibt.

Der andere Weg nahm dem Resolver die Vertrauensentscheidung nicht ab, sondern verlagerte sie. Vor der Nutzung musste der Betreiber einen Vertrauensanker für die DLV-Domain konfigurieren. RFC 5074 empfiehlt, zunächst alle passenden gewöhnlichen Vertrauensanker zu prüfen; gelingt die normale Validierung, ist DLV nicht erforderlich. Bei überlappenden DLV-Domains überlässt der RFC die Reihenfolge den Implementierungen und empfiehlt, sie für Betreiber konfigurierbar zu machen. Der zusätzliche Pfad brachte Spielraum, ließ aber sichtbar, wer ihn freigab.

Eine Statusänderung räumte alte Konfigurationen nicht ab

Nach Angaben von ISC startete die DLV Registry 2006 als vorübergehende Hilfe bei der DNSSEC-Einführung. Mit der signierten Rootzone und mehr signierten Top-Level-Delegationen verlor der zusätzliche Pfad an Bedeutung. RFC 8749 von W. Mekking und Dan Mahoney hält fest, dass die Rootzone im Juli 2010 signiert wurde und im Mai 2019 1.389 von 1.531 Top-Level-Domains eine sichere Delegation von der Rootzone hatten. Der 2020 veröffentlichte RFC stufte RFC 4431 und RFC 5074 als Historic ein.

Damit war ein Eintrag in einem Standardsregister geändert, aber keine Konfiguration auf einem alten Resolver. ISC entfernte die DLV-Einträge am 30. September 2017 und ließ dlv.isc.org als signierte leere Zone bestehen. Laut ISC hätten einige ältere, weiterhin für DLV konfigurierte BIND-Resolver bei einer vollständigen Entfernung der Zone für viele Clientanfragen SERVFAIL zurückgegeben. Die leere Zone sollte solchen Altinstallationen keine gültigen DLV-Aussagen mehr liefern, ohne in den von ISC untersuchten Fällen sofort den Betrieb abzuschneiden.

Das ist ein Bericht über bestimmte Legacy-Konfigurationen, keine Aussage über jedes Resolverprodukt.

RFC 8749 nennt Nutzen und Aufwand: DLV konnte den Druck auf Elternzonen zu signieren und auf Registrare, DS-Einträge anzunehmen, mindern, erhöhte aber zugleich die Komplexität der Validierungslogik. Die Autoren nennen Implementierungen in BIND 9 und Unbound und ihnen keine bekannten privaten Unternehmensnutzungen. Das beschreibt den Kenntnisstand bei Veröffentlichung, nicht den gesamten Resolverbestand von 2026. Die Quellen tragen eine begrenzte Aussage: DLV füllte eine Lücke, solange die gewöhnliche Kette wuchs; für den Rückbau mussten Betreiber jedoch Konfigurationen berücksichtigen, die den ursprünglichen Bedarf überdauert hatten.

Heng Lus Note 64 dient hier ausschließlich als redaktionelle Perspektive: Sie fragt, ob ein gemeinsamer Mechanismus auf das nötige Maß begrenzt bleibt und ob Änderungen an tatsächlicher Einführung gemessen werden. Sie ist kein Beleg für Aussagen über Weiler oder DNSSEC.

Quellen