Zusammenfassung

  • DNS Push ersetzt die laufende TTL durch eine sitzungsgebundene Zustellungspflicht. Der Client darf nur dann nicht weiter altern, wenn das passende NAME/TYPE/CLASS-Abonnement angenommen und aktiv ist.
  • Mit dem Ende der Verbindung enden alle Abonnements. TLS resumption baut schneller einen geschützten Kanal auf, bringt aber keinen DSO-Zustand zurück; neue SUBSCRIBE-Antworten und ein neuer Anfangszustand sind erforderlich.
  • Ein belastbarer Aktualitätsnachweis verbindet Discovery, TLS-Identität, DSO-Lebenszyklus, Abonnement, PUSH-Änderungen, Cacheuhr und einen unabhängigen Diensttest.

Die grüne Verbindung ohne laufenden Auftrag

Ein ausdrücklich illustratives Beispiel: Ein Client abonniert ein SRV-RRset und erhält per initialem PUSH ein Ziel mit TTL 120. Zehn Minuten lang bleibt das Abonnement aktiv, deshalb sinkt der gespeicherte Wert nicht. Dann zieht der Betreiber das Ziel zurück; nahezu gleichzeitig trennt ein Middlebox-Fehler die Dauerverbindung.

TLS wird mit einem Ticket rasch wiederaufgenommen. Der Kanal erscheint gesund. Auf der neuen DSO-Sitzung wurde jedoch kein SUBSCRIBE angenommen. Die frühere Pflicht des Servers, eine Entfernung zu liefern, ist beendet. Lässt der Client die Uhr trotzdem stehen, verwandelt er eine zweiminütige Veröffentlichung eigenmächtig in eine unbegrenzte lokale Behauptung.

RFC 8765 trennt diese Zustände. Eine geschlossene TLS-Verbindung beendet DSO. Nach TLS resumption besitzt der Server keinen DNS-Push-Abonnementzustand; der Client muss alle gewünschten Abonnements neu erzeugen. Wiederaufgenommen wird eine kryptografische Beziehung, nicht ein Auftrag zur Änderungszustellung.

Warum der Cache seine Uhr stoppen darf

Normales DNS-Caching lässt die vom Publisher gesetzte TTL sinken. Bei null endet die Frischebehauptung, bis eine neue Abfrage Daten liefert. Für häufig wechselnde RRsets kann kurzes Polling die Erkennungszeit verkürzen, erzeugt aber auch dann Last, wenn sich nichts geändert hat.

DNS Push tauscht diese Last gegen gehaltenen Zustand. Ein SUBSCRIBE bezeichnet genau einen NAME, TYPE und CLASS. Der Server entscheidet für jedes Abonnement. Ist die Antwortmenge bei Annahme nicht leer, folgt unmittelbar ein initialer PUSH; danach überträgt der geordnete TLS/TCP-Stream Ergänzungen und Entfernungen.

Der Client speichert die TTL eines hinzugefügten RR, dekrementiert sie während eines relevanten aktiven Abonnements aber nicht. Die Zone hat die Lebensdauer nicht verlängert. Stattdessen soll jede TTL-Änderung und jedes Verschwinden als Update eintreffen. Frische stützt sich vorübergehend auf eine lebende Lieferpflicht.

UNSUBSCRIBE beendet ein Abonnement, das Ende von DSO alle. Dann beginnt die Alterung mit der gespeicherten TTL erneut; bei null verschwindet der Eintrag. Stoppen und Starten der Uhr müssen daher erstklassige, einer Sitzung zugeordnete Ereignisse sein.

Vier Nachweise statt eines Verbindungsstatus

Üblicherweise versucht der Client zuerst seinen konfigurierten rekursiven Resolver über DNS over TLS auf Port 853. Der Resolver kann ein Upstream-Abonnement halten und Resultate weiterreichen. Andernfalls kann _dns-push-tls._tcp.<zone> einen Dienst anzeigen. Discovery-Antwort, TTL, DNSSEC-Ergebnis, Resolver und Beobachtungspunkt gehören in den Beleg.

Strict Privacy ist vorgeschrieben. Trotzdem heilt TLS keine manipulierte Discovery. Ein falscher SRV-Eintrag kann zu einem korrekt verschlüsselten Kanal mit dem falschen Ziel führen. Zielname, SNI, Zertifikat oder TLSA und tatsächlicher Peer bleiben deshalb getrennt.

Keepalive oder die erste SUBSCRIBE-Operation etabliert DSO. SUBSCRIBE trägt eine von null verschiedene MESSAGE ID und einen einzigen Dreierwert. Erst der Antwort-RCODE entscheidet über das Abonnement. DSO-Unterstützung bedeutet nicht Push-Unterstützung; Push-Unterstützung bedeutet nicht Autorität für den Namen; freie Verbindung bedeutet nicht freie Zustandskapazität.

Diese Trennung schützt lokale Entscheidungen. Der Standard definiert gemeinsame Nachrichten und Fehler. Der Betreiber legt Aufnahmebudget und Retry-Verhalten fest. Der Client soll Abonnements beenden, sobald kein aktueller Bedarf mehr besteht.

PUSH ist kein dauerhafter Änderungszähler

PUSH ist eine unidirektionale Servernachricht mit MESSAGE ID null. TTL von null bis 0x7FFFFFFF fügt ein RR hinzu. 0xFFFFFFFF entfernt ein einzelnes RR; 0xFFFFFFFE beschreibt eine kollektive Entfernung mit leerer RDATA und durch TYPE/CLASS bestimmtem Umfang.

