Verificador de propagação de DNS

Como verificar se a alteração de DNS já propagou

Três passos, todos nesta página. A verificação lê o DNS público via HTTPS a partir do seu navegador — não entra na sua conta do Registro.br nem no painel da hospedagem, e não há nada para instalar nem cadastro para fazer.

1. Digite o domínio. Digite o domínio, o nome de host ou a URL e clique em Verificar. A página lê o cadastro do domínio no próprio registro via RDAP — num .com.br, em rdap.registro.br — e, em paralelo, consulta NS, SOA, A, AAAA, MX e TXT em dns.google e cloudflare-dns: a resposta atual do registro ao lado de dois caches independentes.
2. Leia primeiro a linha da delegação. Ela tem um de três estados. NOERROR com servidores significa que a delegação está intacta e você está esperando cache. NXDOMAIN significa que a zona pai não tem delegação para você, e esperar não ajuda. SERVFAIL significa que a delegação está lá, mas os servidores por trás dela não estão servindo a zona.
3. Depois compare o registro com os resolvedores. Se o registro já lista os seus novos servidores DNS e um resolvedor ainda devolve os antigos, esse resolvedor está com uma cópia em cache — isso é propagação, e termina sozinha. Se o próprio registro ainda lista o conjunto antigo, não há nada em trânsito: a troca nunca chegou ao registro, e esperar não ajuda. Nos TLDs cujo registro não publica RDAP, compare os dois resolvedores.

Três respostas, não duas: NOERROR, NXDOMAIN, SERVFAIL

Quase todo tutorial sobre o assunto divide o mundo em duas caixas: funcionou, ou «ainda está propagando». Esse corte está errado, e é por causa dele que tanta gente espera 24, 48, 72 horas por algo que nunca ia se resolver sozinho. Uma consulta NS no seu domínio tem três respostas, não duas: NOERROR com registros NS = a delegação está lá e você está esperando o cache expirar; NXDOMAIN = a zona pai não tem delegação para o seu domínio; SERVFAIL = a delegação existe, mas nenhum servidor autoritativo respondeu.

A ferramenta acima lê esse estado e depois uma segunda coisa, que separa os dois primeiros casos sem margem para dúvida: o SOA. Peça SOA no seu domínio e uma zona saudável responde com o próprio SOA — prova de que a cadeia da raiz, passando pelo TLD, até os seus servidores resolveu de ponta a ponta. Um domínio sem delegação responde NXDOMAIN e coloca o SOA da zona pai na seção authority; num .com.br, o SOA de com.br., com hostmaster.registro.br como responsável — o próprio registro dizendo, com todas as letras, que não tem nada para você. No navegador, as duas situações parecem iguais: uma página que não carrega. Não são nem de longe o mesmo problema.

O que a «propagação de DNS» realmente é

Não existe propagação. Nada é copiado de servidor em servidor e nenhuma onda atravessa o país. Quando você troca os servidores DNS, o registro grava a nova delegação — no .br, ela entra na zona na publicação seguinte — e a partir daí os servidores autoritativos já dão a resposta nova. O que leva tempo é o contrário: resolvedores que já fizeram a pergunta continuam com a resposta antiga até o TTL dela acabar. Propagação é um conjunto de caches expirando, cada um no seu relógio.

O teto, então, não é «24 a 48 horas»: é o TTL das entradas antigas quando o último resolvedor as guardou, mais o TTL de NS da zona pai. E aqui o .br não é o .com. Em 26 de setembro de 2026, perguntando direto a a.dns.br e c.dns.br, a delegação de um .com.br veio com TTL de 3600 segundos — uma hora; a de um .com, em a.gtld-servers.net, com 172800, dois dias. As 48 horas dos tutoriais são do .com. Num .com.br, a parte que depende do registro fecha em pouco mais de uma hora (quem sai do DNS do próprio Registro.br tem outro prazo, descrito abaixo); o resto é o TTL das entradas antigas, que quem escolheu foi a zona antiga.

A ferramenta acima troca o folclore pelo número: toda resposta vem com o TTL restante da cópia que aquele resolvedor guarda. Dois resolvedores devolvendo servidores diferentes são a propagação visível; dois concordando numa resposta que você não configurou significam que a troca nunca chegou ao registro — volte ao painel em vez de esperar. Um mapa de propagação mostra quais caches já expiraram, não se a sua troca está certa.

