„Als ich das letzte Mal über unsere DNS-Propagations-Pipeline geschrieben habe, empfing der Zone Builder etwa 250 DNS-Record-Änderungen pro Sekunde“, schreibt ein Cloudflare-Entwickler. Heute sind es rund 700, dazu etwa 100 weitere Ereignisse. Damit verschiebt sich die Frage: Es geht nicht mehr nur um die Menge, sondern um die Art der Arbeit. Ein Vergleich mit einem Paketdienst hilft: Nicht die Zahl der Pakete ist das Problem, sondern dass für jedes kleine Paket manchmal das ganze Lager neu sortiert wird.
Von 250 auf 700 DNS Record Änderungen pro Sekunde
Der Autor beschreibt einen Wandel, der zunächst nach einem reinen Skalierungsproblem klingt. 2022 lag der Zone Builder bei etwa 250 DNS Record Änderungen pro Sekunde, heute sind es rund 700, dazu kommen ungefähr 100 weitere Ereignisse wie Änderungen an Zoneneinstellungen. Einige Zonen enthalten mehr als 20 Millionen Records; die Erwartung geht in Richtung hunderter Millionen. Jedes Ereignis startet eine Uhr: Wie lange dauert es, bis die Änderung in einer Form vorliegt, die autoritative DNS-Server verwenden können? Diese Zeitspanne ist die DNS-Build-Verzögerung.
Die Ursache liegt laut Bericht nicht in der Ereignisrate, sondern in der Arbeit, die ein einzelnes Ereignis auslösen kann. Ein Build liest den aktuellen Datenbankzustand, wandelt ihn in das Format für den Edge-Betrieb um und schreibt Änderungen nach Quicksilver. 2022 waren Per-Record-Builds im Durchschnitt 150-mal schneller als Full Builds; auf einer Testzone mit einer Million Records lag der Unterschied bei 4.250-mal. Der nächste Schritt war, dasselbe Prinzip auf Zoneneinstellungen anzuwenden. In der Lager-Analogie bleibt das Regal voll, aber der Sortierlauf soll kleiner werden.
Warum Full Builds nicht mehr skalieren
Der ursprüngliche DNS Zone Builder hatte eine praktische Eigenschaft: Er musste nicht wissen, warum sich eine Zone geändert hatte. Er las die aktuelle Zone und ihre Einstellungen, alle DNS Records, baute daraus Quicksilver-Schlüssel, verglich sie mit dem vorhandenen Stand und schrieb nur Unterschiede. Für kleine Zonen ist das effizient. Der Lese-, Kodier- und Vergleichsaufwand wächst aber mit jedem Record. Bei den größten Zonen passt der Arbeitszustand nicht mehr vollständig in den Speicher. Ein Full Build wird damit zum Komplettscan.
Besonders unangenehm wurde es bei Zoneneinstellungen. Universal SSL ist ein Beispiel: Ein Schalter ändert Metadaten und kann CAA-Records am Apex, also an der nackten Domain, beeinflussen. Ein Full Build musste nur wissen, dass sich die Zone geändert hat. Ein gezielter Build muss beantworten, welche DNS-Namen betroffen sind, ob gemeinsame Metadaten oder die Liste veröffentlichter Zonen betroffen sind und welcher alte Zustand aus Quicksilver entfernt werden muss. Diese drei Fragen sind der Kern des Problems. Ohne belastbare Antwort bleibt nur die sichere, aber teure Variante.
Gezielte Zone Builds: der kleinste sichere Schritt
Die erste Voraussetzung war, dass Ereignisse sagen, was sich geändert hat. Der Event-Produzent liefert nun geänderte Zonenfelder und Einstellungen mit vorherigen und neuen Werten, sofern verfügbar. Danach wurde jede Einstellung durch den Code verfolgt, der DNS-Ausgaben erzeugt, und klassifiziert, was sie beeinflussen kann. Nicht jedes Ereignis ist so präzise: Manche Datenbankfunktionen aktualisieren nur einen Zeitstempel und sagen damit im Kern „irgendetwas an dieser Zone hat sich geändert“. Solche Fälle bleiben Full Builds, solange der Aufrufer und sein Zweck nicht sicher identifiziert sind. Bei Unsicherheit bleibt es bei der sicheren Variante.
Daraus entstand ein Planer für fünf Build-Typen. Er kann nur Ressourcen an bestimmten DNS-Namen neu bauen, Ressourcen plus Metadaten, Apex plus Metadaten, eine Zone entfernen oder als letzte sichere Option die ganze Zone neu bauen. Gewöhnliche A-, AAAA-, TXT- und CNAME-Änderungen landen meist beim ersten Typ; Nameserver- und Wildcard-Änderungen brauchen Records und Metadaten; Einstellungen wie Universal SSL können Apex plus Metadaten nutzen. Die Regel dahinter ist streng: Jeder Schlüssel, den ein gezielter Build schreibt, muss byte-genau dem entsprechen, was ein Full Build schreiben würde. Lässt sich das nicht beweisen, gewinnt die teurere Variante. Alte Zustände entfernt der Builder, indem er die vorhandenen Schlüssel unter jedem neu gebauten Namen in Quicksilver sucht und alles löscht, was der neue Build nicht geschrieben hat.
Es gibt eine bewusste Ausnahme. Oberhalb einer festen Record-Schwelle eskaliert der Zone Builder nie mehr zu einem Full Build. Bei den größten Zonen würde dieser ohnehin nicht fertig und würde während der Wiederholungen alle anderen Änderungen auf derselben Kafka-Partition blockieren. Stattdessen werden Apex, Metadaten und alle Namen aus den eingereihten Ereignissen neu gebaut. Das bleibt ein Kompromiss. Zone Holds verhindern, dass derselbe Name einfach einem anderen Account hinzugefügt wird, und für seltene Restfälle lassen sich einzelne Namen manuell neu bauen.
Ein Name, mehrere Zonen und gemeinsame Quicksilver-Metadaten
Quicksilver speichert Record-Schlüssel je Zone getrennt, aber für denselben Domainnamen existiert ein gemeinsamer Metadaten-Schlüssel. Der Autor vergleicht ihn mit einem Verzeichnis: Er sagt den autoritativen DNS-Servern, welche internen Zonen-IDs bei einer Anfrage verwendet werden dürfen. Während Onboarding, Offboarding und anderer Lebenszyklusphasen können kurzzeitig mehrere Cloudflare-Zonenobjekte für dieselbe öffentliche Domain existieren. Eine Prioritätsregel wählt daraus eine kleine, begrenzte Menge aus, die veröffentlicht wird. Für example.com können intern die Zonen 101, 202, 303 und 404 existieren, während der Metadaten-Schlüssel nur 101, 202 und 303 listet. Der Kunde sieht weiterhin einen Domainnamen, die Technik dahinter braucht aber eine klare Auswahl.
Eine TXT-Änderung an www.example.com in Zone 202 betrifft nur die Record-Schlüssel dieser Zone, der gemeinsame Metadaten-Schlüssel bleibt unverändert. Nameserver- und Wildcard-Änderungen sind anders, weil der Metadaten-Schlüssel Informationen über sie enthält. Solche Builds müssen Records und Metadaten aktualisieren. Zur Ausführungszeit liest der Zone Builder die aktuelle Liste erneut und baut den Metadaten-Schlüssel vollständig aus dieser frischen Sicht neu, statt eine ältere Kopie zu patchen. Die Records der auslösenden Zone werden vor den Metadaten geschrieben, die auf sie verweisen. Erst das Regal einräumen, dann das Etikett an der Tür ändern.
Planen aus dem Ereignis, prüfen vor dem Schreiben
Ein Ereignis beschreibt die Vergangenheit, der Build wartet aber möglicherweise, während weitere Ereignisse eintreffen und sich die Datenbank ändert. Deshalb plant der Zone Builder zweimal: zuerst konservativ aus dem Ereignis, unmittelbar vor der Ausführung dann mit einem frischen Veröffentlichungs-Snapshot. Dieser Snapshot enthält aktuelle Zoneneinstellungen, ob die Zone auf dem jeweiligen Netzwerk veröffentlicht werden soll und welche gleichnamigen Zonen-IDs in den Metadaten-Schlüssel gehören. Ein Netzwerk ist eine getrennte Quicksilver-Kopie für eine Umgebung; eine Zone kann auf dem globalen Netzwerk und zugleich im China-Netzwerk aktiv sein. Frischer Zustand kann einen gezielten Build zu einem Full Build machen, ihn in eine Purge verwandeln, ihn überspringen oder den Metadaten-Schlüssel aus der aktuellen Kandidatenmenge neu aufbauen.
Die frische Lesung kommt aus schreibgeschützten Datenbank-Replicas, damit Builds nicht mit Kunden-Schreibvorgängen konkurrieren. Kafka-Zustellung und Datenbank-Replikation bewegen sich jedoch unabhängig; ein Ereignis kann eintreffen, bevor die zugehörige Änderung auf einer Replica sichtbar ist. Der DNS Kafka Aggregator verzögert Ereignisse so lange, dass normale Verzögerungen abgedeckt sind, und eine abschließende Datenbankprüfung verwirft die Lesung, wenn die Replica noch hinterherhängt. So wird aus „ungefähr aktuell“ eine belastbare Grundlage. Das macht die Lesung belastbar, nicht nur schnell.
Der neue Scheduler führt Arbeit für dieselbe Zone zusammen. Dort treffen Speicherverbrauch und Wartezeiten aufeinander. Wenn mehrere Ereignisse dieselbe Zone betreffen, muss nicht jedes für sich einen vollständigen Kontext aufbauen. Gleichzeitig darf das Zusammenfassen keine Kafka-Nachricht verlieren; sonst gehen Daten verloren. Laut Bericht senkt diese Kombination den Spitzenverbrauch an Speicher um 85 Prozent.
Was die halbierte DNS-Build-Verzögerung praktisch bedeutet
Laut Bericht lässt sich die DNS-Build-Verzögerung um die Hälfte reduzieren. Zoneneinstellungsänderungen bauen keine Zonen mit zig Millionen Records mehr neu, und der zusätzliche Spielraum erlaubte, die ohnehin nötigen Wartezeiten der Pipeline sicher zu verkürzen. Zusammen mit dem um 85 Prozent gesenkten Spitzen-Speicherverbrauch heißt das: DNS Record Änderungen kommen schneller in Quicksilver an, ohne dass die Sicherheitsprüfungen weggelassen werden. Die Arbeit verschiebt sich vom pauschalen Komplettlauf zum kleinsten nachweisbar sicheren Schritt.
Die Grenzen bleiben wichtig. Full Builds skalieren nicht mehr, verschwinden aber nicht. Unbekannte Ereignisse, unklare Zeitstempel-Updates, Änderungen, die jeden Namen in der Zone betreffen können, oder eine erstmalige Veröffentlichung brauchen weiterhin den sicheren Weg. Bei sehr großen Zonen wird bewusst nicht mehr eskaliert, weil ein Full Build dort nicht fertig würde und andere Änderungen blockieren würde. Gezielte Zone Builds für DNS sind leistungsfähig, aber nur mit einer strengen Beweisregel. Wer eine DNS-Propagation-Pipeline betreibt, sollte weniger über die Zahl der Ereignisse sprechen und mehr darüber, welche Arbeit ein Ereignis tatsächlich auslösen darf.
Für den Betrieb zählt eine Regel: Ein DNS Zone Builder ist kein Sortierband, das einfach schneller laufen muss. Er ist eher ein Lager, in dem jedes Fach genau dann angefasst wird, wenn sich sein Inhalt nachweislich ändert. Der Cloudflare-Bericht zeigt, wie viel Gewinn in dieser Disziplin steckt: Speicherverbrauch senken, DNS-Änderungen schneller propagieren und die Verzögerung halbieren, ohne die Fehlerkontrolle aufzugeben. Die Halbierung kommt nicht von einem einzelnen Trick. Sie folgt aus präziseren Ereignissen, kleineren Builds, gemeinsamer Metadatenpflege und einem Scheduler, der Arbeit bündelt. So wird aus einem Full Build ein gezielter Zone Build, der schneller ist und kontrollierbar bleibt.
Quelle: blog.cloudflare.com
