Le risposte DNS negative causano query ripetute, secondo i dati APNIC

Il Domain Name System (DNS), il protocollo che trasforma i nomi di dominio in indirizzi IP numerici usati dai computer per connettersi, gestisce ogni giorno un numero enorme di risposte 'no'. Una nuova discussione sul podcast PING del blog APNIC, pubblicata il 17 settembre 2026, mostra che il modo esatto in cui un server DNS fornisce quel 'no' può cambiare in modo significativo il carico di lavoro per la rete nel suo complesso.

Nell'episodio, il Chief Scientist di APNIC Geoff Huston e l'autore del blog George Michaelson proseguono una conversazione sulle query ripetute osservate nell'esperimento di misurazione di APNIC Labs. APNIC Labs è il braccio di ricerca e misurazione di APNIC, il Regional Internet Registry per l'Asia Pacifico. Huston e Michaelson riferiscono che il numero di query ripetute è cambiato nel tempo man mano che cambiava l'uso dei protocolli DNS. Record DNS che non esistevano quando il problema è stato osservato per la prima volta ora compaiono, creando più query su più cose per quella che sembra una singola ricerca.

Huston esplora due aspetti del comportamento del DNS. Il primo è come i diversi modi di rispondere 'no' influenzino il volume delle query e la quantità di lavoro richiesta dai server autoritativi (i server che detengono la copia ufficiale dei record di un dominio), dai resolver intermedi (i server che cercano le risposte per conto dei client e memorizzano i risultati nella cache) e dai client (i dispositivi o le applicazioni che effettuano la richiesta). Le risposte negative comuni includono NXDOMAIN (il nome non esiste) e NODATA (il nome esiste ma non ha un record del tipo richiesto), e un server può anche semplicemente non rispondere affatto. Huston afferma che i risultati sono talvolta sorprendenti, con modi diversi di dire no che portano a esiti molto diversi.

I resolver in genere memorizzano nella cache sia le risposte positive che quelle negative per un periodo stabilito dal server autoritativo. Il modo in cui viene espressa una risposta negativa può cambiare per quanto tempo quella risposta in cache è considerata valida, e quindi con quale frequenza client e resolver devono porre di nuovo la stessa domanda. Le misurazioni di Huston mostrano che queste scelte hanno conseguenze reali sul carico di lavoro.

Il secondo aspetto è l'impatto che i protocolli di trasporto DNS alternativi potrebbero avere sulla ripetizione delle query e sul carico complessivo delle query. Gran parte di questa ripetizione può essere una conseguenza dell'User Datagram Protocol (UDP), un trasporto senza connessione che invia dati in messaggi individuali senza prima stabilire una sessione, quindi una risposta persa non viene ritrasmessa automaticamente e il client deve chiedere di nuovo. Molti ingegneri hanno sostenuto che il sovraccarico di mantenere lo stato di connessione per TCP (Transmission Control Protocol, un trasporto orientato alla connessione che stabilisce un canale affidabile) e protocolli simili li rendesse inadatti al DNS su larga scala. Tuttavia, man mano che il volume di query ripetute inutili continua a crescere, è possibile che, end-to-end, mantenere lo stato del protocollo possa effettivamente richiedere meno lavoro rispetto a gestire ripetutamente le stesse query.

Per gli utenti Internet di tutti i giorni, questi risultati contano perché le query DNS ripetute possono aggiungere ritardo e carico di rete. Un servizio DNS cifrato attento alla privacy come AEU DNS, che offre DNS over HTTPS e DNS over TLS, può proteggere le singole query dall'osservazione sul percorso e offre agli utenti un resolver con una chiara politica sulla privacy pubblicata. Questo non elimina la ripetizione delle query a livello di protocollo descritta da Huston, ma mantiene riservate le query stesse e consente agli utenti di scegliere un resolver che si impegna a non registrare né profilare la loro navigazione.

Il post sul blog APNIC indirizza inoltre i lettori a un articolo più lungo di Geoff Huston sul blog APNIC, 'What part of No is so hard for DNS to understand?', che esamina il problema con maggiori dettagli di misurazione. L'episodio del podcast stesso è disponibile tramite Apple Podcasts, Spotify, YouTube, iHeartRadio, JioSaavn, Gaana e RSS.