Quando um site desaparece do navegador, a primeira suspeita costuma cair na hospedagem. Só que o servidor pode estar funcionando: quem falhou foi o caminho que leva o domínio até ele. O DNS transforma nomes em endereços IP e também informa para onde devem ir os e-mails.
Mensagens como NXDOMAIN ou servidor DNS não responde escondem causas diferentes. Antes de trocar configurações no escuro, separe o sintoma e teste cada parte. Este roteiro parte do guia oficial da Cloudflare sobre problemas comuns de DNS.
Comece pelo endereço que falha
Teste o domínio principal e as variações com www, sem www e, se existir, um subdomínio como blog. Um site pode responder em papodeprompt.com e falhar em www.papodeprompt.com porque cada nome pode ter um registro diferente. A página abrir também não prova que os registros MX do e-mail estão corretos.
Confira erros de digitação. Um caractere a mais já pode produzir NXDOMAIN, que significa domínio inexistente para o resolvedor consultado. Se apenas uma pessoa vê o erro, teste outra rede ou outro dispositivo antes de alterar o DNS por causa de um cache local.
Quando várias redes apresentam o mesmo problema, anote a hora, o endereço e a mensagem. Isso ajuda a separar uma falha no computador de uma alteração que ainda não chegou aos resolvedores.
Leia os registros antes de editar
O registro A aponta um nome para IPv4; o AAAA faz algo parecido para IPv6. O CNAME encaminha um nome, como www, para outro hostname. Um A com IP antigo leva o visitante ao servidor errado. Um CNAME incorreto impede o subdomínio de chegar ao serviço esperado.
Abra o painel que realmente administra o DNS. Ele pode ser o registrador, a hospedagem ou um provedor especializado. Procure os nameservers: eles informam quais servidores têm autoridade pelo domínio. Se o registrador aponta para um provedor e você edita a zona em outro, a mudança não aparece na internet.
Compare os valores com a documentação da hospedagem. Não copie um IP de tutorial antigo nem apague registros por tentativa. Confirme se o host deve ser escrito como @, como domínio completo ou apenas como subdomínio.
Propagação não é botão de atualizar
Cada registro tem um TTL, o tempo em segundos durante o qual um resolvedor pode manter o dado em cache. Depois de uma alteração, algumas pessoas recebem o valor novo enquanto outras ainda recebem o anterior. Redes diferentes consultam caches diferentes.
TTL alto prolonga a espera. A Cloudflare cita 86.400 segundos, ou 24 horas, como máximo comum, embora muitos registros usem menos. Limpar o cache de um resolvedor não atualiza todos os outros; o botão de flush não substitui uma configuração correta.
Durante a espera, teste redes diferentes e registre os resultados. Se apenas uma rede mostra o IP antigo, pode ser cache. Se todas mostram valor errado, olhe para o registro, os nameservers e a autoridade do domínio.
Quando entra segurança ou infraestrutura
Latência alta pode surgir em uma rede congestionada ou quando o resolvedor está distante dos usuários. A página demora ou atinge o tempo limite mesmo com o registro certo. Um provedor distribuído ajuda, mas a região dos visitantes entra na conta.
Em um DDoS contra o DNS, consultas legítimas podem deixar de encontrar o domínio. Em cache poisoning, um resolvedor guarda um IP falso. DNSSEC ajuda a validar a origem dos dados, enquanto bloqueios no registrador dificultam o sequestro do domínio.
Esses casos não se resolvem apagando e recriando registros. Se o painel mostra alterações que ninguém fez, se o domínio foi transferido sem autorização ou se usuários chegam a uma página estranha, preserve horários e auditoria e fale com registrador, hospedagem e provedor DNS.
Checklist para fechar o diagnóstico
Confirme o endereço exato que falha. Compare A, AAAA, CNAME e MX com a documentação. Confira os nameservers e anote o TTL. Teste outra rede, aguarde o cache e só então faça nova consulta. Depois abra o domínio em janela limpa e confirme o servidor de destino.
Para NXDOMAIN, procure erro de digitação, nameserver incorreto ou registro ausente. Para servidor DNS sem resposta, compare redes e resolvedores. Se o site abre, mas o e-mail parou, concentre a investigação nos registros MX, não no A da página.
DNS fica menos misterioso quando cada nome, registro, autoridade e cache vira uma pergunta separada. A fonte original da Cloudflare, Common DNS issues and how to fix them, detalha os casos usados neste guia.
O que não vale a pena fazer
Evite mudar vários registros ao mesmo tempo, reduzir TTL depois da alteração e esperar que essa redução corrija o cache imediatamente. Também não confunda a troca do resolvedor no seu computador com a correção da zona autoritativa. A primeira muda o caminho da consulta para você; a segunda muda a resposta que o domínio entrega. Fazer uma coisa não garante a outra.
Se a hospedagem foi trocada recentemente, mantenha uma cópia dos valores antigos e confirme o novo destino com o suporte. Para serviços de e-mail, confira SPF, DKIM e DMARC conforme a documentação do provedor. Uma página funcionando e mensagens rejeitadas podem ser dois problemas diferentes no mesmo domínio.
Uma forma simples de não se perder é montar uma tabela com quatro colunas: nome consultado, resposta observada, resposta esperada e horário do teste. Faça isso para o domínio, para www e para os nomes usados no e-mail. O registro deixa de ser uma abstração quando você consegue apontar exatamente qual consulta voltou diferente.
Em equipes pequenas, guarde essa documentação junto das instruções de deploy. O painel pode mudar, o provedor pode trocar o IP e alguém pode lembrar apenas da última alteração. Um histórico curto evita que a próxima investigação comece com exclusões e recriações. A regra mais segura continua sendo confirmar a autoridade do domínio, alterar uma coisa por vez e verificar o resultado em mais de uma rede.
