Record DNS Cloudflare con la modifica di un singolo elemento.
Internet / La storia

Cloudflare accelera le modifiche DNS ricostruendo meno dati

La ricostruzione mirata riduce tempi di preparazione e memoria. I risultati riguardano la pipeline interna, senza annullare le cache dei resolver.

GeekRadarData della notizia Pubblicato 3 min di lettura

Cloudflare dichiara di avere circa dimezzato il tempo necessario a preparare le modifiche DNS per il proprio sistema di distribuzione, evitando ricostruzioni inutili di zone enormi. Nel resoconto tecnico la mediana del ritardo di completamento scende da circa 7,7 a 3,3 secondi, mentre il picco di memoria utilizzata diminuisce dell’85%. Sono misure della catena di aggiornamento: non significano che ogni richiesta DNS o risposta nella cache diventi due volte più veloce.

La distinzione è centrale. Il fornitore deve trasformare una modifica di configurazione in dati utilizzabili dai server autoritativi. Accelerare quella preparazione rende i cambiamenti pronti prima, ma non modifica retroattivamente la durata delle risposte già conservate nelle cache esterne.

Lo schema Cloudflare segue modifiche a record e impostazioni attraverso Kafka, il zone builder e Quicksilver.
Lo schema Cloudflare segue modifiche a record e impostazioni attraverso Kafka, il zone builder e Quicksilver.

Piccole modifiche avviavano lavori enormi

Una zona DNS raccoglie record e impostazioni associati a un dominio. Il componente Zone Builder di Cloudflare legge lo stato del database, lo converte nel formato richiesto dall’infrastruttura e scrive le chiavi modificate in Quicksilver, il sistema di archiviazione distribuito.

Il vecchio percorso completo era semplice: leggere tutti i record, calcolare lo stato desiderato e confrontarlo con quello archiviato. Anche quando cambiavano poche chiavi finali, il processo leggeva e trasformava tutta la zona. Il costo diventa importante quando alcune zone superano i 20 milioni di record.

Il nuovo pianificatore cerca invece il lavoro minimo che rimane corretto. Una modifica a un normale record di indirizzo può riguardare un solo nome DNS. Nameserver, wildcard e metadati condivisi possono richiedere operazioni più ampie. Una zona pubblicata per la prima volta può ancora aver bisogno di una ricostruzione completa. L’ottimizzazione dipende dalla comprensione delle conseguenze, non dal saltare record solo perché sono numerosi.

Il problema difficile è restare corretti

Durante alcuni cambiamenti del ciclo di vita, più oggetti interni possono condividere temporaneamente lo stesso dominio pubblico. Record e metadati devono concordare su quali dati possano essere serviti. Un aggiornamento che scrive meno chiavi ma lascia sbagliato l’elenco delle zone pubblicate sarebbe rapido e scorretto.

Cloudflare descrive quindi una pianificazione basata sull’evento seguita da un nuovo controllo dello stato prima dell’esecuzione. Gli eventi sconosciuti o descritti in modo insufficiente mantengono generalmente la ricostruzione completa. Esiste un’eccezione dichiarata per zone troppo grandi per entrare in memoria: vengono gestite con interventi mirati e ulteriori cautele operative, invece di riprovare senza fine un lavoro impossibile da completare.

L’azienda ha confrontato i risultati con quelli delle ricostruzioni complete e utilizzato una catena parallela che legge eventi reali ma scrive in un archivio separato. Il confronto campionava il 20% delle zone, distinguendo gli errori persistenti dalle differenze temporanee dovute a elaborazioni concluse in momenti diversi.

Il risparmio permette di ridurre anche le attese

In una misurazione di 24 ore, il 92,95% delle elaborazioni ha evitato di ricostruire l’intera zona. Il picco di memoria è passato da 79 a 12 GiB. Lavori meno costosi e una migliore gestione del ritardo delle repliche del database hanno permesso di accorciare anche alcuni intervalli di attesa protettivi.

La mediana riportata riflette quindi sia elaborazioni più circoscritte sia attese inferiori. Cloudflare segnala inoltre che gli intervalli troppo larghi di alcuni istogrammi rendevano imprecise certe stime dei percentili: i numeri non diventano una garanzia per ogni singola zona.

Per chi gestisce domini, il vantaggio è avere meno piccole modifiche bloccate dietro lavori sproporzionati. È anche un esempio di come Internet possa migliorare attraverso un’organizzazione più precisa: sapere quali record cambiare può contare più di aggiungere un’altra macchina che rilegga tutti quelli rimasti uguali.