APNIC Labs: I client DNS rifiutano di accettare NXDOMAIN come risposta, inviando 4,4 query per nome

Quando un dispositivo chiede al Domain Name System (DNS) un nome che non esiste, il server autorevole invia una risposta negativa chiamata NXDOMAIN (codice di risposta DNS 3), che significa "nessun dominio di questo tipo". In teoria, un chiaro "no" dovrebbe bastare. Ma nuove misurazioni di APNIC Labs suggeriscono che milioni di client e resolver semplicemente rifiutano di accettare quella risposta al primo tentativo, inviando query ripetute e moltiplicando il carico sui server dei nomi. Questo comportamento è importante perché rende il DNS più fragile e aiuta a spiegare perché un particolare attacco denial-of-service, noto come attacco a nomi casuali, sia così efficace.

Un attacco a nomi casuali mira a inondare i server autorevoli di un dominio con query per nomi inesistenti casuali in quella zona. Poiché ogni query casuale è unica, i resolver con cache non possono servire le risposte dalla memoria, quindi ogni query raggiunge il server autorevole. Se l'attacco usasse un nome esistente costante, la cache del resolver proteggerebbe l'autorità; anche un nome inesistente costante verrebbe memorizzato nella cache dopo la prima risposta. Ma la casualità sconfigge completamente la cache. Se arrivano abbastanza query, il server diventa troppo occupato per rispondere alle richieste legittime e il dominio preso di mira può andare offline. A differenza di attacchi più sofisticati, un attacco a nomi casuali non richiede pacchetti costruiti o controllo privilegiato di bot; un semplice script su molte macchine compromesse può generare infinite etichette casuali sotto il dominio bersaglio.

Per capire perché funziona, APNIC Labs ha eseguito un esperimento incorporato in pubblicità online. Lo script pubblicitario generava una query DNS per un nome inesistente casuale i cui unici server autorevoli appartenevano al laboratorio. Il team ha poi osservato quante query arrivavano effettivamente a quei server. Nell'ottobre 2019, 60.210.983 misurazioni hanno prodotto 142.631.272 query DNS, una media di 2,37 query per nome unico. Quattro server sperimentali erano situati a Singapore, Francoforte, Dallas e San Paolo, e la maggior parte dei tempi di andata e ritorno era ben al di sotto del mezzo secondo, quindi il solo ritardo di rete non poteva spiegare l'alto tasso di ripetizione. All'epoca, il 24% dei client campionati aveva capacità IPv6 e le query HTTPS non erano in uso, quindi un comportamento ideale avrebbe prodotto circa 75 milioni di query, meno della metà del totale osservato.

Passiamo all'agosto 2026. Dal 5 all'11 agosto, lo stesso esperimento ha utilizzato un pool di 115.750.503 endpoint raccolti tramite una campagna Google Ads, provenienti da tutte le parti di Internet raggiunte da Google Ads, con la Russia come principale eccezione. Tutti i nomi DNS sono stati costruiti casualmente per prevenire hit nella cache, e i server autorevoli hanno restituito NXDOMAIN. La zona non era firmata con Domain Name System Security Extensions (DNSSEC), quindi le risposte non includevano record di prova NSEC o NSEC3. I server supportavano UDP e TCP ma non trasporti DNS crittografati come DNS over TLS o DNS over HTTPS. In quella settimana, APNIC Labs ha visto 509.410.787 query, ovvero una media di 4,40 query per nome di dominio unico. Questo è quasi il doppio della media del 2019.

L'aumento ha diverse componenti. Il 48% degli endpoint ha interrogato sia record A che AAAA, in aumento dal 23% del 2019, mentre il 51% ha chiesto solo record A, in calo dal 74%, e l'1% ha chiesto solo AAAA. Inoltre, il 39% degli endpoint ha generato una query per il record HTTPS. Se ogni tipo di query fosse inviato esattamente una volta, il totale sarebbe stato di 218 milioni di query. Le restanti 291 milioni di query, ovvero il 57% di tutte le ricerche osservate, provenivano da qualche forma di ripetizione. In media, ogni nome ripetuto è stato interrogato altre 2,5 volte. Ma le medie nascondono i dettagli: 67.316.541 endpoint hanno completato la risoluzione con non più di una query per tipo, mentre 48.433.962 endpoint sono stati responsabili di 291.919.927 query ripetute, con un tasso medio di ripetizione di 6,03 tra questi ripetitori.

Perché client e resolver ripetono una query dopo aver ricevuto una chiara risposta negativa? Parte della spiegazione risiede nel modo in cui sono costruiti i resolver stub dei client. Un resolver stub è la piccola libreria DNS all'interno di un dispositivo che invia query a un resolver ricorsivo. Poiché il DNS normalmente funziona su User Datagram Protocol (UDP), non c'è garanzia di consegna. Se un timer scade prima che arrivi una risposta, il resolver stub invia di nuovo la query, spesso a un resolver configurato diverso. La libreria del client Microsoft, ad esempio, usa un timer di un secondo per la prima ripetizione, poi due secondi, poi quattro secondi, e abbandona dopo cinque query e dieci secondi. I resolver ricorsivi hanno una logica di timeout simile e possono anche ri-interrogare i server autorevoli. La regola generale è che server che non rispondono provocheranno ulteriori query, ma queste ri-query non dovrebbero moltiplicarsi al punto da imporre un carico aggiuntivo significativo sul server. Se lo fanno, una singola query utente può trasformarsi in una tempesta, e un evento di carico transitorio può diventare un denial of service involontario.

La promessa originale di NXDOMAIN è che sia una risposta terminante e memorizzabile nella cache. Un resolver ricorsivo può memorizzare la risposta negativa per la durata del suo time to live (TTL) e rispondere a query ripetute per lo stesso nome localmente. Ma con nomi casuali, ogni query è nuova, quindi la cache non può aiutare. I dati del 2026 mostrano che dopo una risposta negativa, molti sistemi chiedono ancora, come se non credessero al server. Questo solleva la questione se NXDOMAIN sia il modo più efficiente per dire no nel DNS. APNIC Labs nota che esistono altre risposte negative, come NOERROR senza dati di risposta, ma il confronto sarà parte di uno studio separato.

La fonte tocca anche i problemi del chiedere se un nome esiste nel DNS. Ogni query DNS chiede un tipo di record specifico, come A per IPv4 o AAAA per IPv6. Il tipo di query ANY è stato storicamente trattato da alcuni server come una richiesta per tutti i record, ma ciò crea rischi di riflessione e amplificazione, specialmente con zone firmate DNSSEC. RFC 8482, Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY, raccomanda che i server rispondano alle query ANY con un record sintetico compatto come HINFO, o con record NS, invece di scaricare l'intera zona. Questo aiuta a limitare gli abusi e mantiene il DNS più robusto.

I risultati sono un promemoria che il DNS è costruito su una catena di fiducia e tentativi che può essere sfruttata quando un attaccante genera nomi inesistenti casuali. Per gli utenti internet comuni e i proprietari di siti web, il messaggio è di non dare per scontato che il DNS si comporti sempre in modo efficiente. Usare un resolver crittografato privacy-first come AEU DNS può proteggere le proprie ricerche da spoofing locale e sorveglianza, e la sua cache e il filtraggio aiutano a ridurre le query upstream non necessarie. Per chi gestisce domini, scegliere un provider DNS con rate limiting, distribuzione anycast e protezione DDoS è essenziale per sopravvivere a un'inondazione di nomi casuali.