Cloudflare accelera il DNS: -85% di memoria e modifiche in 3 secondi

Modificare un record DNS è un’operazione che richiede pochi secondi: assicurarsi che la modifica raggiunga correttamente migliaia di server distribuiti nel mondo è tutt’altra faccenda. Cloudflare ha riprogettato una parte fondamentale della sua infrastruttura DNS, ottenendo risultati significativi: 85% di memoria in meno nei picchi di utilizzo e tempi mediani di elaborazione delle modifiche ridotti da 7,7 a circa 3,3 secondi. Il miglioramento non deriva dall’introduzione di hardware più potente, ma da una revisione del modo in cui la piattaforma individua, prepara e distribuisce i dati DNS.

La questione interessa da vicino chiunque gestisca domini, applicazioni Web e servizi online. Il Domain Name System (DNS) associa i nomi di dominio alle informazioni necessarie per raggiungere i servizi Internet; quando un amministratore modifica un indirizzo IP, aggiunge un sottodominio o interviene sulle impostazioni di una zona DNS, i server autorevoli devono disporre di informazioni aggiornate. Un ritardo nella loro distribuzione può tradursi in risposte differenti a seconda del server interrogato.

La soluzione Cloudflare: ricostruire soltanto ciò che cambia

Come accennato in precedenza, la modifica di un record DNS è ben diversa dalla preparazione dei dati che i server DNS poi andranno a usare.

Cloudflare affida tale attività a un componente denominato Zone Builder, che legge le informazioni dai database, applica le regole di pubblicazione e produce una rappresentazione ottimizzata.

La società guidata da Matthew Prince ha introdotto un targeted build planner, componente che determina quali informazioni debbano essere rigenerate in seguito a ogni evento: l’obiettivo consiste nell’individuare il lavoro minimo compatibile con la correttezza del risultato.

Le 5 categorie d’intervento

Il nuovo sistema distingue 5 categorie di intervento, ciascuna delle quali determina quali informazioni DNS debbano essere aggiornate e quanto lavoro sia necessario eseguire:

1. Ricostruzione delle singole risorse DNS (Resource-only build): quando cambia un record A, AAAA, TXT o CNAME, il sistema aggiorna soltanto i dati relativi al nome DNS interessato. Per esempio, se cambia l’indirizzo IP associato a www.example.com, non occorre rielaborare gli altri record della zona. È l’operazione più circoscritta e generalmente meno costosa.
2. Ricostruzione delle risorse e dei metadati (Resource + metadata build): alcune modifiche non riguardano soltanto un record, ma anche le informazioni utilizzate dai server DNS per interpretare correttamente la zona. È il caso, ad esempio, di determinati aggiornamenti ai nameserver o ai record wildcard (*.example.com). Il sistema rigenera quindi sia le risorse interessate sia i metadati condivisi, senza ricostruire l’intera zona.
3. Ricostruzione dell’apex e dei metadati (Apex + metadata build): interessa le modifiche che coinvolgono il dominio principale, ad esempio example.com, anziché i suoi sottodomini. L’attivazione o la disattivazione di Universal SSL può richiedere un aggiornamento dei record CAA, che stabiliscono quali autorità di certificazione sono autorizzate a emettere certificati per il dominio. In questi casi basta rigenerare i dati dell’apex e i metadati pertinenti, evitando di elaborare tutti i record DNS.
4. Rimozione della zona (Zone removal): quando una zona non deve più risultare pubblicata, il sistema elimina le informazioni che la rendono disponibile ai server DNS autorevoli. L’operazione comprende anche l’aggiornamento dei metadati condivisi, affinché i server non continuino a considerare valida una zona ormai rimossa.
5. Ricostruzione completa (Full zone build): il sistema rielabora l’intera zona DNS, compresi record e metadati. È l’operazione più impegnativa in termini di memoria e capacità di calcolo, ma rimane necessaria quando una modifica può interessare numerose risorse oppure quando le informazioni disponibili non permettono di stabilire con certezza quali dati aggiornare.

