Centinaia di query per un singolo dominio: il lavoro nascosto dietro una risoluzione DNS a freddo

Ogni volta che digiti un indirizzo web, un processo silenzioso chiamato risoluzione DNS traduce quel nome in un indirizzo IP leggibile dalla macchina. Normalmente, gran parte di questo lavoro è invisibile perché il tuo resolver locale tiene una memoria temporanea, una cache, delle ricerche recenti. Ma cosa succede quando quella cache è vuota? Questo cosiddetto stato di avvio a freddo costringe il resolver a riscoprire da zero l'intera catena di informazioni, e come mostra una nuova ricerca presentata all'incontro RIPE 92 da Ondřej Surý dell'Internet Systems Consortium, il costo può variare drasticamente da poche query a diverse centinaia.

Per apprezzare la scala, considera un semplice esempio: il dominio www.potaroo.net. Usando un resolver ricorsivo BIND versione 9.20.23 senza dati in cache, la risoluzione richiede solo quattro query. Il resolver inizia chiedendo a un server radice (i cui indirizzi sono preconfigurati) i nameserver della zona radice, un aggiornamento che restituisce anche gli indirizzi IP attuali per quei server radice. Successivamente interroga uno di questi server per i nameserver del dominio di primo livello .net. Una terza query va a un server .net per conoscere i nameserver di potaroo.net, e la query finale richiede l'indirizzo IP di www.potaroo.net stesso. Poiché ogni etichetta nel nome corrisponde a un punto di delega, un passaggio da una zona all'altra, quattro query sono il minimo teorico. Il resolver usa una tecnica chiamata minimizzazione del nome della query, che chiede solo il prossimo pezzo di informazione necessario, ma anche un approccio più diretto produrrebbe lo stesso numero di passaggi.

Passa a un nome più complesso come teams.microsoft.com e il quadro cambia drasticamente. I test di Surý hanno trovato che un resolver BIND 9.16 richiedeva 247 query per eseguire la stessa risoluzione a freddo. La versione 9.20 ha ridotto a 94 query, e la versione 9.21 ha ulteriormente ridotto a sole 29. La causa principale risiede in una catena di quattro record CNAME, alias che dicono al resolver "questo nome punta a un altro nome, vai a cercare quello". Ogni CNAME effettivamente riavvia il processo di risoluzione, e poiché i target attraversano diversi domini di primo livello (office.com, poi un dominio .net), il resolver deve ripetutamente riattraversare l'albero DNS dalla radice. Lunghe catene CNAME, specialmente quelle che saltano tra zone non correlate, moltiplicano il lavoro.

Un altro fattore è la gestione degli indirizzi dei nameserver. Quando una zona padre delega un sottodominio, fornisce i nomi dei server autoritativi, ma non direttamente i loro indirizzi IP. Per evitare un problema dell'uovo e della gallina, il padre spesso include record glue: indirizzi IP forniti nella sezione aggiuntiva della risposta. Il glue è obbligatorio quando il nome del nameserver cade all'interno della zona delegata (in-baliwick), perché senza di esso la risoluzione si bloccherebbe. Per i nameserver che sono fratelli, che condividono lo stesso dominio padre ma sono fuori dalla zona delegata, fornire glue è opzionale. Storicamente, i resolver potevano fidarsi di questo glue fratello, ma una vulnerabilità di avvelenamento della cache scoperta in BIND (CVE-2025-40778) ha portato a cambiamenti dalla versione 9.20.14 in poi: il glue fratello ora viene ignorato, costringendo il resolver a cercare indipendentemente quegli indirizzi IP. Questo aggiunge query extra ma chiude una falla di sicurezza.

Oltre al glue, i progettisti di resolver affrontano una scelta strategica. Un approccio è risolvere completamente ogni nome di nameserver, caricando la cache con tutti gli indirizzi IP sia per IPv4 che per IPv6. Questo costruisce resilienza, se un server fallisce, le alternative sono immediatamente disponibili. Tuttavia, con lunghe catene CNAME e molti nameserver fuori-baliwick, il numero di query esplode. L'approccio opposto risolve un solo nameserver, o anche una sola famiglia di indirizzi, e ripiega solo in caso di fallimento. Questo accelera le prestazioni a freddo e riduce il carico complessivo di query, ma rischia timeout se il server scelto è lento o irraggiungibile.

Una decisione correlata è se fidarsi dei dati di delega del padre o verificarli interrogando la zona figlia stessa. BIND 9.21.20 è passato a un modello incentrato sul padre, affidandosi alla lista di nameserver del padre senza eseguire una query extra al figlio. Il ragionamento è pragmatico: se i dati del padre sono stati manomessi, il resolver è già stato dirottato prima che qualsiasi query al figlio possa aiutare. Per una garanzia più forte, DNSSEC, un sistema che firma crittograficamente i record DNS, offre una difesa più robusta, anche se aggiunge il suo overhead. Nell'esempio potaroo.net, la validazione DNSSEC ha richiesto due query aggiuntive per i record DNSKEY; con catene CNAME, il lavoro extra scala con il numero di etichette di ogni alias.

Cosa possono fare gli operatori di zona per alleggerire il carico? La presentazione di Surý ha offerto una guida chiara. Quando possibile, usa nomi di nameserver che stanno all'interno del dominio che servono (in-baliwick), così il glue è garantito e la risoluzione è efficiente. Google.com è un caso da manuale: tutti i suoi nameserver finiscono in google.com. Evita di distribuire i nomi dei nameserver su molti domini di primo livello, una pratica che costringe i resolver a inseguire indirizzi IP attraverso più zone. Mantenere semplice l'infrastruttura DNS non solo aiuta le prestazioni ma rimuove anche punti di fallimento inutili.

Per gli utenti di tutti i giorni, la complessità della risoluzione a freddo è in gran parte invisibile perché le cache la nascondono. Tuttavia i principi di progettazione contano: un resolver troppo aggressivo può sprecare risorse, mentre uno che taglia gli angoli può lasciarti con ricerche lente o fallite. Usare un servizio DNS che combina caching intelligente con forti pratiche di sicurezza aiuta sia velocità che sicurezza. Un resolver DNS crittografato incentrato sulla privacy come AEU DNS crittografa le tue query end-to-end, impedendo agli intercettatori di vedere quali siti visiti, mentre la sua politica senza log garantisce che anche l'operatore del resolver non registri la tua attività. Scegliendo un resolver che rispetta gli standard moderni, minimizzazione delle query, gestione attenta del glue e validazione DNSSEC, ottieni protezione senza sacrificare le prestazioni.