Zusammenfassung

  • Klassische RCODEs teilen ein interoperables Ergebnis mit, nicht dessen ganze Ursache. RFC 8914 legte in EDNS-Option 15 einen registrierten INFO-CODE und optionalen, für Menschen bestimmten EXTRA-TEXT ab.
  • EDE kann SERVFAIL, NXDOMAIN, REFUSED und sogar NOERROR begleiten; mehrere Optionen dürfen nebeneinander stehen. Die Anwendung muss weiterhin dem RCODE folgen und darf Diagnose nicht zur zweiten Steuergrammatik machen.
  • Auch Erklärungen brauchen Herkunft: Forwarder können sie unterdrücken oder neu bilden, Größenlimits entfernen sie zuerst, Freitext kann interne Politik verraten, und ungeschützte EDE lässt sich fälschen.

Für den Bereitschaftsdienst sehen beide Fehler zunächst gleich aus. Im Erreichbarkeitsfall kann ein anderer Pfad neue Evidenz liefern. Im DNSSEC-Fall kann ein nicht validierender Resolver zwar eine Adresse zurückgeben, widerlegt damit aber den Fehler nicht. Er hat lediglich die Beweisanforderung aufgegeben.

Das historische Ziel war deshalb kein umfangreicherer Grundstatus. DNS brauchte einen Begleitkanal, dessen Genauigkeit die Reparatur verbessert, ohne die Autorität des Ergebnisses zu übernehmen.

Der RCODE war Ergebnis, nicht Ursachenbericht

RFC 1035 definierte wenige breite Antworten: Erfolg, Formatfehler, Serverversagen, nicht vorhandener Name, nicht unterstützte Operation und Ablehnung. Diese Stabilität erlaubt gemeinsame Verarbeitung ohne Wissen über interne Resolverarchitektur.

SERVFAIL trennt jedoch weder startenden Server von unerreichbarer Autorität noch Validierungsfehler von gecachtem Fehler. REFUSED sagt nicht, ob Autorität fehlt, der Client unzulässig ist oder eine Filterregel greift.

Jede interne Ursache in einen neuen RCODE zu heben, hätte Ergebnis und Diagnose vermischt. Die Basis musste klein bleiben; der Kontext durfte wachsen.

EDNS stellte einen untergeordneten Platz bereit

RFC 6891 führte das OPT-Pseudo-RR und den EDNS-Optionsraum ein. OPT steht in der Nachricht, nicht als gewöhnliche Zonenaussage. Zusatzbedingungen können daher reisen, ohne Datenbesitz vorzutäuschen.

RFC 8914 wies Extended DNS Error 2020 die Option 15 zu. Ihr Inhalt beginnt mit einem 16-Bit-INFO-CODE; danach kann UTF-8-EXTRA-TEXT folgen.

Der Code verweist auf das IANA-Register. Der Text richtet sich an Menschen und ist keine automatisch auswertbare Syntax. Er darf leer sein, braucht keinen Nullabschluss und erhält seine Grenze aus der Optionslänge.

Mit OPT in der Anfrage kann EDE jede Antwort begleiten. Mehrere EDE sind zulässig; Empfänger müssen sie akzeptieren, aber nicht auf alle reagieren. Ihre bloße Anwesenheit ändert keine RCODE-Regel.

So bleibt SERVFAIL mit DNSSEC Bogus ein Fehlschlag. NOERROR mit Stale Answer liefert Daten, verschweigt aber deren Alter nicht. Diagnose lenkt die Untersuchung, nicht die Protokollentscheidung.

Bogus war kein Beweis für einen Angreifer

RFC 4035 nennt ein RRset Bogus, wenn eine Vertrauenskette erwartet wird, sich wegen ungültiger Signaturen oder fehlender erwarteter Daten aber nicht herstellen lässt. Ursache können Angriff, Fehlkonfiguration oder Beschädigung sein.

Indeterminate bedeutet, dass die nötigen DNSSEC-Daten fehlen, um überhaupt zu entscheiden, ob eine Signatur erwartet werden muss. Gescheiterter erwarteter Beweis und unbestimmbare Beweispflicht sind verschiedene Zustände.

RFC 8914 unterscheidet beide und zusätzlich nicht unterstützte DNSKEY-Algorithmen, unbekannte DS-Digests, abgelaufene oder noch nicht gültige Signaturen, fehlende DNSKEY-, RRSIG- oder NSEC-Daten und ein fehlendes Zone-Key-Bit.

Diese Genauigkeit weist keinen Schuldigen zu. Kindzone, Elternzone, Registrar, Uhr, Software und Pfad können beteiligt sein. Der Code dokumentiert die Sicht des Resolvers; institutionelle Verantwortung verlangt weitere Evidenz.

