1. Introduzione

Questo documento specifica un meccanismo per la gestione delle connessioni DNS con stato. Il DNS opera più comunemente su un trasporto UDP, ma può anche operare su trasporti in streaming; l'RFC DNS originale specifica DNS-over-TCP [RFC1035], ed è stato specificato un profilo per DNS-over-TLS [RFC7858]. Questi trasporti possono offrire sessioni persistenti di lunga durata e quindi, quando li si utilizza per il trasporto di messaggi DNS, è vantaggioso disporre di un meccanismo in grado di stabilire parametri associati a tali sessioni, come i timeout. In tali situazioni, è anche vantaggioso supportare messaggi avviati dal server (come le notifiche push DNS [Push]).

Il meccanismo di estensione esistente per DNS (EDNS(0)) [RFC6891] è definito esplicitamente per avere solo una semantica "per messaggio". Sebbene EDNS(0) sia stato utilizzato per segnalare almeno un parametro relativo alla sessione (opzione edns-tcp-keepalive EDNS(0) [RFC7828]), il risultato è meno che ottimale a causa delle restrizioni imposte dalla semantica EDNS(0) e dalla mancanza di segnalazione avviata dal server. Ad esempio, un server non può istruire arbitrariamente un client a chiudere una connessione perché il server può inviare opzioni EDNS(0) solo nelle risposte alle query che contenevano opzioni EDNS(0).

Questo documento definisce un nuovo OPCODE DNS per le operazioni DNS con stato (DSO) con un valore di 6. I messaggi DSO sono utilizzati per comunicare le operazioni all'interno di sessioni persistenti con stato, espresse utilizzando la sintassi Tipo Lunghezza Valore (TLV). Questo documento definisce un set iniziale di tre TLV utilizzati per gestire i timeout della sessione, la terminazione e il riempimento della crittografia.

Tutti e tre i TLV definiti qui sono obbligatori per tutte le implementazioni di DSO. Ulteriori TLV possono essere definiti in specifiche aggiuntive.

I messaggi DSO possono o meno essere confermati. Se un messaggio DSO deve essere confermato (un messaggio di richiesta DSO) o non deve essere confermato (un messaggio unidirezionale DSO) è specificato nella definizione di quel particolare tipo di messaggio DSO. L'ID MESSAGGIO è diverso da zero per i messaggi di richiesta DSO e zero per i messaggi unidirezionali DSO. I messaggi sono inviati in pipeline e le risposte possono apparire fuori ordine quando più richieste vengono elaborate contemporaneamente.

Il formato per i messaggi DSO (Sezione 5.4) differisce leggermente dal formato tradizionale dei messaggi DNS utilizzato per query e risposte standard. Viene utilizzata l'intestazione standard di dodici byte, ma i quattro campi di conteggio (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) sono impostati a zero e, di conseguenza, le loro sezioni corrispondenti non sono presenti.

I dati effettivi relativi alle operazioni DNS con stato (espressi in sintassi TLV) sono aggiunti alla fine dell'intestazione del messaggio DNS. Proprio come nel tradizionale DNS-over-TCP [RFC1035] [RFC7766], il protocollo di flusso che trasporta i messaggi DSO (che sono solo un altro tipo di messaggio DNS) li incornicia mettendo una lunghezza del messaggio di 16 bit all'inizio. La lunghezza del messaggio DSO è quindi determinata da quella lunghezza piuttosto che da uno qualsiasi dei conteggi dell'intestazione DNS.

Quando visualizzato utilizzando strumenti di analisi dei pacchetti che non sono stati aggiornati per riconoscere il formato DSO, ciò risulterà nella visualizzazione dei dati DSO come dati extra sconosciuti dopo la fine del messaggio DNS.

Questo nuovo formato presenta vantaggi distinti rispetto a un formato basato su RR perché è più esplicito e più compatto. Ogni definizione TLV è specifica per il suo caso d'uso e, di conseguenza, non contiene campi ridondanti o sovraccarichi. È importante sottolineare che evita completamente di confondere le operazioni DNS con stato in qualsiasi modo con le normali operazioni DNS o con le funzionalità esistenti basate su EDNS(0). Un obiettivo di questo approccio è evitare i problemi operativi che hanno colpito EDNS(0), in particolare per quanto riguarda il comportamento delle middlebox (vedere le sezioni che discutono EDNS(0) e i problemi causati da firewall e bilanciatori di carico, nel recente lavoro che descrive le cause dei fallimenti DNS [Fail]).

Con EDNS(0), più opzioni possono essere compresse in un singolo pseudo-RR OPT e non esiste un meccanismo generalizzato per consentire a un client di sapere se un server ha elaborato o agito in altro modo su ciascuna singola opzione all'interno dello pseudo-RR OPT combinato. Le specifiche per ciascuna singola opzione devono definire come ciascuna diversa opzione deve essere confermata, se necessario.

A differenza di EDNS(0), con DSO non c'è una motivazione convincente per comprimere più operazioni in un singolo messaggio per motivi di efficienza, perché DSO opera sempre utilizzando un protocollo di trasporto orientato alla connessione. Ogni operazione DSO viene comunicata nel proprio messaggio DNS separato e il protocollo di trasporto può occuparsi di comprimere più messaggi DNS in un singolo pacchetto IP se appropriato. Ad esempio, TCP può comprimere più piccoli messaggi DNS in un singolo segmento TCP. Questa semplificazione consente una semantica più chiara. Ogni messaggio di richiesta DSO comunica solo un'operazione primaria e l'RCODE nel messaggio di risposta corrispondente indica il successo o il fallimento di quell'operazione.