Zusammenfassung

  • RFC 8914 transportiert Extended DNS Error in EDNS-Option 15: einen 16-Bit-INFO-CODE und optionalen UTF-8-EXTRA-TEXT. EDE ergänzt den Basis-RCODE, ersetzt ihn nicht; Empfänger verarbeiten den RCODE weiter und müssen auf die Diagnose nicht reagieren.
  • Ein EDE ist die Aussage eines Resolvers oder Forwarders über seine Beobachtung, kein Ende-zu-Ende-Beweis der Ursache. Zwischenstellen dürfen die Option verwerfen oder neu erzeugen; bei knappem UDP-Platz verschwindet die Erklärung vor dem grundlegenden DNS-Ergebnis.
  • Eine belastbare Kette verbindet Rohbytes, sendenden Hop, RCODE, Cache, Upstream-Versuche, DNSSEC-Trace, lokale Regel, Retry und unabhängige Bestätigung. Kein einzelner Code darf Validierung abschalten oder einen schwächeren Resolver wählen.

Der Unterschied zwischen Benennung und Befund

SERVFAIL fasst viele Vorgänge zusammen. Ein Validator kann eine abgelaufene Signatur sehen, ein Resolver kann die Authority nicht erreichen, und eine lokale Policy kann eine Antwort sperren. EDE macht diese Unterschiede übertragbar.

Die Oberfläche „DNSSEC Bogus“ wirkt dennoch endgültiger, als die Evidenz ist. Das Urteil kann von einem bestimmten Trust Anchor, einer falschen Uhr, einem alten Cache, einer Softwareversion oder einer vom Upstream übernommenen Bewertung abhängen. Der Code macht die Beobachtung auffindbar; konkurrierende Erklärungen beseitigt er nicht.

Die Diagnose darf ein Ticket öffnen, Packet Capture priorisieren und das zuständige Team auswählen. Allein darf sie nicht DNSSEC deaktivieren, Ersatzdaten akzeptieren, dauerhaft zu einem weniger strengen Resolver wechseln oder öffentlich Schuld zuschreiben.

Eine kleine Option mit getrennten Verträgen

RFC 8914 definiert EDE als EDNS option code 15. Die ersten zwei Oktette enthalten INFO-CODE; danach kann menschenlesbarer UTF-8-EXTRA-TEXT folgen. Programme sollen diesen Text nicht als Steuerbefehl auswerten. Eine Antwort darf mehrere EDE tragen, und EDE kann mit jedem RCODE einschließlich NOERROR erscheinen.

Der Basis-RCODE bleibt maßgeblich. Erkennen, anzeigen, speichern, alarmieren und Verhalten ändern sind getrennte lokale Entscheidungen. Der Standard gibt dem Sender durch eine Diagnose keine Fernsteuerung über den Empfänger.

Das IANA-Register schafft ein gemeinsames Vokabular. RFC 8914 definierte zunächst 0 bis 24 für DNSSEC-Fehler, stale answers, forged, blocked, censored, filtered, prohibited, Netzwerkfehler und unerreichbare Authorities. Das Register wächst weiter und kennt öffentliche sowie private Bereiche. Eine Registrierung koordiniert die Bedeutung, bestätigt aber nicht, dass eine konkrete Zuordnung wahr ist.

An jedem Forwarder kann die Urheberschaft wechseln

Zwischen Stub und Authority können Unternehmens-Forwarder, Filter und rekursive Resolver liegen. RFC 8914 erlaubt einem Forwarder, empfangene EDE zu verwerfen oder aus eigener Verarbeitung neue zu erzeugen. Gibt er eine Upstream-Aussage weiter, sollte der Text deren Quelle nennen.

Diese Flexibilität unterstützt reale Netze, verlangt aber Provenienz. Nur den letzten Code zu speichern, verwischt direkte Beobachtung, Übernahme und Neuerzeugung. Benötigt werden Prozess, Endpoint, Node, Version, Transport, Upstream-Versuch, auslösende Regel und vollständige Reihenfolge aller Optionen.

