Zusammenfassung

  • RFC 8490 trennt einen verbundenen DNS-Transport von einer eingerichteten DSO-Sitzung. Erst ein erfolgreicher Austausch schafft dauerhaften Zustand.
  • Eine primäre TLV, Nachrichtenkennungen, zwei Timer und Retry Delay machen Beginn, Pflege und Ende des Zustands zurechenbar.
  • Keepalive belegt Erreichbarkeit, nicht den fortbestehenden Zweck oder die Berechtigung einer gespeicherten Operation.

Der Socket hat kein eigenes Mandat

Klassisches DNS verbindet Frage und Antwort. TCP kann mehrere Vorgänge auf derselben Verbindung tragen, erteilt aber allein keine Erlaubnis für Abonnements, spätere Mitteilungen oder Zustand nach der Antwort. Transportkontinuität ist keine Anwendungsbefugnis.

RFC 8490 erschien im März 2019 und wurde von Ray Bellis, Stuart Cheshire, John Dickinson, Sara Dickinson, Ted Lemon und Tom Pusateri verfasst. Er definiert DNS Stateful Operations, DSO, als OPCODE 6 und aktualisiert RFC 1035 und 7766. Entscheidend ist ein benannter Zustand, dessen Existenz und Regeln beide Endpunkte kennen.

Zunächst besteht nur eine Verbindung. Abgesehen von eng begrenzten Early-Data-Fällen entsteht die DSO-Sitzung erst nach einer erfolgreichen Anfrage und der Antwort mit passender Kennung. Schweigt ein alter Server, darf der Client keine Zustimmung unterstellen. Nach der Frist muss er abbrechen und aus bekanntem Zustand neu beginnen.

Eine Hauptoperation je Nachricht

DSO nutzt den DNS-Header, trägt Operationen aber in Type-Length-Value-Strukturen. Jede Nachricht hat genau eine Primary TLV. Sie bestimmt, ob eine Anfrage mit nicht null gesetzter MESSAGE ID beantwortet werden muss oder eine einseitige Nachricht mit ID null unbeantwortet bleibt.

Anfragen dürfen gepipelined werden und Antworten in anderer Reihenfolge eintreffen; ausgeführt wird dennoch nach Empfangsreihenfolge. Eine unbekannte Primary TLV erhält DSOTYPENI, eine unbekannte zusätzliche TLV wird ignoriert. Erweiterung verlangt somit nicht, unverstandene Bedeutung als akzeptiert auszugeben.

Zwei Uhren für dieselbe Stille

Eine ruhige Verbindung kann verlassen sein oder ein gültiges Abonnement halten. Deshalb trennt RFC 8490 Inactivity Timeout und Keepalive Interval.

Der erste Timer betrifft sinnvolle Arbeit. Eine lang laufende Operation bleibt bis zur Kündigung aktiv, selbst ohne Verkehr. Der zweite prüft Erreichbarkeit und kann NAT- und Firewall-Zustand erhalten. Ein Keepalive ist ein Puls des Pfades, keine Verlängerung des Anwendungszwecks.

Wer beides vermischt, zerstört ruhige Abonnements oder macht veralteten Zustand unsterblich. Neben den Timern muss die offene Operation sichtbar sein, die den Ressourcenverbrauch rechtfertigt.

Beenden ohne Wiederverbindungssturm

Retry Delay erlaubt dem Server, die Sitzung zu schließen und eine Wartezeit vor dem Wiederverbinden zu nennen. Gründe unterscheiden normalen Neustart, schweren Formatfehler, Ressourcenmangel und Neukonfiguration. Ein geordneter Ausstieg muss so nicht zur Lastspitze werden.

Die Codes bleiben begrenzte Belege. SERVFAIL offenbart nicht die interne Ursache einer Überlastung; REFUSED beweist weder Fehlverhalten noch dauerhaften Entzug. DSO benötigt zuverlässigen, geordneten Transport: DNS über TCP oder TLS. UDP hat keine passenden Sitzungseigenschaften, HTTPS eine eigene Sitzungsverwaltung.

RFC 8765 nutzt DSO für DNS Push Notifications. Der Nutzen liegt damit nicht bloß in der langen Verbindung, sondern im gemeinsam nutzbaren Lebenszyklus. Das IANA-Register belegt Codezuweisungen, nicht Verbreitung oder Betriebsqualität.

Der Beitrag von Ray Bellis zeigt sich in der Trennung von Aufbau, Stille, Erreichbarkeit, Überlastung, Ende und Wiederholung. Dauerhaftigkeit kann genutzt werden, ohne unsichtbare Befugnis zu werden.

Quellen