Ferramenta gratuita
Se a sua alteração de DNS já se vê em todo o mundo, e quanto falta a cada cópia antiga.
Referência
O seu fornecedor de DNS serve a alteração assim que a guarda. O que demora é cada resolver deitar fora a cópia que tinha guardado, e isso é decidido pelo TTL.
A referência
Perguntamos diretamente aos servidores autoritativos do domínio, sem cache pelo meio: o que dizem é o que todos verão quando as cópias expirarem. Se eles ainda não dão o valor novo, esperar não adianta: a alteração não está na zona que o domínio usa.
A mesma pergunta, três respostas
exemplons1.oseufornecedor.com
autoritativo: o valor atual
1.1.1.1 · Cloudflare
já renovou a sua cópia
8.8.8.8 · Google
cópia guardada antes da alteração
O TTL
O TTL diz quantos segundos um resolver pode guardar a resposta. Cada um pediu-a num momento diferente, por isso cada um renova-a à sua hora. No pior caso, o último demora um TTL inteiro desde a sua alteração.
TTL de 1 h: o que lhes falta
exemplo1.1.1.1
Cloudflare
9.9.9.9
Quad9
8.8.8.8
O que não é propagação
Os serviços grandes dão um IP diferente consoante o local de onde se pergunta: é balanceamento geográfico ou uma CDN e, com um TTL de um minuto, não deixa cópias antigas. Além disso, quase todos estes resolvers são anycast: responde o nó mais próximo de quem pergunta, por isso o país é o do operador. E se mudar os servidores DNS de um .es, antes de qualquer cache manda a Red.es, que publica a zona por turnos de cerca de quatro horas.
www.github.com · A
exemplo realns-520.awsdns-01.net
autoritativo
dns1.p08.nsone.net
autoritativo, outro IP
4.2.2.1 · Level 3
outra região do serviço
168.126.63.1 · KT
outra região do serviço
No máximo, o TTL que o registo tinha antes de o alterar, contado a partir da alteração. Com um TTL de 300 são cinco minutos; com 86400, um dia. As «48 horas» que se repetem vêm das alterações de servidores DNS no registador, onde manda o TTL da delegação na zona do domínio de topo (nos .com, dois dias), e de fornecedores de Internet que prolongam as cópias por conta própria.
Porque cada resolver guardou a sua cópia num momento diferente e renova-a quando expira, não quando você altera o registo. O seu próprio computador, o navegador e o router também guardam cópias: se aqui estiver tudo bem e continuar a ver o anterior, limpe a cache DNS do equipamento (ipconfig /flushdns no Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder no macOS) e experimente com o navegador em modo privado.
Depois de feita a alteração, não: as cópias que já estão guardadas duram o seu TTL. O que funciona é prepará-la: baixe o TTL para 300 um dia antes (ou, no mínimo, com o TTL antigo de margem), faça a alteração e volte a subi-lo quando tiver terminado. A Google e a Cloudflare permitem também pedir que limpem a cópia de um nome nos seus resolvers públicos, mas isso só os afeta a eles.
Porque a Red.es não publica as alterações da zona .es de imediato, mas por ciclos de cerca de quatro horas: têm sido observados às 2, 6, 10, 14, 18 e 22 h, hora de Espanha peninsular, embora não haja um horário oficial. Uma mudança de servidores feita às 10:05 costuma esperar pela das 14:00, e depois ainda contam as caches. Só afeta as mudanças de servidores DNS e os domínios novos: editar um registo A, MX ou TXT de uma zona que já funciona não espera por ninguém.
Em serviços grandes, sim. Muitos repartem o tráfego com balanceamento geográfico ou uma CDN e respondem com o IP do centro de dados mais próximo de quem pergunta; por isso www.github.com dá vários IP ao mesmo tempo. Detetamo-lo quando os próprios servidores autoritativos dão respostas diferentes ou quando há várias com um TTL curto e, nesse caso, não o marcamos como uma alteração a meio. Se o nome for um alias (CNAME) para uma CDN, comparamos o alias, que é o que a sua zona publica. Para ver todos os registos de um nome, use a consulta DNS.