A linha do registro, no topo do resultado, tira a dúvida sem adivinhação. O RDAP, sucessor do WHOIS, responde por HTTPS com os servidores DNS que o registro tem agora, e a RFC 7480 recomenda que servidores RDAP deixem navegadores ler dados públicos. O Registro.br segue isso: rdap.registro.br responde com access-control-allow-origin: * para .br, .com.br, .net.br e .org.br (conferido em 26 de setembro de 2026). Então a página pergunta ao próprio registro: se o registro já lista os seus novos servidores DNS, você está esperando cache; se ainda lista os antigos, a troca não entrou. O mesmo vale para .com, .net, .org, .app, .dev, .ai e .info; registros sem RDAP legível por navegador — .de, .jp, .es, .it e .io, entre eles — deixam a linha vazia, e a página diz isso em vez de chutar.

Como o Registro.br aceita — ou recusa — a troca de servidores DNS

No .br, a troca passa por uma porta que muitos TLDs não têm. Pelas características técnicas que o próprio Registro.br publica, uma delegação só é aceita depois de verificado que os servidores indicados respondem com autoridade pelo domínio. O Registro.br consulta os servidores novos antes de aceitar; se eles não respondem com autoridade, a alteração não entra e o conjunto antigo continua valendo. A tela mostra o resultado dessa consulta, e a FAQ de DNS do Registro.br lista os códigos. Os que denunciam uma troca mal preparada:

Por isso, no .br, o erro clássico «troquei o DNS antes de criar a zona» aparece na hora de salvar, e não como um SERVFAIL horas depois. Dá para testar antes na Verificação de DNS do Registro.br: segundo a FAQ, está resolvido quando o resultado é «Autoridade sobre o domínio» e a versão da configuração é a mesma em todos os servidores. O equivalente de terminal está na seção de comandos.

Publicação a cada 5 minutos, transição de 24 horas

Aceita, a troca entra na zona na publicação seguinte: segundo o Registro.br, as publicações de domínios acontecem a cada 5 minutos, por seis servidores (a.dns.br a f.dns.br). Conferimos em 26 de setembro de 2026: o número de série do SOA de com.br. mudou às 09:35, 09:40, 09:45 e 09:50 UTC. (A página da Locaweb sobre o Registro.br ainda fala em 30 minutos.) A mesma FAQ acrescenta que, depois de uma alteração, o domínio passa por um período de transição de 24 horas, em que os servidores DNS anteriores devem continuar respondendo de forma consistente com os novos. Na prática: não cancele a hospedagem antiga no dia da troca, e deixe na zona antiga as mesmas entradas da nova até o dia seguinte.

Saindo do DNS do Registro.br: pelo menos 2 horas

Quem registrou sem informar servidores, e nunca trocou, usa o DNS gratuito do próprio Registro.br — na linha do registro, a.auto.dns.br e b.auto.dns.br. Para ir para a hospedagem, você desativa esse serviço e informa pelo menos dois servidores com autoridade sobre o domínio, e o prazo muda: segundo o Registro.br, a publicação dos novos servidores leva pelo menos 2 horas, o tempo de remover do DNS a chave DNSSEC do domínio, e a transição completa, até 3 horas. Reativar os servidores do Registro.br só é possível 4 horas depois da desativação.

A verificação continua depois

As delegações são verificadas periodicamente, problemas são avisados por e-mail aos contatos do domínio, e o resultado da última verificação e a data da última resposta com autoridade («último AA») são públicos: no whois, nsstat e nslastaa; no RDAP, os eventos delegation check (ns aa quando está certo) e last correct delegation check de cada servidor — e, para o DS, delegation sign check. A ferramenta mostra servidores, status e DNSSEC; esses eventos ficam no JSON que o curl impresso por ela devolve.

Onde a troca é feita: Registro.br, Provedor de Serviços ou outro painel

Nas ajudas das hospedagens brasileiras, «alterar o DNS» é trocar os servidores DNS — os nameservers — do domínio. O lugar certo depende de quem administra o domínio, não de onde o site está. Uma troca feita no lugar errado não chega ao registro: a linha do registro continua com os servidores antigos e os dois resolvedores concordam com ela.

Os nomes dos servidores vêm da hospedagem nova, exatamente como ela mostra — ns1 a ns3.locaweb.com.br na Locaweb, dns1 a dns6.kinghost.com.br na KingHost. Cole-os no campo opcional da ferramenta: ela diz se o registro já tem exatamente esse conjunto.

Cache negativo: por que a delegação corrigida continua dando NXDOMAIN

A versão mais ingrata é aquela em que você corrige o problema e nada acontece. Depois que uma delegação é corrigida, o NXDOMAIN pode continuar voltando pelo tempo do TTL de cache negativo — o minimum do SOA. Resolvedores guardam «este nome não existe» do mesmo jeito que guardam endereços; a RFC 2308 fixa a duração dessa memória no menor valor entre o campo minimum do SOA e o TTL do próprio registro SOA, e por isso a ferramenta mostra um número só. Em com.br. e em br., medimos 900 segundos — 15 minutos — em 26 de setembro de 2026; em com., também 900. Na raiz, um dia inteiro.

