6.2.2. SUBSCRIBE Response (SUBSCRIBE Antwort)
6.2.2. SUBSCRIBE Response (SUBSCRIBE Antwort)
Eine SUBSCRIBE-Antwort beginnt mit dem standardmäßigen DSO 12-Byte-Header [RFC8490]. Das QR-Bit im Header ist gesetzt und zeigt an, dass es sich um eine Antwort handelt. Dem Header KÖNNEN ein oder mehrere optionale zusätzliche TLVs wie ein Retry Delay Additional TLV folgen. Eine SUBSCRIBE-Antwort ist in Abbildung 2 dargestellt.
Das Feld MESSAGE ID MUSS den im Feld MESSAGE ID der SUBSCRIBE-Anfrage angegebenen Wert zurückgeben. So weiß der Client, auf welche Anfrage geantwortet wird.
Die anderen Header-Felder MÜSSEN wie in der DSO-Spezifikation [RFC8490] beschrieben gesetzt werden. Das Feld DNS OPCODE enthält den OPCODE-Wert für DNS Stateful Operations (6). Die vier Zählfelder müssen Null sein, und die entsprechenden vier Abschnitte müssen leer sein (d.h. nicht vorhanden).
Eine SUBSCRIBE-Antwortnachricht DARF KEIN SUBSCRIBE-TLV enthalten. Wenn ein Client eine SUBSCRIBE-Antwortnachricht erhält, die ein SUBSCRIBE-TLV enthält, wird die Antwortnachricht verarbeitet, aber das SUBSCRIBE-TLV MUSS stillschweigend ignoriert werden.
In der SUBSCRIBE-Antwort gibt der RCODE an, ob das Abonnement akzeptiert wurde oder nicht. Unterstützte RCODEs sind wie folgt:
| Mnemonik | Wert | Beschreibung |
|---|---|---|
| NOERROR | 0 | SUBSCRIBE erfolgreich. |
| FORMERR | 1 | Server konnte Anfrage aufgrund einer fehlerhaften Anfrage nicht verarbeiten. |
| SERVFAIL | 2 | Server konnte Anfrage aufgrund eines Problems mit dem Server nicht verarbeiten. |
| NOTIMP | 4 | Server implementiert DSO nicht. |
| REFUSED | 5 | Server lehnt die Verarbeitung der Anfrage aus Richtlinien- oder Sicherheitsgründen ab. |
| NOTAUTH | 9 | Server ist für den angeforderten Namen nicht autoritativ. |
| DSOTYPENI | 11 | SUBSCRIBE-Operation wird nicht unterstützt. |
Tabelle 1: SUBSCRIBE-Antwortcodes
Dieses Dokument spezifiziert nur diese RCODE-Werte für SUBSCRIBE-Antworten. Server, die SUBSCRIBE-Antworten senden, SOLLTEN einen dieser Werte verwenden. Beachten Sie, dass NXDOMAIN kein gültiger RCODE als Antwort auf eine SUBSCRIBE-Anfrage ist. Zukünftige Umstände können jedoch Situationen schaffen, in denen andere RCODE-Werte in SUBSCRIBE-Antworten angemessen sind, daher MÜSSEN Clients darauf vorbereitet sein, SUBSCRIBE-Antworten mit anderen Nicht-Null-RCODE-Fehlerwerten zu akzeptieren und zu behandeln.
Wenn der Server einen Nicht-Null-RCODE in der SUBSCRIBE-Antwort sendet, bedeutet dies:
a. der Client ist (zumindest teilweise) falsch konfiguriert, oder b. die Serverressourcen sind erschöpft, oder c. es gibt einen anderen unbekannten Fehler auf dem Server.
In jedem Fall sollte der Client das Abonnement nicht sofort erneut auf diesem Server versuchen. Wenn mehrere SRV-Einträge zurückgegeben wurden, wie in Abschnitt 6.1, Absatz 9, Punkt 7 beschrieben, KANN sofort ein nachfolgender Server versucht werden.
Wenn der Client andere erfolgreiche Abonnements zu diesem Server hat, bleiben diese Abonnements bestehen, auch wenn zusätzliche Abonnements möglicherweise abgelehnt werden. Weder der Client noch der Server ist verpflichtet, die Verbindung zu schließen, obwohl beide Enden dies tun können.
Wenn der Server einen Nicht-Null-RCODE sendet, SOLLTE er ein Retry Delay Additional TLV [RFC8490] an die Antwort anhängen, das eine Verzögerung angibt, bevor der Client diesen Vorgang erneut versucht. Empfohlene Werte für die Verzögerung für verschiedene RCODE-Werte sind unten angegeben. Diese empfohlenen Werte gelten sowohl für die Standardwerte, die ein Server im Retry Delay Additional TLV platzieren sollte, als auch für die Standardwerte, die ein Client annehmen sollte, wenn der Server kein Retry Delay Additional TLV bereitstellt.
Für RCODE = 1 (FORMERR) kann die Verzögerung jeder vom Implementierer gewählte Wert sein. Ein Wert von fünf Minuten wird EMPFOHLEN, um das Risiko hoher Last von defekten Clients zu verringern.
Für RCODE = 2 (SERVFAIL) sollte die Verzögerung entsprechend dem Grad der Serverüberlastung und der erwarteten Dauer dieser Überlastung gewählt werden. Standardmäßig wird ein Wert von einer Minute EMPFOHLEN. Wenn ein schwerwiegenderer Serverfehler auftritt, kann die Verzögerung entsprechend dem spezifischen aufgetretenen Problem länger sein.
Für RCODE = 4 (NOTIMP), der auf einem Server auftritt, der DNS Stateful Operations [RFC8490] nicht implementiert, ist es unwahrscheinlich, dass der Server in den nächsten Minuten DSO unterstützen wird, daher SOLLTE die Wiederholungsverzögerung eine Stunde betragen. Beachten Sie, dass in einem solchen Fall ein Server, der DSO nicht implementiert, wahrscheinlich kein Retry Delay Additional TLV in seiner Antwort platziert, sodass dieser empfohlene Wert insbesondere für das gilt, was ein Client standardmäßig annehmen sollte.
Für RCODE = 5 (REFUSED), der auf einem Server auftritt, der DNS Push Notifications implementiert, aber derzeit so konfiguriert ist, dass er DNS Push Notifications nicht zulässt, kann die Wiederholungsverzögerung jeder vom Implementierer gewählte und/oder vom Operator konfigurierte Wert sein.
Wenn der abgefragte Server in einem "_dns-push-tls._tcp.<zone>" SRV-Eintrag für die Zone aufgeführt ist, handelt es sich um eine Fehlkonfiguration, da dieser Server als Unterstützung von DNS Push Notifications für diese Zone beworben wird, der Server selbst aber derzeit nicht für die Ausführung dieser Aufgabe konfiguriert ist. Da es möglich ist, dass die Fehlkonfiguration jederzeit behoben wird, sollte die Wiederholungsverzögerung nicht zu hoch eingestellt werden. Standardmäßig wird ein Wert von 5 Minuten EMPFOHLEN.
Für RCODE = 9 (NOTAUTH), der auf einem Server auftritt, der DNS Push Notifications implementiert, aber nicht so konfiguriert ist, dass er für den angeforderten Namen autoritativ ist, kann die Wiederholungsverzögerung jeder vom Implementierer gewählte und/oder vom Operator konfigurierte Wert sein.
Wenn der abgefragte Server in einem "_dns-push-tls._tcp.<zone>" SRV-Eintrag für die Zone aufgeführt ist, handelt es sich um eine Fehlkonfiguration, da dieser Server als Unterstützung von DNS Push Notifications für diese Zone beworben wird, der Server selbst aber derzeit nicht für die Ausführung dieser Aufgabe konfiguriert ist. Da es möglich ist, dass die Fehlkonfiguration jederzeit behoben wird, sollte die Wiederholungsverzögerung nicht zu hoch eingestellt werden. Standardmäßig wird ein Wert von 5 Minuten EMPFOHLEN.
Für RCODE = 11 (DSOTYPENI), der auf einem Server auftritt, der DSO implementiert, aber DNS Push Notifications nicht implementiert, ist es unwahrscheinlich, dass der Server in den nächsten Minuten DNS Push Notifications unterstützen wird, daher SOLLTE die Wiederholungsverzögerung eine Stunde betragen.
Für andere RCODE-Werte sollte die Wiederholungsverzögerung vom Server entsprechend dieser Fehlerbedingung angemessen festgelegt werden. Standardmäßig wird ein Wert von 5 Minuten EMPFOHLEN.
Für RCODE = 9 (NOTAUTH) gilt die Zeitverzögerung für Anfragen für andere Namen, die in dieselbe Zone fallen. Anfragen für Namen, die in andere Zonen fallen, unterliegen nicht der Verzögerung. Für alle anderen RCODEs gilt die Zeitverzögerung für alle nachfolgenden Anfragen an diesen Server.
Nach dem Senden einer Fehlerantwort KANN der Server zulassen, dass die Sitzung offen bleibt, oder ihr mit einer DSO Retry Delay-Operation (unter Verwendung des Retry Delay Primary TLV) folgen, die den Client anweist, die Sitzung wie in der DSO-Spezifikation [RFC8490] beschrieben zu schließen. Clients MÜSSEN beide Fälle korrekt behandeln. Beachten Sie, dass die DSO Retry Delay-Operation (unter Verwendung des Retry Delay Primary TLV) sich vom oben erwähnten Retry Delay Additional TLV unterscheidet.