Eine erfolgreiche Antwort durfte ihr Alter nennen

Kann ein Resolver abgelaufene Cachedaten nicht aktualisieren, darf er unter Grenzen Kontinuität vor Ausfall wählen. RFC 8767 beschreibt diese stale-Nutzung. EDE 3 markiert eine alte positive Antwort, EDE 19 ein altes NXDOMAIN.

NOERROR und Stale Answer widersprechen sich nicht. Der RCODE klassifiziert die Lieferung, EDE ihre zeitliche Herkunft. Weitergabe macht die Daten weder frisch noch beweist sie eine neue Bestätigung durch die Autorität.

Forged Answer bezeichnet eine politisch veränderte, dennoch gelieferte Antwort. Verhindert Politik die Antwort, unterscheiden Blocked, Censored und Filtered interne Betreiberregel, äußere Vorgabe und vom Client gewünschte Filterung. Prohibited kann eine Ablehnung gegenüber einem unberechtigten Client erläutern.

Diese Begriffe zeigen behauptete Kontrollflächen, authentisieren aber weder Rechtsgrund noch Listenqualität noch Zustimmung.

Ein gecachter Fehler war keine neue Beobachtung

Vollständige Auflösung bei jeder Anfrage kann einen Ausfall verstärken. RFC 9520 präzisiert die begrenzte Speicherung von Auflösungsfehlern.

EDE 13, Cached Error, kennzeichnet einen SERVFAIL aus diesem lokalen Zustand. Er wird dadurch nicht zu autoritativen Zonendaten und beweist nicht, dass die ursprüngliche Ursache noch besteht.

Ohne Herkunft wirken tausend Cachetreffer wie tausend unabhängige Versuche. Neue Evidenz verlangt Ablauf, einen anderen kontrollierten Resolver oder einen direkten Test der Autoritätsstrecke.

Der Forwarder konnte zum scheinbaren Sprecher werden

Ein Stub spricht oft mit einem lokalen Resolver, der an weitere Dienste weiterleitet. Die EDE am Rand kann also von einem anderen System stammen als der sichtbare Absender.

RFC 8914 erlaubt, empfangene EDE zu unterdrücken, weiterzugeben oder neu zu erzeugen. Wird ein Upstream-Befund weitergereicht, sollte dessen Quelle im EXTRA-TEXT stehen, weil der Client sonst den unmittelbaren Resolver für den Urheber hält.

Mehrere Optionen können Upstream-Validierungsfehler, lokalen Fehlercache und Ausgangspolitik getrennt bewahren. Nummern ohne Sprecher bilden aber keine Verantwortlichkeitskette. Freitext kann Herkunft nennen, bleibt jedoch menschlich und standardmäßig unauthentisiert.

Bei Platzmangel verschwand Kontext zuerst

Langer Text kann die angekündigte UDP-Größe überschreiten. RFC 8914 empfiehlt dann, EDE vor anderen Antwortdaten zu entfernen und bei Entfernung das Truncation-Bit zu setzen.

Die Priorität ordnet den Vertrag: Diagnose ist nützlich, Antwort und Beweis sind wichtiger. Fehlende EDE beweist keine fehlende Diagnose. Größe, Forwarding-Politik oder fehlende Unterstützung können sie beseitigen.

Telemetry muss Erzeugung, Empfang, Umschreibung, Unterdrückung und Trunkierung auseinanderhalten. Ausführlichkeit kann sonst genau den Hinweis verdrängen, den sie verbessern sollte.

Präziser Text blieb unbewiesen

„Signatur abgelaufen“ klingt belastbarer als ein allgemeiner Fehler. Spezifität ist trotzdem keine kryptografische Authentisierung.

RFC 8914 behandelt EDE ohne authentisierte DNS-Transaktion oder sicheren Transport als unauthentisiert. Wer EDE einschleusen kann, kann womöglich auch RCODE oder Adressdaten ändern. Diagnose darf die DNS-Verarbeitung deshalb nicht beeinflussen.

Freitext kann außerdem Konten, interne Upstreams, Blocklisten oder Richtlinien offenlegen. Gute Erklärung nennt nur so viel, wie für nächsten Test und zuständige Stelle nötig ist.

Das IANA-Register der DNS-Parameter führt Option 15 und spätere INFO-CODEs. Es belegt koordinierte Zuweisung, nicht Einsatz, korrekte Emission, treue Weitergabe, Schutz oder Benutzeranzeige.

EDE gab DNS mehr Sprache, aber nicht zwei Wahrheiten. Der RCODE behielt Verarbeitungsautorität. EDE trug Ursachenhinweise. Gerade diese Unterordnung machte bessere Reparatur möglich, ohne eine scheinbare Verfügbarkeit über Integrität zu stellen.