Copie locali della zona radice DNS possono aumentare il traffico del resolver, secondo i ricercatori

Un progetto di ricerca discusso nel podcast APNIC PING del 3 settembre 2026 ha scoperto che servire localmente la zona radice DNS può, in alcune configurazioni, generare più traffico di rete rispetto alle query ordinarie che dovrebbe ridurre. Il lavoro è stato condotto da Ilyas Rahimi, che ha recentemente completato un Master in Security and Network Engineering presso l'Università di Amsterdam (UvA), e Willem Toorop di NLnet Labs. Ilyas ha completato il programma Master OS3 presso l'UvA, che prende il nome dal suo focus su Open Standards, Open Software e Open Security. NLnet Labs ha sede nel campus dell'UvA e Willem ha collaborato strettamente con il programma per molti anni, supervisionando la ricerca degli studenti su DNS e DNSSEC durante la componente di tesi del Master. Come parte del programma, gli studenti svolgono due progetti di ricerca originali della durata di un mese, con il secondo che costituisce la base della loro tesi di Master.

La zona radice DNS si trova all'apice della gerarchia DNS. In termini quotidiani, il DNS, o Domain Name System, è la rubrica di Internet che trasforma i nomi di dominio leggibili dall'uomo in indirizzi leggibili dalla macchina. La zona radice è la lista di livello superiore di tutte le desinenze dei nomi di dominio, come .com, .org e le desinenze dei codici paese. Un resolver DNS è il server o programma che esegue queste ricerche per conto dei tuoi dispositivi. Normalmente, un resolver interroga i server radice per informazioni su quale dominio di primo livello interrogare successivamente. La radice servita localmente è un modello di resolver che pre-carica e memorizza una copia di questa zona radice. Avere una copia locale consente ai resolver di terminare rapidamente le query per domini di primo livello inesistenti e può fornire alcuni vantaggi in termini di privacy riducendo la necessità di interrogare i server radice per nomi risolvibili. C'è una proposta attuale nell'IETF, la Internet Engineering Task Force, per rendere questa una Best Current Practice, cioè un modo raccomandato di fare qualcosa su Internet.

Ilyas ha esaminato tre codebase di resolver pubblici, BIND, Unbound e Knot Resolver, in quattro diverse configurazioni. La sua ricerca ha esplorato sia il recupero in banda della zona radice, cioè il resolver recupera la zona attraverso il proprio meccanismo DNS, sia il recupero tramite HTTPS, la versione crittografata del protocollo web. Questi sono i due metodi principali che un resolver può utilizzare per ottenere una copia della zona radice. La scelta del software resolver e del metodo di recupero è importante perché ogni implementazione gestisce la zona in modo diverso, e queste differenze si manifestano nel traffico di rete reale.

Le misurazioni hanno prodotto due risultati notevoli. In primo luogo, Ilyas ha identificato un bug in Unbound che causava un picco di traffico. Unbound è un resolver DNS open source ampiamente utilizzato, quindi un bug che causa traffico extra può influenzare molte reti. In secondo luogo, ha scoperto che il ciclo di aggiornamento della zona radice può generare una quantità sorprendentemente grande di traffico di rete quando si recupera la zona. In alcuni casi, questo ha superato il traffico associato alle query molto più frequenti ma molto più piccole inviate ai server radice per dati non memorizzati nella cache. In altre parole, il download periodico di una copia completa della zona radice può superare i risparmi derivanti dal non inviare molte piccole ricerche. Il compromesso dipende da quanto spesso il resolver aggiorna la zona e da come la recupera.

C'è ancora molto lavoro da fare in quest'area. Con la componente di tesi del Master OS3 ora allocata con più tempo all'interno del programma di laurea, Willem spera di continuare a collaborare con gli studenti dell'UvA ed estendere il lavoro di misurazione. Ha anche esplorato come il sistema si comporta quando si utilizzano aggiornamenti incrementali della zona, noti come IXFR, piuttosto che recuperare l'intera zona radice ogni volta. IXFR trasferisce solo le parti modificate di una zona DNS, il che potrebbe ridurre la quantità di dati trasferiti durante ogni aggiornamento. La fonte indica anche ulteriori letture: la tesi di Master di Ilyas Rahimi intitolata "Local root serving by default: Quantifying the traffic trade-off", una presentazione che Ilyas ha fatto sulla sua tesi presso NLnet Labs, una bozza IETF BCP di Warren Kumari chiamata "Populating resolvers with the root zone", un esempio di stati radice firmati incrementalmente in un repository git di Willem Toorop su codeberg, e il documento RSSAC 02 "Measurements of the Root Server System" di ICANN.

Per gli utenti Internet di tutti i giorni e le aziende che scelgono un resolver DNS, questa ricerca mostra che il comportamento del resolver non è neutro. Qualcosa che sembra efficiente, come mantenere una copia locale della zona radice, può avere costi di traffico inaspettati a seconda di come viene implementato e aggiornato. È un promemoria che il software dietro le tue ricerche DNS dovrebbe essere mantenuto aggiornato, perché i bug possono causare carico extra anche quando l'idea è valida. Per i lettori che desiderano un resolver privato e sicuro per progettazione, un servizio DNS crittografato privacy-first come AEU DNS offre DNS over HTTPS, TLS e QUIC con una politica di non registrazione dei log, così le tue query rimangono confidenziali mentre l'operatore gestisce gli aggiornamenti della zona radice dietro le quinte. Questo ti dà il vantaggio di un resolver gestito con cura senza dover regolare gli intervalli di aggiornamento della zona o fare debug del software resolver da solo.