3. Overview (Übersicht)
3. Overview (Übersicht)
Ein DNS Push Notification-Client abonniert Push Notifications für ein bestimmtes RRset, indem er sich mit dem entsprechenden Push Notification-Server für dieses RRset verbindet und DSO-Nachricht(en) sendet, die das/die interessierende(n) RRset(s) angeben. Wenn der Client kein Interesse mehr daran hat, weitere Updates zu diesen Einträgen zu erhalten, kündigt er das Abonnement.
Der DNS Push Notification-Server für eine DNS-Zone ist jeder Server, der in der Lage ist, die korrekten Änderungsbenachrichtigungen für einen Namen zu generieren. Es kann sich um einen primären, sekundären oder versteckten Nameserver [RFC8499] handeln.
Der "_dns-push-tls._tcp.<zone>" SRV-Eintrag für eine Zone KANN auf denselben Ziel-Host und Port verweisen wie der "_dns-update-tls._tcp.<zone>" SRV-Eintrag dieser Zone. Wenn derselbe Ziel-Host und Port sowohl für DNS Updates als auch für DNS Push Notifications angeboten wird, KANN ein Client eine einzelne DSO-Sitzung zu diesem Server sowohl für DNS Updates als auch für DNS Push Notification-Abonnements verwenden. DNS Updates und DNS Push Notifications können auf verschiedenen Ports desselben Ziel-Hosts behandelt werden, in welchem Fall sie für die Zwecke dieser Spezifikation nicht als "derselbe Server" betrachtet werden und die Kommunikation mit diesen beiden Ports unabhängig behandelt wird. Die Unterstützung von DNS Updates und DNS Push Notifications auf demselben Server ist OPTIONAL. Ein DNS Push Notification-Server ist nicht verpflichtet, DNS Update zu unterstützen.
Standard-DNS-Abfragen KÖNNEN über eine DNS Push Notification (d.h. DSO) Sitzung gesendet werden. Für jede Zone, für die der Server autoritativ ist, MUSS er autoritativ auf Abfragen für Namen antworten, die in diese Zone fallen (z.B. der "_dns-push-tls._tcp.<zone>" SRV-Eintrag), sowohl für normale DNS-Abfragen als auch für DNS Push Notification-Abonnements. Für Namen, für die der Server als rekursiver Resolver fungiert (z.B. wenn der Server der lokale rekursive Resolver ist), MUSS er für jede Abfrage, für die er DNS Push Notification-Abonnements unterstützt, auch Standard-Abfragen unterstützen.
DNS Push Notifications belasten den antwortenden Server weniger als schnelles Polling, aber Push Notifications haben immer noch Kosten. Daher DÜRFEN DNS Push Notification-Clients NICHT rücksichtslos eine übermäßige Anzahl von Push Notification-Abonnements erstellen. Konkret:
(a) Ein Abonnement sollte nur aktiv sein, wenn es einen gültigen Grund gibt, Live-Daten zu benötigen (zum Beispiel, wenn eine Bildschirmanzeige derzeit die Ergebnisse dem Benutzer zeigt), und das Abonnement SOLLTE gekündigt werden, sobald der Bedarf für diese Daten endet (zum Beispiel, wenn der Benutzer diese Anzeige schließt). Im Falle eines Geräts wie eines Smartphones, das nach einer gewissen Zeit der Inaktivität in den Ruhemodus geht oder seinen Bildschirm anderweitig verdunkelt, sollte es seine Abonnements beim Verdunkeln des Bildschirms kündigen (da der Benutzer ohnehin keine Änderungen auf dem Display sehen kann) und seine Abonnements beim Aufwachen aus dem Display-Schlaf wiederherstellen.
(b) Ein DNS Push Notification-Client SOLLTE NICHT routinemäßig ein DNS Push Notification-Abonnement 24 Stunden am Tag, 7 Tage die Woche aktiv halten, nur um eine Liste im Speicher auf dem neuesten Stand zu halten, damit, wenn der Benutzer sich entscheidet, eine Bildschirmanzeige dieser Daten aufzurufen, sie wirklich schnell angezeigt werden kann. DNS Push Notifications sind so konzipiert, dass sie schnell genug sind, dass es nicht notwendig ist, eine "warme" Liste im Speicher vorab zu laden, nur für den Fall, dass sie später benötigt wird.
Im Allgemeinen darf ein Client, wie in der DNS Stateful Operations-Spezifikation [RFC8490] beschrieben, eine DSO-Sitzung zu einem Server nicht unbegrenzt offen halten, wenn er keine Abonnements (oder andere Operationen) auf dieser Sitzung aktiv hat. Ein Client sollte mit dem Schließen einer DSO-Sitzung unmittelbar beginnen, nachdem sie inaktiv wird, und dann, falls in Zukunft benötigt, eine neue Sitzung öffnen, wenn erforderlich. Alternativ kann ein Client spekulativ eine inaktive DSO-Sitzung für einige Zeit offen halten, vorbehaltlich der Einschränkung, dass er eine Sitzung nicht offen halten darf, die länger als das Inaktivitäts-Timeout der Sitzung (standardmäßig 15 Sekunden) [RFC8490] inaktiv war.
Beachten Sie, dass eine DSO-Sitzung mit einem aktiven DNS Push Notification-Abonnement nicht als inaktiv gilt, selbst wenn über einen längeren Zeitraum kein Datenverkehr fließt. In diesem Fall gilt das DSO-Inaktivitäts-Timeout nicht, da die Sitzung nicht inaktiv ist, aber das Keepalive-Intervall gilt weiterhin, um die Erzeugung ausreichender Nachrichten zur Aufrechterhaltung des Zustands in Middleboxes (wie NAT-Gateways oder Firewalls) zu gewährleisten und damit Client und Server regelmäßig überprüfen können, dass sie noch Konnektivität zueinander haben. Dies wird in Abschnitt 6.2 der DSO-Spezifikation [RFC8490] beschrieben.