Zusammenfassung

  • DNSOP eröffnete am 2. September den Working-Group-Adoption-Call für draft-farrokhi-dnsop-ede-nta-01; er endet am 16. September. Revision 01 bleibt ein individueller Internet-Draft, kein RFC und kein abgeschlossenes Adoptionsergebnis.
  • EDE 33 teilt mit, dass beim Erzeugen einer Antwort eine abdeckende NTA aktiv war. Der Entwurf erlaubt das Signal auch dann, wenn die Ausnahme den Inhalt materiell nicht beeinflusst hat.
  • Ein eng begrenzter Wirkungsbeleg sollte EDE-Ursprung und Transportschutz mit einer zeitgleichen Validierung ohne NTA verbinden oder den Gegenversuch ausdrücklich als nicht gemessen festhalten.

Eine Zuweisung entscheidet nicht über die Dokumenthoheit

Der DNSOP-Aufruf fragt, ob die Arbeitsgruppe den Entwurf zur Offenlegung negativer Vertrauensanker übernehmen soll. Die Frist läuft vom 2. bis 16. September. Im Datatracker steht weiterhin Call For Adoption By WG Issued. Der Text ist als Informational vorgesehen, bleibt aber ein individueller Entwurf.

Das IANA-Register der DNS-Parameter führt Nummer 33 bereits als Negative Trust Anchor. Der gemeinsame Wert verhindert, dass frühe Implementierungen verschiedene Zahlen verwenden. Er entscheidet weder den Call noch den Wortlaut und misst keine Verbreitung.

Die Trennung ist sachgerecht. IANA koordiniert den Namensraum, die Vorsitzenden dokumentieren den Arbeitsgruppenkonsens, ein späterer Publikationsschritt bestimmt den RFC-Status, und Betreiber wählen die laufende Implementierung. Ein registrierter Code kann diese Rollen nicht zusammenziehen.

Die NTA setzt eine lokale Prüfung aus

RFC 7646 verortet eine NTA im validierenden rekursiven Resolver. Ab einem gewählten Namen beendet er die normale DNSSEC-Authentifizierungskette und behandelt abgedeckte Antworten wie Daten aus einer unsignierten Zone. Er repariert weder Signaturen noch Delegation und erhält keine Autorität über die Zone.

Weil Erreichbarkeit durch das Aussetzen eines Schutzes entsteht, ist die Ausnahme gebunden. Sie darf nicht automatisch eingerichtet werden. Geschultes Personal soll Fehlkonfiguration und möglichen Angriff unterscheiden, absichtlich defekte Testdomains ausschließen und den Zonenbetreiber angemessen zu erreichen versuchen. Der Bereich bleibt eng. Reguläre Validierung wird erneut geprüft; die NTA läuft automatisch ab, möglichst nach höchstens einer Woche, wird nach erfolgreicher Validierung rasch entfernt, und der betroffene Cache wird geleert.

Diese Genehmigungs-, Laufzeit- und Entfernungsakte sind bereits Gegenstand anderer Berichterstattung. Hier geht es ausschließlich um den Beweiswert einer Antwort, die EDE 33 enthält.

Gleiches Signal, unterschiedliche Gegenwelt

Nach Revision 01 bedeutet EDE 33, dass beim Generieren der Antwort eine abdeckende NTA in Kraft war. Die Information bleibt diagnostisch, verändert die AD-Bit-Verarbeitung nicht und gehört nicht auf einen rein autoritativen Server, der keine Validierung ausführt.

Ein Betreiber soll den Code bei betroffenen Antworten senden. Zusätzlich darf der Resolver ihn bei jeder Antwort unter einer aktiven NTA beifügen, unabhängig davon, ob die NTA den Inhalt materiell verändert hat.

Unter derselben Ausnahme kann ein Name ohne NTA an DNSSEC scheitern, während ein zweiter Name auch im normalen Pfad erfolgreich validiert. Beide Antworten dürfen 33 tragen. Bei der ersten ändert sich das Ergebnis; bei der zweiten wird nur eine Umgebungseigenschaft gemeldet. Dem Empfänger fehlt der nicht ausgeführte Vergleich.

Der Entwurf vermeidet damit eine verpflichtende Doppelvalidierung jeder Anfrage. Das ist eine vernünftige Grenze für ein leichtes Transparenzsignal. Sie verlangt aber, dass Auswertungssysteme Anwesenheit nicht mit Wirkung gleichsetzen.

Strukturierte Hinweise bleiben unvollständig

EXTRA-TEXT kann den eingerichteten Namen, einen Grund, einen Verweis oder die erwartete Dauer nennen. Im strukturierten Format steht d für die Domain der NTA und t für einen ungefähren Zeitpunkt, bis zu dem sie bestehen könnte.

