Zusammenfassung

  • RFC 9567 erlaubt einer autoritativen Antwort, ungefragt einen Agent-Domainnamen in der EDNS-Option Report-Channel anzukündigen. Ein unterstützender validierender Resolver übersetzt seine Extended-DNS-Error-Beobachtung danach in eine eigene TXT-Anfrage; die ursprüngliche Antwort wird weder berichtigt noch ersetzt.
  • Zwischen berichtendem Resolver und Monitoring-Agent besteht keine Ende-zu-Ende-Authentisierung. TCP oder DNS Cookies stärken die Aussage über die Quelladresse, nicht über die Diagnose; Cache, Namensgrenze und betriebliche Prüfung bestimmen weiterhin, was ankommt und was handlungsfähig ist.

Eine RRSIG-Signatur läuft auf einer autoritativen Kopie der Zone ab. Der Server beantwortet weiterhin Fragen, und seine Erfolgszähler können unauffällig bleiben. Erst der validierende Resolver verwirft das RRset. Die Partei mit der besten Fehlerbeobachtung ist nicht die Partei mit dem Recht, die Zone zu ändern.

RFC 9567 baut für diese Trennung einen kleinen Rückkanal. Die autoritative Antwort kann EDNS-Option 18, Report-Channel, mit einem vollständig qualifizierten Agent-Domainnamen tragen. Die Option ist unaufgefordert: In der Frage war sie nicht nötig, und in Fragen darf sie nie erscheinen. Der Server bestimmt ein Ziel, nicht die Meldepflicht.

Unterstützt und aktiviert der Resolver die Funktion und ordnet den Fehler einem Extended DNS Error zu, erzeugt er eine neue DNS-Frage. EDE 7 für eine fehlgeschlagene A-Abfrage von broken.test kann als _er.1.broken.test.7._er.a01.agent-domain.example erscheinen. Gefragt wird nach TXT, doch Name, Typ und Diagnose stehen schon im QNAME.

Der Bericht ergänzt nicht rückwärts die fehlerhafte Antwort und ändert deren RCODE nicht. Er ist eine gewöhnliche Auflösung unter einer anderen Autorität. RFC 9567 gibt dem TXT-RDATA keine festgelegte Bedeutung. Eine positive Antwort beendet die Anfrage und liefert einen TTL, mit dem der Resolver Wiederholungen dämpft.

Eine angekündigte Adresse ist kein Diagnosemonopol

Der Betreiber der ursprünglichen Autorität wählt die Agent-Domain. Der Resolver validiert, wählt den EDE-Code und wendet seine Meldepolitik an. Der Agent empfängt, bewertet Herkunft und bündelt. Der Zoneninhaber genehmigt eine Reparatur. Ein gemeinsames Drahtformat überträgt keine dieser Befugnisse an den nächsten Akteur.

Das IANA-Register der DNS-Parameter belegt Code 18 und den TXT-Namen _er. Die Registrierung schafft eindeutige Syntax, nicht Implementierung, Aktivierung, Zustellung oder Wahrheit.

Auch EDE ist begrenzte Evidenz. RFC 8914 lässt die RCODE-Verarbeitung unverändert. RFC 9567 bestimmt weder universell, was ein Fehler ist, noch welche Codes jeder Resolver unterstützen muss. Beim Agenten kommt die Behauptung eines bestimmten Verarbeitungswegs an: Dieser Resolver hat diesem Namen und Typ diesen Code zugeordnet.

Die DNSSEC-Validierung macht eine abgelaufene Signatur oder einen DS/DNSKEY-Bruch häufig unabhängig reproduzierbar. Eine veraltete lokale Vertrauensanker-Konfiguration kann aber denselben Alarm auslösen. Der Agent muss deshalb aus einer sauberen Sicht validieren, bevor er die Zone als Ursache behandelt.

Der Vorfall passt in einen QNAME — oder wird verworfen

Der Berichtsname enthält _er, den dezimalen QTYPE, die Labels des fehlgeschlagenen Namens, den dezimalen EDE-Code, ein zweites _er und die Agent-Domain. DNS-Klasse und gewöhnlicher RCODE fehlen. Die erste Marke zeigt, dass der vollständige Bericht und nicht ein durch QNAME-Minimierung sichtbares Präfix angekommen ist; die zweite trennt Vorfall und Ziel.

Überschreitet der zusammengesetzte Name 255 Oktette, darf er nicht gesendet werden. Der Resolver muss außerdem Aufwand oder Tiefe begrenzen, weil die Auflösung der Agent-Domain selbst scheitern und einen weiteren Bericht erzeugen könnte. Ein fehlender Bericht ist sicherer als rekursive Telemetrie.

Die Agent-Domain darf nicht unterhalb der gemeldeten Domain liegen. Sonst beschädigt derselbe Fehler den Rückweg. Ein kurzer Agentenname lässt mehr Platz für lange ursprüngliche Namen. Namensarchitektur ist hier Ausfallschutz.

