6.2.1. SUBSCRIBE Request (SUBSCRIBE-Anfrage)
6.2.1. SUBSCRIBE Request (SUBSCRIBE-Anfrage)
Eine SUBSCRIBE-Anfrage beginnt mit dem standardmäßigen DSO-12-Byte-Header [RFC8490], gefolgt vom SUBSCRIBE-Primary-TLV (Primary TLV). Eine SUBSCRIBE-Anfrage ist in Abbildung 1 dargestellt.
Das Feld MESSAGE ID MUSS auf einen eindeutigen Wert gesetzt werden, den der Client für keine andere aktive Operation in dieser DSO-Sitzung verwendet. Für die Zwecke hier gilt ein MESSAGE ID als auf dieser Sitzung in Benutzung, wenn der Client ihn entweder für eine Anfrage verwendet hat, für die er noch keine Antwort erhalten hat, oder wenn er ihn für ein Abonnement verwendet hat, das er noch nicht mit UNSUBSCRIBE abgebrochen hat. In der SUBSCRIBE-Antwort MUSS der Server den Wert von MESSAGE ID unverändert zurückgeben.
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).
Der DSO-TYPE ist SUBSCRIBE (0x0040).
Die DSO-LENGTH ist die Länge des folgenden DSO-DATA, das Name, Typ und Klasse (class) der gesuchten Datensätze angibt.
Das DSO-DATA einer SUBSCRIBE-Anfrage MUSS genau ein NAME, TYPE und CLASS enthalten. Da SUBSCRIBE-Anfragen über TCP gesendet werden, können mehrere SUBSCRIBE-DSO-Anfragenachrichten in einem einzelnen TCP-Strom verkettet und effizient in TCP-Segmenten gepackt werden.
Wenn sie akzeptiert wird, bleibt das Abonnement in Kraft, bis der Client das Abonnement mit UNSUBSCRIBE abbricht oder bis die DSO-Sitzung zwischen Client und Server geschlossen wird.
SUBSCRIBE-Anfragen in einer gegebenen Sitzung MÜSSEN eindeutig sein. Ein Client DARF KEINE SUBSCRIBE-Nachricht senden, die Name, Typ und Klasse eines bestehenden aktiven Abonnements in dieser DSO-Sitzung dupliziert. Für diesen Abgleich gilt die etablierte DNS-Groß-/Kleinschreibungsunempfindlichkeit für US-ASCII-Buchstaben [RFC0020] (z. B. sind «example.com» und «Example.com» gleich). Wenn ein Server eine solche doppelte SUBSCRIBE-Nachricht erhält, handelt es sich um einen fatalen Fehler, und der Server MUSS die Verbindung sofort zwangsweise abbrechen.
DNS-Wildcarding (Platzhalter) wird nicht unterstützt. Das heißt, ein Sternzeichen («») in einer SUBSCRIBE-Nachricht stimmt nur mit einem wörtlichen Stern («») in einem Namen überein und sonst mit nichts. Entsprechend stimmt ein CNAME in einer SUBSCRIBE-Nachricht nur mit einem CNAME-Datensatz mit diesem Namen in der Zone überein und nicht mit anderen Datensätzen mit diesem Namen.
Ein Client KANN Datensätze abonnieren, die dem Server zum Zeitpunkt der Anfrage unbekannt sind (sofern der Name in eine der Zonen fällt, für die der Server zuständig ist), und dies ist kein Fehler. Der Server DARF in diesem Fall kein NXDOMAIN zurückgeben. Der Server MUSS diese Anfragen akzeptieren und Push-Benachrichtigungen (Push Notifications) senden, falls und sobald passende Datensätze gefunden werden.
Weder TYPE noch CLASS sind ANY (255), handelt es sich um ein spezifisches Abonnement auf Änderungen für den gegebenen Namen, Typ und Klasse. Wenn eines oder beide von TYPE oder CLASS ANY (255) sind, entspricht dieses Abonnement allen Typen und/oder allen Klassen, je nachdem.
HINWEIS: Eine wenig bekannte Eigenheit von DNS ist, dass in DNS-QUERY-Anfragen QTYPE und QCLASS 255 «ANY» bedeuten, nicht «ALL». Sie bedeuten, dass der Server mit beliebigen passenden Datensätzen seiner Wahl antworten soll, nicht notwendigerweise mit allen passenden Datensätzen. Das kann zu überraschenden und unerwarteten Ergebnissen führen, bei denen eine Abfrage einige gültige Antworten, aber nicht alle zurückgibt, und macht Abfragen mit QTYPE = 255 (ANY) weniger nützlich, als manche annehmen.
In Verbindung mit SUBSCRIBE sollten TYPE 255 und CLASS 255 als «ALL» interpretiert werden, nicht als «ANY». Nach Annahme eines Abonnements, bei dem eines oder beide von TYPE oder CLASS 255 sind, MUSS der Server Push-Notification-Updates (Push Notification Updates) für ALLE Datensatzänderungen senden, die dem Abonnement entsprechen, nicht nur für einige davon.