Sincronizzazione DNS: copie complete, rsync e alberi di Merkle

L'affidabilità del Domain Name System (DNS), la rubrica di Internet che trasforma i nomi di dominio in indirizzi IP numerici, dipende da migliaia di server indipendenti che mantengono le loro copie dei dati perfettamente allineate. In un post sul blog APNIC del 13 luglio 2026, Geoff Huston esplora gli strumenti utilizzati per sincronizzare i dati replicati, partendo da un incidente reale: la mattina presto dell'8 luglio 2026, il fornitore di servizi di rete australiano Telstra ha subito un'interruzione su larga scala che ha fermato alcuni servizi ferroviari urbani e regionali, causato guasti ai terminali punto vendita e interrotto la piattaforma mobile di Telstra. Un rapporto di notizie di quel giorno ha attribuito il guasto a un errore di sincronizzazione tra i data center, cosa che Huston nota essere del tutto plausibile in una piattaforma di provider di servizi ospitata in molte località.

Huston osserva innanzitutto che Internet di oggi si basa su enormi quantità di dati replicati e la coerenza tra punti distribuiti separa l'ordine dal caos. Il Border Gateway Protocol (BGP), il protocollo di routing che consente ai provider Internet di scambiare informazioni di raggiungibilità, mantiene i router attivi sincronizzati in modo che ogni router possa inoltrare i pacchetti in modo indipendente e corretto. Il DNS affronta sfide di sincronizzazione simili. Esamina quindi diversi approcci, cominciando dalla forza bruta.

Il metodo di sincronizzazione più semplice è che un server secondario scarichi una copia completa dei dati da una fonte primaria e sovrascriva la propria copia locale. Questo approccio a copia completa richiede solo di sapere dove si trova la fonte originale, e ogni altro server recupera l'intero set di dati ogni volta che deve aggiornarsi. Per decidere se un file è cambiato, i sistemi in genere confrontano la dimensione del file e la sua data e ora di modifica, il che rende importante l'orario sincronizzato tra i sistemi di rete. Quando una visione uniforme del tempo non è disponibile, il confronto deve basarsi su un calcolo più costoso come un hash MD5 o SHA del contenuto del file. Questo è il modello utilizzato dalla sincronizzazione mirror dei file system basata su FTP. È semplice ma estremamente inefficiente: i file di log scritti in modalità append vengono trasferiti per intero ogni volta, qualsiasi file modificato viene scaricato di nuovo nella sua interezza, e raccolte molto grandi richiedono che client e server esaminino l'intero spazio dei file controllando ogni file. Huston sottolinea anche che FTP in modalità mirror è una scelta sbagliata perché trasferisce i dati in chiaro e scambia le credenziali apertamente.

Un miglioramento è rsync, progettato da Andrew Tridgell nel 1996. rsync tratta un file come una sequenza di blocchi e aggiorna solo i blocchi che differiscono, piuttosto che l'intero file. Il ricevente invia al mittente un elenco di nomi di file e checksum di ogni blocco; dove i checksum differiscono, il mittente invia un blocco sostitutivo. Un blocco è definito da rsync come il massimo tra 700 byte e la radice quadrata della lunghezza del file. Il protocollo ha anche meccanismi per gestire inserimenti e cancellazioni, non solo l'aggiunta in coda. Questo approccio a blocchi riduce il traffico di rete ma aumenta il carico di elaborazione su entrambe le estremità a causa del calcolo dei checksum e dell'allineamento dei blocchi. Funziona bene quando il numero di file è modesto, i file non sono enormi e le modifiche sono incrementali. Tuttavia, quando il set di dati contiene un numero molto elevato di file, generare e inviare checksum per ogni file diventa un processo intensivo. Il mittente deve anche lavorare sodo per controllare le sequenze e riallineare i confini dei blocchi, e questo lavoro è costante anche se un solo byte è cambiato in un solo file. In una raccolta di un milione di file, Huston nota che questo carico di lavoro è un sovraccarico costante, e a volte può essere più veloce rinunciare ai checksum di rsync ed eseguire un semplice passaggio mirror FTP perché i controlli sui file sono molto più veloci da calcolare.

Un approccio diverso tratta lo stato attuale di una raccolta di dati come il risultato di transazioni di modifica applicate a uno stato precedente. Questo è meglio descritto dal protocollo di trasferimento incrementale di zona DNS, IXFR, definito nella RFC 1995. Quando una zona DNS cambia, il server primario aggiorna il numero seriale del Start of Authority (SOA). Un server secondario che vuole sincronizzarsi invia una richiesta IXFR con il suo numero seriale SOA corrente. Se il primario supporta IXFR e dispone di un file journal delle modifiche tra quel seriale e quello corrente, invia solo la sequenza di aggiunte e cancellazioni. Questo approccio è utilizzato anche nel Near Real Time Mirroring (NRTM) definito nella RFC 7682 per la sincronizzazione del Route Registry e nel RPKI Repository Delta Protocol (RRDP) definito nella RFC 8182 per la Resource Public Key Infrastructure. Il server mantiene un sovraccarico costante assegnando numeri di versione e registrando le modifiche tra le versioni, ma il vantaggio è che vengono trasmesse solo le operazioni che trasformano una versione nella successiva. Questo può essere applicato a singoli file o intere raccolte, quindi anche raccolte di file molto grandi possono essere trattate come un unico artefatto con journal. In alcuni scenari è inefficiente: un client che recupera una copia corrente riceve modifiche più vecchie che potrebbero essere annullate più avanti nella sequenza. Una migliore comprensione dei dati può migliorare questo aspetto. Ad esempio, il BGP stesso esegue la compressione delta sugli aggiornamenti di routing. Ogni peer BGP viene aggiornato circa ogni 30 secondi se vengono utilizzati i timer Minimum Route Advertisement Interval (MRAI). Quando viene elaborato un aggiornamento di routing, ciò che viene accodato è il valore del prefisso, non l'aggiornamento stesso. Quando il timer MRAI scade, il speaker BGP locale estrae ogni prefisso e cerca il suo stato corrente nella Forwarding Information Base (FIB) locale, quindi invia quello stato al peer. Se il speaker locale tiene traccia di ciò che ha già inviato al peer, non invia alcun aggiornamento quando lo stato è invariato. Questo tipo di compressione delta richiede che gli elementi di dati abbiano una chiave primaria univoca e un valore; le chiavi multi-valore non possono essere facilmente supportate.

