Zusammenfassung

  • RFC 9539 ist ein experimentelles IETF-Profil für die freiwillige, einseitige Nutzung von DoT oder DoQ zwischen rekursiven und autoritativen DNS-Systemen.
  • Es schützt vor allem gegen passive Beobachter. Der Client akzeptiert jedes Zertifikat und wechselt bei Fehlern zu Do53; aktive Herabstufung, MitM und die DNS-Datenauthentizität löst das Profil nicht.
  • Ein belastbarer Nachweis trennt IP-Fähigkeit von Anfragenvertraulichkeit und hält Start, Gewinnerpfad, Zertifikatsurteil, SNI, Timer, Fehlerart, Fallback und Netzpfad fest.

Der Klartext war schneller

Ein Resolver benötigt erstmals eine Antwort von der autoritativen Adresse X. Für dieses Ziel ist kein frischer verschlüsselter Erfolg gespeichert. Um die Namensauflösung nicht vom Experiment abhängig zu machen, sendet der Resolver die Anfrage über Do53 und beginnt nahezu gleichzeitig einen DoT- oder DoQ-Aufbau auf Port 853.

Die Klartextantwort trifft zuerst ein. Sie passt zu einer offenen Anfrage und wird verarbeitet. Wenige Millisekunden später gelingt auch der verschlüsselte Handshake. Der Resolver trägt für die Verbindung aus eigener Quell-IP, Ziel-IP und Transport einen Erfolg ein. Solange die persistence gilt, können weitere Anfragen an X ohne paralleles Do53 laufen.

Damit ist die Fähigkeit des Ziels bewiesen, nicht die Vertraulichkeit der ersten Anfrage. Eine Kennzahl wie „verschlüsselte autoritative Server“ kann steigen, obwohl kalte Anfragen weiterhin offen über das Netz gehen. RFC 9539 erlaubt diese Konkurrenz, damit das Entdecken einer optionalen Fähigkeit die Auflösung nicht unnötig verzögert. Der Betreiber darf das Ergebnis aber nicht als rückwirkenden Schutz ausweisen.

Auch das Zertifikat ändert die Aussage nicht. Der Client muss im einseitigen Profil jedes vorgelegte Zertifikat akzeptieren. Eine fehlgeschlagene Identitätsprüfung darf protokolliert werden, soll jedoch nicht allein zum Klartextwechsel führen. Gegen passive Beobachtung kann der Kanal damit nützlich sein; gegen einen aktiven Angreifer, der sich dazwischenschaltet, bietet er keine verlässliche Abwehr.

Freiwillige Einführung ohne neue Anerkennungsstelle

RFC 9539 erschien im Februar 2024 als Experimental RFC. DoT und DoQ definieren die Transportmechanismen; das Experiment beschreibt ihre Nutzung auf dem rekursiv-autoritativen Abschnitt.

Ein autoritativer Betreiber kann Port 853 aktivieren, ohne auf eine neue globale Kennzeichnung zu warten. Ein rekursiver Betreiber kann Adressen prüfen, die er durch die normale Delegationsauflösung kennt. Es gibt keinen Einschreibedatensatz und keinen Termin, an dem alle Teilnehmer umstellen müssen.

Das entspricht RFC 7435: Wenn Klartext die Ausgangslage ist, kann nicht authentisierte Verschlüsselung die flächige passive Erfassung erschweren. Eine ausdrücklich stärkere Richtlinie hat Vorrang. Heng Lus Modell der Localized Future Decision beschreibt denselben Machtumfang: Die gemeinsame Spezifikation bleibt eng; Betreiber entscheiden lokal, und erst laufende Implementierung macht eine Option tatsächlich wirksam.

Die Option erzeugt keine neue Autorität. Port 853 ändert keine Delegation. Der abgeschlossene Handshake macht den Peer nicht zum bewiesenen Nameserver. Ein aktiver Angreifer kann das verschlüsselte Angebot unterdrücken oder übernehmen. DNSSEC bleibt die getrennte Methode zur Prüfung signierter DNS-Daten.

Zustandswissen ist pfadgebunden

Das Profil empfiehlt Zustandsführung je autoritativer IP. Ein NS-Name kann mehrere Adressen besitzen, eine Adresse einen Load-Balancer oder mehrere Anycast-Standorte vertreten. Wird ein Erfolg auf den ganzen Namen übertragen, kann die nächste Verbindung bei einer noch nicht aktualisierten Instanz landen und einen zusätzlichen Timeout erzeugen.

Auch die Quell-IP des Resolvers zählt. Ein Load-Balancer kann Clients stabil verschiedenen Backends zuweisen; Anycast-Routen können Quellgruppen an andere Standorte führen. Die prüfbare Aussage lautet daher: Diese Quelle erreichte zu diesem Zeitpunkt dieses Ziel mit diesem Transport.

Gespeichert werden initiated, completed, status, last-response, Wiederaufnahmedaten, Session, offene Anfragen und last-activity. Nach Neustart dürfen Socket und Queue nicht als aktiv fortbestehen; jüngste Fähigkeitserfahrung kann erhalten bleiben.

