Propagation DNS : les 3 secondes de Cloudflare et votre TTL
En bref (vérifié le 2026-11-03) : Cloudflare a écrit cette semaine avoir divisé par deux le temps entre la modification d'un enregistrement DNS et le moment où son système de build l'a écrite : la médiane est passée d'environ 7,7 à environ 3,3 secondes, avec 85% de mémoire en moins. C'est du bon travail d'ingénierie, mais ce n'est pas l'attente que vous voyez quand vous déplacez un site vers un nouveau serveur. Votre attente dépend de valeurs que vous choisissez ou que vous pouvez au moins lire : le TTL de l'enregistrement, la valeur de cache négatif du SOA et, si vous changez de serveurs de noms, un TTL de deux jours chez le registre du .com. Nous avons écrit un petit script qui les lit toutes pour n'importe quelle zone, l'avons lancé sur notre zone et sur celle de Cloudflare, et en avons tiré un plan de bascule.
Source. "We halved DNS build delay and cut memory use by 85%" (blog Cloudflare, publié le 2026-11-02), discuté sur Hacker News avec 173 points au 2026-11-03. Leurs chiffres sont cités tels que publiés ; les réponses DNS ci-dessous, nous les avons interrogées nous-mêmes.
Ce que Cloudflare a changé
Une modification faite par l'API ou le tableau de bord part dans une base de données, puis dans Kafka, puis dans un Zone Builder qui transforme la zone en clés et n'écrit que la différence dans Quicksilver, le stockage clé-valeur qui la transporte vers chaque centre de données Cloudflare. Le "délai de build" n'en est que la première partie : de la modification jusqu'à ce que Zone Builder ait fini d'écrire. La distribution n'est pas incluse. Les modifications sont passées d'environ 250 par seconde en 2022 à environ 700, et certaines zones comptent plus de 20 millions d'enregistrements : reconstruire toute une zone pour un seul enregistrement devenait coûteux. Un nouveau planificateur choisit désormais le plus petit build sûr ; sur un échantillon de 24 heures, 92,95% des builds ont évité une reconstruction complète.
| Indicateur (Cloudflare, publié le 2026-11-02) | Avant | Après |
|---|---|---|
| Délai de build médian | environ 7,7 s | environ 3,3 s |
| Plus gros pic de p99 | 14,6 min | 1,21 min |
| Mémoire de travail moyenne | 49 GiB | 7 GiB |
| Part des builds de zone complète | 11,88% | 7,04% |
Sur le nouvel histogramme, plus fin, le p99 se situe le plus souvent entre 10 et 14 secondes. Pour un client, l'intérêt est dans la queue : une modification qui prenait un quart d'heure lors d'une mauvaise minute en prend maintenant environ une.
Les couches que vous attendez vraiment
Le résolveur d'un visiteur n'interroge pas Cloudflare, ni aucun autre fournisseur, à chaque requête. Il garde la réponse pendant le TTL de l'enregistrement et seulement ensuite redemande. Les secondes du fournisseur s'ajoutent donc à des minutes ou des jours décidés ailleurs :
| Couche | Qui la fixe | Valeur vue ou trouvée |
|---|---|---|
| Build chez le fournisseur | le fournisseur DNS | Cloudflare médiane ~3,3 s, p99 10-14 s |
| TTL de l'enregistrement | vous | 300 s www.cloudflare.com, 1800 s dcxv.com |
| Cache négatif (le nom n'existait pas) | minimum du SOA, RFC 2308 | 300 s cloudflare.com, 3600 s dcxv.com |
| Délégation des serveurs de noms | le registre du .com | 172800 s (2 jours) pour les deux zones |
| Serve-stale pendant une panne | le résolveur, RFC 8767 | 1 à 3 jours suggérés, avec TTL 30 s |
Les lignes de TTL viennent de notre exécution ci-dessous ; la ligne serve-stale est la suggestion du RFC, pas une mesure. La documentation Cloudflare indique qu'un enregistrement proxifié est fixé à Auto = 300 s, et qu'un enregistrement DNS seul va de 60 s (30 s en Enterprise) à 1 jour (documentation TTL de Cloudflare, vérifiée le 2026-11-03).
Vérifiez une zone vous-même : dnscut.js
Le script demande au serveur du TLD le TTL de la délégation, à chaque serveur faisant autorité son numéro de série SOA et l'enregistrement, et à trois résolveurs publics ce qu'ils détiennent et pour combien de temps encore. Il n'a besoin que du node:dns intégré à Bun et de dig pour la seule requête sans récursion. Enregistrez-le sous 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
Sortie, exécuté sur un serveur DCXV Cloud avec Bun 1.4.4 et dig 9.20.24 le 2026-11-03 (notre zone d'abord, puis celle de 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.
Quatre choses que dit la sortie
- Des numéros de série identiques signifient que le fournisseur a fini. Le même numéro de série SOA sur chaque serveur de noms signifie que la modification a quitté le fournisseur ; le reste, ce sont des caches. Les serveurs anycast peuvent différer selon le lieu, donc cela vaut pour l'endroit d'où vous interrogez. Si les numéros diffèrent, attendez ou ouvrez un ticket : aucune astuce de TTL n'aide.
- Les résolveurs décomptent, ils ne rafraîchissent pas plus tôt. Quad9 avait encore 181 s pour www.cloudflare.com et le résolveur de Cloudflare 242 s. Une modification faite à ce moment-là aurait atteint leurs utilisateurs trois à quatre minutes plus tard, quelle que soit la vitesse du build. Sur dcxv.com, la même attente peut durer 30 minutes, car notre enregistrement A a un TTL de 1800 s.
- Un nouveau nom peut être plus lent qu'un nom modifié. Si quelqu'un a cherché un nom avant qu'il existe, son résolveur peut garder la réponse "ce nom n'existe pas" jusqu'au minimum du SOA : 3600 s sur notre zone. Créez les nouveaux noms d'hôte avant de les annoncer.
- Changer de serveurs de noms, c'est une autre échelle. La délégation du .com porte 172800 s, soit deux jours. Déplacer le DNS chez un autre fournisseur implique que les deux servent des zones identiques au moins aussi longtemps.
Un plan de bascule pour un nouveau serveur ou un nouveau bloc IPv4
- Un ancien TTL avant : abaissez les enregistrements A et AAAA à 300 s. La liste complète est dans migrer un site vers un serveur cloud.
- Au moment de la bascule : modifiez les enregistrements, lancez
dnscut.jsjusqu'à ce que les numéros de série concordent, puis regardez les TTL des résolveurs décompter jusqu'à la nouvelle adresse. Laissez l'ancien serveur répondre jusqu'à ce que ses logs se taisent. - Si les serveurs de noms changent : construisez d'abord la nouvelle zone, changez les NS chez le registraire et laissez l'ancien fournisseur servir les mêmes enregistrements au moins deux jours après.
- Nouvelles adresses : si le déménagement apporte un bloc fraîchement acheté ou loué, vérifiez le DNS inverse et la géolocalisation avant l'arrivée du trafic ; voir corriger la géolocalisation IPv4 après un transfert et notre courtage IPv4.
- Après une semaine : remontez le TTL (1800 à 3600 s est courant), pour qu'une courte panne du fournisseur ne vide pas tous les caches en quelques minutes.
Préparez le déménagement avec nous
Nos centres de données Tier III à Prague et Covilha hébergent des serveurs cloud et des serveurs dédiés. Lancez un serveur cloud, exécutez dnscut.js sur votre zone la veille du déménagement et envoyez la sortie à sales@dcxv.com : nous vous aiderons à planifier la bascule.
