Propagazione DNS: 3 secondi di Cloudflare contro il tuo TTL
In breve (verificato il 2026-11-03): Cloudflare ha scritto questa settimana di aver dimezzato il tempo tra la modifica di un record DNS e il momento in cui il suo sistema di build l'ha scritta: la mediana è scesa da circa 7,7 a circa 3,3 secondi, con l'85% di memoria in meno. È buona ingegneria, ma non è l'attesa che vedi quando sposti un sito su un nuovo server. La tua attesa dipende da valori che scegli o che almeno puoi leggere: il TTL del record, il valore di cache negativa nel SOA e, se cambi name server, un TTL di due giorni presso il registro del .com. Abbiamo scritto un piccolo script che li legge tutti per qualsiasi zona, l'abbiamo eseguito sulla nostra zona e su quella di Cloudflare e ne abbiamo ricavato un piano di passaggio.
Fonte. "We halved DNS build delay and cut memory use by 85%" (blog di Cloudflare, pubblicato il 2026-11-02), discusso su Hacker News con 173 punti al 2026-11-03. I loro numeri sono citati come pubblicati; le risposte DNS qui sotto le abbiamo interrogate noi.
Cosa ha cambiato Cloudflare
Una modifica fatta tramite API o dashboard finisce in un database, poi in Kafka, poi in uno Zone Builder che trasforma la zona in chiavi e scrive solo la differenza in Quicksilver, l'archivio chiave-valore che la porta in ogni data center di Cloudflare. Il "ritardo di build" è solo la prima parte: dalla modifica fino a quando Zone Builder ha finito di scrivere. La distribuzione non è inclusa. Le modifiche ai record sono passate da circa 250 al secondo nel 2022 a circa 700, e alcune zone contengono più di 20 milioni di record, quindi ricostruire una zona intera per un solo record era diventato costoso. Un nuovo pianificatore sceglie ora la build sicura più piccola; in un campione di 24 ore il 92,95% delle build ha evitato una ricostruzione completa.
| Metrica (Cloudflare, pubblicato il 2026-11-02) | Prima | Dopo |
|---|---|---|
| Mediana del ritardo di build | circa 7,7 s | circa 3,3 s |
| Picco p99 più alto | 14,6 min | 1,21 min |
| Memoria di lavoro media | 49 GiB | 7 GiB |
| Quota di build di zona completa | 11,88% | 7,04% |
Nel nuovo istogramma, più fine, il p99 sta per lo più tra 10 e 14 secondi. Per un cliente conta la coda: una modifica che in un minuto sfortunato richiedeva un quarto d'ora ora ne richiede circa uno.
Gli strati che aspetti davvero
Il resolver di un visitatore non interroga Cloudflare, né un altro provider, a ogni richiesta. Tiene la risposta per il TTL del record e solo dopo chiede di nuovo. I secondi del provider si sommano quindi a minuti o giorni decisi altrove:
| Strato | Chi lo decide | Valore visto o trovato |
|---|---|---|
| Build del provider | il provider DNS | Cloudflare mediana ~3,3 s, p99 10-14 s |
| TTL del record | tu | 300 s www.cloudflare.com, 1800 s dcxv.com |
| Cache negativa (il nome non esisteva) | minimo del SOA, RFC 2308 | 300 s cloudflare.com, 3600 s dcxv.com |
| Delega dei name server | il registro del .com | 172800 s (2 giorni) per entrambe le zone |
| Serve-stale durante un guasto | il resolver, RFC 8767 | 1-3 giorni suggeriti, con TTL 30 s |
Le righe sul TTL vengono dalla nostra esecuzione qui sotto; la riga serve-stale è il suggerimento dell'RFC, non una misura. La documentazione di Cloudflare dice che un record con proxy è fisso su Auto = 300 s, mentre un record solo DNS va da 60 s (30 s su Enterprise) a 1 giorno (documentazione TTL di Cloudflare, verificata il 2026-11-03).
Controlla una zona da solo: dnscut.js
Lo script chiede al server del TLD il TTL della delega, a ogni server autoritativo il numero di serie SOA e il record, e a tre resolver pubblici cosa tengono ora e per quanto ancora. Servono solo il node:dns integrato in Bun e dig per l'unica query senza ricorsione. Salvalo come 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
Output, eseguito su un server DCXV Cloud con Bun 1.4.4 e dig 9.20.24 il 2026-11-03 (prima la nostra zona, poi quella di 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.
Quattro cose che dice l'output
- Numeri di serie uguali significano che il provider ha finito. Lo stesso numero di serie SOA su ogni name server indica che la modifica ha lasciato il provider; il resto sono cache. I server anycast possono differire a seconda del luogo, quindi vale per il punto da cui interroghi. Se i numeri differiscono, aspetta o apri un ticket: nessun trucco sul TTL aiuta.
- I resolver contano alla rovescia, non aggiornano prima. Quad9 aveva ancora 181 s per www.cloudflare.com e il resolver di Cloudflare 242 s. Una modifica fatta in quel momento sarebbe arrivata ai loro utenti tre o quattro minuti dopo, per quanto veloce fosse la build. Su dcxv.com la stessa attesa può durare 30 minuti, perché il nostro record A ha un TTL di 1800 s.
- Un nome nuovo può essere più lento di uno modificato. Se qualcuno ha cercato un nome prima che esistesse, il suo resolver può tenere la risposta "nome inesistente" fino al minimo del SOA: 3600 s nella nostra zona. Crea i nuovi nomi host prima di annunciarli.
- Cambiare name server è un'altra scala. La delega nel .com porta 172800 s, due giorni. Spostare il DNS su un altro provider significa che entrambi servono zone identiche almeno per quel tempo.
Un piano di passaggio per un nuovo server o un nuovo blocco IPv4
- Un vecchio TTL prima: abbassa i record A e AAAA a 300 s. La checklist completa è in come migrare su un server cloud.
- Al passaggio: cambia i record, esegui
dnscut.jsfinché i numeri di serie coincidono, poi guarda i TTL dei resolver scendere fino al nuovo indirizzo. Tieni il vecchio server attivo finché i suoi log non tacciono. - Se cambiano i name server: crea prima la nuova zona, cambia gli NS presso il registrar e lascia il vecchio provider con gli stessi record per almeno due giorni dopo.
- Indirizzi nuovi: se il trasloco porta un blocco appena comprato o in leasing, controlla DNS inverso e geolocalizzazione prima che arrivi il traffico; vedi correggere la geolocalizzazione IPv4 dopo un trasferimento e il nostro servizio di intermediazione IPv4.
- Dopo una settimana: rialza il TTL (1800-3600 s è comune), così un breve guasto del provider non svuota tutte le cache in pochi minuti.
Pianifica il trasloco con noi
I nostri data center Tier III a Praga e Covilha ospitano server cloud e server dedicati. Avvia un server cloud, esegui dnscut.js sulla tua zona il giorno prima del trasloco e invia l'output a sales@dcxv.com: ti aiutiamo a pianificare il passaggio.