Die empfohlenen Ausgangswerte sind drei Tage success persistence, ein Tag failure damping und vier Sekunden handshake timeout. Sie sind keine universellen Grenzwerte. Sie bestimmen, wie lange ein einzelner Erfolg Klartext unterdrückt und wie lange ein einzelner Fehler einen neuen Verschlüsselungsversuch verhindert. Deshalb müssen sie mit Pfad und Lastprofil dokumentiert werden.

Fehler, sauberes Ende und einzelne Zeitüberschreitung

Scheitert der Handshake oder bricht der verschlüsselte Transport, setzt der Resolver fail, verschiebt anderweitig ungedeckte Anfragen zu Do53 und wartet bis zum Ablauf des damping. Ein sauberer Verbindungsabbau ist anders. Ein autoritativer Server darf alte Sessions schließen, um Speicher und CPU zu schützen; die nächste Anfrage kann dennoch sofort wieder verschlüsselt versuchen.

Ein Query-Timeout ist ebenfalls kein Beweis für den Ausfall der gesamten Session. Andere Anfragen, ein zweiter Transport oder eine andere autoritative Adresse können noch funktionieren. TLS-Alert, stiller Port, Rate Limit, Clean Shutdown und ein korrektes DNS-SERVFAIL brauchen verschiedene Einträge. Ein aktiver Angreifer kann einige Fehlerbilder erzeugen, um Do53 zu erzwingen.

Jeder Fallback hält Ursache, Zeitpunkt, Anfrage, Ersatzweg und nächste Probe fest. Ein bloßes encrypted=false sagt nicht, ob Interoperabilität, Ressourcenpolitik oder Angriff die Entscheidung ausgelöst haben.

Fail closed ist hier nicht vorgesehen, weil das Angebot keine authentisierte Zusage ist. Eine strengere Zukunftsvariante bräuchte ein downgrade-resistentes Signal, Serverauthentisierung und einen klaren Geltungsbereich. Andernfalls könnte eine optionale Verbesserung plötzlich die gesamte Auflösung sperren.

Kanal, Identität und DNS-Daten

Drei Fragen sind unabhängig. Wurden die Bytes dieser Session verschlüsselt? War der Peer der erwartete autoritative Server? Waren die DNS-Daten authentisch? TLS oder QUIC beantworten die erste. RFC 9539 beantwortet die zweite bewusst nicht. DNSSEC kann unter einer gültigen Vertrauenskette die dritte beantworten.

Eine DNSSEC-validierte Klartextantwort besitzt Datenauthentizität ohne Transportvertraulichkeit. Eine DoT-Antwort mit ungeprüftem Zertifikat kann vor einem passiven Beobachter verborgen sein, ohne Peer-Identität zu beweisen. Ohne DNSSEC beweist sie auch nicht die Datenquelle. „Sicheres DNS“ ist daher kein hinreichender Status.

SNI kann bei gemeinsam genutzter IP verraten, welcher NS-Name und damit welche Zonenbeziehung interessiert. Das Profil empfiehlt, SNI wegzulassen; ECH kann die Offenlegung reduzieren. EDNS-Padding aus RFC 7830 und RFC 8467 erschwert Größenanalyse. QNAME-Minimierung reduziert Namensteile pro Hop. Keines dieser Mittel authentisiert den Peer.

Ein Ziel, mehrere Betriebszustände

Verschlüsselte und unverschlüsselte Listener müssen dieselben Zonendaten verwenden. Transportbedingte Größe, EDNS und TC können abweichen; der inhaltliche DNS-Stand darf nicht auseinanderlaufen.

Hinter einem Load-Balancer können aktualisierte und alte Backends dennoch wechseln. Anycast kann dieselbe IP an Standorte mit verschiedenen Rollout-Zuständen führen. RFC 9539 empfiehlt kurze Pool-Rollouts, Client-IP-Affinität oder ein bewusstes Routing nur zu kompatiblen Backends.

Deshalb werden Ergebnisse nach Quellgruppe, Standort und Zeit verglichen. Handshake ohne DNS-Antwort, schwankender Support und unerlaubte Inhaltsabweichung sind eigene Alarme. Eine positive Probe bescheinigt keinen ganzen Anycast-Verbund.

Der Nachweis je Anfrage

Die Zeile enthält Query-ID, QNAME, QTYPE, QCLASS, Zeit, Resolverquelle, autoritatives Ziel, NS-/Zonenkontext und Vantage. Sie listet Transportversuche, Port, ALPN, Start, Abschluss, offene Queues und die verarbeitete Antwort.

Für Verschlüsselung kommen Zertifikatsfingerprint, Zertifikatstyp, Identitätsurteil, SNI/ECH, Session/Resumption, Early Data und Fehlerklasse hinzu. Für Richtlinien gelten persistence, damping und timeout. Die DNS-Antwort wird als Bytes oder Hash mit RCODE, Flags und DNSSEC-Urteil erhalten.

Abschließend wird festgehalten, ob diese Anfrage Do53 nutzte, wann und warum der Fallback geschah, wann ein neuer Versuch zulässig ist und welche Kohorte antwortete. Die Flottenkennzahl zählt tatsächlich geschützte Anfragen, nicht aktivierte Listener.

Quellen