Zusammenfassung

  • RFC 7646 erlaubt einem Resolver-Betreiber, die DNSSEC-Validierung für einen bestimmten Zweig anzuhalten, nachdem geschultes Fachpersonal eine Fehlkonfiguration statt eines Angriffs festgestellt hat.
  • Die Ausnahme muss lokal, vorübergehend und präzise sein: Antworten werden wie Daten aus einer unsignierten Zone behandelt, tragen kein AD-Bit und sollen wieder validiert werden, sobald die Zone funktioniert.

Analyse

DNSSEC macht den rekursiven Resolver zu einem Prüfer. Er sucht nicht nur eine Antwort, sondern kann eine Authentifizierungskette von signierten DNS-Daten bis zu mindestens einem konfigurierten Vertrauensanker aufbauen. Das Ergebnis unterscheidet zwischen Secure, Insecure, Bogus und Indeterminate. Authentifizierte Daten können mit dem AD-Bit gekennzeichnet werden. Als Bogus bewertete Daten führen für einen Stub, der nicht selbst validiert, üblicherweise zu einem Fehler statt zu einer verwendbaren Antwort.

Dieser Schutz betrifft Herkunft und Integrität der DNS-Daten, nicht ihre Vertraulichkeit. Zugleich schafft er eine wirkliche Durchsetzungsgrenze. Bei korrekter Signatur liefert der Resolver eine überprüfbare Zusicherung. Läuft eine Signatur ab, wird eine Delegation inkonsistent oder bricht die Authentifizierungskette aus einem anderen Grund, verhindert dieselbe Kontrolle die Nutzung der Antwort. Die Reparatur bleibt Aufgabe des Zonenbetreibers, doch die Störung trifft zunächst die Nutzer des Resolvers.

RFC 7646 definiert für diesen Ausnahmefall den negativen Vertrauensanker, kurz NTA. Konfiguriert ein Betreiber einen NTA an einem Namen, beendet der Resolver dort die DNSSEC-Validierung. Antworten im ausgewählten Zweig behandelt er wie Daten aus einer unsignierten Zone und setzt kein AD-Bit. Die Konfiguration repariert weder die Zone noch ihre Delegation oder Signaturen. Sie ändert die lokale Richtlinie der rekursiven Infrastruktur.

Der Ort der Kontrolle verschiebt die praktische Autorität. Ein gewöhnlicher Vertrauensanker gibt der Authentifizierung einen Ausgangspunkt. Ein NTA veröffentlicht dagegen keine alternative Wahrheit im DNS. Er weist eine Organisation an, innerhalb ihrer eigenen Verwaltungsgrenze vorübergehend auf einen Schutz zu verzichten, und soll nicht darüber hinaus verteilt werden. Zwei Nutzer können daher gleichzeitig denselben Namen abfragen: Ein Resolver hält den Fehler aufrecht, ein anderer liefert unter seiner Ausnahme nicht authentifizierte Daten.

Verfügbarkeitsdruck allein darf die Ausnahme nicht auslösen. Vor ihrer Aktivierung muss geschultes technisches Personal feststellen, dass eine Fehlkonfiguration und kein Angriff vorliegt. Es muss außerdem bestätigen, dass die Domain nicht absichtlich defekt ist, und sollte in angemessener Weise versuchen, den Domaininhaber zu erreichen. Ein NTA ist deshalb kein automatischer Fallback, den Software bei jedem Validierungsfehler wählen darf.

Hier verläuft die Grenze zwischen Tatsache, Schlussfolgerung und Unbekanntem. Die RFCs beschreiben Mechanismus und Bedingungen, beweisen aber nicht, dass ein bestimmter Vorfall harmlos ist. Die eingefrorenen Quellen sagen auch nicht, welche namentlich bekannten Resolver-Betreiber derzeit NTAs zulassen oder einsetzen, wie viel Ausfallzeit sie vermeiden oder wie groß Nutzen und Schaden in einer konkreten Produktionsflotte wären. Die Anwendung auf einen realen Vorfall braucht zusätzliche Betriebsbelege und eine eigenständige menschliche Entscheidung.

Die zweite Grenze ist der erfasste Name. Die Ausnahme soll genau an der fehlerhaften Domain oder Subdomain liegen. Sie darf nicht zu einem übergeordneten Namen hochgezogen oder auf unbeteiligte Zweige ausgedehnt werden. Belegen die Fakten nur den Fehler eines einzelnen Dienstes, würde ein NTA an einem Vorfahren mehr DNS-Daten ohne Authentifizierung zulassen, als die Diagnose rechtfertigt.

