DNS-Synchronisation: Vollkopien, rsync und Merkle-Bäume

Die Zuverlässigkeit des Domain Name Systems (DNS), des Adressbuchs des Internets, das benutzerfreundliche Domainnamen in numerische IP-Adressen umwandelt, hängt von Tausenden unabhängiger Server ab, die ihre Datenkopien perfekt synchron halten. In einem APNIC-Blogbeitrag vom 13. Juli 2026 untersucht Geoff Huston die Werkzeuge zur Synchronisation replizierter Daten, ausgehend von einem realen Vorfall: Am frühen Morgen des 8. Juli 2026 erlitt der australische Netzwerkdienstanbieter Telstra einen großflächigen Ausfall, der einige Stadt- und Regionalzüge stoppte, Zahlungsterminals ausfallen ließ und die Mobilfunkplattform von Telstra störte. Ein Nachrichtenbericht an diesem Tag führte den Fehler auf einen Synchronisationsfehler zwischen Rechenzentren zurück, was Huston für durchaus plausibel hält in einer Plattform, die an vielen Standorten gehostet wird.

Huston stellt zunächst fest, dass das heutige Internet auf riesigen replizierten Datenmengen läuft und dass Konsistenz über verteilte Punkte hinweg Ordnung von Chaos trennt. Das Border Gateway Protocol (BGP), das Routing-Protokoll, das Internetdienstanbietern den Austausch von Erreichbarkeitsinformationen ermöglicht, hält aktive Router synchron, sodass jeder Router Pakete unabhängig korrekt weiterleiten kann. Das DNS steht vor ähnlichen Synchronisationsherausforderungen. Anschließend untersucht er mehrere Ansätze, beginnend mit der einfachsten Methode.

Die einfachste Synchronisationsmethode besteht darin, dass ein sekundärer Server eine vollständige Kopie der Daten von einer primären Quelle abruft und seine lokale Kopie überschreibt. Dieser Vollkopie-Ansatz erfordert nur die Kenntnis des ursprünglichen Quellorts, und jeder andere Server ruft den gesamten Datensatz ab, wann immer er aktualisiert werden muss. Um zu entscheiden, ob sich eine Datei geändert hat, vergleichen Systeme typischerweise die Dateigröße sowie das Änderungsdatum und die Änderungszeit, was synchronisierte Zeit über vernetzte Systeme hinweg wichtig macht. Wenn eine solche einheitliche Zeitsicht nicht verfügbar ist, muss der Vergleich auf einer teureren Berechnung basieren, wie einem MD5- oder SHA-Hash des Dateiinhalts. Dies ist das Modell, das bei der FTP-basierten Spiegel-Synchronisation von Dateisystemen verwendet wird. Es ist einfach, aber äußerst ineffizient: Protokolldateien, die im Anhängemodus geschrieben werden, werden jedes Mal vollständig übertragen, jede geänderte Datei wird erneut vollständig heruntergeladen, und bei sehr großen Sammlungen müssen Client und Server den gesamten Dateiraum durchgehen und jede Datei prüfen. Huston weist auch darauf hin, dass FTP im Spiegelmodus eine schlechte Wahl ist, da es Daten im Klartext überträgt und Anmeldeinformationen offen austauscht.

Eine Verbesserung ist rsync, das 1996 von Andrew Tridgell entwickelt wurde. rsync behandelt eine Datei als eine Folge von Blöcken und aktualisiert nur die Blöcke, die sich unterscheiden, anstatt der gesamten Datei. Der Empfänger sendet dem Sender eine Liste von Dateinamen und Prüfsummen jedes Blocks; wo sich Prüfsummen unterscheiden, sendet der Sender einen Ersatzblock. Ein Block wird von rsync als das Maximum aus 700 Bytes und der Quadratwurzel der Dateilänge definiert. Das Protokoll verfügt auch über Mechanismen, um mit Einfügungen und Löschungen umzugehen, nicht nur mit Anhängen. Dieser blockweise Ansatz reduziert den Netzwerkverkehr, erhöht aber die Verarbeitungslast auf beiden Seiten aufgrund der Prüfsummenberechnung und Blockausrichtung. Er funktioniert gut, wenn die Anzahl der Dateien moderat ist, die Dateien nicht massiv sind und die Änderungen inkrementell sind. Wenn der Datensatz jedoch eine sehr große Anzahl von Dateien enthält, wird das Erzeugen und Senden von Prüfsummen für jede Datei zu einem intensiven Prozess. Der Sender muss auch hart arbeiten, um Sequenzen zu prüfen und Blockgrenzen neu auszurichten, und diese Arbeit ist konstant, selbst wenn nur ein Byte in einer Datei geändert wurde. Bei einer Sammlung von einer Million Dateien, so Huston, ist diese Arbeitslast ein konstanter Overhead, und es kann manchmal schneller sein, auf rsync-Prüfsummen zu verzichten und einen einfachen FTP-Spiegeldurchlauf durchzuführen, da Dateiprüfungen weitaus schneller zu berechnen sind.

