DNS-Propagation: Cloudflares 3 Sekunden gegen Ihre TTL
Kurz gesagt (geprüft am 2026-11-03): Cloudflare schrieb diese Woche, dass sich die Zeit von einer DNS-Änderung bis zu dem Moment, in dem das Build-System sie geschrieben hat, halbiert hat: im Median von etwa 7,7 auf etwa 3,3 Sekunden, bei 85% weniger Speicher. Das ist gute Technik, aber nicht die Wartezeit, die Sie sehen, wenn Sie eine Website auf einen neuen Server umziehen. Ihre Wartezeit bestimmen Werte, die Sie selbst wählen oder zumindest auslesen können: die TTL des Eintrags, der Negativ-Cache-Wert im SOA und, wenn Sie die Nameserver wechseln, eine TTL von zwei Tagen bei der .com-Registry. Wir haben ein kleines Skript geschrieben, das all das für jede Zone ausliest, es auf unserer und auf Cloudflares Zone laufen lassen und daraus einen Umschaltplan gemacht.
Quelle. "We halved DNS build delay and cut memory use by 85%" (Cloudflare-Blog, veröffentlicht am 2026-11-02), Diskussion auf Hacker News mit 173 Punkten bis 2026-11-03. Ihre Zahlen geben wir wie veröffentlicht wieder; die DNS-Antworten unten haben wir selbst abgefragt.
Was Cloudflare geändert hat
Eine Änderung über API oder Dashboard landet in einer Datenbank, dann in Kafka, dann bei einem Zone Builder, der die Zone in Schlüssel umwandelt und nur die Differenz in Quicksilver schreibt, den Key-Value-Speicher, der sie in jedes Cloudflare-Rechenzentrum bringt. "Build delay" ist nur der erste Teil: von der Änderung, bis Zone Builder fertig geschrieben hat. Die Verteilung ist nicht enthalten. Die Zahl der Änderungen stieg von etwa 250 pro Sekunde im Jahr 2022 auf etwa 700, und manche Zonen haben mehr als 20 Millionen Einträge, also wurde es teuer, für einen Eintrag die ganze Zone neu zu bauen. Ein neuer Planer wählt jetzt den kleinsten sicheren Build; in einer 24-Stunden-Stichprobe kamen 92,95% der Builds ohne Komplett-Neubau aus.
| Kennzahl (Cloudflare, veröffentlicht 2026-11-02) | Vorher | Nachher |
|---|---|---|
| Median der Build-Verzögerung | etwa 7,7 s | etwa 3,3 s |
| Größte p99-Spitze | 14,6 min | 1,21 min |
| Durchschnittlicher Arbeitsspeicher | 49 GiB | 7 GiB |
| Anteil kompletter Zonen-Builds | 11,88% | 7,04% |
Im neuen, feineren Histogramm liegt p99 meist zwischen 10 und 14 Sekunden. Für Kunden zählt vor allem das Ende der Verteilung: Eine Änderung, die in einer schlechten Minute eine Viertelstunde dauerte, dauert jetzt etwa eine Minute.
Die Schichten, auf die Sie wirklich warten
Der Resolver eines Besuchers fragt nicht bei jeder Anfrage bei Cloudflare oder einem anderen Anbieter nach. Er behält die Antwort für die TTL des Eintrags und fragt erst dann wieder. Die Sekunden des Anbieters kommen also zu Minuten oder Tagen hinzu, die woanders entschieden werden:
| Schicht | Wer sie festlegt | Was wir gesehen oder gefunden haben |
|---|---|---|
| Build beim Anbieter | der DNS-Anbieter | Cloudflare Median ~3,3 s, p99 10-14 s |
| TTL des Eintrags | Sie | 300 s www.cloudflare.com, 1800 s dcxv.com |
| Negativ-Cache (Name gab es nicht) | SOA-Minimum, RFC 2308 | 300 s cloudflare.com, 3600 s dcxv.com |
| Nameserver-Delegation | die .com-Registry | 172800 s (2 Tage) für beide Zonen |
| Serve-stale bei einem Ausfall | der Resolver, RFC 8767 | 1-3 Tage empfohlen, mit TTL 30 s |
Die TTL-Zeilen stammen aus unserem Lauf unten; die Serve-stale-Zeile ist die Empfehlung des RFC, keine Messung. Laut Cloudflare-Doku hat ein proxied Eintrag fest Auto = 300 s, ein reiner DNS-Eintrag lässt sich von 60 s (30 s bei Enterprise) bis 1 Tag setzen (Cloudflare-Doku zur TTL, geprüft am 2026-11-03).
Prüfen Sie eine Zone selbst: dnscut.js
Das Skript fragt den TLD-Server nach der TTL der Delegation, jeden autoritativen Server nach SOA-Seriennummer und Eintrag und drei öffentliche Resolver, was sie gerade halten und wie lange noch. Es braucht nur Buns eingebautes node:dns und dig für die eine Abfrage ohne Rekursion. Speichern Sie es als dnscut.js:
// dnscut.js - how long until a DNS change is visible everywhere
// usage: bun dnscut.js <zone> [name] e.g. bun dnscut.js example.com www.example.com
import { Resolver } from 'node:dns/promises'
const zone = process.argv[2] ?? 'example.com'
const name = process.argv[3] ?? zone
const PUBLIC = { Cloudflare: '1.1.1.1', Google: '8.8.8.8', Quad9: '9.9.9.9' }
const sys = new Resolver()
const at = ip => {
const r = new Resolver({ timeout: 3000, tries: 2 })
r.setServers([ip])
return r
}
// 1. parent (TLD) delegation: how long resolvers may keep the old name servers
const tld = zone.split('.').pop()
const tldNs = (await sys.resolveNs(tld)).sort()[0]
const tldIp = (await sys.resolve4(tldNs))[0]
const dig = Bun.spawnSync(['dig', '+norec', '+noall', '+authority', 'NS', zone, '@' + tldIp])
const deleg = dig.stdout.toString().split('\n').find(l => /\sNS\s/.test(l))
console.log(`Zone ${zone}, name ${name}`)
console.log(`Delegation at .${tld} (${tldNs}): NS TTL ${deleg?.split(/\s+/)[1] ?? '?'} s`)
// 2. every authoritative server: same SOA serial, same answer?
const serials = new Set()
let ttl = 0
let neg = 0
for (const n of (await sys.resolveNs(zone)).sort()) {
try {
const r = at((await sys.resolve4(n))[0])
const soa = await r.resolveSoa(zone)
const a = await r.resolve4(name, { ttl: true })
serials.add(soa.serial)
ttl = Math.max(ttl, ...a.map(x => x.ttl))
neg = soa.minttl // RFC 2308: negative answers are cached for min(SOA TTL, SOA MINIMUM)
console.log(` ${n.padEnd(24)} serial ${soa.serial} A ${a.map(x => x.address).join(',')} TTL ${a[0].ttl}`)
} catch (e) {
console.log(` ${n.padEnd(24)} ERROR ${e.code}`)
}
}
console.log(serials.size === 1 ? 'Authoritative servers agree.' : `Authoritative servers DISAGREE: ${[...serials].join(' / ')}`)
// 3. public resolvers: what they hold now and how long they may keep it
let left = 0
for (const [label, ip] of Object.entries(PUBLIC)) {
try {
const a = await at(ip).resolve4(name, { ttl: true })
left = Math.max(left, ...a.map(x => x.ttl))
console.log(` ${label.padEnd(10)} ${a.map(x => x.address).join(',')} TTL left ${a[0].ttl} s`)
} catch (e) {
console.log(` ${label.padEnd(10)} ERROR ${e.code}`)
}
}
console.log(`Record TTL ${ttl} s: after a change, caches may serve the old answer for up to ${ttl} s (these three: ${left} s).`)
console.log(`SOA minimum ${neg} s: a resolver that saw NXDOMAIN for a new name may keep it that long.`)
bun dnscut.js dcxv.com
bun dnscut.js cloudflare.com www.cloudflare.com
Ausgabe, ausgeführt auf einem DCXV Cloud-Server mit Bun 1.4.4 und dig 9.20.24 am 2026-11-03 (zuerst unsere Zone, dann die von Cloudflare):
Zone dcxv.com, name dcxv.com
Delegation at .com (a.gtld-servers.net): NS TTL 172800 s
ns1.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns2.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns3.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns4.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns5.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
ns6.dcxv.com serial 2025120630 A 217.28.140.182 TTL 1800
Authoritative servers agree.
Cloudflare 217.28.140.182 TTL left 1800 s
Google 217.28.140.182 TTL left 1800 s
Quad9 217.28.140.182 TTL left 1800 s
Record TTL 1800 s: after a change, caches may serve the old answer for up to 1800 s (these three: 1800 s).
SOA minimum 3600 s: a resolver that saw NXDOMAIN for a new name may keep it that long.
Zone cloudflare.com, name www.cloudflare.com
Delegation at .com (a.gtld-servers.net): NS TTL 172800 s
ns3.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
ns4.cloudflare.com serial 2418847198 A 104.16.123.96,104.16.124.96 TTL 300
ns5.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
ns6.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
ns7.cloudflare.com serial 2418847198 A 104.16.124.96,104.16.123.96 TTL 300
Authoritative servers agree.
Cloudflare 104.16.124.96,104.16.123.96 TTL left 242 s
Google 104.16.124.96,104.16.123.96 TTL left 300 s
Quad9 104.16.123.96,104.16.124.96 TTL left 181 s
Record TTL 300 s: after a change, caches may serve the old answer for up to 300 s (these three: 300 s).
SOA minimum 300 s: a resolver that saw NXDOMAIN for a new name may keep it that long.
Vier Dinge, die die Ausgabe zeigt
- Gleiche Seriennummern heißen: Der Anbieter ist fertig. Dieselbe SOA-Seriennummer auf jedem Nameserver bedeutet, dass die Änderung den Anbieter verlassen hat; der Rest sind Caches. Anycast-Server können je nach Standort abweichen, das gilt also für den Ort, von dem Sie fragen. Weichen die Nummern ab, warten Sie oder eröffnen ein Ticket: Kein TTL-Trick hilft.
- Resolver zählen herunter, sie holen nicht früher neu. Quad9 hatte für www.cloudflare.com noch 181 s übrig, Cloudflares Resolver 242 s. Eine Änderung in diesem Moment hätte deren Nutzer drei bis vier Minuten später erreicht, egal wie schnell der Build ist. Bei dcxv.com kann dieselbe Wartezeit 30 Minuten betragen, weil unser A-Eintrag eine TTL von 1800 s hat.
- Ein neuer Name kann langsamer sein als ein geänderter. Hat jemand einen Namen abgefragt, bevor es ihn gab, darf sein Resolver die Antwort "Name existiert nicht" bis zum SOA-Minimum behalten: 3600 s in unserer Zone. Legen Sie neue Hostnamen an, bevor Sie sie ankündigen.
- Ein Nameserver-Wechsel hat eine andere Größenordnung. Die .com-Delegation trägt 172800 s, also zwei Tage. Wer DNS zu einem anderen Anbieter umzieht, lässt beide Anbieter mindestens so lange identische Zonen ausliefern.
Umschaltplan für einen neuen Server oder einen neuen IPv4-Block
- Eine alte TTL vorher: Senken Sie A- und AAAA-Einträge auf 300 s. Die vollständige Checkliste steht in Website auf einen Cloud-Server migrieren.
- Beim Umschalten: Ändern Sie die Einträge, starten Sie
dnscut.js, bis die Seriennummern übereinstimmen, und sehen Sie zu, wie die Resolver-TTL bis zur neuen Adresse herunterzählt. Lassen Sie den alten Server antworten, bis seine Logs ruhig werden. - Wenn die Nameserver wechseln: Bauen Sie zuerst die neue Zone, stellen Sie die NS beim Registrar um und lassen Sie den alten Anbieter danach noch mindestens zwei Tage dieselben Einträge ausliefern.
- Neue Adressen: Kommt mit dem Umzug ein frisch gekaufter oder gemieteter Block, prüfen Sie Reverse-DNS und Geolokalisierung, bevor Traffic ankommt; siehe IPv4-Geolokalisierung nach einem Transfer korrigieren und unsere IPv4-Vermittlung.
- Nach einer Woche: Heben Sie die TTL wieder an (1800-3600 s sind üblich), damit ein kurzer Ausfall des Anbieters nicht binnen Minuten alle Caches leert.
Planen Sie den Umzug mit uns
Unsere Tier-III-Rechenzentren in Prag und Covilha betreiben Cloud-Server und dedizierte Server. Starten Sie einen Cloud-Server, lassen Sie dnscut.js am Tag vor dem Umzug über Ihre Zone laufen und senden Sie die Ausgabe an sales@dcxv.com: Wir helfen bei der Planung der Umschaltung.