Gli alberi di Merkle adottano un approccio gerarchico. I singoli elementi di dati vengono ordinati in una sequenza canonica, ogni elemento viene sottoposto a hash crittografico, gli hash vengono accoppiati in ordine e sottoposti nuovamente a hash, ripetendo fino a quando rimane un singolo hash radice. Se un dato cambia, l'hash alterato si propaga fino alla radice, quindi confrontare due set di dati può iniziare confrontando solo i loro hash radice. Le differenze possono essere trovate scendendo nell'albero e ignorando i rami i cui valori hash superiori corrispondono. Gli alberi di Merkle sono utilizzati nel file system ZFS, Bitcoin, il File System Interplanetario e la trasparenza dei certificati. Huston scrive che il prerequisito è un ordine canonico degli elementi di dati, e la funzione di sincronizzazione opera efficientemente su set di dati sia grandi che piccoli. Attualmente è proposto per la Resource Public Key Infrastructure (RPKI) e il protocollo ERIC, dove ogni client deve mantenere una copia locale sincronizzata dell'intera PKI. Con la crescita dell'uso di RPKI, il carico di sincronizzazione cresce con il prodotto del numero di client e oggetti, ma gli alberi di Merkle possono spezzare questa crescita operando a una scala del logaritmo del numero di oggetti. Un ulteriore miglioramento utilizza i valori hash come identificatori di dati per il recupero: richiedere un nodo intermedio restituisce la coppia ordinata dei suoi due valori hash subordinati, mentre un nodo terminale restituisce l'elemento di dati stesso. Tale schema di nome dei dati si presta alla replica anycast, in cui lo stesso indirizzo viene annunciato da molte località, migliorando ulteriormente la scalabilità.

Huston contrappone anche i modelli pull e push. In un modello pull, il client chiede al server se la sua copia differisce e scarica i dati quando necessario. Usa il framework CDS/CDNSKEY definito nella RFC 8078 come esempio. Un dominio figlio delegato pubblica un record CDS firmato DNSSEC contenente un hash di una nuova chiave che il figlio vuole che il genitore pubblichi come record DS. Il genitore periodicamente scansiona la zona delegata interrogando un record CDS all'apice della zona. Se il record può essere validato DNSSEC utilizzando la chiave di firma della zona (ZSK) del figlio, il genitore può pubblicarlo come record DS. La RFC 8078 raccomanda che il periodo tra la pubblicazione di CDS/CDNSKEY da parte del figlio e la pubblicazione del record DS sincronizzato da parte del genitore sia il più breve possibile, ma per una zona di grandi dimensioni questa scansione periodica di ogni delega può diventare un carico difficile. Un altro esempio di pull è il sistema di pubblicazione RPKI: i client mantengono una copia sincronizzata di tutte le credenziali pubblicate ma non sanno quando un editore aggiorna, quindi sono motivati a interrogare frequentemente. Al contrario, i resolver DNS ricorsivi mantengono copie cache dei dati autorevoli, e ogni record DNS porta un valore Time-to-Live (TTL) che dice al resolver per quanto tempo può mantenere la copia in cache prima di controllare gli aggiornamenti. Ciò consente a ogni editore di dati di scegliere tra una propagazione degli aggiornamenti più rapida e una migliore performance del server. Il pull è semplice e non richiede l'arruolamento del client, ma espone il server a un carico non vincolato che cresce sia con il numero di client che con la frequenza dei loro controlli. Il campo TTL è una risposta utile perché i dati stessi specificano quanto una copia locale può discostarsi dalla versione autorevole. In un modello push, al contrario, il server invia i dati ai client ogni volta che i dati cambiano.

Per gli utenti Internet di tutti i giorni e gli operatori di siti web, questi meccanismi interni di sincronizzazione sono invisibili ma essenziali; quando falliscono, come nell'incidente Telstra, treni, pagamenti con carta e reti mobili possono fermarsi insieme. Sottolineano anche perché la scelta di un resolver DNS ricorsivo affidabile sia importante. Un servizio DNS crittografato che mette la privacy al primo posto come AEU DNS consente all'utente di mantenere le proprie ricerche crittografate e fuori dai log di terze parti, anche se non cambia il modo in cui i server autorevoli sincronizzano i dati di zona. Comprendere i compromessi tra copie complete, aggiornamenti a livello di blocco, delta e alberi di Merkle aiuta a spiegare perché il DNS si è così tanto scalato, e perché vengono prese in considerazione nuove proposte come il protocollo ERIC.