2. Motivation

Da sich das Domain Name System weiterhin an neue Anwendungen und Änderungen in der Bereitstellung anpasst, hat Polling das Potenzial, DNS-Server auf vielen Ebenen im gesamten Netzwerk zu belasten. Andere Netzwerkprotokolle haben erfolgreich ein Publish/Subscribe-Modell nach dem Observer-Designmuster [OBS] eingesetzt. Extensible Messaging and Presence Protocol (XMPP) Publish-Subscribe [XEP0060] und Atom [RFC4287] sind Beispiele. Während DNS-Server im Allgemeinen hochgradig optimiert sind und eine hohe Rate von Abfrage-/Antwort-Verkehr bewältigen können, kann das Hinzufügen eines Publish/Subscribe-Modells zur Verfolgung von Änderungen an DNS-Datensätzen zeitnahere Benachrichtigungen über Änderungen mit reduzierter CPU-Nutzung und geringerem Netzwerkverkehr liefern.

Das leitende Designprinzip von DNS Push Notifications ist, dass Clients, die sich für die Verwendung von DNS Push Notifications anstelle von wiederholtem Polling mit DNS-Abfragen entscheiden, die gleichen Ergebnisse erhalten wie durch ausreichend schnelles Polling, nur effizienter. Dies bedeutet, dass die Regeln dafür, welche Datensätze mit einem bestimmten DNS-Push-Benachrichtigungsabonnement übereinstimmen, dieselben sind wie die bereits etablierten Regeln zur Bestimmung, welche Datensätze mit einer bestimmten DNS-Abfrage übereinstimmen [RFC1034]. Beispielsweise werden Namensvergleiche auf Groß- und Kleinschreibung unabhängige Weise durchgeführt, und ein Datensatz vom Typ CNAME in einer Zone stimmt mit jedem DNS-TYP in einer Abfrage oder einem Abonnement überein.

Multicast DNS [RFC6762]-Implementierungen hören immer auf einer bekannten Link-Local-IP-Multicast-Gruppenadresse, und Änderungen werden an diese Multicast-Gruppenadresse gesendet, damit alle Gruppenmitglieder sie empfangen können. Daher verfügt Multicast DNS bereits über eine asynchrone Änderungsbenachrichtigungsfunktion. Wenn DNS-basierte Service Discovery [RFC6763] über ein Weitverkehrsnetzwerk unter Verwendung von Unicast DNS verwendet wird (möglicherweise über einen Discovery Proxy [RFC8766] erleichtert), wäre es von Vorteil, eine gleichwertige Funktion für Unicast DNS zu haben, damit Clients zeitnah über DNS-Datensatzänderungen informiert werden können, ohne polling zu müssen.

Der DNS Long-Lived Queries (LLQ)-Mechanismus [RFC8764] ist eine bestehende eingesetzte Lösung zur Bereitstellung asynchroner Änderungsbenachrichtigungen; er wurde von Apples Back to My Mac [RFC6281]-Dienst verwendet, der 2007 in Mac OS X 10.5 Leopard eingeführt wurde. Back to My Mac wurde in einer Ära entwickelt, als das Rechenzentrum-Betriebspersonal behauptete, es sei unmöglich für einen Server, eine große Anzahl von TCP-Verbindungen zu verarbeiten, selbst wenn diese Verbindungen sehr wenig Verkehr übertragen und die meiste Zeit inaktiv sind. Folglich wurde LLQ als UDP-basiertes Protokoll definiert, das im Wesentlichen einen Großteil der Verbindungszustandsverwaltungslogik von TCP im Benutzerbereich repliziert und seine eigene Nachahmung vorhandener TCP-Funktionen wie Flusskontrolle, Zuverlässigkeit und den Drei-Wege-Handshake erstellt.

Dieses Dokument baut auf den mit dem LLQ-Protokoll gewonnenen Erfahrungen mit einem verbesserten Design auf. Anstatt UDP zu verwenden, verwendet diese Spezifikation DNS Stateful Operations (DSO) [RFC8490], die über TLS über TCP ausgeführt werden, und muss daher die vorhandene TCP-Funktionalität nicht neu erfinden. Die Verwendung von TCP gibt langlebigen Verbindungen mit geringem Verkehr auch eine bessere Langlebigkeit durch NAT-Gateways, ohne dass das Gateway das NAT Port Mapping Protocol (NAT-PMP) [RFC6886] oder das Port Control Protocol (PCP) [RFC6887] unterstützen muss oder auf übermäßigen Keepalive-Verkehr zurückgreifen muss.