Como verificar a propagação de DNS

De onde vem a espera

Imagine a cadeia por onde uma consulta viaja. Seu dispositivo pergunta a um resolvedor recursivo, operado pelo seu provedor de internet ou por um provedor público. Se esse resolvedor tem uma resposta recente em cache, ele a devolve sem perguntar a ninguém. Só quando o cache expira é que ele desce até os servidores raiz, o registro do domínio de topo, e por fim os seus servidores de nomes autoritativos, que guardam o registro que você editou.

Então, quando você muda um registro A, o novo valor existe no segundo em que seu provedor de DNS o salva. Todo resolvedor que ainda tem a resposta antiga continua servindo ela até sua cópia expirar. O TTL, time to live, é um número em segundos anexado ao registro que diz aos resolvedores por quanto tempo eles podem guardá-lo em cache. Um registro com TTL de 3600 pode ser servido a partir do cache por uma hora depois de ter sido buscado, então uma hora é o pior caso para um resolvedor que o buscou pouco antes da sua edição.

É por isso que duas pessoas no mesmo escritório podem ver resultados diferentes, e por isso que limpar o seu próprio cache não ajuda mais ninguém. Não há uma propagação global para esperar, apenas vários temporizadores independentes se esgotando em momentos diferentes.

Como verificar a partir de vários resolvedores

O jeito manual é perguntar a mesma coisa a vários resolvedores e comparar as respostas:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # seu próprio resolvedor
dig +short example.com @ns1.yourdns.example  # autoritativo: a fonte da verdade

A consulta autoritativa é a que importa. Se ela devolver o novo valor, sua mudança está correta e completa, e tudo o mais é uma questão de cache. Se ela devolver o valor antigo, a mudança não foi salva, você editou a zona errada, ou os servidores de nomes do domínio não são os que você pensa.

Para ver o tempo de cache restante em vez de só o valor, tire o +short e leia a coluna do TTL:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

O número antes do tipo de registro vai diminuindo conforme a cópia em cache envelhece, o que te diz exatamente por quanto tempo mais aquele resolvedor vai servir a resposta antiga. No Windows, nslookup example.com 8.8.8.8 faz a comparação sem ferramentas extras. Uma consulta de DNS baseada na web que interroga várias localidades de uma vez faz o mesmo trabalho mais rápido, e também cobre resolvedores que você não consegue alcançar a partir da sua própria máquina.

Por que pode levar horas

• O TTL antigo é quem manda, não o novo. Se o registro tinha um TTL de 86400 e você o diminui ao fazer a mudança, os resolvedores que guardaram o registro antigo em cache ainda têm direito ao dia inteiro. Diminuir o TTL só ajuda a próxima mudança.
• Alguns resolvedores ignoram TTLs curtos. Vários provedores de internet impõem o próprio mínimo, geralmente uma hora ou mais, independentemente do que o seu registro diz.
• Mudanças de servidor de nomes são mais lentas. Registros NS no nível do registro do domínio costumam ter um TTL medido em dias, então trocar de provedor de DNS realmente pode levar de um a dois dias para se acomodar em todo lugar.
• O cache negativo também conta. Se um nome não existia quando alguém o consultou, a resposta "não existe" também fica em cache, pelo período definido no campo mínimo do SOA da zona.
• Caches encadeados. Um navegador guarda DNS em cache, o sistema operacional guarda DNS em cache, e um resolvedor corporativo pode ficar na frente do público. Cada camada soma seu próprio atraso.
• Conexões de longa duração. Aplicações que resolveram um nome de host uma vez na inicialização continuam usando aquele endereço até reiniciarem, não importa o que o DNS diga agora.

Como deixar a próxima mudança rápida

1. Diminua o TTL primeiro, depois espere. Reduza o TTL do registro para 300 segundos e deixe assim por pelo menos o tempo do TTL antigo antes de fazer a mudança de verdade. Nesse ponto, toda cópia em cache já carrega o valor curto.
2. Faça a mudança. Com um TTL de 300 segundos, a maioria dos resolvedores capta a mudança em até cinco minutos.
3. Mantenha o servidor antigo respondendo durante a sobreposição. Não o desligue no momento em que o DNS é atualizado. Deixe-o servindo até que o tráfego para ele pare, e a migração passa sem que ninguém perceba.
4. Confira nos servidores de nomes autoritativos e em vários resolvedores públicos antes de considerar concluído.
5. Suba o TTL de volta assim que a mudança tiver se acomodado, para que o tráfego normal volte a se beneficiar do cache.

Para uma mudança de servidor de nomes não há atalho, porque o TTL do registro não é seu para definir. Planeje um dia ou dois, e mantenha os dois provedores de DNS servindo registros idênticos durante todo esse tempo, para que não importe qual deles um resolvedor consulte.

Depois que a mudança se acomodar

Verificar alguns resolvedores manualmente te diz até onde uma mudança se espalhou no momento em que você olhou, o que é útil durante uma migração e inútil no resto do tempo. As falhas que vale a pena pegar são as posteriores: um registro que muda sem ninguém perceber, um servidor de nomes que para de responder, uma zona que expira. O monitoramento contínuo de DNS consulta várias localidades em uma agenda e avisa quando a resposta para de bater com o que deveria ser, o que também pega o caso de "funciona daqui, quebrado dali" que uma única consulta não consegue ver. Rode uma consulta agora com a ferramenta de consulta DNS. Se o site está inacessível para você mas normal em outro lugar, está fora do ar para todo mundo ou só para mim continua a partir daí.