Cloudflare senkt den DNS-Build-Aufwand mit gezielten Zonen-Builds: 92,95 % der Builds sparen den Vollaufbau, Durchschnittsspeicher von 49 auf 7 GiB laut eigenen Messungen

Am 2. November 2026 veröffentlichte Cloudflare einen Engineering-Beitrag von Alex Fattouche darüber, wie die Arbeit des DNS Zone Builder nach einer Änderung verringert wurde. Der Zone Builder wandelt Änderungen an DNS-Einträgen und Zoneneinstellungen in Daten um, die Cloudflares autoritative DNS-Server nutzen können, und schreibt sie in Quicksilver, den verteilten Key-Value-Speicher, der sie im Netzwerk verbreitet. Als der Autor 2022 zuletzt über diese Pipeline schrieb, erhielt der Builder etwa 250 Eintragsänderungen pro Sekunde. Heute sind es etwa 700, dazu rund 100 weitere Ereignisse wie Änderungen von Zoneneinstellungen. Der Beitrag sagt, die Zahl der Ereignisse sei nie das eigentliche Problem gewesen. Das Problem war die Art der Arbeit, die manche Ereignisse nach sich zogen: Manche Zonen enthalten inzwischen mehr als 20 Millionen Einträge, und Cloudflare erwartet, dass sie auf Hunderte Millionen wachsen.

Das alte Design hatte eine nützliche Eigenschaft. Ein vollständiger Build musste nicht wissen, warum sich eine Zone geändert hatte. Er las die Zone und jeden Eintrag, wandelte sie in Quicksilver-Schlüssel um, verglich sie mit dem Gespeicherten und schrieb nur den Unterschied. Das ist für eine kleine Zone billig, liest und vergleicht aber weiterhin jeden Eintrag und hält die ganze Zone im Speicher. Eine Änderung der Zoneneinstellungen, etwa das Aktivieren von Universal SSL, kann Metadaten und CAA-Einträge am Zonen-Apex ändern, doch das Ereignis sagte oft nicht, was sich geändert hatte. Cloudflare änderte daher die Ereigniserzeuger so, dass sie geänderte Felder mit alten und neuen Werten angeben, wenn verfügbar, und baute einen Planer, der den kleinsten Build wählt, den er als sicher beweisen kann.

Der Planer wählt aus fünf Build-Typen: nur Ressourcen, Ressourcen und Metadaten, Apex und Metadaten, Löschen und gesamte Zone. Die im Beitrag genannte Regel ist streng: Jeder Schlüssel, den ein gezielter Build schreibt, muss Byte für Byte identisch mit dem sein, was ein vollständiger Build schreiben würde, und wenn das nicht bewiesen werden kann, führt das System einen vollständigen Build aus. Fehlende Details, unbekannte Ereignisse und reine Zeitstempel-Updates lösen weiterhin einen vollständigen Build aus, sodass Unsicherheit nie zu weniger Arbeit wird. Das Bereinigen alten Zustands funktioniert wie 2022: Eintragsereignisse enthalten gelöschte Einträge und frühere Versionen, und der Builder durchsucht Quicksilver nach vorhandenen Schlüsseln unter jedem neu gebauten Namen und entfernt veraltete. Für die größten Zonen gibt es eine bewusste Ausnahme. Oberhalb einer festen Eintragsschwelle wechselt der Builder nie zu einem vollständigen Build, weil ein solcher nicht abgeschlossen werden könnte und andere Änderungen auf seiner Kafka-Partition aufhielte. Stattdessen baut er Apex, Metadaten und die benannten Einträge neu, und seltene Fälle lassen sich von Hand korrigieren.

Gemeinsame Namen erschweren das. Quicksilver speichert die Eintragsschlüssel jeder Zone getrennt, hält aber einen Metadatenschlüssel, der von allen Zonen mit demselben Domainnamen geteilt wird und angibt, welche internen Zonen-IDs Anfragen beantworten dürfen. Beim Onboarding und Offboarding können für eine Domain kurzzeitig mehrere Zonenobjekte existieren. Der Beitrag behandelt außerdem das erneute Lesen der Datenbank zwischen Ereignis und Build sowie das Zusammenführen von Arbeit derselben Zone in einem Scheduler, ohne eine Kafka-Nachricht zu verlieren.

Cloudflare prüfte die Sicherheitsbehauptung auf drei Wegen. Äquivalenztests führen aus demselben Datenbankzustand einen vollständigen und einen gezielten Build aus und vergleichen jeden Schlüssel des gezielten Plans. Beim Rollout lief neben jedem gezielten Build auch ein vollständiger. Danach verarbeitete ein Spiegel-Zone-Builder den Kafka-Strom der Produktion, las den Produktionszustand der Datenbank und schrieb in ein getrenntes Quicksilver, das keine Kunden bediente. Ein Vergleicher prüfte eine Stichprobe von 20 Prozent der Zonen, und das Dashboard im Beitrag zeigt eine Abweichungsrate von 0,31 Prozent bei 234.313 zugeordneten Zonen, überwiegend Zeitunterschiede. Die Einführung erfolgte gestaffelt nach einem Hash des Zonennamens, zuerst kostenlose Zonen, dann bezahlte.

Eine 24-Stunden-Zählung der Build-Typen ergab 86,81 Prozent nur Ressourcen, 2,54 Prozent Ressourcen und Metadaten, 2,30 Prozent Apex und Metadaten und 1,30 Prozent Löschungen: 92,95 Prozent vermieden den Neuaufbau der ganzen Zone, 7,04 Prozent blieben vollständige Builds. Ihr Anteil fiel von 11,88 Prozent um etwa 40 Prozent. In einem getrennten Parallelvergleich mit denselben Ereignissen über dieselben 24 Stunden zeigten alter Produktions- und neuer Spiegel-Scheduler fast unveränderte typische Verzögerungen, aber einen Rückgang der größten p99-Spitze von 14,6 auf 1,21 Minuten. Die Verzögerung endet beim Schreiben in Quicksilver und enthält dessen weltweite Verteilung nicht. Der aggregierte Arbeitsspeicher des gesamten Zone-Builder-Deployments sank im Mittel von 49 auf 7 GiB und in der Spitze von 79 auf 12 GiB während des Rollouts; das Diagramm belegt nicht dasselbe 24-Stunden-Fenster. Erst nach späterer Verkürzung des Neuaufbauintervalls und Kafka-Aggregator-Puffers fiel der Median von etwa 7,7 auf 3,3 Sekunden. Das grobe Histogramm umfasst fast zwei Stunden; ein späteres feineres über etwa vier Stunden zeigt ungefähr 3,4 Sekunden Median.

Dies sind Cloudflares Messungen aus verschiedenen Phasen und ausgewiesenen Zeitfenstern; weder ein einziger Messtag für alle Kennzahlen noch unterschiedliche Kalendertage sind belegt. Der Build-Anteil zählt Builds; der Arbeitsspeicher des gesamten Deployments ist nicht der Speicher eines einzelnen Builds. Die Verzögerung im Parallelvergleich umfasst alle Build-Typen und Tarife und ist keine Zusage für eine einzelne Zone. Andere Teams können Änderungen in Ereignissen kennzeichnen, die Gleichheit gezielter Ausgaben beweisen, den sicheren Rückfall mit Ausnahme sehr großer Zonen bewahren und vor dem Rollout im Spiegel testen.