Vimos isso acontecer nos nossos próprios domínios. Em junho de 2026, quatro domínios .app perderam a delegação no registro e ficaram em NXDOMAIN no mundo todo por cerca de quatro dias. O registrador devolveu a delegação em 30 de junho, às 17:30 UTC — e os domínios não voltaram para boa parte da internet naquela noite: resolvedores que tinham perguntado durante a queda ainda estavam dentro da janela de cache negativo. Dois painéis nos disseram o tempo todo que estava tudo bem: a zona na Cloudflare seguia active, e o campo do próprio registrador seguia verified. O DNS autoritativo público, lido de dois resolvedores independentes, foi o único sinal verdadeiro. É por isso que a checagem de saúde de domínio em quatro camadas (em inglês) começa pela camada do registro, e não pelo campo de status de algum fornecedor.

Consequência prática: se a ferramenta mostrar NXDOMAIN, corrija a delegação e dê o tempo do cache negativo — quinze minutos num .com.br — antes de concluir que o conserto não funcionou; se for um dia, espere uma cauda longa e não «conserte» de novo no meio do caminho. Um detalhe do .br, medido no mesmo dia: numa consulta SOA a um nome .br inexistente, dns.google e cloudflare-dns devolvem esse SOA com TTL 0 (numa consulta A ou NS, 900) — por isso a ferramenta lê o cache negativo da resposta à consulta NS, que é a que mostra o valor do registro, 900. A calculadora de TTL de DNS faz a conta a partir dos dois números do SOA.

O que realmente quebra depois de trocar o DNS

O estado da delegação acima diz em qual família de problema você está; esta lista diz o que ir olhar em cada uma.

1. A troca foi salva, mas não chegou ao registro. O painel diz que salvou e a internet pública continua com o conjunto antigo. No .br há dois caminhos para isso: o Registro.br recusou a troca porque os novos servidores não respondiam com autoridade, ou ela foi feita num lugar que não é a delegação — a zona DNS do Registro.br, o painel da hospedagem, registros NS digitados dentro da zona. Sintoma na ferramenta: a linha do registro ainda mostra os servidores antigos.
2. A zona não existe nos novos servidores. Onde ninguém confere antes, a delegação passa a apontar para servidores que nunca ouviram falar do seu domínio e se recusam a responder por ele: SERVFAIL nos dois resolvedores. No .br, o Registro.br recusa a troca nesse caso («Pesquisa recusada», «Domínio desconhecido») e você cai no item 1. Crie a zona primeiro, troque a delegação depois: essa ordem é o truque todo.
3. O DNSSEC ficou ligado na mudança. O DS continua na zona pai apontando para as chaves do provedor antigo, e todo resolvedor que valida recusa as respostas do novo. Sintoma: SERVFAIL em toda parte, enquanto os novos servidores respondem perfeitamente se consultados direto. Remova o DS no painel onde o domínio é administrado, espere o TTL dele (medimos 3600 segundos no DS de dois domínios .br) e reative o DNSSEC do lado novo. Todas as categorias do .br são assinadas, e o Registro.br confere o DS (códigos NOSIG, EXPSIG, NOKEY… na mesma FAQ).
4. As entradas não foram copiadas. Delegação perfeita, zona no ar, e nenhum A ou AAAA para o nome que as pessoas de fato digitam. Sintoma: a delegação verde e a linha de endereço vazia. É o site fora do ar depois de uma troca que «funcionou»: a delegação está certa, o conteúdo da zona não.
5. MX, SPF, DKIM e DMARC ficaram para trás. O e-mail quebra mais quieto que o site, e mais tarde, porque os servidores que enviam tentam de novo por dias antes de alguém notar as devoluções. Confira as linhas MX e TXT do resultado. Se o domínio tem uma caixa de que o seu agente depende, o lado de e-mail (em inglês) apaga no mesmo momento.
6. Você só está dentro de um TTL antigo e longo — ou desligou a hospedagem antiga cedo demais. No primeiro caso nada está errado: alguns caches ainda guardam as entradas antigas, e o TTL restante em cada resposta acima é a contagem regressiva. No segundo, quem ainda pergunta aos servidores antigos pode ficar sem resposta — é por isso que o Registro.br pede 24 horas de transição com eles respondendo.
7. O domínio expirou ou foi congelado durante a mudança. No navegador, não se distingue dos outros casos; numa resposta DNS, é impossível não ver. Sintoma: NXDOMAIN com o SOA da zona pai na seção authority e, nos TLDs genéricos, um status como client hold, server hold ou redemption period na linha do registro. No .br, um domínio congelado por falta de pagamento deixa de ser publicado; a extensão de pagamento do Registro.br, de uso único, o publica de novo por um período curto enquanto você paga. Esperar não faz nada.
8. Um bloqueio impediu a alteração. client update prohibited manda o registro recusar alterações no domínio; server update prohibited é a versão do lado do registro. Se a linha do registro mostra um dos dois ao lado dos servidores antigos, é o primeiro suspeito: o client sai no registrador, o server só pelo registro. No .br, a trava equivalente é de permissão: só os contatos administrativo e técnico ou o contato do titular alteram os servidores, e um domínio com Provedor de Serviços só é alterado por ele.