Erreichbarkeit beweist keine Ursache

RFC 9567 authentisiert den Resolver nicht gegenüber dem Agenten. UDP-Quellen lassen sich fälschen, und eine erreichbare Quelle kann sich irren. Resolver sollten DNS Cookies, DNS über TCP oder einen anderen verbindungsorientierten Transport verwenden. Erhält der Agent UDP ohne Cookie, sollte er TC setzen und eine TCP-Wiederholung erzwingen.

Diese Kontrollen erhöhen die Gewissheit, dass jemand an der Quelladresse antworten kann. Sie bestätigen weder Organisation noch Vertrauensanker noch Diagnose. Eine bekannte Resolver-Adresse kann höher priorisiert werden, erhält aber kein Recht zur Produktionsänderung.

Automatisierung braucht daher Stufen. UDP ohne Cookie eröffnet eine Beobachtung. Cookie oder TCP erhöhen die Herkunftsstufe. Mehrere unabhängige Quellen und eine saubere Reproduktion eröffnen einen Vorfall. Die Zonenänderung bleibt an Eigentümer, Freigabe und Rückrollmöglichkeit gebunden.

Cache dämpft Last und verwischt Häufigkeit

Der Agent sollte positiv mit TXT antworten. Der TTL verhindert, dass derselbe Resolver denselben Bericht bei jeder Nutzerfrage erneut sendet. Diese Dämpfung macht das Verfahren leichtgewichtig, verbietet aber die Gleichsetzung von Berichten mit Nutzern oder Fehlerereignissen.

NXDOMAIN kann breiter unterdrücken. RFC 8020 lässt Nichtexistenz auf darunterliegende Namen wirken, und RFC 2308 speichert sie. Eine falsche negative Antwort kann viele Berichtsformen blockieren. Der Agent darf für überwachte Namen daher kein NXDOMAIN liefern; ein positives Wildcard-RR ist eine mögliche Lösung.

Ist die Agentenzone signiert, erlaubt RFC 8198 die lokale Synthese negativer Antworten aus validiertem NSEC oder NSEC3. Spätere Berichte erreichen den Agenten nicht. RFC 9567 nennt eine unsignierte Agent-Domain als Möglichkeit, diese besondere Last zu vermeiden, verlangt aber weiterhin normale Validierung: Eine tatsächlich signierte Opferdomain darf nicht per Annahme herabgestuft werden.

Schweigen hat deshalb mehrere Ursachen. Reparatur, laufender TTL, negative Synthese, Ausfall des Agenten, deaktivierte Unterstützung oder Missbrauchsfilter sehen von außen gleich aus. Erholung ist erst belegt, wenn eine unabhängige Validierung wieder erfolgreich ist.

Der Rückkanal kann gegen Dritte gelenkt werden

Der QNAME offenbart dem Agenten fehlgeschlagenen Namen, Typ und EDE-Code. Er kann auch einen lokalen Fehler wie einen alten Vertrauensanker verraten. Minimierung senkt die Offenlegung gegenüber Zwischenautoritäten, nicht gegenüber dem Ziel.

Ein Angreifer kann absichtlich eine kaputte Zone veröffentlichen und die Domain eines Opfers als Agenten nennen. Offene Resolver und verteilte Messsysteme senden dann Zusatzverkehr an dieses Ziel. Eine Flut erfundener Berichte kann reale Störungen verdecken. Ratenbegrenzung, Herkunftsstufen, Prüfung der Beziehung zwischen Zone und Agent sowie externe Validierung sind deshalb Teil des Betriebs.

Auch TXT-Inhalt ist kein Vertrauenseingang. Weil der RFC keine Semantik vorgibt, kann der Agent einen festen Wert senden und nur die definierten QNAME-Labels auswerten. Beliebiger geloggter Text muss als feindlich gelten. Der Bericht liegt in der Frage, nicht in einer entfernten Anweisung.

Heng Lus Trennung von laufendem Code, minimaler Spezifikation und lokaler Entscheidung sowie Realitätsebenen passt genau. Der Standard definiert Grammatik und Ziel. Die Autorität kündigt an. Der Resolver beobachtet. Das Netz liefert. Der Agent gewichtet. Der Betreiber repariert. Ob Nutzer danach validieren können, ist eine weitere Tatsache.

Eine belastbare Prüfung bewahrt Originalantwort, DNSSEC-Zustand, angekündigte Domain, konstruierten Berichtsnamen, Verwerfungsgrund, Transport, Cookie, Agentenantwort, TTL, unabhängige Reproduktion, Änderung und spätere Validierung getrennt auf. Die neue Frage ist wertvoll, weil sie nicht vorgibt, das letzte Urteil zu sein.