Vor einer Cacheänderung muss der Client ein passendes aktives Abonnement auf derselben Sitzung finden. Ein PUSH, der sich mit UNSUBSCRIBE kreuzt, darf ignoriert werden, wenn die Zuordnung bereits verschwunden ist. Darum ist ein Änderungsdatensatz ohne Sitzungs- und Abonnementkontext unvollständig.

TCP bewahrt Reihenfolge innerhalb einer Verbindung. Es liefert keinen Cursor über einen Verbindungsbruch hinweg. Die null im PUSH-Header ist keine Sequenznummer, und eine Nachricht kann Änderungen mehrerer Abonnements bündeln. Nach der Trennung muss ein neues Abonnement mit neuem Anfangszustand die Sicht rekonstruieren.

Auch eine leere Menge braucht korrekte Semantik. Nur bei nicht leerem Bestand ist ein initialer PUSH vorgeschrieben. Eine erfolgreiche SUBSCRIBE-Antwort ohne folgenden PUSH kann daher „angenommen und leer“ bedeuten. Nachrichtenschweigen allein ist weder Fehler noch Inhaltsbeweis.

Keepalive und RECONFIRM bleiben schmal

Keepalive erhält NAT- und Firewallzustand und zeigt gegenseitige Erreichbarkeit. Ein aktives Abonnement macht eine Sitzung auch ohne Änderungen nicht inaktiv. Daraus folgt weder Vollständigkeit der Updates noch Gesundheit des angekündigten Dienstes.

RECONFIRM kann bei einem Discovery Proxy neue Multicast-DNS-Abfragen auslösen, wenn ein Client veraltete Daten vermutet. Stellt der Proxy das Verschwinden fest, folgen Entfernungen. Bei anderen Serverarten ist die Wirkung undefiniert; NOERROR muss keine Prüfung ausgelöst haben. Das Ergebnis darf nicht als allgemeine Bestätigung dargestellt werden.

Wiederaufnahme ohne Zustandsvererbung

Ein sauberer Recovery-Beleg beginnt mit dem Ende der alten DSO-Sitzung und der Wiederaufnahme der TTL-Alterung. Danach folgen neue TCP/TLS-Verbindung, Kennzeichnung full/resumed, neue DSO-Sitzung, SUBSCRIBE für jedes benötigte RRset, Antwort-RCODE und gegebenenfalls neuer initialer PUSH. Erst dann darf die Uhr wieder stoppen.

SUBSCRIBE ist in TLS early data zulässig. 0-RTT bietet aber keine allgemeine Replay-Eindeutigkeit zwischen Verbindungen und nicht dieselbe forward secrecy. Eine wiederholte Anfrage kann kurzlebigen Doppelzustand erzeugen. Der Versand ist deshalb kein exactly-once-Beleg; maßgeblich bleibt die angenommene Antwort auf der wirklichen Sitzung.

Scheitert Push, ist Polling ein sichtbarer Fallback. RFC 8765 empfiehlt für dasselbe NAME/TYPE/CLASS mindestens das kleinere Intervall aus 900 Sekunden und TTL plus zwei Sekunden und vor jedem Poll einen neuen Push-Versuch. Diese Schonung garantiert keine sofortige Frische und braucht einen eigenen Betriebsstatus.

Eine prüfbare Aussage „aktuell“

Der Nachweis erfasst Discovery-QNAME, Antwort, TTL, DNSSEC und Vantage; TLS-Ziel, SNI, Peer, Zertifikat/TLSA und Handshakeart; DSO-Start/-Ende, Keepalive, inactivity und Retry Delay. Jedes Abonnement erhält MESSAGE ID, NAME, TYPE, CLASS, Request, RCODE und Annahmezeit.

Für PUSH werden Streamreihenfolge, Add/Remove-Art, RR, gespeicherte TTL, passende Subscription und Cacheentscheidung festgehalten. Beim Ende sind UNSUBSCRIBE, close_notify, FIN, Timeout, Reset und fataler Fehler zu unterscheiden. Eine direkte authoritative Abfrage und ein Dienst-Probe schließen die Wirkungskette.

So bleiben die Aussagen klein: geschützter Peer, aktive DSO-Sitzung, angenommenes Abonnement, aktuelles RRset unter Push, beobachtete authoritative Antwort, erreichbarer Dienst. Keine grüne Anzeige darf mehrere davon behaupten, ohne mehrere Belege zu besitzen.

Heng Lus dünne Koordinationsschicht

Minimum Initial Specification umfasst hier OPCODE, TLV, Rollen, Abonnementidentität, Timer, Sicherheit und Ende. Aufnahmebudget, Telemetrie, UI, Fallback und Rollback bleiben lokale Zukunftsentscheidungen. Freiwillige Einführung wird nicht durch RFC oder IANA-Code bewiesen, sondern durch Interoperabilität und beobachtete Zustände.

Running-code primacy verlangt, die ausgeführten Bytes und Folgen zu betrachten. Bleibt eine TTL ohne tragendes Abonnement eingefroren, ist der laufende Code der Beleg für einen Autoritätsfehler. Die Lösung ist keine größere zentrale Vorgabe, sondern eine wieder schmale Zuständigkeit jeder Schicht.

Quellen