Kanalschutz löst eine andere Frage. Authentisiertes oder verschlüsseltes DNS kann den Peer auf diesem Hop binden, beweist aber nicht dessen Erklärung eines entfernten Fehlers. In ungeschütztem UDP oder TCP kann zudem ein On-Path-Akteur die Option verändern. Transportintegrität ist keine kausale Autorität.

Unter Größendruck verschwindet zuerst die Erklärung

EDNS aus RFC 6891 stellt Optionsraum bereit, doch UDP-Antworten haben ein Budget. Wird es überschritten, soll nach RFC 8914 zuerst EXTRA-TEXT, dann die gesamte EDE-Option entfallen; reicht das nicht, folgt TC nach den DNS-Regeln. Eine große signierte Antwort kann SERVFAIL bewahren und die Erklärung verlieren.

Fehlendes EDE beweist also keine fehlende Diagnose. Vorhandenes EDE beweist nicht, dass jeder Hop dieselbe Aussage sah. Canaries müssen fehlende Option, einen oder mehrere Codes, geänderte Reihenfolge, unbekannte und private Werte, leeren oder langen Text, ungültiges UTF-8, UDP-Entfernung, TCP-Retry sowie Preserve/Drop/Recreate durch Forwarder abdecken.

EXTRA-TEXT liegt außerhalb der Vertrauensgrenze

Freitext kann die Untersuchung beschleunigen und zugleich Kontonummer, Kundenname, interne Blocklist, Backend-Adresse oder unveröffentlichte Policy offenlegen. Steuerzeichen und bidirektionale Sequenzen können Logs oder Anzeigen täuschen. RFC 8914 weist ausdrücklich auf Datenschutzrisiken hin.

Der Evidence Store hält Originalbytes unter engem Zugriff. Analysten sehen sicher decodierten Text, öffentliche Oberflächen nur die minimal bereinigte Fassung. Retention braucht eine Frist. Aus EXTRA-TEXT dürfen keine automatischen Befehle entstehen.

Running Code verbindet Codes mit lokaler Policy

Unbound kann EDE, Hinweise für serve-expired und DNS Error Reporting nach RFC 9567 aktivieren. BIND kann Response-Policy-Zone-Ergebnissen Codes wie forged, blocked, censored, filtered und prohibited geben. PowerDNS Recursor sendet Extended Resolution Errors und kann die Anwendung eines Negative Trust Anchor erläutern.

Damit ist EDE produktive Praxis, aber der Trigger bleibt lokal. Derselbe Wire Code kann je nach Produkt, Version und Konfiguration aus anderer Evidenz entstehen. Ein Audit muss vom Bytewert bis zur tatsächlich ausgeführten Regel reichen und darf nicht beim Namen im Register enden.

RFC 8767 zeigt dieselbe Trennung bei stale data. EDE kann erklären, warum eine alte Antwort geliefert wurde; zulässiges Alter, Auswahl und Abschaltung bleiben Resolver-Policy. Die Erklärung erteilt keine unbegrenzte Erlaubnis.

RESINFO und Report-Channel vergrößern die Verantwortungsfläche

RFC 9606 kann unterstützte EDE-Codes über exterr in RESINFO ankündigen. Das erleichtert Capability Discovery, kann aber bei abweichenden Anycast-Nodes, Versionen oder Konfigurationen ungenau werden. Wie der Client die Angabe nutzt, bleibt lokale Auswahl.

RFC 9567 codiert QTYPE, QNAME und EDE in einer neuen Report-Anfrage, damit Authority-Betreiber Validatorfehler sehen. Das kann Reparaturen beschleunigen, erzeugt aber Kosten, Rekursion und Datenschutzrisiko; Tiefe und Volumen sind zu begrenzen. Der Kanal bietet keine wechselseitige Authentisierung. TCP oder DNS Cookies erhöhen Quellenvertrauen, beweisen aber nicht den Inhalt.

Die Stärke liegt in einer dünnen gemeinsamen Schicht: Option, Register und Grundverarbeitung werden geteilt; Anzeige, Speicherung, Alarm, Bericht und Fallback bleiben lokal. Paket-Canaries und Running Code müssen zeigen, was jede Version und jeder Hop tatsächlich tut.

Quellen