La regola adottata dagli ingegneri Cloudflare è particolarmente rigorosa: ogni chiave generata da una ricostruzione mirata deve essere identica, byte per byte, a quella ottenuta attraverso una ricostruzione completa. L’ottimizzazione, insomma, non deve modificare il risultato. Se il sistema non può garantire tale equivalenza, privilegia la ricostruzione completa, salvo i casi eccezionali delle zone talmente grandi da rendere impraticabile l’operazione.

Come Cloudflare gestisce gli aggiornamenti DNS senza perdere modifiche

Ridurre il numero di operazioni necessarie per aggiornare una zona DNS non basta: bisogna anche sapere esattamente cosa è cambiato ed evitare che modifiche successive si sovrappongano o vadano perse.

Cloudflare ha quindi migliorato il sistema di notifiche, che ora comunica quali impostazioni o record sono cambiati e, quando possibile, i valori precedenti e quelli nuovi. In questo modo lo Zone Builder può individuare le informazioni da aggiornare senza ricostruire l’intera zona. Se una notifica non contiene dettagli sufficienti, il sistema ricorre comunque alla ricostruzione completa, tranne nel caso di zone talmente grandi da rendere l’operazione impraticabile: in queste circostanze aggiorna soltanto il dominio principale, i metadati e i nomi DNS identificati dagli eventi disponibili.

Un’ulteriore complicazione nasce quando più zone condividono lo stesso nome di dominio, ad esempio durante una migrazione: Cloudflare deve assicurarsi che i server DNS utilizzino gli identificativi corretti e che i record siano disponibili prima di pubblicare i metadati che li richiamano.

Per coordinare tutte le operazioni è stato introdotto uno scheduler unificato, capace di raggruppare più modifiche alla stessa zona in un’unica elaborazione, rispettando però le dipendenze tra gli aggiornamenti. Il sistema sfrutta Apache Kafka per gestire le notifiche e conferma il completamento dei messaggi soltanto quando tutte le operazioni precedenti risultano concluse: se un processo si interrompe, qualche aggiornamento potrebbe essere ripetuto, ma non deve andare perso.

Infine, per evitare di pubblicare informazioni superate, lo Zone Builder verifica lo stato effettivo della zona prima di procedere e controlla che le repliche del database abbiano già ricevuto le modifiche segnalate. Kafka e database possono non aggiornarsi nello stesso istante: senza tale verifica, una notifica potrebbe arrivare prima dei dati corrispondenti, causando la pubblicazione di record DNS non aggiornati.

I risultati: memoria ridotta dell’85% e ritardi DNS dimezzati

Le misurazioni pubblicate da Cloudflare, relative a una finestra di 24 ore, mostrano che l’86,81% delle elaborazioni interessa soltanto risorse specifiche. Un ulteriore 2,54% coinvolge risorse e metadati, mentre il 2,30% riguarda apex e metadati. Le rimozioni rappresentano l’1,30% e le ricostruzioni complete appena il 7,04%.

Complessivamente, il 92,95% delle elaborazioni evita una ricostruzione integrale. Rispetto all’approccio precedente, il numero di full build diminuisce di circa il 40%, con un beneficio particolarmente significativo per le zone più grandi.

Il consumo medio aggregato di memoria dello Zone Builder è sceso da 49 GB a 7 GB, con una riduzione dell’86%; nei picchi si passa da 79 GB a 12 GB, pari a circa l’85% in meno. È migliorata anche la gestione dei ritardi più estremi: gli eventi più lenti hanno molte meno probabilità di accumulare attese prolungate.

Il lavoro di Cloudflare mostra che una parte importante delle prestazioni DNS dipende da operazioni che precedono la distribuzione effettiva delle informazioni. Ridurre la quantità di dati da elaborare, gestire correttamente gli eventi concorrenti e impedire che una singola zona rallenti quelle degli altri clienti può produrre benefici superiori a un aumento delle risorse hardware.