Ein anderer Ansatz behandelt den aktuellen Zustand einer Datensammlung als Ergebnis von Bearbeitungstransaktionen, die auf einen früheren Zustand angewendet wurden. Dies wird am besten durch das DNS-Protokoll für inkrementelle Zonenübertragung, IXFR, beschrieben, das in RFC 1995 definiert ist. Wenn sich eine DNS-Zone ändert, aktualisiert der primäre Server seine SOA-Seriennummer (Start of Authority). Ein sekundärer Server, der synchronisieren möchte, sendet eine IXFR-Anfrage mit seiner aktuellen SOA-Seriennummer. Wenn der primäre Server IXFR unterstützt und eine Journaldatei der Änderungen zwischen dieser Seriennummer und der aktuellen führt, sendet er nur die Sequenz von Hinzufügungen und Löschungen. Dieser Ansatz wird auch im Near Real Time Mirroring (NRTM) verwendet, das in RFC 7682 für die Synchronisation von Routing-Registrierungen definiert ist, sowie im RPKI Repository Delta Protocol (RRDP), das in RFC 8182 für die Resource Public Key Infrastructure definiert ist. Der Server hält einen konstanten Overhead, indem er Versionsnummern vergibt und Änderungen zwischen Versionen protokolliert, aber der Vorteil ist, dass nur die Operationen übertragen werden, die eine Version in die nächste überführen. Dies kann auf einzelne Dateien oder ganze Sammlungen angewendet werden, sodass auch sehr große Dateisammlungen als ein einziges journalisiertes Artefakt behandelt werden können. In einigen Szenarien ist es ineffizient: Ein Client, der eine aktuelle Kopie abruft, erhält ältere Änderungen, die später in der Sequenz möglicherweise rückgängig gemacht werden. Ein besseres Verständnis der Daten kann dies verbessern. Beispielsweise führt BGP selbst eine Delta-Kompression bei Routing-Updates durch. Jeder BGP-Peer wird ungefähr alle 30 Sekunden aktualisiert, wenn Minimum Route Advertisement Interval (MRAI)-Timer verwendet werden. Wenn ein Routing-Update verarbeitet wird, wird der Präfixwert in die Warteschlange gestellt, nicht das Update selbst. Wenn der MRAI-Timer abläuft, entfernt der lokale BGP-Sprecher jeden Präfix aus der Warteschlange und schlägt seinen aktuellen Zustand in der lokalen Forwarding Information Base (FIB) nach und sendet diesen Zustand dann an den Peer. Wenn der lokale Sprecher eine Aufzeichnung darüber führt, was er bereits an den Peer gesendet hat, sendet er kein Update, wenn sich der Zustand nicht geändert hat. Diese Art der Delta-Kompression erfordert, dass Datenelemente einen eindeutigen Primärschlüssel und einen Wert haben; mehrwertige Schlüssel können nicht ohne Weiteres unterstützt werden.

Merkle-Bäume verfolgen einen hierarchischen Ansatz. Einzelne Datenelemente werden in eine kanonische Reihenfolge sortiert, jedes Element wird kryptografisch gehasht, Hashes werden paarweise in Reihenfolge gehasht, und dies wird wiederholt, bis ein einzelner Wurzel-Hash übrig bleibt. Wenn sich irgendein Datenelement ändert, pflanzt sich der geänderte Hash bis zur Wurzel fort, sodass der Vergleich zweier Datensätze damit beginnen kann, nur ihre Wurzel-Hashes zu vergleichen. Unterschiede können gefunden werden, indem man den Baum hinabsteigt und Zweige ignoriert, deren übergeordnete Hash-Werte übereinstimmen. Merkle-Bäume werden im ZFS-Dateisystem, in Bitcoin, im Interplanetary File System und bei Certificate Transparency verwendet. Huston schreibt, dass die Voraussetzung eine kanonische Reihenfolge der Datenelemente ist, und die Synchronisationsfunktion arbeitet effizient über große und kleine Datensätze. Sie wird derzeit für die Resource Public Key Infrastructure (RPKI) und das ERIC-Protokoll vorgeschlagen, bei dem jeder Client eine synchronisierte lokale Kopie der gesamten PKI unterhalten muss. Mit zunehmender RPKI-Nutzung wächst die Synchronisationslast mit dem Produkt aus Anzahl der Clients und Objekte, aber Merkle-Bäume können dieses Wachstum durchbrechen, indem sie in einer Größenordnung des Logarithmus der Anzahl der Objekte arbeiten. Eine weitere Verbesserung verwendet Hash-Werte als Datenidentifikatoren für den Abruf: Das Anfordern eines Zwischenknotens gibt das geordnete Paar seiner beiden untergeordneten Hash-Werte zurück, während ein Endknoten das Datenelement selbst zurückgibt. Ein solches Datennamensschema eignet sich für Anycast-Replikation, bei der dieselbe Adresse von vielen Standorten aus angekündigt wird, was die Skalierbarkeit weiter verbessert.