Beide Angaben sind optional. d grenzt die Abdeckung ein, beweist jedoch keinen Einfluss auf diese Antwort. t ist eine Erwartung, kein protokolliertes Entfernen. Eine menschlich lesbare Begründung weist weder den Genehmigenden noch dessen Mandat nach. Mehrere aktive NTAs können mehrere Instanzen erzeugen; Text pro Instanz liefert mehr Kontext, aber keine Kausalentscheidung.

RFC 8914 beschreibt EDE als Zusatzinformation, die den DNS-Ablauf nicht verändern darf. Ohne geschützte DNS-Transaktion oder Transportstrecke ist sie nicht inhärent authentisiert. Ein Forwarder kann das EDE verwerfen, weiterreichen oder neu erzeugen. Die Quelle sollte genannt werden, weil der letzte Sender sonst als Urheber erscheint.

Belegt ist folglich nur: „Das antwortende System erklärt, dass diese Antwort zu diesem Zeitpunkt von einer NTA abgedeckt war.“ Nicht belegt sind Zonenfehler, Berechtigung der Ausnahme, ihre Wirkung oder ihr heutiger Fortbestand. Auch ein fehlender Code beweist keine NTA-freie Validierung, denn das Senden ist eine Empfehlung und Zwischenstationen dürfen ihn entfernen.

Der Versuchsaufbau änderte sich unter dem Dokument

Im Adoptionsfaden entstand ein präzises Beispiel für diese Zeitgrenze. Revision 01 nutzt eine absichtlich falsche sichere Kinddelegation. Mitautor Joe Abley erklärte in einer Antwort vom 2. September, dass Cloudflares Standardautomatisierung die Delegation wiederholt repariere oder den Zone Cut entferne. Der Live-Zustand zeigte daher in diesem Moment nicht mehr das gewünschte Szenario; die Autoren wollten ihn korrigieren.

Daraus folgt weder ein Ausfall noch ein versagender Produktionsschutz. Es zeigt, dass Dokument und Demonstrationsumgebung getrennte Versionen besitzen. Automatische Reparatur kann den ursprünglichen Vergleichszustand beseitigen, während die Textrevision unverändert bleibt.

Eine frühere Implementierungsdiskussion zeigte bereits eine reale Antwort mit EDE 33. Aus ihr ging nicht hervor, ob die NTA am abgefragten Namen oder einem Vorfahren lag, ob mehrere bestanden oder ob die Antwort auch ohne Ausnahme validiert hätte. Ein begrenztes Signal kann wahr sein, ohne eine vollständige Erklärung zu liefern.

Wirkung außerhalb des Pakets dokumentieren

Kundenadressen, Abfrageverläufe, interne Tickets und sensible Störungsdetails gehören nicht in EXTRA-TEXT. Die Lücke lässt sich mit einem getrennten NTA-Wirkungsbeleg schließen. Das ist mein redaktioneller Vorschlag, keine Vorgabe von IETF oder IANA.

Für eine Stichprobe oder einen Vorfall verbindet er Zeitpunkt und Antwort-Fingerprint, Resolver- oder Forwarderrolle, Ursprung des EDE, Schutz der beobachteten Strecke, Code sowie d und t, AD-Zustand, eine zeitgleiche Validierung in einem isolierten Pfad ohne NTA oder die begründete Angabe nicht gemessen, Unterschiede in Daten oder Ergebnis sowie einen Verweis auf die getrennte Genehmigungs- und Ablaufakte.

Nicht jede Nutzeranfrage muss doppelt laufen. Stichproben und sichere Reproduktionen genügen; ein fehlender Gegenversuch bleibt sichtbar. Öffentliche Berichte können Wirkungsklassen aggregieren, ohne Domains oder Nutzer offenzulegen. Ungewissheit zu speichern ist belastbarer, als Koinzidenz zur Ursache zu machen.

Heng Lus The Policy Mirror trennt Akteur, Regel und Beleg. IANA verwaltet den Index, der IETF-Prozess den Dokumentstatus, der Betreiber die Ausnahme und ein bestimmter Pfad die Diagnose. Running Code Primary verankert die Wirkungsfrage anschließend in einem beobachteten Resolver statt in der Absicht des Entwurfs.

EDE 33 macht eine Ausnahme sichtbar. Gerade weil der Code keine Wirkung behauptet, sollte die Auswertung diese Behauptung nicht hinzufügen.

Quellen

  1. DNSOP-Aufruf zur Arbeitsgruppenadoption
  2. Aktueller Datatracker-Eintrag
  3. Offenlegung von NTAs in DNS-Antworten, Revision 01
  4. Dokumentverlauf
  5. Joe Ableys Hinweis zum Beispielzustand
  6. Diskussion der Implementierungsgrenze
  7. RFC 7646 — DNSSEC Negative Trust Anchors
  8. RFC 8914 — Extended DNS Errors
  9. IANA DNS Parameters
  10. DNSOP-Arbeitsgruppeneintrag
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Running Code Primary