Dentro un messaggio DNS: header, flag, sezioni e formato wire

Ogni lookup DNS, dal browser che chiede un indirizzo al resolver che insegue una delega, è un breve messaggio binario in un formato comune. I byte si vedono di rado, ma strumenti come dig stampano i campi dell'header come testo, e sapere cosa significano trasforma quell'output da rumore in prova. Il formato è specificato dall'RFC 1035 fin dal 1987, come perfezionamento dell'RFC 883 del 1983, e da allora è stato esteso, non sostituito.

L'header di 12 byte

Ogni messaggio inizia con gli stessi 12 byte: un ID a 16 bit, una parola a 16 bit di flag e codici e quattro conteggi a 16 bit.

Dopo l'header arrivano le quattro sezioni, in quest'ordine. La sezione question riporta ciò che è stato chiesto, la sezione answer contiene i record che rispondono, la sezione authority indica i nameserver responsabili della zona e la sezione additional trasporta record extra che il server si aspetta che il client voglia subito dopo, come gli indirizzi di quei nameserver.

Fai attenzione a AA. Un resolver ricorsivo che risponde dalla propria cache non è autorevole per quei dati e non lo imposta. Nel progetto originale, un server contrassegna una risposta come autorevole quando risponde da dati di zona che possiede, e non da dati in cache (Mockapetris e Dunlap, 1988). Vedere aa in una risposta di uno dei nameserver della zona stessa è il caso normale, tranne che per un referral verso una zona figlia, che non lo riporta nemmeno se proviene da un server autorevole.

Come leggere la riga di header di dig

dig stampa l'header su due righe. Una tipica risposta ha questo aspetto:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

opcode e status sono i campi Opcode e RCODE. La riga flags elenca i bit impostati, qui qr, rd e ra, che insieme significano: una risposta, a una query che chiedeva la ricorsione, da un server che la offre. I quattro conteggi sono le dimensioni delle sezioni. L'ADDITIONAL: 1 è di solito lo pseudo-record EDNS del server, restituito perché dig ne include uno nella propria query; non è un indirizzo in più.

Lo status è la cosa più rapida da leggere. L'RFC 1035 definisce sei codici di risposta.

Un risultato comune non ha un codice proprio. Un nome che esiste ma non ha alcun record del tipo richiesto restituisce NOERROR senza record di quel tipo nella sezione answer (può comunque comparire un CNAME), situazione che l'RFC 2308 chiama NODATA. La differenza conta in fase di diagnosi; vedi NXDOMAIN spiegato e Timeout DNS o SERVFAIL per sapere cosa fare in ciascun caso.

Una query, byte per byte

Questa è una query completa per il record A di example.com nella sua forma classica, senza EDNS, come la invierebbe un client con la ricorsione richiesta. È lunga 29 byte.

1a 2b 01 00 00 01 00 00 00 00 00 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01

Gli stessi byte viaggiano all'interno dei trasporti cifrati. Nel DNS over HTTPS (RFC 8484), per esempio, lo stesso messaggio viaggia come corpo grezzo di una richiesta HTTP POST oppure, in una richiesta GET, codificato in base64url in un parametro dns, e ai client si consiglia di impostare l'ID a 0; vedi DNS over HTTPS e DNS over TLS spiegati.

Nomi, limiti e compressione

Un nome è una sequenza di etichette, ciascuna preceduta dalla propria lunghezza, che termina con un byte zero. L'RFC 1035 limita un'etichetta a 63 ottetti e un nome intero a 255. Poiché il byte di lunghezza di un'etichetta non supera mai 63, i suoi due bit più alti sono sempre zero, e questo ha lasciato spazio alla compressione: quando i due bit più alti valgono entrambi uno, quel byte e il successivo formano un puntatore, e i restanti 14 bit indicano un offset dall'inizio del messaggio. In una risposta, il nome della risposta è molto spesso formato dai due byte c0 0c, un puntatore all'offset 12, dove il nome della domanda inizia subito dopo l'header. Ogni programma DNS deve saper interpretare i puntatori nei messaggi che riceve, anche se può scegliere di non produrli.

Perché i 512 byte contavano, e cosa li ha sostituiti

L'RFC 1035 limita i messaggi UDP a 512 byte, senza contare gli header IP e UDP. Un messaggio più lungo viene troncato e il bit TC viene impostato, il che dice al client di riprovare via TCP. I progettisti originali giudicarono il limite dei datagrammi un successo più che un problema: le prestazioni erano molto migliori rispetto ai circuiti TCP e le risorse del sistema operativo non restavano impegnate, anche se la scelta richiedeva strategie di ritrasmissione accurate (Mockapetris e Dunlap, 1988).

Con la crescita delle risposte dovuta a IPv6 e DNSSEC, il limite è diventato stretto. EDNS(0), definito nell'RFC 6891, permette a un client di annunciare una dimensione maggiore del payload UDP in uno pseudo-record OPT. L'RFC suggerisce 4096 ottetti come punto di partenza e, se non funziona, un ripiego su un valore compreso all'incirca tra 1280 e 1410 byte. Dall'RFC 7766, nel 2016, il supporto di TCP è una parte obbligatoria di un'implementazione DNS completa. Risposte UDP più grandi hanno anche un costo in termini di sicurezza, perché rendono più redditizi gli attacchi di riflessione; ne parla Attacchi di amplificazione DNS e resolver aperti.

Fonti e letture di approfondimento

• RFC 1035: Domain Names - Implementation and Specification (Mockapetris, 1987)
• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) (Andrews, 1998)
• RFC 2535: Domain Name System Security Extensions (Eastlake, 1999)
• RFC 4035: Protocol Modifications for the DNS Security Extensions (Arends et al., 2005)
• RFC 6891: Extension Mechanisms for DNS (EDNS(0)) (Damas, Graff and Vixie, 2013)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• Paul V. Mockapetris and Kevin J. Dunlap, Development of the Domain Name System, Proceedings of SIGCOMM '88, Computer Communication Review 18(4), 1988, pp. 123-133
• Paul Albitz and Cricket Liu, DNS and BIND, 5th edition (O'Reilly, 2006)
• Kevin R. Fall and W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition (Addison-Wesley, 2011)