2. Motivation

Alors que le système de noms de domaine continue de s'adapter à de nouvelles utilisations et à des changements de déploiement, le polling a le potentiel de surcharger les serveurs DNS à de nombreux niveaux dans le réseau. D'autres protocoles réseau ont déployé avec succès un modèle publish/subscribe suivant le modèle de conception Observer [OBS]. Extensible Messaging and Presence Protocol (XMPP) Publish-Subscribe [XEP0060] et Atom [RFC4287] en sont des exemples. Bien que les serveurs DNS soient généralement très optimisés et capables d'un taux élevé de trafic requête/réponse, l'ajout d'un modèle publish/subscribe pour suivre les modifications des enregistrements DNS peut fournir des notifications de modifications plus rapides avec une utilisation réduite du processeur et un trafic réseau moindre.

Le principe de conception directeur des DNS Push Notifications est que les clients qui choisissent d'utiliser les DNS Push Notifications, au lieu du polling répété avec des requêtes DNS, recevront les mêmes résultats qu'ils pourraient obtenir via un polling suffisamment rapide, mais de manière plus efficace. Cela signifie que les règles déterminant quels enregistrements correspondent à un abonnement DNS Push Notification donné sont les mêmes que les règles déjà établies utilisées pour déterminer quels enregistrements correspondent à une requête DNS donnée [RFC1034]. Par exemple, les comparaisons de noms sont effectuées de manière insensible à la casse, et un enregistrement de type CNAME dans une zone correspond à n'importe quel TYPE DNS dans une requête ou un abonnement.

Les implémentations Multicast DNS [RFC6762] écoutent toujours sur une adresse de groupe de multidiffusion IP link-local bien connue, et les modifications sont envoyées à cette adresse de groupe de multidiffusion pour que tous les membres du groupe les reçoivent. Par conséquent, Multicast DNS dispose déjà d'une capacité de notification de changement asynchrone. Lorsque DNS-based Service Discovery [RFC6763] est utilisé sur un réseau étendu utilisant l'Unicast DNS (éventuellement facilité via un Discovery Proxy [RFC8766]), il serait bénéfique d'avoir une capacité équivalente pour l'Unicast DNS afin de permettre aux clients d'apprendre les modifications des enregistrements DNS en temps opportun sans polling.

Le mécanisme DNS Long-Lived Queries (LLQ) [RFC8764] est une solution déployée existante pour fournir des notifications de changement asynchrones; il a été utilisé par le service Back to My Mac [RFC6281] d'Apple introduit dans Mac OS X 10.5 Leopard en 2007. Back to My Mac a été conçu à une époque où le personnel d'exploitation des centres de données affirmait qu'il était impossible pour un serveur de gérer un grand nombre de connexions TCP, même si ces connexions transportaient très peu de trafic et passaient la plupart de leur temps inactives. Par conséquent, LLQ a été défini comme un protocole basé sur UDP, répliquant effectivement une grande partie de la logique de gestion d'état de connexion de TCP dans l'espace utilisateur et créant sa propre imitation des fonctionnalités TCP existantes comme le contrôle de flux, la fiabilité et la poignée de main à trois voies.

Ce document s'appuie sur l'expérience acquise avec le protocole LLQ, avec une conception améliorée. Au lieu d'utiliser UDP, cette spécification utilise DNS Stateful Operations (DSO) [RFC8490] fonctionnant sur TLS sur TCP, et n'a donc pas besoin de réinventer la fonctionnalité TCP existante. L'utilisation de TCP donne également aux connexions à longue durée de vie avec peu de trafic une meilleure longévité à travers les passerelles NAT sans dépendre de la passerelle pour prendre en charge le NAT Port Mapping Protocol (NAT-PMP) [RFC6886] ou le Port Control Protocol (PCP) [RFC6887], ou avoir recours à un trafic keepalive excessif.