DNS Resolution, Start to Finish

Ogni volta che digiti un dominio nel browser, una catena di ricerche si avvia prima che un singolo pacchetto raggiunga il sito desiderato. La maggior parte di questa catena è invisibile, e la maggior parte delle spiegazioni si ferma a "è come un'agenda telefonica." Ecco cosa accade effettivamente, passo dopo passo, incluse le parti che di solito vengono saltate.

Il resolver stub non è intelligente

Il sistema operativo non esegue una vera risoluzione DNS da solo. Esegue un resolver stub, un codice semplice che inolttra la query al server DNS configurato in /etc/resolv.conf su Linux oppure nelle impostazioni della scheda di rete su Windows. Controlla il tuo con:

cat /etc/resolv.conf

Questo file di solito punta al tuo router (come 192.168.1.1), al resolver del tuo ISP, oppure a uno pubblico come 1.1.1.1 o 8.8.8.8. Il resolver stub non ha logica di cache propria al di là di quella fornita dal sistema operativo o da un daemon locale come systemd-resolved.

Il resolver ricorsivo fa il lavoro vero

Una volta che la tua query raggiunge un resolver ricorsivo, quel server prende in carico il compito di trovare la risposta, anche se deve chiedere a più altri server per arrivarci. Se la risposta è già in cache da una ricerca precedente, la ottieni immediatamente. Controlla il TTL con:

dig example.com

Guarda la ANSWER SECTION — il numero prima del tipo di record (come 300 prima di A) è il TTL in secondi. È il tempo per cui i resolver possono mantenere il record in cache prima di chiedere di nuovo.

Se nulla è in cache, il resolver ricorsivo inizia a scendere la gerarchia DNS dalla radice.

Server root, TLD e autoritativi

Ci sono 13 indirizzi di server root (da a.root-servers.net a m.root-servers.net), ognuno supportato da molte macchine fisiche attraverso routing anycast. Il server root non sa dove si trova example.com, ma sa quali server gestiscono .com, quindi restituisce un rinvio.

Il resolver chiede quindi a un server TLD .com, che di nuovo non conosce la risposta finale ma sa quali nameserver sono autoritativi per example.com specificamente. Puoi vedere questa delegazione tu stesso:

dig +trace example.com

Questo comando mostra ogni hop: root, poi TLD, poi i nameserver autoritativi per il dominio, terminando con il record A o AAAA effettivo. È il comando migliore per capire il DNS visivamente invece che teoricamente.

Il nameserver autoritativo è l'ultima fermata. È il server che il proprietario del dominio ha effettivamente configurato, spesso tramite il pannello DNS di un registrar o un servizio come Route 53 o Cloudflare DNS. Questo è l'unico server dell'intera catena che ha la risposta reale e canonica invece di una copia in cache o un rinvio.

Tipi di record che effettivamente incontrerai

Un record A associa un nome a un indirizzo IPv4, AAAA fa lo stesso per IPv6. CNAME punta un nome a un altro nome piuttosto che a un IP, che è come i CDN come Cloudflare o Fastly instradano il traffico senza esporre indirizzi IP grezzi. I record MX gestiscono l'instradamento della posta, e i record TXT contengono testo arbitrario, più comunemente usati ora per SPF, DKIM e stringhe di verifica del dominio. I record NS dicono al mondo quali server sono autoritativi per una zona, ed è il tipo di record che rende possibile la delegazione in primo luogo.

Dove la cache effettivamente risiede

La cache avviene su più livelli contemporaneamente: il browser stesso (Chrome ha la propria cache DNS visibile in chrome://net-internals/#dns), la cache del resolver del sistema operativo, il router locale, e il resolver ricorsivo a monte. Questo è il motivo per cui una modifica DNS può sembrare funzionare istantaneamente su un dispositivo e impiegare ore per comparire su un altro — non stai consultando la stessa cache.

Quando abbassi il TTL di un record prima di una migrazione pianificata, non stai accelerando nulla immediatamente. Stai semplicemente riducendo la finestra durante la quale i dati obsoleti possono persistere una volta che il cambiamento accade effettivamente. Fai questo almeno un ciclo TTL in anticipo, non cinque minuti prima del cutover.

Perché questo è importante per la risoluzione dei problemi

Quando un sito non è raggiungibile, dig +trace ti dice esattamente quale livello è rotto: un problema root/TLD appare completamente diverso da un server autoritativo mal configurato o una cache obsoleta sulla tua stessa macchina. Confrontando dig example.com con un resolver noto come funzionante, come dig example.com @1.1.1.1, isoli se il problema è il tuo resolver locale o l'effettiva configurazione DNS del dominio.

Il DNS sembra semplice dall'esterno perché di solito si risolve in meno di 100ms e nessuno ci pensa. Sotto la superficie, è un sistema di query distribuito, in cache e gerarchico che è rimasto largely unchanged nella struttura dagli anni '80, il che è un argomento piuttosto valido per quanto bene il design originale abbia retto.

Se vuoi approfondire ulteriormente, Korra Studio ha segmenti correlati su DEFENSE_GRID che coprono le estensioni di sicurezza DNS, il DNS tunneling come tecnica di esfiltrazione, e la costruzione del tuo resolver da zero in Python.