Die dritte Grenze ist die Zeit. Jeder NTA braucht eine konfigurierte Laufzeit und muss automatisch ablaufen. RFC 7646 besagt, dass er nicht länger als eine Woche bestehen sollte. Die Implementierung sollte die Validierung regelmäßig erneut versuchen und die Ausnahme entfernen, sobald sie wieder erfolgreich ist. Bei der Entfernung sollten auch Cache-Einträge am betroffenen Knoten und darunter gelöscht werden, damit unter der Ausnahme akzeptierte Daten die Rückkehr der Authentifizierung nicht überdauern.

Es geht somit nicht um eine abstrakte Wahl zwischen Sicherheit und Verfügbarkeit. Nutzer und Dienstverantwortliche können den fehlerhaften Zweig wieder erreichen. Im Gegenzug verlieren sie während eines bekannten Zeitfensters die DNSSEC-Zusicherung des Resolvers für diesen Zweig. Korrekt betriebene Zonen außerhalb der Grenze sollen weiter validiert werden. Der Mechanismus begrenzt den Tausch, doch seine tatsächliche Wirkung lässt sich nur mit Daten über Verkehr, Abhängigkeiten und den konkreten Vorfall messen.

Transparenz vervollständigt die Kontrolle. RFC 7646 empfiehlt, aktuelle und frühere NTAs einschließlich Aktivierungs- und Entfernungszeit offenzulegen. In der ursprünglichen Definition gab es keinen eigenen DNS-Antwortcode, der die Nutzung eines NTA direkt anzeigte. Ein fehlendes AD-Bit bedeutet, dass keine Authentifizierungszusage vorliegt. Es erklärt allein jedoch nicht, welche Richtlinie dazu geführt hat.

Erweiterte DNS-Fehler brachten später zusätzliche Diagnosesignale. RFC 8914 definiert unter anderem DNSSEC Indeterminate und DNSSEC Bogus. Solche Codes können die Untersuchung unterstützen, ändern aber nicht die Protokollverarbeitung. Sie sind zudem nicht authentifiziert, wenn die DNS-Transaktion, die sie transportiert, ungeschützt ist. Ein EDE ist daher ein Hinweis, kein hinreichender Beleg für eine Fehlkonfiguration und keine Berechtigung, die Validierung auszusetzen.

Auch das Gegenmodell hat Kosten. Ein abgelehnter NTA bewahrt die Validierungsrichtlinie, kann aber den signierten Zweig unerreichbar lassen. Eine globale Abschaltung der Validierung oder der Wechsel zu einem nicht validierenden Resolver könnte mehr Erreichbarkeit herstellen, würde den Verlust der Zusicherung jedoch weit über den betroffenen Namen hinaus ausdehnen. Ein enger NTA liegt dazwischen: Er stellt eine bestimmte Abhängigkeit wieder her und lässt den Rest des DNS-Baums unter Validierung.

Die RFCs schreiben keine einheitliche Genehmigungskette für alle Organisationen vor. Aus ihren Kontrollen lässt sich dennoch ableiten, was ein belastbares Register enthalten sollte: die genehmigende Person, die Belege für eine Fehlkonfiguration, den kleinsten betroffenen Namen, Aktivierung und Ablauf, den Kontaktversuch mit dem Domaininhaber, erneute Validierungen, die endgültige Entfernung und die Cache-Bereinigung. Das ist eine betriebliche Schlussfolgerung aus dem Mechanismus, keine Behauptung über die heutige Praxis eines bestimmten Betreibers.

Um das Risiko zu verstehen, muss niemand beschuldigt werden. Die Stärke des NTA liegt gerade darin, einen Dienst ohne Änderung seiner fehlerhaften signierten Zone wieder erreichbar zu machen. Bei korrekter Diagnose schützt das die Kontinuität. Bei einer Fehldiagnose oder einer zum Normalfall gewordenen Ausnahme kann es Nutzer nicht authentifizierten Daten aussetzen. Die verantwortbare Schlussfolgerung ist daher eng: Ein NTA darf nur als benannte, dokumentierte, menschlich genehmigte, zeitlich begrenzte und offengelegte Authentizitätsausnahme mit automatischem Ablauf und überprüfter Entfernung bestehen.

Quellen