Cloudflare reduziert 100 TB Speicher von 1.1.1.1 durch Neugestaltung der DNS-Cache-Interna

In einem technischen Beitrag vom 27. August 2026 beschrieb der Cloudflare-Ingenieur Sebastiaan Neuteboom, wie das Unternehmen rund 100 Terabyte Speicher freisetzte, indem es die Art und Weise überarbeitete, wie der öffentliche DNS-Resolver 1.1.1.1 zwischengespeicherte Antworten speichert. Die Änderung war für die Nutzer unsichtbar, ist aber ein klares Beispiel dafür, wie winzige Ineffizienzen im Code zu enormen Kosten werden können, wenn sie über ein globales Netzwerk multipliziert werden.

Um die Leistung zu verstehen, hilft es zu wissen, was ein DNS-Resolver tut. Das Domain Name System (DNS) ist das Telefonbuch des Internets: Wenn Sie einen Website-Namen eingeben, sucht ein Resolver wie 1.1.1.1 die passende numerische Adresse und sendet sie an Ihr Gerät zurück. Da dies täglich milliardenfach geschieht, halten Resolver einen DNS-Cache vor, einen temporären Speicher für kürzliche Antworten, damit sie nicht bei jeder Abfrage die vollständige Auflösung wiederholen müssen. Dieser Cache ist einer der speicherhungrigsten Teile des Dienstes, und seine Anordnung im RAM wirkt sich direkt auf Geschwindigkeit, Kosten und Zuverlässigkeit aus.

Der 1.1.1.1-Resolver von Cloudflare ist in Rust geschrieben, einer Programmiersprache, die für Sicherheit und Leistung bekannt ist. Jedes zwischengespeicherte Element wird durch ein Paar von Strukturen dargestellt: einen Schlüssel, der die Abfrage identifiziert, und einen Wert namens CacheEntry, der die Antwort selbst speichert. Der im Beitrag gezeigte CacheEntry enthält einen Zeitstempel, eine Startzeit, einen Time-to-Live-Wert (TTL), einen Trefferzähler und drei Listen von DNS-Einträgen für die Antwort-, Autoritäts- und Zusatzabschnitte sowie Felder für Fehlerdaten. Jede dieser Listen ist ein Vec, das standardmäßige wachsende Array von Rust. Ein Vec speichert drei Dinge: einen Zeiger auf die Daten, die aktuelle Länge der Liste und die Kapazität, also den bereits zugewiesenen Gesamtspeicherplatz. Die Kapazität ist oft größer als die Länge, da das Array in Blöcken wächst, und dieser zusätzliche Speicherplatz plus die Zeiger- und Längenfelder selbst erhöhen den Overhead für jeden einzelnen Eintrag.

Das Team erkannte, dass mehrere Feldtypen mehr Overhead mit sich brachten als nötig, sobald ein Eintrag gespeichert wurde. Beispielsweise können Zeitstempel und andere Metadaten in kleineren, kompakteren Formen gehalten werden, wenn sie nicht mehr die Flexibilität der ursprünglichen Typen benötigen. Durch die Umstellung auf schlankere Darstellungen und die Umstrukturierung der Listen reduzierten sie die Speicherkosten pro Eintrag erheblich. Dies galt sowohl für den Cache-Schlüssel als auch für den Cache-Wert, und die Einsparungen wurden erzielt, ohne die Informationen zu opfern, die benötigt werden, um Antworten korrekt zu liefern.

Um jede Optimierung zu messen, baute Cloudflare einen Benchmark, der den Cache mit zufällig generierten Einträgen füllt, die dem in der Produktion gesehenen Verkehrsmix entsprechen: 56 % A-Einträge, die klassischen Einträge, die Namen IPv4-Adressen zuordnen; 25 % AAAA-Einträge, die Namen IPv6-Adressen zuordnen; und 19 % TXT-Einträge, die beliebigen Text enthalten und im Test für alle anderen Antworttypen mit variabler Länge stehen. Jeder Eintrag enthält zwischen einem und vier Datensätzen, und die TXT-Einträge werden zwischen 64 und 224 Bytes randomisiert, nahe der durchschnittlichen Antwortgröße für diese Kategorie. Der Benchmark verfolgt die Speichernutzung über einen benutzerdefinierten Allokator, der den System-Allokator von Rust umschließt und die Anzahl und Größe jeder Allokation pro Cache-Eintrag aufzeichnet. Gleichzeitig misst er den Einfügedurchsatz und die Abfragelatenz über den gesamten Cache-Fluss, um sicherzustellen, dass die Speichereinsparungen nicht auf Kosten langsamerer Abfragen gingen.

Das Ergebnis war eine Reduzierung von etwa 100 Terabyte über die Produktionsinstanzen. Das Team überprüfte die Verbesserung auch, indem es während einer schrittweisen Einführung den residenten Speicher, also den tatsächlich verwendeten RAM, beobachtete. Ein kleinerer Fußabdruck pro Eintrag bedeutet, dass derselbe physische Speicher mehr zwischengespeicherte Antworten aufnehmen kann, was die Antwortzeiten für Benutzer verbessert und die Notwendigkeit, weitere Server hinzuzufügen, verzögern kann. Selbst ein paar gesparte Bytes pro Eintrag werden enorm, wenn sie mit Milliarden von zwischengespeicherten Namen und Tausenden von Maschinen multipliziert werden.

Für Leser, die einen privaten, verschlüsselten DNS-Dienst wie AEU DNS nutzen, ist dies die Art von Technik, die dazu beiträgt, Abfragen schnell, zuverlässig und mit einem strengen No-Logs-Ansatz kompatibel zu halten, denn ein gut gestalteter Cache speichert nur das, was benötigt wird, und nichts mehr. Die Optimierung zeigt auch, dass die effektivste Leistungsarbeit oft im Verborgenen stattfindet, im Low-Level-Code, den Benutzer nie sehen, aber bei jedem schnellen Laden einer Seite spüren.