2. Motivation (Motivazione)

Poiché il sistema dei nomi di dominio continua ad adattarsi a nuovi utilizzi e cambiamenti nella distribuzione, il polling ha il potenziale di sovraccaricare i server DNS a molti livelli in tutta la rete. Altri protocolli di rete hanno distribuito con successo un modello publish/subscribe seguendo il pattern di design Observer [OBS]. Extensible Messaging and Presence Protocol (XMPP) Publish-Subscribe [XEP0060] e Atom [RFC4287] sono esempi. Sebbene i server DNS siano generalmente altamente ottimizzati e capaci di un alto tasso di traffico query/response, l'aggiunta di un modello publish/subscribe per tracciare le modifiche ai record DNS può fornire notifiche più tempestive delle modifiche con un utilizzo ridotto della CPU e un traffico di rete inferiore.

Il principio guida di progettazione delle DNS Push Notifications è che i client che scelgono di utilizzare le DNS Push Notifications, invece del polling ripetuto con query DNS, riceveranno gli stessi risultati che potrebbero ottenere tramite un polling sufficientemente rapido, ma in modo più efficiente. Ciò significa che le regole per determinare quali record corrispondono a una data sottoscrizione DNS Push Notification sono le stesse delle regole già stabilite utilizzate per determinare quali record corrispondono a una data query DNS [RFC1034]. Ad esempio, i confronti dei nomi vengono effettuati in modo insensibile alle maiuscole e minuscole, e un record di tipo CNAME in una zona corrisponde a qualsiasi TYPE DNS in una query o sottoscrizione.

Le implementazioni Multicast DNS [RFC6762] ascoltano sempre su un indirizzo di gruppo multicast IP link-local ben noto, e le modifiche vengono inviate a quell'indirizzo di gruppo multicast affinché tutti i membri del gruppo le ricevano. Pertanto, Multicast DNS ha già una capacità di notifica di modifica asincrona. Quando DNS-based Service Discovery [RFC6763] viene utilizzato su una rete geografica utilizzando Unicast DNS (possibilmente facilitato tramite un Discovery Proxy [RFC8766]), sarebbe vantaggioso avere una capacità equivalente per Unicast DNS al fine di consentire ai client di conoscere le modifiche ai record DNS in modo tempestivo senza polling.

Il meccanismo DNS Long-Lived Queries (LLQ) [RFC8764] è una soluzione distribuita esistente per fornire notifiche di modifica asincrone; è stato utilizzato dal servizio Back to My Mac [RFC6281] di Apple introdotto in Mac OS X 10.5 Leopard nel 2007. Back to My Mac è stato progettato in un'era in cui il personale operativo dei data center affermava che era impossibile per un server gestire un gran numero di connessioni TCP, anche se tali connessioni trasportavano pochissimo traffico e trascorrevano la maggior parte del tempo inattive. Di conseguenza, LLQ è stato definito come un protocollo basato su UDP, replicando effettivamente gran parte della logica di gestione dello stato di connessione di TCP nello spazio utente e creando la propria imitazione di funzionalità TCP esistenti come il controllo di flusso, l'affidabilità e il three-way handshake.

Questo documento si basa sull'esperienza acquisita con il protocollo LLQ, con un design migliorato. Invece di utilizzare UDP, questa specifica utilizza DNS Stateful Operations (DSO) [RFC8490] in esecuzione su TLS su TCP, e quindi non ha bisogno di reinventare la funzionalità TCP esistente. L'uso di TCP dà anche alle connessioni di lunga durata con poco traffico una migliore longevità attraverso i gateway NAT senza dipendere dal gateway per supportare il NAT Port Mapping Protocol (NAT-PMP) [RFC6886] o il Port Control Protocol (PCP) [RFC6887], o ricorrere a traffico keepalive eccessivo.