CNAME prima di A? Il bug nell'ordine dei record DNS che ha mandato in crash gli switch Cisco

Il 14 gennaio 2026, Cloudflare ha pubblicato un post mortem su un bug nel suo resolver DNS pubblico 1.1.1.1 che ha causato l'elenco di alcuni record CNAME dopo la risposta finale del record A invece che prima. Per chi non ha familiarità con questi termini, il Domain Name System (DNS) è l'elenco telefonico di Internet che trasforma nomi leggibili come www.example.com in indirizzi IP numerici che i computer usano per connettersi. Un record CNAME è come un indirizzo di inoltro, che dice che un nome è un alias per un altro, mentre un record A fornisce l'indirizzo IP numerico finale. Un resolver è il server che riceve la tua richiesta e segue questi passaggi di inoltro fino a trovare il record A.

Il bug è emerso da un'ottimizzazione delle prestazioni. Nel tentativo di risparmiare alcune allocazioni di memoria e copie, gli ingegneri di Cloudflare hanno modificato il codice del resolver per aggiungere i record CNAME a una lista di risposte esistente invece di inserirli all'inizio. Di conseguenza, le risposte a volte posizionavano le voci CNAME in fondo alla sezione delle risposte, dopo il record A risolto. Molti programmi client DNS assumono un ordine specifico quando leggono una risposta. Iniziano cercando i record che corrispondono al nome di query originale, poi quando vedono un CNAME, aggiornano il nome che stanno cercando e continuano lungo la lista. Se il CNAME appare dopo il record A finale, il client vede prima il record A per l'alias, lo ignora perché non corrisponde al nome originale previsto, poi vede il CNAME e aggiorna il nome previsto, ma a quel punto non ci sono più record, quindi il client pensa che la risposta sia vuota.

Una implementazione prominente che si è rotta è stata la funzione getaddrinfo in glibc, una libreria software fondamentale usata su molti sistemi Linux per la risoluzione DNS. La sua routine interna getanswer_r si aspetta che i record CNAME vengano prima di qualsiasi record di indirizzo; quando l'ordine è stato invertito, non è riuscita a restituire la risposta, causando errori di risoluzione dei nomi. L'impatto non è stato limitato al software sui computer ordinari. Cloudflare ha dichiarato che il processo DNSC in tre modelli di switch Ethernet Cisco ha subito loop di riavvio spontanei quando questi switch erano configurati per usare 1.1.1.1 e ricevevano una risposta con CNAME riordinati. Cisco ha pubblicato un documento di servizio che descrive il problema. Non tutti i client DNS sono colpiti. Cloudflare ha notato che systemd-resolved, comune sulle moderne distribuzioni Linux, analizza prima tutti i record di risposta in un insieme ordinato e può cercare nell'intero insieme quando segue una catena CNAME, quindi l'ordine non ha importanza per esso.

Gli standard stessi hanno lasciato spazio a questa confusione. La specifica DNS fondamentale, RFC 1034, pubblicata nel 1987, dice che una risposta ricorsiva può includere la risposta alla query, possibilmente preceduta da uno o più record CNAME. La parola "preceduta" suggerisce che i CNAME dovrebbero venire prima, ma RFC 1034 non usa il linguaggio normativo che gli standard moderni usano, come MUST o SHOULD. Quel linguaggio è stato standardizzato solo più tardi, in RFC 2119, pubblicata nel 1997. Un'ulteriore sottigliezza è la differenza tra un Resource Record Set (RRset) e la sezione di risposta complessiva. RFC 1034 dice che l'ordine dei record all'interno di un RRset, che è un gruppo di record con lo stesso nome, tipo e classe, non è significativo. Ma la specifica non afferma chiaramente come dovrebbe essere ordinata una sezione di risposta contenente più RRset. Le specifiche DNS moderne hanno mostrato che una sezione di messaggio può contenere più RRset, ad esempio nelle risposte DNSSEC, ma il testo più vecchio era ambiguo.

Il post mortem di Cloudflare nota che il resolver originariamente implementava la specifica correttamente, con i CNAME per primi, ma non c'erano test automatizzati che affermassero quel comportamento. L'ottimizzazione delle prestazioni che ha risparmiato memoria ha inavvertitamente cambiato l'ordine, e poiché il linguaggio RFC non era rigoroso, la regressione è passata inosservata finché utenti reali e dispositivi hanno iniziato a fallire. Questo incidente evidenzia una lezione più ampia: anche resolver pubblici ampiamente utilizzati e ben gestiti possono incontrare casi limite nelle vecchie specifiche di protocollo, e la mancanza di requisiti normativi espliciti combinata con una copertura di test insufficiente può permettere a bug sottili di raggiungere la produzione.

Per gli utenti Internet di tutti i giorni, le aziende e i team IT, la storia è un promemoria che il DNS è una parte fondamentale di quasi ogni attività online, e la sua affidabilità dipende sia dal client che dal server che interpretano correttamente standard vecchi di decenni. Un servizio DNS attento alla privacy come AEU DNS, che offre query DNS crittografate per aiutare a prevenire lo snooping e la manomissione, ha anche la responsabilità di gestire correttamente questi dettagli di protocollo, perché un resolver che restituisce record in un ordine inaspettato può rompere la connettività con la stessa efficacia di uno che è giù. La migliore difesa è mantenere aggiornati i tuoi dispositivi e le apparecchiature di rete, usare un resolver con manutenzione e test attivi, e capire che anche ottimizzazioni apparentemente minori possono avere conseguenze nel mondo reale.