Zusammenfassung

  • Revision 01 von dry-run DNSSEC schlägt einen Zwischenzustand vor: Unterstützende Resolver validieren die signierte Zone und melden Fehler, liefern bei einem ungültigen Ergebnis dem gewöhnlichen Client aber die unsichere Antwort, die ohne den Test-DS verfügbar wäre.
  • Der vorgeschlagene NOERROR-Bericht belegt, dass ein Teilnehmer erfolgreich geprüft hat. Er zählt weder stumme Resolver noch deren Clients; zudem sind Berichte nach RFC 9567 cachegedämpft und authentisieren den Absender nicht.
  • Bevor die Parent-Zone den Test-DS durch einen echten DS ersetzt, sollte ein Freigabebeleg Kohorte, Clienttests, Parent-Zustand, Transportgrenzen, Registerstand und verbleibende Ungewissheit binden. Das ist Daniel Kades Empfehlung, keine IETF-Vorgabe.

Die folgenreichste Änderung einer DNSSEC-Einführung liegt außerhalb der signierten Child-Zone. Solange im Parent kein DS veröffentlicht ist, lassen sich Signaturen prüfen, ohne eine öffentliche Vertrauenskette zu schaffen. Nach dem echten DS kann derselbe Fehler bei validierenden Resolvern als SERVFAIL auftreten und über fremde Caches Nutzer erreichen, die der Zonenbetreiber nicht kontrolliert.

Der aktive DNSOP-Arbeitsgruppenentwurf dry-run DNSSEC will zwischen Vorbereitung und Durchsetzung eine beobachtbare Stufe einziehen. Revision 01 erschien am 21. Juni 2026 und nennt Standards Track als Ziel. Sie bleibt ein Internet-Draft, kein RFC, kein genehmigter Standard und kein Nachweis einer produktiven Einführung. Vorgeschlagene EDE- und EDNS-Codes sind noch offen.

Technisch nutzt der Entwurf die Regel aus RFC 6840 für unbekannte DS-Digest-Algorithmen. Ein Validator verwirft einen authentisierten DS, dessen Algorithmus nicht verwendbar ist. Bleibt kein unterstützter Authentisierungspfad, behandelt er das Child als unsigniert. Der Entwurf bildet Testwerte über das höchstwertige Bit und verlangt, dass das gesamte DS-RRset im Parent aus Testtypen besteht. Eine Mischung mit gewöhnlichen DS würde unterstützende Resolver veranlassen, die Testwerte zu ignorieren und den normalen Pfad zu verwenden.

Damit entstehen zwei Populationen. Ein Resolver ohne Implementierung verwirft den unbekannten Digest, löst unsicher auf und sendet keinen Testbericht. Ein unterstützender Resolver erkennt das Signal, validiert die Zone und kann das Ergebnis melden. Bei Erfolg kann er authentische Daten kennzeichnen. Ist das Ergebnis bogus, hält er dem gewöhnlichen Client den üblichen DNSSEC-Fehler vor und liefert stattdessen die unsichere Antwort, die es ohne Test-DS gegeben hätte.

Das ist kein halber DNSSEC-Schutz. Der Entwurf sagt, eine Testdelegation solle noch nicht als DNSSEC-signiert gelten. Der Sicherheitsteil warnt, dass der unsichere Rückfall die Integritätsgarantie abschaltet und gefälschte Antworten wirksam werden können. Der Probelauf kauft Einblick in reale Pfade mit einer Phase ohne Durchsetzung; er darf nicht zum bequemen Dauerzustand werden.

Ein sichtbarer Fehler ist noch kein erzwungener Fehler

Extended DNS Errors aus RFC 8914 klassifizieren den Grund eines Fehlers. RFC 9567 definiert DNS Error Reporting: Der Resolver baut eine Anfrage an die Domain eines vom autoritativen Server angekündigten Monitoring-Agenten. Fehlerhafter QNAME, QTYPE und EDE-Code werden im Berichtsnamen codiert.

Für den Betreiber ist das wertvoller als ein Labortest. Die Beobachtung stammt aus einem tatsächlich eingesetzten Validator samt Cache- und Anfrageverhalten. Ein Bericht belegt eng gefasst, dass ein bestimmter Meldepfad zu einem Zeitpunkt einen bestimmten Fehler sah.

