5. Protokolldetails (Protocol Details)
Der Gesamtablauf der DNS Stateful Operations durchläuft eine Reihe von Phasen:
Verbindungsaufbau (Connection Establishment): Ein Client baut eine Verbindung zu einem Server auf (Abschnitt 4.2).
Verbunden aber Sitzungslos (Connected but Sessionless): Eine Verbindung besteht, aber eine DSO-Sitzung wurde nicht hergestellt. DNS-Nachrichten können vom Client zum Server gesendet werden, und DNS-Antworten können vom Server zum Client gesendet werden. In diesem Zustand kann ein Client, der DSO verwenden möchte, versuchen, eine DSO-Sitzung zu etablieren (Abschnitt 5.1). Die Standard-DNS-over-TCP-Inaktivitäts-Timeout-Behandlung ist aktiv [RFC7766] (siehe Abschnitt 7.1.2 dieses Dokuments).
DSO-Sitzungsetablierung in Bearbeitung (DSO Session Establishment in Progress): Ein Client hat innerhalb der letzten 30 Sekunden eine DSO-Anfrage gesendet, aber noch keine DSO-Antwort für diese Anfrage erhalten. In dieser Phase darf der Client weitere DSO-Anfragen und weitere DNS-Anfragen senden, DARF aber KEINE unidirektionalen DSO-Nachrichten senden (Abschnitt 5.1).
DSO-Sitzungsetablierung Timeout: Ein Client hat eine DSO-Anfrage gesendet und nach 30 Sekunden immer noch keine DSO-Antwort für diese Anfrage erhalten. Dies bedeutet, dass sich der Server nun in einem unbestimmten Zustand befindet. Der Client bricht die Verbindung zwangsweise ab. Der Client DARF erneut verbinden, ohne DSO zu verwenden, falls angemessen.
DSO-Sitzungsetablierung Fehlgeschlagen (DSO Session Establishment Failed): Ein Client hat eine DSO-Anfrage gesendet und eine entsprechende DSO-Antwort mit einem RCODE ungleich Null erhalten. Dies bedeutet, dass der Versuch, die DSO-Sitzung zu etablieren, nicht erfolgreich war. An diesem Punkt ist es dem Client erlaubt, ohne DSO-Sitzung (Verbunden aber Sitzungslos) weiterzuarbeiten, sendet aber keine weiteren DSO-Nachrichten (Abschnitt 5.1).
DSO-Sitzung Etabliert (DSO Session Established): Ein Client hat eine DSO-Anfrage gesendet und eine entsprechende DSO-Antwort mit RCODE gesetzt auf NOERROR (0) erhalten. Eine DSO-Sitzung wurde nun erfolgreich etabliert. Sowohl Client als auch Server können DSO-Nachrichten und DNS-Nachrichten senden; beide können Antworten auf empfangene Nachrichten senden (Abschnitt 5.2). Der Inaktivitäts-Timer (Abschnitt 6.4) ist aktiv; der Keepalive-Timer (Abschnitt 6.5) ist aktiv. Die Standard-DNS-over-TCP-Inaktivitäts-Timeout-Behandlung ist nicht mehr wirksam [RFC7766] (siehe Abschnitt 7.1.2 dieses Dokuments).
Server-Herunterfahren (Server Shutdown): Der Server hat beschlossen, die Sitzung ordnungsgemäß zu beenden und hat dem Client eine Retry Delay-Nachricht gesendet (Abschnitt 6.6.1). Es können noch unverarbeitete Nachrichten vom Client vorhanden sein; der Server wird diese ignorieren. Der Server wird keine weiteren Nachrichten an den Client senden (Abschnitt 6.6.1.1).
Client-Herunterfahren (Client Shutdown): Der Client hat beschlossen, die Verbindung zu trennen, entweder weil er keinen Dienst mehr benötigt, die Verbindung inaktiv ist (Abschnitt 6.4.1) oder weil der Server ihm eine Retry Delay-Nachricht gesendet hat (Abschnitt 6.6.1). Der Client schließt die Verbindung ordnungsgemäß (Abschnitt 5.3).
Erneut Verbinden (Reconnect): Der Client hat die Verbindung aufgrund eines Server-Herunterfahrens getrennt. Der Client wartet entweder bis die vom Server angegebene Retry Delay abgelaufen ist (Abschnitt 6.6.3) oder verbindet sich mit einer anderen Server-Instanz. Wenn der Client keinen Dienst mehr benötigt, verbindet er sich nicht erneut.
Zwangsabbruch (Forcibly Abort): Der Client oder Server hat einen Protokollfehler erkannt, und weitere Kommunikation hätte undefiniertes Verhalten zur Folge. Der Client oder Server bricht die Verbindung zwangsweise ab (Abschnitt 5.3).
Abbruch-Neuverbindung-Wartezeit (Abort Reconnect Wait): Der Client hat die Verbindung zwangsweise abgebrochen, benötigt aber noch Dienst. Oder der Server hat die Verbindung zwangsweise abgebrochen, aber der Client benötigt noch Dienst. Der Client verbindet sich entweder mit einer anderen Dienst-Instanz (Abschnitt 9.1) oder wartet, um sich erneut zu verbinden (Abschnitt 6.6.3.1).
5.1. DSO-Sitzungsetablierung (DSO Session Establishment)
Damit eine Sitzung zwischen einem Client und einem Server etabliert werden kann, muss der Client zunächst eine Verbindung zum Server über einen anwendbaren Transport herstellen (siehe Abschnitt 4.2).
In einigen Umgebungen kann durch externe Mittel im Voraus bekannt sein, dass sowohl Client als auch Server DSO unterstützen, und in diesen Fällen kann entweder Client oder Server DSO-Nachrichten jederzeit initiieren. In diesem Fall wird die Sitzung etabliert, sobald die Verbindung hergestellt ist; dies wird als implizite DSO-Sitzungsetablierung bezeichnet.
In der Regel wird ein Server jedoch nicht im Voraus wissen, ob ein Client DSO unterstützt. Daher DARF ein Server im Allgemeinen, sofern nicht durch andere Mittel im Voraus bekannt ist, dass ein Client DSO unterstützt, KEINE DSO-Anfrage-Nachrichten oder unidirektionalen DSO-Nachrichten initiieren, bis eine DSO-Sitzung durch mindestens einen erfolgreichen vom Client initiierten DSO-Anfrage/Antwort-Austausch gegenseitig etabliert wurde, wie unten beschrieben. Dies wird als explizite DSO-Sitzungsetablierung bezeichnet.
Bis eine DSO-Sitzung implizit oder explizit etabliert wurde, DARF ein Client KEINE unidirektionalen DSO-Nachrichten initiieren.
Eine DSO-Sitzung wird über eine Verbindung etabliert, indem der Client eine DSO-Anfrage-Nachricht sendet, wie z.B. eine DSO-Keepalive-Anfrage-Nachricht (Abschnitt 7.1), und eine Antwort mit einer passenden MESSAGE ID und RCODE gesetzt auf NOERROR (0) erhält, was anzeigt, dass die DSO-Anfrage erfolgreich war.
Einige DSO-Nachrichten sind als Early Data erlaubt (Abschnitt 11.1). Andere nicht. Unidirektionale Nachrichten sind niemals als Early Data erlaubt, es sei denn, es existiert eine implizite DSO-Sitzung.
Wenn ein Server eine DSO-Nachricht in Early Data erhält, deren Primary TLV nicht in Early Data erscheinen darf, MUSS der Server die Verbindung zwangsweise abbrechen. Wenn ein Client eine DSO-Nachricht in Early Data erhält und keine implizite DSO-Sitzung besteht, MUSS der Client die Verbindung zwangsweise abbrechen. Dies kann nur bei TLS-Verbindungen durchgesetzt werden; daher MÜSSEN Server TCP Fast Open (TFO) NICHT aktivieren, wenn sie auf eine Verbindung warten, die kein TLS erfordert.
5.1.1. DSO-Sitzungsetablierung Fehlschlag
Wenn der Antwort-RCODE auf NOTIMP (4) oder in der Praxis auf einen anderen Wert als NOERROR (0) oder DSOTYPENI (unten definiert) gesetzt ist, MUSS der Client annehmen, dass der Server DSO überhaupt nicht implementiert. In diesem Fall ist es dem Client erlaubt, weiterhin DNS-Nachrichten über diese Verbindung zu senden, DARF aber KEINE weiteren DSO-Nachrichten über diese Verbindung ausgeben.
Wenn der RCODE in der Antwort auf DSOTYPENI ("DSO-TYPE Not Implemented"; RCODE 11) gesetzt ist, zeigt dies an, dass der Server DSO unterstützt, aber den DSO-TYPE des Primary TLV in dieser DSO-Anfrage-Nachricht nicht implementiert. Ein Server, der DSO implementiert, DARF DSOTYPENI NICHT für eine DSO-Keepalive-Anfrage-Nachricht zurückgeben, da der Keepalive-TLV zwingend zu implementieren ist. Wenn ein Client jedoch in Zukunft versucht, eine DSO-Sitzung mit einer antwortpflichtigen DSO-Anfrage-Nachricht unter Verwendung eines neu definierten DSO-TYPE zu etablieren, den der Server nicht versteht, würde dies zu einer DSOTYPENI-Antwort führen. Wenn der Server DSOTYPENI zurückgibt, wird eine DSO-Sitzung nicht als etabliert betrachtet. Der Client darf jedoch weiterhin DNS-Nachrichten über die Verbindung senden, einschließlich anderer DSO-Nachrichten wie DSO-Keepalive, was zu einer erfolgreichen NOERROR-Antwort führen kann, wodurch eine DSO-Sitzung etabliert wird.
Wenn eine DSO-Nachricht von einem bestehenden DNS-Server empfangen wird, der den DSO-OPCODE nicht erkennt, bestehen zwei andere mögliche Ergebnisse: Der Server sendet möglicherweise keine Antwort auf die DSO-Nachricht, oder der Server trennt möglicherweise die Verbindung.
Wenn der Server keine Antwort auf die DSO-Nachricht sendet, SOLLTE der Client 30 Sekunden warten, danach wird angenommen, dass der Server DSO nicht unterstützt. Wenn der Server nicht innerhalb von 30 Sekunden antwortet, kann angenommen werden, dass er nicht antworten wird; dies lässt ihn in einem nicht spezifizierten Zustand: Es gibt keine Spezifikation, die erfordert, dass eine Antwort auf eine unbekannte Nachricht gesendet wird, aber es gibt auch keine Spezifikation, die besagt, in welchem Zustand sich der Server befindet, wenn keine Antwort gesendet wird. Daher MUSS der Client die Verbindung zum Server zwangsweise abbrechen. Der Client DARF erneut verbinden, aber kein DSO verwenden, falls angemessen (Abschnitt 6.6.3.1). Durch Trennen und erneutes Verbinden stellt der Client sicher, dass sich der Server in einem bekannten Zustand befindet, bevor weitere Anfragen gesendet werden.
Wenn der Server die Verbindung trennt, SOLLTE der Client diese Dienst-Instanz als DSO nicht unterstützend markieren und für einen bestimmten Zeitraum (mindestens eine Stunde) nach dem fehlgeschlagenen Versuch keine DSO-Verbindung versuchen. Der Client DARF erneut verbinden, aber kein DSO verwenden, falls angemessen (Abschnitt 6.6.3.2).
5.1.2. DSO-Sitzungsetablierung Erfolg
Wenn der Server eine DSO-Anfrage-Nachricht von einem Client empfängt und eine erfolgreiche NOERROR-Antwort auf diese Anfrage sendet, betrachtet der Server die DSO-Sitzung als etabliert.
Wenn der Client die NOERROR-Antwort des Servers auf seine DSO-Anfrage-Nachricht erhält, betrachtet der Client die DSO-Sitzung als etabliert.
Sobald eine DSO-Sitzung etabliert wurde, kann jede Seite jederzeit unilateral geeignete DSO-Nachrichten senden, und daher kann entweder Client oder Server der Initiator einer Nachricht sein.
5.2. Operationen nach DSO-Sitzungsetablierung (Operations after DSO Session Establishment)
Sobald eine DSO-Sitzung etabliert wurde, sollten sich Clients und Server wie in dieser Spezifikation in Bezug auf Inaktivitäts-Timeouts und Sitzungsbeendigung beschrieben verhalten, nicht wie zuvor in der früheren Spezifikation für DNS-over-TCP vorgeschrieben [RFC7766].
Da ein Server, der DNS Stateful Operations unterstützt, einen RCODE von "NOERROR" zurückgeben MUSS, wenn er eine Keepalive-TLV-DSO-Anfrage-Nachricht erhält, ist der Keepalive-TLV ein idealer Kandidat für die Verwendung beim Etablieren einer DSO-Sitzung. Jede andere Option, die nur erfolgreich sein kann, wenn sie an einen Server der gewünschten Art gesendet wird, ist ebenfalls ein guter Kandidat für die Verwendung beim Etablieren einer DSO-Sitzung. Für Clients, die nur die in dieser Basisspezifikation definierten DSO-TYPEs implementieren, ist das Senden eines Keepalive-TLV die einzige verfügbare DSO-Anfrage-Nachricht, um eine DSO-Sitzung zu initiieren. Selbst für Clients, die andere zukünftige DSO-TYPEs implementieren, KÖNNEN sie aus Gründen der Einfachheit wählen, immer eine anfängliche DSO-Keepalive-Anfrage-Nachricht als ihre Art zu senden, eine DSO-Sitzung zu initiieren. Eine zukünftige Definition eines neuen antwortpflichtigen DSO-TYPE gibt Implementierern die Option, diesen neuen DSO-TYPE zu verwenden, wenn sie möchten, ändert jedoch nicht die Tatsache, dass das Senden eines Keepalive-TLV eine gültige Art bleibt, eine DSO-Sitzung zu initiieren.
5.3. DSO-Sitzungsbeendigung (DSO Session Termination)
Eine DSO-Sitzung wird beendet, wenn die zugrunde liegende Verbindung geschlossen wird. DSO-Sitzungen werden "ordnungsgemäß geschlossen", wenn der Server eine DSO-Sitzung schließt, weil er überlastet ist, der Client die DSO-Sitzung schließt, weil er fertig ist, oder der Client die DSO-Sitzung schließt, weil sie inaktiv ist. DSO-Sitzungen werden "zwangsweise abgebrochen", wenn entweder Client oder Server die Verbindung aufgrund eines Protokollfehlers schließen.
-
Wo diese Spezifikation "ordnungsgemäß schließen" sagt, bedeutet dies das Senden eines TLS close_notify (falls TLS verwendet wird), gefolgt von einem TCP FIN, oder das Äquivalent für andere Protokolle. Wo diese Spezifikation erfordert, dass eine Verbindung ordnungsgemäß geschlossen wird, wird die Anforderung, diesen ordnungsgemäßen Abschluss zu initiieren, dem Client auferlegt, um die Last des TCP-TIME-WAIT-Zustands auf den Client statt auf den Server zu legen.
-
Wo diese Spezifikation "zwangsweise abbrechen" sagt, bedeutet dies das Senden eines TCP RST oder das Äquivalent für andere Protokolle. In der BSD Sockets API wird dies erreicht, indem die SO_LINGER-Option auf Null gesetzt wird, bevor der Socket geschlossen wird.
5.3.1. Behandlung von Protokollfehlern (Handling Protocol Errors)
In der Protokollimplementierung gibt es im Allgemeinen zwei Arten von Fehlern, mit denen Softwareentwickler umgehen müssen. Die erste sind Situationen, die aufgrund von Faktoren in der Umgebung entstehen, wie z.B. vorübergehender Konnektivitätsverlust. Obwohl unerwünscht, weisen diese Situationen nicht auf einen Fehler in der Software hin und sind Situationen, von denen sich die Software im Allgemeinen erholen können sollte.
Die zweite sind Situationen, die niemals auftreten sollten, wenn mit einer konformen DSO-Implementierung kommuniziert wird. Wenn sie auftreten, weisen sie auf einen schwerwiegenden Fehler in der Protokollimplementierung hin, über das hinaus, was vernünftigerweise von Software erwartet werden kann, sich zu erholen. Dieses Dokument beschreibt diese letztere Form der Fehlerbedingung als "fatalen Fehler" und spezifiziert, dass eine Implementierung, die auf eine fatale Fehlerbedingung trifft, "die Verbindung sofort zwangsweise abbrechen MUSS".
5.4. Nachrichtenformat (Message Format)
Eine DSO-Nachricht beginnt mit dem standardmäßigen zwölf Byte langen DNS-Nachrichten-Header [RFC1035], wobei das OPCODE-Feld auf den DSO-OPCODE (6) gesetzt ist. Im Gegensatz zu Standard-DNS-Nachrichten sind jedoch die Question-Section, Answer-Section, Authority-Records-Section und Additional-Records-Section nicht vorhanden. Die entsprechenden Count-Felder (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) MÜSSEN bei der Übertragung auf Null gesetzt werden.
Wenn eine DSO-Nachricht empfangen wird, bei der eines der Count-Felder nicht Null ist, MUSS ein FORMERR zurückgegeben werden.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MESSAGE ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR | OPCODE (6) | Z | RCODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| QDCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ANCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| NSCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ARCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO Data /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
5.4.1. DNS-Header-Felder in DSO-Nachrichten (DNS Header Fields in DSO Messages)
In einer unidirektionalen DSO-Nachricht MUSS das MESSAGE ID-Feld auf Null gesetzt werden. In einer DSO-Anfrage-Nachricht MUSS das MESSAGE ID-Feld auf einen eindeutigen Nicht-Null-Wert gesetzt werden, den der Initiator derzeit für keine andere aktive Operation auf dieser Verbindung verwendet. Für die hiesigen Zwecke ist eine MESSAGE ID in dieser DSO-Sitzung in Verwendung, wenn der Initiator sie in einer DSO-Anfrage-Nachricht verwendet hat, für die er noch auf eine Antwort wartet, oder wenn der Client sie verwendet hat, um eine langlebige Operation einzurichten, die noch nicht abgebrochen wurde. Zum Beispiel könnte eine langlebige Operation ein Push-Notification-Abonnement [Push] oder ein Discovery-Relay-Interface-Abonnement [Relay] sein.
Ob eine Nachricht eine DSO-Anfrage-Nachricht oder eine unidirektionale DSO-Nachricht ist, wird nur durch die Spezifikation für den Primary TLV bestimmt. Eine Bestätigung kann nicht angefordert werden, indem eine Nicht-Null-MESSAGE ID in einer Nachricht eingefügt wird, die gemäß ihrem Primary TLV als unidirektional erforderlich ist. Ebenso kann eine Bestätigung nicht verhindert werden, indem eine MESSAGE ID von Null in einer Nachricht gesendet wird, die gemäß ihrem Primary TLV als DSO-Anfrage-Nachricht erforderlich ist. Ein Responder, der eine solche fehlerhafte Nachricht empfängt, MUSS sie als fatalen Fehler behandeln und die Verbindung sofort zwangsweise abbrechen.
In einer DSO-Anfrage-Nachricht oder unidirektionalen DSO-Nachricht MUSS das DNS Header Query/Response (QR)-Bit Null sein (QR=0). Wenn das QR-Bit nicht Null ist, ist die Nachricht keine DSO-Anfrage- oder unidirektionale DSO-Nachricht.
In einer DSO-Antwort-Nachricht MUSS das DNS Header QR-Bit Eins sein (QR=1). Wenn das QR-Bit nicht Eins ist, ist die Nachricht keine DSO-Antwort-Nachricht.
In einer DSO-Antwort-Nachricht (QR=1) DARF das MESSAGE ID-Feld NICHT Null sein und MUSS eine Kopie des Wertes des (Nicht-Null) MESSAGE ID-Felds in der DSO-Anfrage-Nachricht enthalten, auf die geantwortet wird. Wenn eine DSO-Antwort-Nachricht (QR=1) empfangen wird, bei der die MESSAGE ID Null ist, ist dies ein fataler Fehler und der Empfänger MUSS die Verbindung sofort zwangsweise abbrechen.
Das DNS Header OPCODE-Feld enthält den DSO-OPCODE-Wert (6).
Die Z-Bits sind derzeit in DSO-Nachrichten nicht verwendet; sowohl in DSO-Anfrage-Nachrichten als auch in DSO-Antworten MÜSSEN die Z-Bits bei der Übertragung auf Null (0) gesetzt werden und MÜSSEN beim Empfang ignoriert werden.
In einer DSO-Anfrage-Nachricht (QR=0) wird der RCODE gemäß der Definition der Anfrage gesetzt. Zum Beispiel gibt in einer Retry Delay-Nachricht (Abschnitt 6.6.1) der RCODE den Grund für die Beendigung an. In den meisten DSO-Anfrage-Nachrichten (QR=0) wird der RCODE jedoch, sofern nicht eindeutig anders angegeben, bei der Übertragung auf Null gesetzt und beim Empfang stillschweigend ignoriert.
Der RCODE-Wert in einer Antwort-Nachricht (QR=1) kann einer der folgenden Werte sein:
| Code | Mnemonik | Beschreibung |
|---|---|---|
| 0 | NOERROR | Operation erfolgreich verarbeitet |
| 1 | FORMERR | Formatfehler |
| 2 | SERVFAIL | Server konnte DSO-Anfrage-Nachricht aufgrund eines Problems mit dem Server nicht verarbeiten |
| 4 | NOTIMP | DSO nicht unterstützt |
| 5 | REFUSED | Operation aus politischen Gründen abgelehnt |
| 11 | DSOTYPENI | DSO-Type des Primary TLV ist nicht implementiert |
Die Verwendung der oben genannten RCODEs ist wahrscheinlich in DSO üblich, schließt aber nicht die Definition und Verwendung anderer Codes in zukünftigen Dokumenten aus, die DSO verwenden.
Wenn ein Dokument, das einen neuen DSO-TYPE definiert, Antwortcodes verwendet, die hier nicht definiert sind, MUSS dieses Dokument die spezifische Interpretation dieser RCODE-Werte im Kontext dieses neuen DSO-TLV spezifizieren.
Auf das RCODE-Feld folgen die vier null-wertigen Count-Felder, gefolgt von den DSO-Daten.
5.4.2. DSO-Daten (DSO Data)
Dem standardmäßigen zwölf Byte langen DNS-Nachrichten-Header mit seinen null-wertigen Count-Feldern folgen die DSO-Daten, ausgedrückt in TLV-Syntax, wie in Abschnitt 5.4.4 beschrieben.
Eine DSO-Anfrage-Nachricht oder unidirektionale DSO-Nachricht MUSS mindestens ein TLV enthalten. Das erste TLV in einer DSO-Anfrage-Nachricht oder unidirektionalen DSO-Nachricht wird als "Primary TLV" bezeichnet und bestimmt die Art der durchgeführten Operation, einschließlich ob es sich um eine DSO-Anfrage oder eine unidirektionale DSO-Operation handelt. In einigen Fällen kann es angemessen sein, andere TLVs in einer DSO-Anfrage-Nachricht oder unidirektionalen DSO-Nachricht einzuschließen, wie z.B. den DSO Encryption Padding TLV (Abschnitt 7.3). Zusätzliche TLVs folgen dem Primary TLV. Zusätzliche TLVs sind nicht auf das in diesem Dokument Definierte beschränkt. Neue Additional TLVs können in Zukunft definiert werden. Ihre Definitionen werden beschreiben, wann ihre Verwendung angemessen ist.
Ein nicht erkannter Primary TLV führt zu einer DSOTYPENI-Fehlerantwort. Nicht erkannte Additional TLVs werden stillschweigend ignoriert, wie in den Abschnitten 5.4.5 und 8.2 beschrieben.
Eine DSO-Antwort-Nachricht kann keine TLVs enthalten oder kann ein oder mehrere TLVs enthalten, die für die zu kommunizierenden Informationen geeignet sind.
Alle TLVs mit demselben DSO-TYPE wie der Primary TLV aus der entsprechenden DSO-Anfrage-Nachricht sind Response Primary TLV(s) und MÜSSEN zuerst in einer DSO-Antwort-Nachricht erscheinen. Eine DSO-Antwort-Nachricht kann mehrere Response Primary TLVs, einen einzelnen Response Primary TLV oder in einigen Fällen keinen Response Primary TLV enthalten. Ein Response Primary TLV ist nicht erforderlich; für die meisten DSO-Operationen ist das MESSAGE ID-Feld im DNS-Nachrichten-Header ausreichend, um die DSO-Anfrage-Nachricht zu identifizieren, auf die sich eine bestimmte Antwort-Nachricht bezieht.
Alle anderen TLVs in einer DSO-Antwort-Nachricht sind Response Additional TLVs, wie z.B. der DSO Encryption Padding TLV (Abschnitt 7.3). Response Additional TLVs folgen dem/den Response Primary TLV(s), falls vorhanden. Response Additional TLVs sind nicht auf das in diesem Dokument Definierte beschränkt. Neue Response Additional TLVs können in Zukunft definiert werden. Ihre Definitionen werden beschreiben, wann ihre Verwendung angemessen ist. Nicht erkannte Response Additional TLVs werden stillschweigend ignoriert, wie in den Abschnitten 5.4.5 und 8.2 beschrieben.
Die Spezifikation für jedes DSO-TLV bestimmt, welche TLVs in einer Antwort auf eine DSO-Anfrage-Nachricht, die dieses TLV verwendet, erforderlich sind. Wenn eine DSO-Antwort für eine Operation empfangen wird, bei der die Spezifikation erfordert, dass die Antwort ein bestimmtes TLV oder TLVs enthält, und die erforderlichen TLV(s) nicht vorhanden sind, dann ist dies ein fataler Fehler und der Empfänger der fehlerhaften Antwort-Nachricht MUSS die Verbindung sofort zwangsweise abbrechen. Ebenso, wenn mehr als die angegebene Anzahl von Instanzen eines gegebenen TLV vorhanden sind, ist dies ein fataler Fehler und der Empfänger der fehlerhaften Antwort-Nachricht MUSS die Verbindung sofort zwangsweise abbrechen.
5.4.3. Unidirektionale DSO-Nachrichten (DSO Unidirectional Messages)
Es wird erwartet, dass die meisten DSO-Operationen spezifiziert werden, um DSO-Anfrage-Nachrichten zu verwenden, die entsprechende DSO-Antworten erzeugen. In einigen spezialisierten hochfrequenten Anwendungsfällen kann es angemessen sein, unidirektionale DSO-Nachrichten zu spezifizieren. Unidirektionale DSO-Nachrichten können im Netzwerk effizienter sein, da sie keinen Strom entsprechender Antwortnachrichten erzeugen. Die Verwendung unidirektionaler DSO-Nachrichten kann auch in einigen Fällen die Software vereinfachen, indem die Notwendigkeit entfällt, dass ein Initiator den Zustand beibehält, während er darauf wartet, Antworten zu erhalten, um die er sich nicht kümmert. Wenn die Spezifikation für ein bestimmtes TLV, das als Primary TLV (d.h. zuerst) in einer ausgehenden DSO-Anfrage-Nachricht (d.h. QR=0) verwendet wird, angibt, dass eine Nachricht unidirektional sein soll, MUSS das MESSAGE ID-Feld auf Null gesetzt werden und der Empfänger DARF KEINE Antwort-Nachricht erzeugen, die dieser unidirektionalen DSO-Nachricht entspricht.
Der vorherige Punkt, dass der Empfänger KEINE Antworten auf unidirektionale DSO-Nachrichten erzeugen DARF, gilt auch im Fall von Fehlern.
Wenn eine DSO-Nachricht empfangen wird, bei der sowohl das QR-Bit als auch das MESSAGE ID-Feld Null sind, DARF der Empfänger KEINE Antwort erzeugen. Wenn beispielsweise der DSO-TYPE im Primary TLV nicht erkannt wird, DARF ein DSOTYPENI-Fehler NICHT zurückgegeben werden; stattdessen MUSS der Empfänger die Verbindung sofort zwangsweise abbrechen.
Unidirektionale DSO-Nachrichten DÜRFEN NICHT "spekulativ" in Fällen verwendet werden, in denen der Sender nicht weiß, ob der Empfänger den Primary TLV in der Nachricht unterstützt, da es keine Möglichkeit gibt, eine Antwort zu erhalten, die Erfolg oder Misserfolg anzeigt. Unidirektionale DSO-Nachrichten sind nur in Fällen angemessen, in denen der Sender bereits weiß, dass der Empfänger diese Nachrichten unterstützt und empfangen möchte.
Nachdem sich beispielsweise ein Client für Push Notifications [Push] angemeldet hat, werden die nachfolgenden Ereignisbenachrichtigungen als unidirektionale DSO-Nachrichten gesendet. Dies ist angemessen, da der Client den Nachrichtenstrom durch sein Push-Notification-Abonnement initiiert hat, wodurch er seine Unterstützung von Push Notifications und seinen Wunsch, diese Benachrichtigungen zu erhalten, angezeigt hat.
Ebenso, nachdem sich ein Discovery Relay-Client angemeldet hat, um eingehenden multicast DNS (mDNS) [RFC6762] Verkehr von einem Discovery Relay zu erhalten, wird der nachfolgende Strom empfangener Pakete unter Verwendung unidirektionaler DSO-Nachrichten gesendet. Dies ist angemessen, da der Client den Nachrichtenstrom durch sein Discovery Relay-Link-Abonnement initiiert hat, wodurch er seine Unterstützung von Discovery Relay und seinen Wunsch, eingehende mDNS-Pakete über diese DSO-Sitzung zu erhalten, angezeigt hat [Relay].
5.4.4. TLV-Syntax (TLV Syntax)
Alle TLVs, ob als "Primary", "Additional", "Response Primary" oder "Response Additional" verwendet, verwenden dieselbe Codierungssyntax.
Eine Spezifikation, die ein neues TLV definiert, muss angeben, ob der DSO-TYPE als Primary TLV verwendet werden kann und ob der DSO-TYPE als Additional TLV verwendet werden kann. Einige DSO-TYPEs sind Dual-Purpose und können als Primary TLVs in einigen Nachrichten und in anderen Nachrichten als Additional TLVs verwendet werden. Die Spezifikation für einen DSO-TYPE muss auch angeben, ob, wenn er als Primary (d.h. erstes) TLV in einer DSO-Nachricht (d.h. QR=0) verwendet wird, diese DSO-Nachricht unidirektional ist oder eine DSO-Anfrage-Nachricht ist, die eine Antwort erfordert.
Wenn eine DSO-Anfrage-Nachricht eine Antwort erfordert, muss die Spezifikation auch angeben, welche TLVs, falls vorhanden, in der Antwort enthalten sein sollen und wie viele Instanzen jedes der TLVs erlaubt sind. Der Primary TLV kann je nachdem, was für dieses TLV spezifiziert ist, in der Antwort enthalten sein oder nicht. Wenn mehrere Instanzen des Primary TLV erlaubt sind, sollte die Spezifikation klar beschreiben, wie sie verarbeitet werden sollen.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
DSO-TYPE: Eine 16-Bit-Ganzzahl ohne Vorzeichen in Netzwerk-Byte-Reihenfolge (Big Endian), die den DSO-TYPE des aktuellen DSO-TLV gemäß dem IANA "DSO Type Codes" Register angibt.
DSO-LENGTH: Eine 16-Bit-Ganzzahl ohne Vorzeichen in Netzwerk-Byte-Reihenfolge (Big Endian), die die Größe der DSO-DATA in Bytes angibt.
DSO-DATA: Typcode-spezifisches Format. Die generische DSO-Maschinerie behandelt die DSO-DATA als opaken "Blob", ohne zu versuchen, sie zu interpretieren. Die Interpretation der Bedeutung der DSO-DATA für einen bestimmten DSO-TYPE liegt in der Verantwortung der Software, die diesen DSO-TYPE implementiert.
5.4.5. Nicht erkannte TLVs (Unrecognized TLVs)
Wenn eine DSO-Anfrage-Nachricht empfangen wird, die einen nicht erkannten Primary TLV mit einer Nicht-Null-MESSAGE ID (was anzeigt, dass eine Antwort erwartet wird) enthält, MUSS der Empfänger eine Fehlerantwort mit einer passenden MESSAGE ID und RCODE DSOTYPENI senden. Die Fehlerantwort DARF KEINE Kopie des nicht erkannten Primary TLV enthalten.
Wenn eine unidirektionale DSO-Nachricht empfangen wird, die sowohl einen nicht erkannten Primary TLV als auch eine Null-MESSAGE ID enthält (was anzeigt, dass keine Antwort erwartet wird), dann ist dies ein fataler Fehler und der Empfänger MUSS die Verbindung sofort zwangsweise abbrechen.
Wenn eine DSO-Anfrage-Nachricht oder unidirektionale DSO-Nachricht empfangen wird, bei der der Primary TLV erkannt wird und die ein oder mehrere nicht erkannte Additional TLVs enthält, MÜSSEN die nicht erkannten Additional TLVs stillschweigend ignoriert werden, und der Rest der Nachricht wird interpretiert und behandelt, als ob die nicht erkannten Teile nicht vorhanden wären.
Ebenso, wenn eine DSO-Antwort-Nachricht empfangen wird, die ein oder mehrere nicht erkannte TLVs enthält, MÜSSEN die nicht erkannten TLVs stillschweigend ignoriert werden, und der Rest der Nachricht wird interpretiert und behandelt, als ob die nicht erkannten Teile nicht vorhanden wären.
5.4.6. EDNS(0) und TSIG
Da das ARCOUNT-Feld Null sein MUSS, kann eine DSO-Nachricht keine gültige EDNS(0)-Option in der Additional-Records-Section enthalten. Wenn Funktionalität, die durch aktuelle oder zukünftige EDNS(0)-Optionen bereitgestellt wird, für DSO-Nachrichten gewünscht wird, müssen ein oder mehrere neue DSO-TLVs definiert werden, um die notwendigen Informationen zu tragen.
Beispielsweise ist die EDNS(0) Padding Option [RFC7830], die für Sicherheitszwecke verwendet wird, in einer DSO-Nachricht nicht erlaubt. Wenn also Nachrichten-Padding für DSO-Nachrichten gewünscht wird, MUSS das in Abschnitt 7.3 beschriebene DSO Encryption Padding TLV verwendet werden.
Eine DSO-Nachricht kann keinen TSIG-Datensatz enthalten, da ein TSIG-Datensatz in der Additional-Section der Nachricht enthalten ist, was bedeuten würde, dass ARCOUNT größer als Null wäre. DSO-Nachrichten müssen ein ARCOUNT von Null haben. Daher müsste, wenn die Verwendung von Signaturen mit DSO-Nachrichten in Zukunft notwendig wird, ein neues DSO-TLV definiert werden, um diese Funktion auszuführen.
Beachten Sie jedoch, dass, während DSO-Nachrichten keine EDNS(0)- oder TSIG-Datensätze enthalten können, eine DSO-Sitzung typischerweise verwendet wird, um eine ganze Reihe von DNS-Nachrichten verschiedener Arten zu übertragen, einschließlich DSO-Nachrichten und anderer DNS-Nachrichtentypen wie Query [RFC1034] [RFC1035] und Update [RFC2136]. Diese Nachrichten können EDNS(0)- und TSIG-Datensätze enthalten.
Obwohl Nachrichten andere EDNS(0)-Optionen wie angemessen enthalten können, verbietet diese Spezifikation ausdrücklich die Verwendung der edns-tcp-keepalive EDNS(0) Option [RFC7828] in allen Nachrichten, die in einer DSO-Sitzung gesendet werden (da sie durch die von der DSO-Keepalive-Operation bereitgestellte Funktionalität überholt ist). Wenn eine in einer DSO-Sitzung gesendete Nachricht eine edns-tcp-keepalive EDNS(0) Option enthält, ist dies ein fataler Fehler und der Empfänger der fehlerhaften Nachricht MUSS die Verbindung sofort zwangsweise abbrechen.
5.5. Nachrichtenbehandlung (Message Handling)
Wie in Abschnitt 5.4.1 beschrieben, wird, ob eine ausgehende DSO-Nachricht mit dem im DNS-Header auf Null gesetzten QR-Bit eine DSO-Anfrage oder eine unidirektionale DSO-Nachricht ist, durch die Spezifikation für den Primary TLV bestimmt, was wiederum bestimmt, ob das MESSAGE ID-Feld in dieser ausgehenden Nachricht Null oder Nicht-Null sein wird.
Jede DSO-Nachricht mit dem im DNS-Header auf Null gesetzten QR-Bit und einem Nicht-Null-MESSAGE ID-Feld ist eine DSO-Anfrage-Nachricht und MUSS eine entsprechende Antwort hervorrufen, wobei das QR-Bit im DNS-Header auf Eins gesetzt ist und das MESSAGE ID-Feld auf den in der entsprechenden DSO-Anfrage-Nachricht angegebenen Wert gesetzt ist.
Gültige vom Client gesendete DSO-Anfrage-Nachrichten mit einem Nicht-Null-MESSAGE ID-Feld rufen eine Antwort vom Server hervor, und gültige vom Server gesendete DSO-Anfrage-Nachrichten mit einem Nicht-Null-MESSAGE ID-Feld rufen eine Antwort vom Client hervor.
Jede DSO-Nachricht mit sowohl dem im DNS-Header auf Null gesetzten QR-Bit als auch dem auf Null gesetzten MESSAGE ID-Feld ist eine unidirektionale DSO-Nachricht und DARF KEINE Antwort hervorrufen.
5.5.1. Verzögerte Bestätigungsverwaltung (Delayed Acknowledgement Management)
Im Allgemeinen verwenden die meisten guten TCP-Implementierungen einen verzögerten Bestätigungstimer, um eine effizientere Nutzung des Netzwerks und bessere Leistung zu bieten.
Bei einem bidirektionalen Austausch über TCP, wie z.B. mit einer DSO-Anfrage-Nachricht, wartet die TCP-Implementierung des Betriebssystems darauf, dass die Anwendungsschicht-Client-Software die entsprechende DSO-Antwort-Nachricht erzeugt. Die TCP-Implementierung kann dann ein einzelnes kombiniertes Paket senden, das die TCP-Bestätigung, das TCP-Fenster-Update und die von der Anwendung erzeugte DSO-Antwort-Nachricht enthält. Dies ist effizienter als das Senden von drei separaten Paketen, wie es auftreten würde, wenn das TCP-Paket, das die DSO-Anfrage enthält, sofort bestätigt würde.
Bei einer unidirektionalen DSO-Nachricht oder DSO-Antwort-Nachricht gibt es keine entsprechende von der Anwendung erzeugte DSO-Antwort-Nachricht und folglich keinen Hinweis an das Transportprotokoll, wann es seine Bestätigung und das Fenster-Update senden sollte.
Einige Netzwerk-APIs bieten einen Mechanismus, der es der Anwendungsschicht-Client-Software ermöglicht, dem Transportprotokoll zu signalisieren, dass keine Antwort kommen wird (tatsächlich kann es als ein "leeres" Write mit null Länge betrachtet werden). Wo in der verwendeten Netzwerk-API verfügbar, SOLLTE der Empfänger einer unidirektionalen DSO-Nachricht oder DSO-Antwort-Nachricht, nachdem er die Nachricht geparst und interpretiert hat, dann diesen von der Netzwerk-API bereitgestellten Mechanismus verwenden, um zu signalisieren, dass keine Antwort für diese Nachricht kommen wird. Die TCP-Implementierung kann dann ihre Bestätigung und das Fenster-Update ohne weitere Verzögerung senden. Siehe Abschnitt 9.5 für weitere Diskussion, warum dies wichtig ist.
5.5.2. MESSAGE ID-Namensräume (MESSAGE ID Namespaces)
Die Namensräume der 16-Bit-MESSAGE IDs sind in jeder Richtung unabhängig. Dies bedeutet, dass es kein Fehler ist, wenn sowohl Client als auch Server gleichzeitig DSO-Anfrage-Nachrichten senden und dabei dieselbe MESSAGE ID in verschiedenen Richtungen verwenden. Diese Vereinfachung ist notwendig, damit das Protokoll implementierbar ist. Es wäre undurchführbar zu erfordern, dass sich Client und Server bezüglich der Zuweisung neuer eindeutiger MESSAGE IDs koordinieren. Es ist auch nicht notwendig zu erfordern, dass sich Client und Server bezüglich der Zuweisung neuer eindeutiger MESSAGE IDs koordinieren. Der Wert der 16-Bit-MESSAGE ID kombiniert mit der Identität des Initiators (Client oder Server) ist ausreichend, um die betreffende Operation eindeutig zu identifizieren. Dies kann als ein 17-Bit-Nachrichten-Identifikationsraum betrachtet werden, der Nachrichten-Identifikatoren 0x00001-0x0FFFF für Client-zu-Server-DSO-Anfrage-Nachrichten und 0x10001-0x1FFFF für Server-zu-Client-DSO-Anfrage-Nachrichten verwendet. Die niedrigstwertigen 16 Bits werden explizit im MESSAGE ID-Feld der DSO-Nachricht gespeichert, und das höchstwertige Bit ist implizit aus der Richtung der Nachricht.
Wie in Abschnitt 5.4.1 beschrieben, DARF ein Initiator eine MESSAGE ID NICHT wiederverwenden, die er bereits für eine ausstehende DSO-Anfrage-Nachricht verwendet (sofern nicht anders durch die relevante Spezifikation für den betreffenden DSO-TYPE angegeben). Dies bedeutet zumindest, dass eine MESSAGE ID nicht in einer bestimmten Richtung auf einer bestimmten DSO-Sitzung wiederverwendet werden kann, während der Initiator auf eine Antwort auf eine vorherige DSO-Anfrage-Nachricht wartet, die diese MESSAGE ID auf dieser DSO-Sitzung verwendet (sofern nicht anders durch die relevante Spezifikation für den betreffenden DSO-TYPE angegeben), und für eine langlebige Operation kann die MESSAGE ID für die Operation nicht wiederverwendet werden, während diese Operation aktiv bleibt.
Wenn ein Client oder Server eine Antwort (QR=1) empfängt, bei der die MESSAGE ID Null ist oder ein anderer Wert ist, der mit der MESSAGE ID keiner seiner ausstehenden Operationen übereinstimmt, ist dies ein fataler Fehler und der Empfänger MUSS die Verbindung sofort zwangsweise abbrechen.
Wenn ein Responder eine DSO-Anfrage-Nachricht (QR=0) empfängt, bei der die MESSAGE ID nicht Null ist, der Responder Anfrage-MESSAGE IDs verfolgt und die MESSAGE ID mit der MESSAGE ID einer DSO-Anfrage-Nachricht übereinstimmt, die er empfangen hat, für die noch keine Antwort gesendet wurde, MUSS er die Verbindung sofort zwangsweise abbrechen. Dieses Verhalten ist erforderlich, um einen hypothetischen Angriff zu verhindern, der undefiniertes Verhalten in diesem Fall ausnutzt. Wenn der Responder MESSAGE IDs jedoch nicht auf diese Weise verfolgt, besteht kein solches Risiko. Daher ist das Verfolgen von MESSAGE IDs nur zur Implementierung dieser Plausibilitätsprüfung nicht erforderlich.
5.5.3. Fehlerantworten (Error Responses)
Wenn eine DSO-Anfrage-Nachricht aus irgendeinem Grund erfolglos ist, gibt der Responder einen Fehlercode an den Initiator zurück.
Im Fall eines Servers, der einen Fehlercode an einen Client als Antwort auf eine erfolglose DSO-Anfrage-Nachricht zurückgibt, KANN der Server wählen, die DSO-Sitzung zu beenden, oder KANN wählen, die DSO-Sitzung für weitere Operationen offen zu lassen. Für Fehlerbedingungen, die nur die einzelne betreffende Operation betreffen, SOLLTE der Server eine Fehlerantwort an den Client zurückgeben und die DSO-Sitzung für weitere Operationen offen lassen.
Für Fehlerbedingungen, die wahrscheinlich alle Operationen in naher Zukunft erfolglos machen, SOLLTE der Server eine Fehlerantwort an den Client zurückgeben und dann die DSO-Sitzung beenden, indem er eine Retry Delay-Nachricht sendet, wie in Abschnitt 6.6.1 beschrieben.
Nach Erhalt einer Fehlerantwort vom Server SOLLTE ein Client NICHT automatisch die DSO-Sitzung schließen. Ein Fehler, der sich auf eine bestimmte Operation auf einer DSO-Sitzung bezieht, impliziert nicht notwendigerweise, dass alle anderen Operationen auf dieser DSO-Sitzung ebenfalls fehlgeschlagen sind oder dass zukünftige Operationen fehlschlagen werden. Der Client sollte annehmen, dass der Server seine eigene Entscheidung darüber treffen wird, ob die DSO-Sitzung beendet werden soll oder nicht, basierend auf der Bestimmung des Servers, ob die Fehlerbedingung sich auf diese bestimmte Operation oder auf nachfolgende Operationen bezieht. Wenn der Server die DSO-Sitzung nicht beendet, indem er dem Client eine Retry Delay-Nachricht sendet (Abschnitt 6.6.1), dann SOLLTE der Client diese DSO-Sitzung für nachfolgende Operationen weiter verwenden.
Wenn ein unidirektionaler DSO-Nachrichtentyp empfangen wird (MESSAGE ID-Feld ist Null), sollte der Empfänger diesen DSO-Nachrichtentyp bereits erwarten. Abschnitt 5.4.5 beschreibt die Behandlung unbekannter DSO-Nachrichtentypen. Wenn ein unidirektionaler DSO-Nachrichtentyp eines unerwarteten Typs empfangen wird, SOLLTE der Empfänger die Verbindung zwangsweise abbrechen. Ob die Verbindung für andere interne Fehler bei der Verarbeitung der unidirektionalen DSO-Nachricht zwangsweise abgebrochen werden sollte, ist implementierungsabhängig gemäß der Schwere des Fehlers.
5.6. Vom Responder initiierte Operationsabbruch (Responder-Initiated Operation Cancellation)
Dieses Dokument, die Basisspezifikation für DNS Stateful Operations, definiert selbst keine langlebigen Operationen, definiert aber ein Framework zur Unterstützung langlebiger Operationen wie Push Notification-Abonnements [Push] und Discovery Relay-Interface-Abonnements [Relay].
Langlebige Operationen bleiben, wenn erfolgreich, bis der Initiator die Operation beendet, aktiv.
Es ist jedoch möglich, dass eine langlebige Operation zum Zeitpunkt ihrer Initiierung gültig war, aber dann eine spätere Änderung der Umstände diese Operation ungültig macht. Beispielsweise kann eine langlebige Client-Operation einen Namen betreffen, für den der Server autoritativ ist, aber dann wird die Serverkonfiguration so geändert, dass er nicht mehr autoritativ für diesen Namen ist.
In solchen Fällen kann es wünschenswert sein, dass der Responder selektiv nur die ungültig gewordenen Operationen abbrechen kann, anstatt die gesamte Sitzung zu beenden.
Der Responder führt diesen selektiven Abbruch durch, indem er eine neue DSO-Antwort-Nachricht mit dem MESSAGE ID-Feld sendet, das die MESSAGE ID der langlebigen Operation enthält, die beendet werden soll (die er zuvor mit einem NOERROR RCODE bestätigt hatte), und das RCODE-Feld der neuen DSO-Antwort-Nachricht den Grund für den Abbruch angibt.
Nachdem eine DSO-Antwort-Nachricht mit Nicht-Null-RCODE gesendet wurde, wurde diese Operation aus Sicht des Responders beendet, und der Responder sendet keine weiteren Nachrichten bezüglich dieser Operation.
Nachdem eine DSO-Antwort-Nachricht mit Nicht-Null-RCODE vom Initiator empfangen wurde, wurde diese Operation aus Sicht des Initiators beendet, und die MESSAGE ID der abgebrochenen Operation ist nun zur Wiederverwendung frei.