Zusammenfassung

  • Ein validierender rekursiver Resolver setzt das DNSSEC-Bit AD, wenn er die relevanten RRsets in Answer und Authority für authentisch hält; es meldet sein Urteil und beweist sich nicht selbst.
  • Ein nicht validierender Stub darf sich darauf nur verlassen, wenn er dem rekursiven Resolver vertraut und den Kanal zu ihm schützt oder authentisiert. Ein validierender Stub sollte selbst prüfen.
  • DNSSEC-Validierung, sichere Übermittlung des Urteils und Anwendungsentscheidung sind getrennte Beweisgrenzen; ein fehlendes AD diagnostiziert allein keine Bogus-Daten.

Ein einzelnes Bit nach umfangreicher Arbeit

Ein Endgerät fragt seinen konfigurierten rekursiven Resolver nach einem Namen. Dieser kann zuvor Delegationen verfolgt, DNSKEY- und DS-Einträge beschafft, eine Kette zum Vertrauensanker aufgebaut, Signaturen geprüft und authentisierte Nicht-Existenz verarbeitet haben. Diese Geschichte passt nicht in die letzte Antwort. Stattdessen kann im Header Authenticated Data, kurz AD, stehen.

Die Verdichtung ist nützlich. Ein kleiner Client muss nicht unbedingt die Arbeit eines leistungsfähigen Resolvers wiederholen. Doch zugleich verschwindet Kontext. Zeigt eine Oberfläche AD=1 bloß als „sicher“, scheint der gesamte Weg samt Ziel und gewünschter Aktion bestätigt. Die Standards machen eine deutlich engere Aussage.

RFC 4035 verlangt, dass ein sicherheitsbewusster rekursiver Nameserver AD nur setzt, wenn er alle RRsets in den Bereichen Answer und Authority der Antwort für authentisch hält. Das handelnde Subjekt ist der Resolver. Er wendet seine Vertrauensanker, seine Richtlinie und seine Sicht auf die Antwort an. Das Bit fasst seine Bewertung zusammen; es ist keine Signatur über den DNS-Header und enthält nicht die Beweise, mit denen ein beliebiger Empfänger das Ergebnis selbst nachvollziehen könnte.

Scott Rose wird neben Roy Arends, Rob Austein, Matt Larson und Dan Massey als einer der fünf Autoren von RFC 4033, 4034 und 4035 genannt. Der gemeinsame Entwurf machte aus einem kleinen Feld keinen universellen Beweis. Er trennte den Ort der Validierung, die Übermittlung des Ergebnisses und das Vertrauen, das am nächsten Übergang weiterhin nötig ist.

Vier Zustände passen nicht in ein Flag

RFC 4033 beschreibt vier allgemeine Ergebnisse sicherheitsbewusster Auflösung: Secure, Insecure, Bogus und Indeterminate. Secure bedeutet eine gültige Kette unter einem akzeptierten Vertrauensanker. Insecure bezeichnet einen nachweisbar unsignierten Zustand. Bogus sind Daten, die validierbar sein sollten, aber die Prüfungen nicht bestehen. Indeterminate gilt, wenn Information oder Richtlinie keine andere Zuordnung erlaubt.

AD codiert diese vier Zustände nicht. Ist es gesetzt, meldet es das positive Authentisierungsergebnis nach den Resolver-Regeln. Ist es nicht gesetzt, gibt es mehrere mögliche Gründe: Daten können ordnungsgemäß Insecure sein, der Resolver validiert vielleicht nicht, die Anfrage verlangte die Rückgabe des Bits nicht oder ein anderer Zustand beziehungsweise eine lokale Regel griff. AD=0 pauschal mit „DNSSEC fehlgeschlagen“ zu übersetzen, verwischt genau die bereitgestellten Unterschiede.

RFC 6840 präzisiert außerdem das Verhalten der Anfrage. Ein Anfragender kann darin AD setzen, um Verständnis und Interesse an dem Ergebnis zu signalisieren, ohne über DO zugleich DNSSEC-Datensätze anzufordern. Ein validierender Resolver soll AD in der Antwort nur setzen, wenn die Validierungsbedingungen erfüllt sind und die Anfrage DO oder AD enthielt. Dieselben validierten Daten können daher ohne das Bit bei einem Client ankommen, der keine dieser Fähigkeiten angezeigt hat. Aus dem Fehlen lässt sich der interne Zustand nicht rekonstruieren.

Auch ein gesetztes Bit behauptet nicht, jeder Resolver käme zum selben Ergebnis. Vertrauensanker und lokale Regeln können abweichen; ebenso Zeit, Cache und beobachtete Antwort. DNSSEC beschreibt die Prüfmechanik. AD berichtet, wie ein bestimmter Resolver sie auf eine bestimmte Antwort angewandt hat.

Das Bit schützt sein Trägerpaket nicht

Kann ein Angreifer den Verkehr zwischen Stub und Resolver verändern, muss er keine DNSSEC-Signatur fälschen, um einen blind auf AD vertrauenden Client zu täuschen. Er kann ein unsigniertes Header-Bit ändern, eine Antwort ersetzen oder in den Kanal eingreifen. Der Client vertraut dann einer Behauptung, deren Transport er nie authentisiert hat.