Er belegt keine institutionelle Identität. RFC 9567 authentisiert den Resolver nicht gegenüber dem Agenten. TCP oder DNS Cookies erschweren das Fälschen von Quelladressen, machen aus einer Adresse aber keinen verifizierten Betreiber. UDP-Berichte und scheinbare Quellen können falsch sein. Berichte können außerdem lokale Fehlkonfigurationen wie veraltete Trust Anchors offenlegen; QNAME-Minimierung bleibt deshalb eine Datenschutzmaßnahme.

Auch die Menge ist geformt. Cache-Dämpfung verhindert Wiederholungen, überlange Berichtsnamen werden nicht gesendet, ein unerreichbarer Agent sieht nichts. Das Dashboard enthält also keine rohe Zählung fehlgeschlagener Anfragen, unabhängiger Resolver oder betroffener Menschen.

NOERROR weist Anwesenheit nach, nicht Repräsentativität

Eine leere Fehlerkurve kann eine korrekte Zone bedeuten. Ebenso möglich sind: kein unterstützender Resolver, kein passender Verkehr, bereits gedämpfte Berichte, ein nicht erreichbarer Agent oder fehlende Implementierung.

Revision 01 schlägt deshalb einen NOERROR-Bericht vor. Nach erfolgreicher Testvalidierung kann ein Resolver ein positives Signal am Zonenapex senden; derselbe Cache begrenzt die Häufigkeit. Damit ist wenigstens belegt, dass ein Teilnehmer anwesend war und eine Prüfung bestand.

Der äußere Nenner bleibt unbekannt. Nicht unterstützende Resolver schweigen absichtlich, weil sie das Child als unsigniert behandeln. Unterstützende Resolver ohne Anfrage erscheinen ebenfalls nicht. Ein positives Signal listet weder alle Clients dahinter noch spätere Routen oder Cachezustände auf. Das Verhältnis von NOERROR zu Fehlern beschreibt die beobachtete Kohorte, nicht die Erfolgsquote des Internets.

Der Entwurf verweist auf DMARC-Berichte, den Root Key Trust Anchor Sentinel aus RFC 8509 und Trust-Anchor-Signale aus RFC 8145. Eine kleine, aktuelle und gut platzierte Beobachtergruppe kann erhebliche betriebliche Hinweise liefern. Daraus folgt keine automatische statistische Vertretung aller Resolver.

Wet-Run benennt den Pfad, der Fehler akzeptiert

Der gewöhnliche Client erlebt wegen des Rückfalls keinen DNSSEC-Ausfall. Resolverberichte testen daher nicht, wie eine Anwendung auf die spätere echte Verweigerung reagiert. Die vorgeschlagene Wet-Run-EDNS-Option lässt einen Client den wirklichen Testfehler ausdrücklich anfordern. Ein unterstützender Resolver bewahrt Test- und Normalstatus neben dem gecachten Ergebnis und spiegelt die Option bei der Fehlerantwort. Ein nicht unterstützender Resolver ignoriert sie.

Geprüft wird eine konkrete Kombination aus Anwendung, Netzwerk und Resolver. Nicht teilnehmende Clients sind nicht eingeschlossen. Auch ein NOERROR auf Resolverseite ersetzt diesen End-to-End-Test nicht. Beide unter „bestanden“ zusammenzufassen, würde Pfad und Einwilligung in den Fehler verwischen.

Negative Antworten brauchen eine weitere Kontrolle. RFC 8198 erlaubt einem Validator, Antworten aus gecachten NSEC- oder NSEC3-Beweisen zu synthetisieren. Das kann einen defekten negativen Beweis beim autoritativen Server verbergen. Der Entwurf verlangt, die Synthese vorübergehend auszusetzen, ausdrücklich nachzufragen, Ergebnisse zu vergleichen und eine Abweichung mit einem vorgeschlagenen EDE zu melden.

Der Parent hält den Freigabeschalter

Die Signatur des Child installiert den Modus nicht allein. Der Parent muss den besonderen DS annehmen und veröffentlichen. Nimmt seine Schnittstelle DS entgegen, liefert das Child den Testwert. Erzeugt sie DS aus DNSKEY, braucht sie eine Modusangabe oder Logik für ein begleitendes CDS. CDNSKEY allein trägt die vorgeschlagene Unterscheidung nicht; der Entwurf rät zu CDS und CDNSKEY.

