Cloudflare riduce di 100 TB la memoria di 1.1.1.1 riprogettando la cache DNS

In un post tecnico pubblicato il 27 agosto 2026, l'ingegnere di Cloudflare Sebastiaan Neuteboom ha descritto come l'azienda ha liberato circa 100 terabyte di memoria rielaborando il modo in cui il suo resolver DNS pubblico 1.1.1.1 memorizza le risposte in cache. Il cambiamento è stato invisibile agli utenti, ma è un chiaro esempio di come piccole inefficienze nel codice possano trasformarsi in costi enormi quando vengono moltiplicate su una rete globale.

Per capire il risultato, è utile sapere cosa fa un resolver DNS. Il Domain Name System, o DNS, è l'elenco telefonico di Internet: quando digiti il nome di un sito web, un resolver come 1.1.1.1 cerca l'indirizzo numerico corrispondente e lo invia al tuo dispositivo. Poiché questo avviene per miliardi di query ogni giorno, i resolver mantengono una cache DNS, una memoria temporanea delle risposte recenti, per non dover ripetere la ricerca completa ogni volta. Questa cache è una delle parti del servizio che consuma più memoria, e il modo in cui è organizzata nella RAM influisce direttamente su velocità, costi e affidabilità.

Il resolver 1.1.1.1 di Cloudflare è scritto in Rust, un linguaggio di programmazione noto per sicurezza e prestazioni. Ogni elemento in cache è rappresentato da una coppia di strutture: una chiave che identifica la ricerca e un valore chiamato CacheEntry che memorizza la risposta stessa. La CacheEntry mostrata nel post contiene un timestamp, un tempo di inizio, un valore Time-to-Live (TTL), un contatore di hit e tre liste di record DNS per le sezioni risposta, autorità e aggiuntive, più campi per i dati di errore. Ognuna di queste liste è un Vec, l'array dinamico standard di Rust. Un Vec memorizza tre cose: un puntatore ai dati, la lunghezza corrente della lista e la capacità, ovvero lo spazio totale già allocato. La capacità è spesso maggiore della lunghezza perché l'array cresce a blocchi, e questo spazio extra, insieme ai campi puntatore e lunghezza, aggiunge overhead a ogni singola voce.

Il team ha capito che diversi tipi di campo portavano più overhead del necessario una volta memorizzata una voce. Ad esempio, i timestamp e altri metadati possono essere contenuti in forme più piccole e compatte quando non hanno più bisogno della flessibilità dei tipi originali. Passando a rappresentazioni più snelle e ristrutturando le liste, hanno ridotto sostanzialmente il costo di memoria per voce. Questo si applicava sia alla chiave della cache sia al valore della cache, e i risparmi sono arrivati senza sacrificare le informazioni necessarie per servire correttamente le risposte.

Per misurare ogni ottimizzazione, Cloudflare ha creato un benchmark che riempie la cache con voci generate casualmente che corrispondono al mix di traffico visto in produzione: 56% record A, i record classici che mappano i nomi agli indirizzi IPv4; 25% record AAAA, che mappano i nomi agli indirizzi IPv6; e 19% record TXT, che contengono testo arbitrario e rappresentano tutti gli altri tipi di risposta a lunghezza variabile nel test. Ogni voce contiene tra uno e quattro record, e i record TXT sono randomizzati tra 64 e 224 byte, vicini alla dimensione media delle risposte per quella categoria. Il benchmark tiene traccia dell'uso della memoria attraverso un allocatore personalizzato che avvolge l'allocatore di sistema di Rust e registra il numero e la dimensione di ogni allocazione per voce di cache. Allo stesso tempo, misura la velocità di inserimento e la latenza di ricerca nell'intero flusso di cache, assicurando che il risparmio di memoria non sia avvenuto a scapito di query più lente.

Il risultato è stato una riduzione di circa 100 terabyte nelle istanze di produzione. Il team ha anche verificato il miglioramento osservando la memoria residente, la RAM effettivamente in uso, durante un'implementazione graduale. Un'impronta più piccola per voce significa che la stessa memoria fisica può contenere più risposte in cache, il che migliora i tempi di risposta per gli utenti e può ritardare la necessità di aggiungere altri server. Anche pochi byte risparmiati per voce diventano enormi quando moltiplicati per miliardi di nomi in cache e migliaia di macchine.

Per i lettori che si affidano a un servizio DNS privato e crittografato come AEU DNS, questo è il tipo di ingegneria che aiuta a mantenere le ricerche veloci, affidabili e compatibili con un rigoroso approccio senza log, perché una cache ben progettata memorizza solo ciò che serve e niente di più. L'ottimizzazione mostra anche che il lavoro più efficace sulle prestazioni spesso avviene fuori dalla vista, nel codice di basso livello che gli utenti non vedono mai ma che sentono ogni volta che una pagina si carica velocemente.