RFC 3655 formulierte diese Grenze bereits vor der endgültigen Kernsuite: Ein sicherheitsunbewusster Stub darf AD nicht blind vertrauen, außer er kommuniziert mit einem vertrauenswürdigen, sicherheitsbewussten rekursiven Resolver über sicheren Transport oder Nachrichtenauthentisierung. RFC 4033 behält diese Architektur bei. Wer Validierung delegiert, muss sowohl dem rekursiven Server als auch dem Kanal vertrauen. Für diese Eigenschaft sind Integrität und Authentisierung maßgeblich; Vertraulichkeit allein macht das Urteil nicht verlässlich.

Die beiden Bedingungen sind unabhängig. Ein authentisierter Kanal zu einem nicht vertrauenswürdigen Resolver beweist nur, wer eine fragwürdige Antwort lieferte. Ein vertrauenswürdiger Resolver über einen veränderbaren Kanal kann nicht für das tatsächlich Angekommene einstehen. Erst die Kombination trägt delegierte Validierung.

Ein validierender Stub wählt einen anderen Weg. Laut RFC 4035 soll er das empfangene AD ignorieren und selbst validieren. Die DNSSEC-Einträge der Antwort können Eingaben sein, doch das Urteil entsteht durch Prüfung der Kette unter eigener Vertrauenskonfiguration. Das fremde Bit ist Beobachtung, nicht Autorität.

Vertrauen in einen Resolver ist eine Betriebsbeziehung

„Vertrauenswürdiger Resolver“ ist kein Produktaufkleber. Der Client muss wissen, welchen Dienst er ansprechen will, den Austausch angemessen authentisieren und dessen Validierungsrichtlinie akzeptieren. Eine konfigurierte Adresse belegt nicht, dass alle Zwischenstationen die Aussage erhalten.

Darum verlagert zentrale Validierung auch Governance. Der Resolverbetreiber wählt Anker, Softwareversionen, Ausnahmen, Fehlerverhalten und Cachezeiten. Clients übernehmen diese Entscheidungen, wenn sie nur das verdichtete Ergebnis konsumieren. Zentralisierung kann die richtige Architektur sein; AD beseitigt die Abhängigkeit aber nicht, sondern komprimiert sie.

Roses beruflicher Hintergrund zeigt die aktuelle Bedeutung. Sein NIST-Profil nennt den Schutz von Internetinfrastruktur und sichere Protokolle. Im März 2026 veröffentlichte NIST eine neue Fassung seines Secure Domain Name System Deployment Guide von Scott Rose, Cricket Liu und Ross Gibson. DNSSEC erscheint darin als laufendes Betriebssystem: Eine signierte Zone ist nur ein Teil; Resolverkonfiguration, geschützte Nutzung des Ergebnisses und Überwachung entscheiden, ob die Evidenz unversehrt zur Entscheidung gelangt.

Die Zuschreibung muss genau bleiben. Rose ist einer von fünf Koautoren der Kernsuite, nicht alleiniger Erfinder von DNSSEC und nicht Herr über dessen Implementierungen. RFC 3655 und RFC 6840 stammen von anderen Autorengruppen. Seine Bedeutung liegt in der dauerhaften Architektur, an der er mitwirkte: Authentisierung hat einen Geltungsbereich, und ein Empfänger muss wissen, wessen Schluss er übernimmt.

Ein DNS-Urteil ist kein Anwendungsurteil

Selbst korrekt erzeugt und authentisiert zugestellt endet AD an der Grenze der DNS-Daten. Es kann stützen, dass bestimmte RRsets unter der DNSSEC-Kette des Resolvers authentisiert wurden. Es beweist nicht, dass ein Webserver unversehrt, eine IP-Adresse harmlos, ein Zertifikat zulässig, ein Empfänger berechtigt oder eine Transaktion freigegeben ist.

Anwendungen verbinden DNS mit TLS-Authentisierung, Zertifikats- und Namensprüfung, Kontoberechtigungen, Aktualitätsanforderungen, Inhaltsrichtlinien, Geschäftsregeln und Nutzerabsicht. Manche Protokolle beziehen DNSSEC-authentisierte Datensätze bewusst in eine größere Entscheidung ein. Das ist nützliche Komposition, bleibt aber Komposition. Die Anwendung muss benennen können, welcher Datensatz, welches Resolverurteil, welche Kanaleigenschaft und welche spätere Prüfung die Handlung trugen.

Ein Auditprotokoll mit nur AD=true löscht diese Abhängigkeiten. Besser sind drei getrennte Ereignisse: Validierungsstatus und Richtlinie des Resolvers, authentisierte Zustellung dieses Status sowie Nutzung oder Ablehnung durch die Anwendung. Bei einem Fehler lässt sich dann zwischen falscher Validierung, Transportmanipulation und überdehnter DNS-Autorität unterscheiden.

Das Authenticated-Data-Bit ist weder belanglos noch magisch. Es ist die kompakte Aussage eines bestimmten Prüfers über bestimmte DNS-Daten. Diszipliniert eingesetzt bewahrt es dessen geleistete Arbeit, ohne geliehenes Vertrauen als Ende-zu-Ende-Beweis auszugeben.

Quellen