Die Freigabe ist erneut eine Parent-Aktion: Das vollständige Test-DS-Set wird durch das echte Set ersetzt. Antrag, Annahme, beobachtete Veröffentlichung und Ablauf alter Cachezustände sind getrennte Tatsachen. Ein einzelner Status „umgestellt“ reicht als Nachweis nicht.

Mit dem Austausch ändert sich die Wirkung. Im Probelauf erzeugt bogus Telemetrie und eine unsichere Antwort für den normalen Client. Unter einem echten, unterstützten DS kann derselbe Zustand die Auflösung stoppen. Ein Dashboard-Schwellenwert ist daher keine bloße Monitorpräferenz, sondern Teil der Ermächtigung, fremde Resolver die Signaturen des Child durchsetzen zu lassen.

Der vorgeschlagene Bereich ist noch nicht zugeteilt

Revision 01 will über das höchstwertige Bit die Werte 128–255 als Dry-run DNSSEC durch IANA kennzeichnen. Das aktuelle Register enthält diese Zuteilung nicht. Mit Stand 13. Januar 2026 sind 128–252 als Reserved, 253–254 als Private Use und 255 als Unassigned geführt; Referenz ist RFC 9904.

Wenn die Spezifikation voranschreitet, muss dieser Unterschied ausdrücklich aufgelöst werden. Der Registerstand belegt keine Ablehnung durch IANA: Eine im Internet-Draft verlangte IANA-Aktion wird erst nach dem vorgesehenen Verfahren zur Zuteilung. Bis dahin darf ein Experiment den ganzen Block nicht als öffentlich vergeben darstellen.

RFC 9904 trennt außerdem Empfehlungen für Nutzung und Implementierung. Softwarefähigkeit und Betriebseinsatz sind verschiedene Fakten. Ebenso sind Unterstützung des Probelaufs, Beobachtung dieser Zone und Abdeckung wichtiger Clientpfade getrennt zu belegen.

Ein überprüfbarer Freigabebeleg

Der Beleg beginnt mit präzisen Artefakten: Fingerabdruck der signierten Zone, DNSKEY-Set, vorgesehener Test-DS, Antrag beim Parent, Annahme und beobachtete Veröffentlichung. Beobachtungsfenster, autoritative Messpunkte und Cachehorizonte werden getrennt festgehalten.

Dann beschreibt er die Kohorte, ohne einen Zensus vorzutäuschen. Welche Resolver waren unabhängig unterscheidbar? Welche Meldungen hatten nur eine durch TCP oder Cookie gestützte Quelladresse? Wie viele NOERROR- und Fehlersignale blieben nach Dämpfung, welche Namen, Typen und Codes betrafen sie, und wie wurde jede Korrektur geschlossen? Aggregation kann Privatsphäre schützen, ohne die Beweisstruktur zu löschen.

Clienttests erhalten einen eigenen Abschnitt: Wet-Run nach Netzwerk, Resolver und Anwendungsklasse; normaler Rückfall; positive und negative Antworten; ausdrückliche NSEC/NSEC3-Anfragen; Cachegrenzen; unerreichbare Populationen. Der aktuelle IANA-Registerstand wird beigefügt, experimentelle Codes werden als nicht zugeteilt gekennzeichnet.

Schließlich nennt der Beleg die Person oder Rolle, die den echten DS autorisieren darf, ihre akzeptierten Mindestnachweise und Restunsicherheiten sowie den Rollback-Verantwortlichen. Einreichung, Annahme, beobachtete Veröffentlichung und Nachkontrolle behalten getrennte Zeitstempel.

Der Beleg kann nicht jeden Resolver zertifizieren. Er verhindert, dass eine ausgewählte Stichprobe im Entscheidungsprotokoll unbemerkt „das Internet“ heißt. Begrenzte Evidenz kann Handeln tragen, wenn die Verantwortlichen ihre Grenze sehen und akzeptieren.

Quellen

  1. dry-run DNSSEC — Revision 01
  2. Datatracker-Eintrag zu dry-run DNSSEC
  3. Dokumenthistorie
  4. Aktive DNSOP-Dokumente
  5. DNSOP-Charta
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — DNSSEC Implementation Notes
  9. RFC 8198 — aggressive Nutzung validierter Caches
  10. RFC 8509 — Root Key Trust Anchor Sentinel
  11. RFC 8145 — Signalisierung bekannter Trust Anchors
  12. RFC 9904 — Aktualisierung kryptografischer Empfehlungen
  13. IANA-Register der DS-Digest-Algorithmen