Propagación DNS: 3 segundos de Cloudflare frente a su TTL
Respuesta corta (comprobado el 2026-11-03): Cloudflare explicó esta semana que redujo a la mitad el tiempo entre un cambio de registro DNS y el momento en que su sistema de compilación lo ha escrito: la mediana pasó de unos 7,7 a unos 3,3 segundos, con un 85% menos de memoria. Es buena ingeniería, pero no es la espera que usted ve al mover un sitio a un servidor nuevo. Su espera la fijan valores que usted elige o al menos puede leer: el TTL del registro, el valor de caché negativa del SOA y, si cambia de servidores de nombres, un TTL de dos días en el registro de .com. Escribimos un pequeño script que los lee todos para cualquier zona, lo ejecutamos sobre nuestra zona y sobre la de Cloudflare, y convertimos el resultado en un plan de cambio.
Fuente. "We halved DNS build delay and cut memory use by 85%" (blog de Cloudflare, publicado el 2026-11-02), debatido en Hacker News con 173 puntos a 2026-11-03. Sus cifras se citan tal como se publicaron; las respuestas DNS de abajo las consultamos nosotros.
Qué cambió Cloudflare
Un cambio hecho por la API o el panel va a una base de datos, luego a Kafka y luego a un Zone Builder que convierte la zona en claves y escribe solo la diferencia en Quicksilver, el almacén clave-valor que la lleva a cada centro de datos de Cloudflare. El "retardo de compilación" es solo la primera parte: desde el cambio hasta que Zone Builder termina de escribir. La distribución no está incluida. Los cambios de registros crecieron de unos 250 por segundo en 2022 a unos 700, y algunas zonas tienen más de 20 millones de registros, así que reconstruir una zona entera por un registro salía caro. Un nuevo planificador elige ahora la compilación segura más pequeña; en una muestra de 24 horas el 92,95% de las compilaciones evitó una reconstrucción completa.
| Métrica (Cloudflare, publicado 2026-11-02) | Antes | Después |
|---|---|---|
| Mediana del retardo de compilación | unos 7,7 s | unos 3,3 s |
| Mayor pico de p99 | 14,6 min | 1,21 min |
| Memoria de trabajo media | 49 GiB | 7 GiB |
| Cuota de compilaciones de zona completa | 11,88% | 7,04% |
En el nuevo histograma, más fino, el p99 queda casi siempre entre 10 y 14 segundos. Para un cliente lo útil es la cola: un cambio que en un mal minuto tardaba un cuarto de hora ahora tarda alrededor de uno.
Las capas que de verdad espera
El resolver de un visitante no pregunta a Cloudflare, ni a ningún otro proveedor, en cada petición. Guarda la respuesta durante el TTL del registro y solo entonces vuelve a preguntar. Así que los segundos del proveedor se suman a minutos o días que se deciden en otro sitio:
| Capa | Quién la fija | Valor que vimos o encontramos |
|---|---|---|
| Compilación del proveedor | el proveedor DNS | Cloudflare mediana ~3,3 s, p99 10-14 s |
| TTL del registro | usted | 300 s www.cloudflare.com, 1800 s dcxv.com |
| Caché negativa (el nombre no existía) | mínimo del SOA, RFC 2308 | 300 s cloudflare.com, 3600 s dcxv.com |
| Delegación de servidores de nombres | el registro de .com | 172800 s (2 días) en ambas zonas |
| Serve-stale durante una caída | el resolver, RFC 8767 | 1-3 días sugeridos, con TTL 30 s |
Las filas de TTL salen de nuestra ejecución de abajo; la fila de serve-stale es la sugerencia del RFC, no una medición. La documentación de Cloudflare dice que un registro con proxy tiene fijo Auto = 300 s, y uno solo DNS puede ir de 60 s (30 s en Enterprise) a 1 día (documentación de TTL de Cloudflare, comprobado el 2026-11-03).
Compruebe una zona usted mismo: dnscut.js
El script pregunta al servidor del TLD el TTL de la delegación, a cada servidor autoritativo su número de serie SOA y el registro, y a tres resolvers públicos qué tienen ahora y cuánto tiempo lo guardarán. Solo necesita el node:dns integrado de Bun y dig para la única consulta sin recursión. Guárdelo como 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
Salida, ejecutado en un servidor DCXV Cloud con Bun 1.4.4 y dig 9.20.24 el 2026-11-03 (primero nuestra zona, luego la 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.
Cuatro cosas que dice la salida
- Números de serie iguales significan que el proveedor terminó. El mismo número de serie SOA en cada servidor de nombres indica que el cambio ya salió del proveedor; el resto son cachés. Los servidores anycast pueden variar según el lugar, así que esto vale para el punto desde el que consulta. Si los números difieren, espere o abra un ticket: ningún truco de TTL ayuda.
- Los resolvers descuentan, no refrescan antes. Quad9 tenía 181 s restantes para www.cloudflare.com y el resolver de Cloudflare 242 s. Un cambio hecho en ese momento habría llegado a sus usuarios tres o cuatro minutos después, por rápida que fuera la compilación. En dcxv.com la misma espera puede ser de 30 minutos, porque nuestro registro A tiene un TTL de 1800 s.
- Un nombre nuevo puede tardar más que uno cambiado. Si alguien buscó un nombre antes de que existiera, su resolver puede guardar la respuesta "no existe" hasta el mínimo del SOA: 3600 s en nuestra zona. Cree los nombres de host nuevos antes de anunciarlos.
- Cambiar de servidores de nombres es otra escala. La delegación en .com lleva 172800 s, dos días. Mover el DNS a otro proveedor significa que ambos sirvan zonas idénticas al menos ese tiempo.
Un plan de cambio para un servidor nuevo o un bloque IPv4 nuevo
- Un TTL antiguo antes: baje los registros A y AAAA a 300 s. La lista completa está en cómo migrar a un servidor cloud.
- En el cambio: modifique los registros, ejecute
dnscut.jshasta que los números de serie coincidan y vea cómo los TTL de los resolvers descuentan hasta la nueva dirección. Mantenga el servidor antiguo respondiendo hasta que sus logs se calmen. - Si cambian los servidores de nombres: cree primero la zona nueva, cambie los NS en el registrador y deje al proveedor antiguo sirviendo los mismos registros al menos dos días después.
- Direcciones nuevas: si la mudanza trae un bloque recién comprado o arrendado, revise el DNS inverso y la geolocalización antes de que llegue el tráfico; vea corregir la geolocalización IPv4 tras una transferencia y nuestro servicio de intermediación IPv4.
- Tras una semana: vuelva a subir el TTL (1800-3600 s es lo habitual), para que una caída breve del proveedor no vacíe todas las cachés en minutos.
Planifique la mudanza con nosotros
Nuestros centros de datos Tier III en Praga y Covilha ofrecen servidores cloud y servidores dedicados. Inicie un servidor cloud, ejecute dnscut.js sobre su zona el día antes de la mudanza y envíe la salida a sales@dcxv.com: le ayudaremos a planificar el cambio.