Huston stellt auch Pull- und Push-Modelle gegenüber. Bei einem Pull-Modell fragt der Client den Server, ob sich seine Kopie unterscheidet, und zieht Daten bei Bedarf. Er verwendet das CDS/CDNSKEY-Framework, das in RFC 8078 definiert ist, als Beispiel. Eine delegierte Child-Domain veröffentlicht einen DNSSEC-signierten CDS-Ressourceneintrag, der einen neuen Schlüssel-Hash enthält, den das Kind möchte, dass die Parent-Domain als DS-Eintrag veröffentlicht. Die Parent-Domain scannt regelmäßig die delegierte Zone, indem sie am Zonen-Apex eine Abfrage nach einem CDS-Eintrag durchführt. Wenn der Eintrag mit dem Zone Signing Key (ZSK) des Kindes DNSSEC-validiert werden kann, kann die Parent-Domain ihn als DS-Eintrag veröffentlichen. RFC 8078 empfiehlt, dass der Zeitraum zwischen der Veröffentlichung von CDS/CDNSKEY durch das Kind und der Veröffentlichung des synchronisierten DS-Eintrags durch die Parent-Domain so kurz wie möglich sein sollte, aber bei einer großen Zone kann dieses periodische Scannen jeder Delegation zu einer schwierigen Last werden. Ein weiteres Pull-Beispiel ist das RPKI-Veröffentlichungssystem: Clients halten eine synchronisierte Kopie aller veröffentlichten Anmeldeinformationen, wissen aber nicht, wann ein Herausgeber aktualisiert, sodass sie motiviert sind, häufig abzufragen. Im Gegensatz dazu halten rekursive DNS-Resolver zwischengespeicherte Kopien von autoritativen Daten, und jeder DNS-Eintrag trägt einen Time-to-Live-Wert (TTL), der dem Resolver mitteilt, wie lange er die zwischengespeicherte Kopie behalten darf, bevor er auf Aktualisierungen prüft. Dies ermöglicht jedem Datenherausgeber, zwischen schnellerer Update-Verbreitung und verbesserter Serverleistung zu wählen. Pull ist einfach und erfordert keine Client-Registrierung, setzt den Server jedoch einer unbegrenzten Last aus, die sowohl mit der Anzahl der Clients als auch mit der Häufigkeit ihrer Prüfungen wächst. Das TTL-Feld ist eine nützliche Antwort, da die Daten selbst angeben, wie weit eine lokale Kopie von der autoritativen Version abweichen darf. Bei einem Push-Modell hingegen sendet der Server Daten an Clients, wann immer sich die Daten ändern.

Für normale Internetnutzer und Website-Betreiber sind diese internen Synchronisationsmechanismen unsichtbar, aber wesentlich; wenn sie versagen, wie beim Telstra-Vorfall, können Züge, Kartenzahlungen und Mobilfunknetze gleichzeitig ausfallen. Sie unterstreichen auch, warum die Wahl eines zuverlässigen rekursiven DNS-Resolvers wichtig ist. Ein datenschutzorientierter, verschlüsselter DNS-Dienst wie AEU DNS ermöglicht es einem Benutzer, seine eigenen Abfragen verschlüsselt und außerhalb von Protokollen Dritter zu halten, obwohl er nicht ändert, wie autoritative Server Zonendaten synchronisieren. Das Verständnis der Abwägungen zwischen Vollkopien, Block-Level-Updates, Deltas und Merkle-Bäumen hilft zu erklären, warum das DNS so weit skaliert hat und warum neue Vorschläge wie das ERIC-Protokoll in Betracht gezogen werden.