As mesmas verificações no terminal

Nada aqui é proprietário: a página é um atalho para dois resolvedores públicos e para o RDAP do registro. Cada linha do resultado pode ser reproduzida com dig e curl, e a ferramenta imprime os comandos exatos para o domínio que você digitou. Os cinco que importam:

dig NS exemplo.com.br +short          # para onde a delegação resolve
      dig @8.8.8.8 NS exemplo.com.br +short # a mesma pergunta, feita a um cache específico
      dig @1.1.1.1 NS exemplo.com.br +short # e a outro — duas respostas diferentes = propagação
      dig SOA exemplo.com.br                # num NXDOMAIN, a seção authority mostra a zona que negou
      curl -s https://rdap.registro.br/domain/exemplo.com.br   # o cadastro no registro: servidores, status, DNSSEC

No .br vale um sexto, antes de salvar a troca: pergunte a cada servidor novo, sem recursão, se ele responde com autoridade pelo domínio — é o que a verificação do Registro.br confere.

dig @ns1.novo-provedor.com.br SOA exemplo.com.br +norec
      # status: NOERROR e flag aa → o servidor tem a zona e responde com autoridade
      # status: REFUSED          → é o que o Registro.br mostra como «Pesquisa recusada»
      # compare o serial do SOA entre os servidores: se diferir, o Registro.br acusa NOT SYNC ZONE

Para ver a cadeia inteira, dig +trace NS exemplo.com.br percorre uma delegação por vez e mostra em qual salto a coisa para. Num .com.br ela vai da raiz ao br. e dali direto aos seus servidores: com.br. mora nos mesmos a.dns.br a f.dns.br, então não aparece como salto separado. E se você não tem dig — Windows, notebook travado, celular —, os mesmos dois resolvedores respondem por HTTPS:

curl -s -H 'accept: application/dns-json' \
        'https://dns.google/resolve?name=exemplo.com.br&type=NS'

Essa requisição é literalmente o que esta página roda. Vale ler o JSON cru uma vez: Status é o RCODE (0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN), Answer traz os registros e, numa negativa, Authority traz o SOA da zona que a emitiu.

O que um navegador não vê — e o que a verificação completa acrescenta

Convém deixar claro o limite desta página. Um navegador fala com resolvedores recursivos via HTTPS e, na maioria dos TLDs — o .br incluído —, com o RDAP do registro; então lê três coisas: o que o registro tem, se a cadeia de delegação resolve e o que a zona responde. Ele não consulta direto os servidores do seu TLD, não vê a sua conta no Registro.br nem a fila de alterações do seu registrador, não vê o registro nos TLDs sem RDAP legível por navegador, e não vê nada acima ou abaixo do DNS público — um proxy na frente do site, um certificado ainda não emitido, uma vinculação de hospedagem que nunca foi criada, uma origem devolvendo 502. Tudo isso parece «o site caiu depois que troquei o DNS», e nada disso é DNS.

clize domain check <domínio> é a mesma primeira camada com mais três por cima. Roda a mesma sonda DoH em dois resolvedores — dns.google primeiro, cloudflare-dns como reserva, RCODE lido em três estados — e depois confere a zona na Cloudflare, a vinculação do nome de host ao worker do site e se o conteúdo está de fato sendo servido. Quatro camadas, um comando: luz verde quer dizer alcançável, e não apenas delegado. Sem argumento de domínio, ela percorre todos os domínios da conta. A plataforma também verifica sozinha: um cron a cada 30 minutos, e e-mail de alerta só depois de duas rodadas seguidas com falha, para que uma resposta DoH instável não acorde ninguém.

Essa verificação existe por causa da queda de junho descrita acima — é o conserto que saiu do incidente, junto com a verificação de delegação que roda depois de cada deploy. O resto está em Agent Domains (comprar, importar e apontar domínios pela CLI), registro de domínios por código e na referência de comandos, os três em inglês. Publicar o site que mora no domínio é outro comando e outra camada — por isso a checagem de saúde reporta as duas separadamente.

$ npm i -g @clize/clize && clize install
$ clize domain check seudominio.com.br