Propagação DNS: os 3 segundos da Cloudflare contra o seu TTL
Resposta curta (verificado em 2026-11-03): A Cloudflare escreveu esta semana que reduziu para metade o tempo entre a alteração de um registo DNS e o momento em que o seu sistema de build a escreveu: a mediana passou de cerca de 7,7 para cerca de 3,3 segundos, com 85% menos memória. É boa engenharia, mas não é a espera que vê quando muda um site para um servidor novo. A sua espera é definida por valores que escolhe ou que pelo menos consegue ler: o TTL do registo, o valor de cache negativa no SOA e, se mudar de servidores de nomes, um TTL de dois dias no registo do .com. Escrevemos um pequeno script que lê todos eles para qualquer zona, corremo-lo na nossa zona e na da Cloudflare e transformámos o resultado num plano de mudança.
Fonte. "We halved DNS build delay and cut memory use by 85%" (blog da Cloudflare, publicado em 2026-11-02), discutido no Hacker News com 173 pontos até 2026-11-03. Os números deles são citados como publicados; as respostas DNS abaixo fomos nós que as consultámos.
O que a Cloudflare mudou
Uma alteração feita pela API ou pelo painel vai para uma base de dados, depois para o Kafka e depois para um Zone Builder que transforma a zona em chaves e escreve apenas a diferença no Quicksilver, o armazenamento chave-valor que a leva a cada centro de dados da Cloudflare. O "atraso de build" é só a primeira parte: desde a alteração até o Zone Builder terminar de escrever. A distribuição não está incluída. As alterações de registos passaram de cerca de 250 por segundo em 2022 para cerca de 700, e algumas zonas têm mais de 20 milhões de registos, por isso reconstruir uma zona inteira por causa de um registo ficou caro. Um novo planeador escolhe agora o menor build seguro; numa amostra de 24 horas, 92,95% dos builds evitaram uma reconstrução completa.
| Métrica (Cloudflare, publicado em 2026-11-02) | Antes | Depois |
|---|---|---|
| Mediana do atraso de build | cerca de 7,7 s | cerca de 3,3 s |
| Maior pico de p99 | 14,6 min | 1,21 min |
| Memória de trabalho média | 49 GiB | 7 GiB |
| Parte de builds de zona completa | 11,88% | 7,04% |
No novo histograma, mais fino, o p99 fica quase sempre entre 10 e 14 segundos. Para um cliente, o que interessa é a cauda: uma alteração que num mau minuto demorava um quarto de hora demora agora cerca de um.
As camadas por que realmente espera
O resolver de um visitante não pergunta à Cloudflare, nem a outro fornecedor, em cada pedido. Guarda a resposta durante o TTL do registo e só depois volta a perguntar. Os segundos do fornecedor somam-se, portanto, a minutos ou dias decididos noutro lado:
| Camada | Quem a define | Valor que vimos ou encontrámos |
|---|---|---|
| Build no fornecedor | o fornecedor DNS | Cloudflare mediana ~3,3 s, p99 10-14 s |
| TTL do registo | você | 300 s www.cloudflare.com, 1800 s dcxv.com |
| Cache negativa (o nome não existia) | mínimo do SOA, RFC 2308 | 300 s cloudflare.com, 3600 s dcxv.com |
| Delegação dos servidores de nomes | o registo do .com | 172800 s (2 dias) nas duas zonas |
| Serve-stale durante uma falha | o resolver, RFC 8767 | 1-3 dias sugeridos, com TTL 30 s |
As linhas de TTL vêm da nossa execução abaixo; a linha de serve-stale é a sugestão do RFC, não uma medição. A documentação da Cloudflare diz que um registo com proxy tem fixo Auto = 300 s, e um registo só DNS pode ir de 60 s (30 s no Enterprise) a 1 dia (documentação de TTL da Cloudflare, verificada em 2026-11-03).
Verifique uma zona você mesmo: dnscut.js
O script pergunta ao servidor do TLD o TTL da delegação, a cada servidor autoritativo o número de série SOA e o registo, e a três resolvers públicos o que têm agora e durante quanto tempo o vão guardar. Precisa apenas do node:dns incluído no Bun e do dig para a única consulta sem recursão. Guarde-o 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
Saída, executado num servidor DCXV Cloud com Bun 1.4.4 e dig 9.20.24 em 2026-11-03 (primeiro a nossa zona, depois a da 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.
Quatro coisas que a saída mostra
- Números de série iguais significam que o fornecedor terminou. O mesmo número de série SOA em todos os servidores de nomes indica que a alteração já saiu do fornecedor; o resto são caches. Servidores anycast podem variar consoante o local, por isso isto vale para o ponto de onde consulta. Se os números forem diferentes, espere ou abra um ticket: nenhum truque de TTL ajuda.
- Os resolvers contam para trás, não atualizam mais cedo. O Quad9 tinha 181 s restantes para www.cloudflare.com e o resolver da Cloudflare 242 s. Uma alteração feita nesse momento teria chegado aos seus utilizadores três a quatro minutos depois, por mais rápido que fosse o build. Em dcxv.com a mesma espera pode ser de 30 minutos, porque o nosso registo A tem um TTL de 1800 s.
- Um nome novo pode demorar mais do que um alterado. Se alguém procurou um nome antes de ele existir, o resolver pode guardar a resposta "este nome não existe" até ao mínimo do SOA: 3600 s na nossa zona. Crie os nomes de host novos antes de os anunciar.
- Mudar de servidores de nomes é outra escala. A delegação no .com tem 172800 s, dois dias. Mudar o DNS para outro fornecedor significa que ambos servem zonas idênticas pelo menos durante esse tempo.
Um plano de mudança para um servidor novo ou um bloco IPv4 novo
- Um TTL antigo antes: baixe os registos A e AAAA para 300 s. A lista completa está em como migrar para um servidor cloud.
- Na mudança: altere os registos, corra
dnscut.jsaté os números de série coincidirem e veja os TTL dos resolvers a contar até ao novo endereço. Mantenha o servidor antigo a responder até os seus logs acalmarem. - Se os servidores de nomes mudarem: crie primeiro a zona nova, troque os NS no registrador e deixe o fornecedor antigo a servir os mesmos registos pelo menos dois dias depois.
- Endereços novos: se a mudança trouxer um bloco acabado de comprar ou arrendar, verifique o DNS inverso e a geolocalização antes de chegar tráfego; veja corrigir a geolocalização IPv4 após uma transferência e o nosso serviço de corretagem IPv4.
- Depois de uma semana: volte a subir o TTL (1800-3600 s é comum), para que uma falha curta do fornecedor não esvazie todas as caches em minutos.
Planeie a mudança connosco
Os nossos centros de dados Tier III em Praga e na Covilhã têm servidores cloud e servidores dedicados. Inicie um servidor cloud, corra dnscut.js na sua zona no dia antes da mudança e envie a saída para sales@dcxv.com: ajudamos a planear a mudança.
