7. Basis-TLVs für DNS Stateful Operations (Base TLVs for DNS Stateful Operations)

Dieser Abschnitt beschreibt die drei Basis-TLVs für DNS Stateful Operations: Keepalive, Retry Delay und Encryption Padding.

7.1. Keepalive TLV

Der Keepalive TLV (DSO-TYPE=1) erfüllt zwei Funktionen. Primär legt er die Werte für die Session Timeouts fest. Nebenbei setzt er auch den Keepalive-Timer für die DSO-Sitzung zurück, was bedeutet, dass er als eine Art "No-Op"-Nachricht zum Zweck der Aufrechterhaltung einer Sitzung verwendet werden kann. Der Client fordert die gewünschten Session Timeout-Werte an und der Server bestätigt mit den Antwortwerten, die er den Client verwenden lassen möchte.

DSO-Nachrichten mit dem Keepalive TLV als Primary TLV können in Early Data erscheinen.

Die DSO-DATA für den Keepalive TLV lautet wie folgt:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 INACTIVITY TIMEOUT (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 KEEPALIVE INTERVAL (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• INACTIVITY TIMEOUT: Der Inaktivitäts-Timeout für die aktuelle DSO-Sitzung, angegeben als 32-Bit-Ganzzahl ohne Vorzeichen, in Netzwerk-Byte-Reihenfolge (Big Endian) in Einheiten von Millisekunden. Dies ist der Timeout, bei dem der Client beginnen MUSS, eine inaktive DSO-Sitzung zu schließen. Der Inaktivitäts-Timeout kann ein beliebiger vom Server gewählter Wert sein. Wenn der Client eine inaktive DSO-Sitzung nicht mit Anstand schließt, wird der Server nach fünf Sekunden oder dem Doppelten dieses Intervalls, je nachdem welcher Wert größer ist, die Verbindung zwangsweise abbrechen.

• KEEPALIVE INTERVAL: Das Keepalive-Intervall für die aktuelle DSO-Sitzung, angegeben als 32-Bit-Ganzzahl ohne Vorzeichen, in Netzwerk-Byte-Reihenfolge (Big Endian) in Einheiten von Millisekunden. Dies ist das Intervall, in dem ein Client DSO-Keepalive-Traffic generieren MUSS, um den Verbindungsstatus aufrechtzuerhalten. Das Keepalive-Intervall DARF NICHT weniger als zehn Sekunden betragen. Wenn der Client den vorgeschriebenen DSO-Keepalive-Traffic nicht generiert, wird der Server nach dem Doppelten dieses Intervalls die Verbindung zwangsweise abbrechen. Da das minimal zulässige Keepalive-Intervall zehn Sekunden beträgt, ist die Mindestzeit, zu der ein Server einen Client für das Versäumnis, den vorgeschriebenen DSO-Keepalive-Traffic zu generieren, zwangsweise trennt, zwanzig Sekunden.

Die Übertragung oder der Empfang von DSO-Keepalive-Nachrichten (d.h. Nachrichten, bei denen der Keepalive TLV der erste TLV ist) setzt nur den Keepalive-Timer zurück, nicht den Inaktivitäts-Timer. Der Grund dafür ist, dass periodische DSO-Keepalive-Nachrichten ausschließlich zum Zweck gesendet werden, eine DSO-Sitzung am Leben zu erhalten, wenn diese DSO-Sitzung aktuelle oder kürzliche Nicht-Wartungsaktivität aufweist, die es rechtfertigt, diese DSO-Sitzung am Leben zu erhalten. Das Senden von DSO-Keepalive-Traffic selbst wird nicht als Client-Aktivität betrachtet; es wird als Wartungsaktivität betrachtet, die im Dienst anderer Client-Aktivitäten durchgeführt wird. Wenn DSO-Keepalive-Traffic selbst den Inaktivitäts-Timer zurücksetzen würde, würde dies einen zirkulären Livelock erzeugen, bei dem Keepalive-Traffic unbegrenzt gesendet würde, um eine DSO-Sitzung am Leben zu erhalten. In diesem Szenario wäre die einzige Aktivität auf dieser DSO-Sitzung der Keepalive-Traffic, der die DSO-Sitzung am Leben hält, damit weiterer Keepalive-Traffic gesendet werden kann. Damit eine DSO-Sitzung als aktiv betrachtet wird, muss sie mehr als nur Keepalive-Traffic transportieren. Aus diesem Grund setzt das bloße Senden oder Empfangen einer DSO-Keepalive-Nachricht den Inaktivitäts-Timer nicht zurück.

Wenn von einem Client gesendet, MUSS die DSO-Keepalive-Anfrage-Nachricht als DSO-Anfrage-Nachricht mit einer Nicht-Null-MESSAGE ID gesendet werden. Wenn ein Server eine DSO-Keepalive-Nachricht mit einer Null-MESSAGE ID empfängt, ist dies ein fataler Fehler und der Server MUSS die Verbindung sofort zwangsweise abbrechen. Die DSO-Keepalive-Anfrage-Nachricht setzt den Keepalive-Timer einer DSO-Sitzung zurück und kommuniziert gleichzeitig dem Server die gewünschten Session Timeout-Werte des Clients. In einer Server-Antwort auf eine vom Client initiierte DSO-Keepalive-Anfrage-Nachricht enthalten die Session Timeouts die vom Server ab diesem Zeitpunkt in der DSO-Sitzung gewählten Werte, die der Client respektieren MUSS. Dies ist dem DHCP-Protokoll nachempfunden, bei dem der Client eine bestimmte Lease-Lifetime mit DHCP-Option 51 [RFC2132] anfordert, der Server jedoch die ultimative Autorität für die Entscheidung ist, welche Lease-Lifetime tatsächlich gewährt wird.

Wenn ein Client seine zweite und nachfolgende DSO-Keepalive-Anfrage-Nachrichten an den Server sendet, SOLLTE der Client jedes Mal weiterhin seine bevorzugten Werte anfordern. Dies ermöglicht Flexibilität, sodass, wenn sich die Bedingungen während der Lebensdauer einer DSO-Sitzung ändern, der Server seine Antworten anpassen kann, um die Bedürfnisse des Clients besser zu erfüllen.

Sobald eine DSO-Sitzung in Gang ist (Abschnitt 5.1), KANN eine DSO-Keepalive-Nachricht von einem Server initiiert werden. Wenn von einem Server gesendet, MUSS die DSO-Keepalive-Nachricht als unidirektionale DSO-Nachricht mit der MESSAGE ID auf Null gesetzt gesendet werden. Der Client DARF KEINE Antwort auf eine vom Server initiierte DSO-Keepalive-Nachricht generieren. Wenn ein Client eine DSO-Keepalive-Anfrage-Nachricht mit einer Nicht-Null-MESSAGE ID empfängt, ist dies ein fataler Fehler und der Client MUSS die Verbindung sofort zwangsweise abbrechen. Die unidirektionale DSO-Keepalive-Nachricht vom Server setzt den Keepalive-Timer einer DSO-Sitzung zurück und informiert gleichzeitig unilateral den Client über die neuen Session Timeout-Werte, die ab diesem Zeitpunkt in dieser DSO-Sitzung zu verwenden sind. Keine Client-DSO-Antwort auf diese einseitige Erklärung ist erforderlich oder erlaubt.

In DSO-Keepalive-Antwort-Nachrichten MUSS genau eine Instanz des Keepalive TLV vorhanden sein und wird nur als Response Primary TLV gesendet, das als Antwort auf eine DSO-Keepalive-Anfrage-Nachricht vom Client gesendet wird. Ein Keepalive TLV DARF NICHT anderen Antworten als Response Additional TLV hinzugefügt werden. Wenn der Server die Session Timeout-Werte eines Clients anders als als Antwort auf eine DSO-Keepalive-Anfrage-Nachricht vom Client aktualisieren möchte, tut er dies, indem er eine eigene unidirektionale DSO-Keepalive-Nachricht sendet, wie oben beschrieben.

Es ist nicht erforderlich, dass der Keepalive TLV in jeder DSO-Sitzung verwendet wird. Während viele DSO-Operationen in Verbindung mit einem langlebigen Sitzungsstatus verwendet werden, erfordern nicht alle DSO-Operationen einen langlebigen Sitzungsstatus, und in einigen Fällen kann der Standard-15-Sekunden-Wert sowohl für den Inaktivitäts-Timeout als auch für das Keepalive-Intervall vollkommen angemessen sein. Beachten Sie jedoch, dass für Clients, die nur die in diesem Dokument definierten DSO-TYPEs implementieren, eine DSO-Keepalive-Anfrage-Nachricht die einzige Möglichkeit für einen Client ist, eine DSO-Sitzung zu initiieren.

7.1.1. Client-Behandlung empfangener Session Timeout-Werte

Wenn ein Client eine Antwort auf seine vom Client initiierte DSO-Keepalive-Anfrage-Nachricht empfängt oder eine vom Server initiierte unidirektionale DSO-Keepalive-Nachricht empfängt, hat der Client dann vom Server vorgeschriebene Session Timeout-Werte erhalten. Die beiden im Keepalive TLV vom Server enthaltenen Timeout-Werte können jeweils höher, niedriger oder gleich den jeweiligen Session Timeout-Werten sein, die der Client zuvor für diese DSO-Sitzung hatte.

Im Fall des Keepalive-Timers ist die Behandlung des empfangenen Werts unkompliziert. Der Akt des Empfangens der Nachricht, die den DSO-Keepalive TLV enthält, setzt selbst den Keepalive-Timer zurück und aktualisiert das Keepalive-Intervall für die DSO-Sitzung. Das neue Keepalive-Intervall gibt die maximale Zeit an, die verstreichen darf, bevor eine weitere Nachricht auf dieser DSO-Sitzung gesendet oder empfangen werden muss, wenn die DSO-Sitzung am Leben bleiben soll.

Im Fall des Inaktivitäts-Timeouts ist die Behandlung des empfangenen Werts etwas subtiler, obwohl die Bedeutung des Inaktivitäts-Timeouts wie spezifiziert bleibt; er gibt immer noch die maximal zulässige Zeit ohne nützliche Aktivität auf einer DSO-Sitzung an. Der Akt des Empfangens der Nachricht, die den Keepalive TLV enthält, setzt selbst den Inaktivitäts-Timer nicht zurück. Die seit der letzten nützlichen Aktivität auf dieser DSO-Sitzung verstrichene Zeit wird durch den Austausch von DSO-Keepalive-Nachrichten nicht beeinflusst. Der neue Inaktivitäts-Timeout-Wert im Keepalive TLV in der empfangenen Nachricht aktualisiert jedoch den Timeout, der dem laufenden Inaktivitäts-Timer zugeordnet ist; dies wird die neue maximal zulässige Zeit ohne Aktivität auf einer DSO-Sitzung.

• Wenn der aktuelle Inaktivitäts-Timer-Wert kleiner als der neue Inaktivitäts-Timeout ist, kann die DSO-Sitzung vorerst geöffnet bleiben. Wenn der Inaktivitäts-Timer-Wert den neuen Inaktivitäts-Timeout erreicht, MUSS der Client dann beginnen, die DSO-Sitzung wie oben beschrieben zu schließen.

• Wenn der aktuelle Inaktivitäts-Timer-Wert gleich dem neuen Inaktivitäts-Timeout ist, dann war diese DSO-Sitzung genau so lange inaktiv, wie der Server es zulassen wird, und nun MUSS der Client sofort beginnen, diese DSO-Sitzung zu schließen.

• Wenn der aktuelle Inaktivitäts-Timer-Wert bereits größer als der neue Inaktivitäts-Timeout ist, dann war diese DSO-Sitzung bereits länger inaktiv, als der Server erlaubt, und der Client MUSS sofort beginnen, diese DSO-Sitzung zu schließen.

• Wenn der aktuelle Inaktivitäts-Timer-Wert bereits mehr als das Doppelte des neuen Inaktivitäts-Timeouts beträgt, wird der Client sofort als säumig betrachtet (diese DSO-Sitzung ist sofort berechtigt, vom Server zwangsweise beendet zu werden) und der Client MUSS sofort beginnen, diese DSO-Sitzung zu schließen. Wenn ein Server den Inaktivitäts-Timeout jedoch abrupt auf diese Weise reduziert, SOLLTE der Server dem Client, um dem Client Zeit zu geben, die Verbindung mit Anstand zu schließen, bevor der Server auf ein zwangsweises Abbrechen zurückgreift, eine zusätzliche Gnadenfrist von entweder fünf Sekunden oder einem Viertel des neuen Inaktivitäts-Timeouts geben, je nachdem welcher Wert größer ist.

7.1.2. Beziehung zur edns-tcp-keepalive EDNS(0) Option

Der Inaktivitäts-Timeout-Wert im Keepalive TLV (DSO-TYPE=1) hat ähnliche Absicht wie die edns-tcp-keepalive EDNS(0) Option [RFC7828]. Ein Client/Server-Paar, das DSO unterstützt, DARF die edns-tcp-keepalive EDNS(0) Option in keiner Nachricht verwenden, nachdem eine DSO-Sitzung etabliert wurde. Ein Client, der eine DSO-Nachricht gesendet hat, um eine Sitzung zu etablieren, DARF ab diesem Zeitpunkt keine edns-tcp-keepalive EDNS(0) Option senden. Sobald eine DSO-Sitzung etabliert wurde, ist dies ein fataler Fehler, wenn entweder Client oder Server eine DNS-Nachricht über die DSO-Sitzung empfängt, die eine edns-tcp-keepalive EDNS(0) Option enthält, und der Empfänger der edns-tcp-keepalive EDNS(0) Option MUSS die Verbindung sofort zwangsweise abbrechen.

7.2. Retry Delay TLV

Der Retry Delay TLV (DSO-TYPE=2) kann als Primary TLV (unidirektional) in einer Server-zu-Client-Nachricht oder als Response Additional TLV in beide Richtungen verwendet werden. DSO-Nachrichten mit einem Relay Delay TLV als ihrem Primary TLV sind in Early Data nicht erlaubt.

Die DSO-DATA für den Retry Delay TLV lautet wie folgt:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     RETRY DELAY (32 bits)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• RETRY DELAY: Ein Zeitwert, angegeben als 32-Bit-Ganzzahl ohne Vorzeichen in Netzwerk-Byte-Reihenfolge (Big Endian), in Einheiten von Millisekunden, innerhalb dessen der Initiator diese Operation oder die Verbindung zu diesem Server NICHT erneut versuchen DARF. Empfehlungen für den RETRY DELAY-Wert werden in Abschnitt 6.6.1 gegeben.

7.2.1. Retry Delay TLV als Primary TLV verwendet

Wenn als Primary TLV in einer unidirektionalen DSO-Nachricht verwendet, wird der Retry Delay TLV vom Server zum Client gesendet. Er wird von einem Server verwendet, um einen Client anzuweisen, die DSO-Sitzung und die zugrunde liegende Verbindung zu schließen und sich für das angegebene Zeitintervall nicht erneut zu verbinden.

In diesem Fall gilt er für die DSO-Sitzung als Ganzes, und der Client MUSS beginnen, die DSO-Sitzung wie in Abschnitt 6.6.1 beschrieben zu schließen. Der RCODE im Nachrichten-Header SOLLTE den Hauptgrund für die Beendigung angeben:

• NOERROR zeigt ein routinemäßiges Herunterfahren oder einen Neustart an.

• FORMERR zeigt an, dass eine Client-DSO-Anfrage so schlecht fehlgeformt war, dass die Sitzung nicht fortgesetzt werden kann.

• SERVFAIL zeigt an, dass der Server aufgrund von Ressourcenerschöpfung überlastet ist und Last abwerfen muss.

• REFUSED zeigt an, dass der Server neu konfiguriert wurde und zu diesem Zeitpunkt nun nicht in der Lage ist, eine oder mehrere der langlebigen Client-Operationen durchzuführen, die zuvor auf dieser DSO-Sitzung durchgeführt wurden.

• NOTAUTH zeigt an, dass der Server neu konfiguriert wurde und zu diesem Zeitpunkt nun nicht in der Lage ist, eine oder mehrere der langlebigen Client-Operationen durchzuführen, die zuvor auf dieser DSO-Sitzung durchgeführt wurden, weil er keine Autorität über die betreffenden Namen hat (zum Beispiel könnte ein DNS-Push-Notification-Server so neu konfiguriert werden, dass er keine DNS-Push-Notification-Anfragen mehr für einen oder mehrere der derzeit abonnierten Namen akzeptiert).

Dieses Dokument spezifiziert nur diese RCODE-Werte für die DSO-Retry Delay-Nachricht. Server, die DSO-Retry Delay-Nachrichten senden, SOLLTEN einen dieser Werte verwenden. Zukünftige Umstände können jedoch Situationen schaffen, in denen andere RCODE-Werte in DSO-Retry Delay-Nachrichten angemessen sind, sodass Clients darauf vorbereitet sein MÜSSEN, DSO-Retry Delay-Nachrichten mit jedem RCODE-Wert zu akzeptieren.

In einigen Fällen kann es, wenn ein Server eine unidirektionale DSO-Retry Delay-Nachricht an einen Client sendet, mehr als einen Grund geben, warum der Server die Sitzung beenden möchte. Möglicherweise könnte die Konfiguration so geändert worden sein, dass einige langlebige Client-Operationen aufgrund von Richtlinien (REFUSED) nicht mehr fortgesetzt werden können, und andere langlebige Client-Operationen können nicht mehr durchgeführt werden, weil der Server nicht mehr autoritativ für diese Namen ist (NOTAUTH). In solchen Fällen KANN der Server einen der anwendbaren RCODE-Werte verwenden oder RCODE=NOERROR (routinemäßiges Herunterfahren oder Neustart).

Beachten Sie, dass die Auswahl des RCODE-Werts in einer DSO-Retry Delay-Nachricht nicht kritisch ist, da der RCODE-Wert im Allgemeinen nur für Informationszwecke wie das Schreiben in eine Protokolldatei zur zukünftigen menschlichen Analyse bezüglich der Art der Trennung verwendet wird. Im Allgemeinen ändern Clients ihr Verhalten nicht abhängig vom RCODE-Wert. Das RETRY DELAY in der Nachricht teilt dem Client mit, wie lange er warten sollte, bevor er versucht, eine neue Verbindung zu dieser Dienst-Instanz herzustellen.

Für Clients, die ihr Verhalten in irgendeiner Weise abhängig vom RCODE-Wert ändern, sollten sie unbekannte RCODE-Werte genauso behandeln wie RCODE=NOERROR (routinemäßiges Herunterfahren oder Neustart).

Eine DSO-Retry Delay-Nachricht (DSO-Nachricht, bei der der Primary TLV Retry Delay ist) vom Server zum Client ist eine unidirektionale DSO-Nachricht; die MESSAGE ID MUSS in der ausgehenden Nachricht auf Null gesetzt werden und der Client DARF KEINE Antwort senden.

Ein Client DARF KEINE DSO-Retry Delay-Nachricht an einen Server senden. Wenn ein Server eine DSO-Nachricht empfängt, bei der der Primary TLV der Retry Delay TLV ist, ist dies ein fataler Fehler und der Server MUSS die Verbindung sofort zwangsweise abbrechen.

7.2.2. Retry Delay TLV als Response Additional TLV verwendet

Im Fall einer DSO-Anfrage-Nachricht, die zu einem RCODE-Wert ungleich Null führt, KANN der Responder einen Retry Delay TLV an die Antwort anhängen, der das Zeitintervall angibt, während dessen der Initiator diese Operation NICHT erneut versuchen SOLLTE.

Das angegebene Zeitintervall, während dessen der Initiator nicht erneut versuchen SOLLTE, gilt nur für die fehlgeschlagene Operation, nicht für die DSO-Sitzung als Ganzes.

Entweder ein Client oder ein Server, je nachdem wer in der Rolle des Responders für eine bestimmte DSO-Anfrage-Nachricht handelt, KANN einen Retry Delay TLV an eine Fehlerantwort anhängen, die er sendet.

7.3. Encryption Padding TLV

Der Encryption Padding TLV (DSO-TYPE=3) kann nur als Additional oder Response Additional TLV verwendet werden. Er ist nur anwendbar, wenn die DSO-Transportschicht Verschlüsselung wie TLS verwendet.

Die DSO-DATA für den Padding TLV ist optional und ist ein Feld variabler Länge, das nicht spezifizierte Werte enthält. Eine DSO-LENGTH von 0 stellt im Wesentlichen 4 Bytes Padding (die Mindestmenge) bereit.

                                             1   1   1   1   1   1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                                                               |
   /              PADDING -- VARIABLE NUMBER OF BYTES              /
   /                                                               /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Wie für die EDNS(0) Padding Option [RFC7830] spezifiziert, SOLLTEN die PADDING-Bytes auf 0x00 gesetzt werden. Andere Werte KÖNNEN verwendet werden, zum Beispiel in Fällen, in denen Bedenken bestehen, dass die gepolsterte Nachricht vor der Verschlüsselung einer Kompression unterzogen werden könnte. PADDING-Bytes jeglichen Werts MÜSSEN in empfangenen Nachrichten akzeptiert werden.

Der Encryption Padding TLV kann entweder in einer DSO-Anfrage-Nachricht, Antwort oder beiden enthalten sein. Wie für die EDNS(0) Padding Option [RFC7830] spezifiziert, wenn eine DSO-Anfrage-Nachricht mit einem Encryption Padding TLV empfangen wird, MUSS die DSO-Antwort auch einen Encryption Padding TLV enthalten.

Die Länge des Paddings ist in diesem Dokument absichtlich nicht spezifiziert und ist eine Funktion aktueller Best Practices in Bezug auf den Typ und die Länge der Daten in den vorhergehenden TLVs [RFC8467].