Domínio não abre o site: como descobrir se o problema está no DNS, na hospedagem ou na configuração

1. “Domínio não abre” pode significar coisas diferentes

Um domínio pode falhar em pontos diferentes:

• não estar mais ativo;
• estar ativo, mas delegado para nameservers inesperados;
• ter nameservers corretos, mas sem uma resposta DNS útil;
• resolver para um destino antigo ou errado;
• chegar à hospedagem, mas mostrar página padrão;
• funcionar apenas com www ou apenas sem www;
• chegar ao servidor e então apresentar erro de certificado;
• abrir e redirecionar para outro endereço.

Por isso, “o domínio não abre” não é uma causa.

A cadeia útil para o diagnóstico é:

registro → delegação/nameservers → resolução DNS → destino esperado → hospedagem/site

Descobrir em qual elo o comportamento deixa de corresponder ao esperado evita alterações que criam um segundo problema.

2. Primeiro confirme se o domínio está ativo

O domínio precisa continuar registrado e utilizável.

A ICANN explica que o direito de usar um domínio é mantido por períodos de registro e que a renovação é necessária para continuar usando serviços associados, como site e e-mail.

Verifique conceitualmente:

• o domínio continua registrado?
• está ativo?
• houve expiração recente?
• houve renovação ou transferência?
• o controle no registrador continua com a conta esperada?

Não presuma que todo domínio expirado mostra a mesma página ou mensagem.

Também não conclua que uma transferência recente mudou automaticamente DNS ou nameservers. Transferência, renovação e configuração DNS são eventos diferentes.

Se o registro está normal, passe à delegação.

3. Veja se os nameservers ainda apontam para o serviço esperado

Nameservers fazem parte da delegação do domínio.

Em termos simples, a delegação informa ao DNS quais servidores autoritativos respondem pelos dados daquela zona.

Se a delegação ainda aponta para:

• um provedor DNS antigo;
• nameservers removidos;
• uma configuração que não corresponde ao ambiente atual;

os registros criados no serviço novo podem nunca ser consultados pelos resolvedores.

O objetivo aqui não é ensinar a trocar nameservers.

É responder:

os servidores autoritativos indicados para o domínio são realmente os que deveriam responder hoje?

Não assuma que todo provedor usa exatamente dois nameservers. A quantidade e a arquitetura podem variar.

4. DNS precisa responder antes de a hospedagem entrar no diagnóstico

Depois de confirmar registro e delegação, verifique se o DNS fornece uma resposta coerente para o hostname usado pelo site.

Há quatro estados conceitualmente diferentes:

1. domínio está registrado;
2. a delegação indica servidores autoritativos;
3. esses servidores publicam uma resposta;
4. a resposta conduz ao destino esperado.

Uma falha em qualquer etapa pode impedir o site de abrir.

Você não precisa usar terminal, dig, nslookup ou PowerShell para entender essa lógica. Painéis do registrador, provedor DNS ou suporte técnico podem confirmar a configuração publicada.

Se o domínio não resolve, a hospedagem WordPress ainda nem entrou no caminho normal da requisição.

Se resolve, passe a verificar para onde ele está levando.

5. Site errado ou página padrão significa outra classe de problema

Se o domínio abre:

• página padrão da hospedagem;
• estacionamento de domínio;
• outro site;
• ambiente antigo;
• página de boas-vindas do servidor;

isso é diferente de “DNS não responde”.

O nome já chegou a algum destino.

Agora é preciso confirmar duas coisas:

1. o DNS está levando ao serviço correto?
2. esse serviço está configurado para responder pelo hostname solicitado?

Em HTTP, o hostname faz parte da requisição e é usado em hospedagem virtual para decidir qual site deve responder.

Por isso, um mesmo servidor pode estar alcançável e ainda entregar o site errado se o hostname não estiver associado ao projeto esperado.

Se uma URL temporária da hospedagem abre o site correto, mas o domínio público não, a camada de domínio/DNS/mapeamento ganha ainda mais peso.

Não conclua que existe uma única causa: DNS pode estar apontando para um servidor antigo ou a hospedagem pode não reconhecer o hostname corretamente.

6. `www` e domínio sem `www` podem falhar separadamente

example.com e www.example.com são nomes relacionados, mas não são o mesmo hostname.

Eles podem:

• ter respostas DNS diferentes;
• chegar a destinos diferentes;
• possuir configurações diferentes na hospedagem;
• ter certificados ou redirecionamentos diferentes.

Portanto:

• se www funciona e o domínio raiz não, teste cada nome separadamente;
• se o domínio raiz funciona e www não, faça o mesmo.

Não tente corrigir isso copiando registros sem entender a arquitetura.

Este artigo não prescreve CNAME, A, AAAA ou outro tipo específico. O princípio é apenas:

cada hostname precisa chegar ao destino que a arquitetura do site espera.

7. Mudanças recentes de DNS não têm um prazo universal

DNS usa cache.

Resolvedores podem guardar respostas durante o período indicado pelo TTL do registro.

Isso significa que, após uma mudança, diferentes usuários ou redes podem temporariamente consultar dados em momentos distintos.

Mas não existe uma regra universal do tipo:

“DNS sempre leva 24–48 horas.”

O tempo observado depende, entre outras coisas, do TTL que estava em vigor e dos caches que já haviam armazenado a resposta anterior.

Se a mudança foi recente:

• confirme primeiro o que os servidores autoritativos publicam agora;
• compare com o destino esperado;
• evite fazer uma segunda mudança apenas porque uma rede ainda mostra informação anterior.

Alterar de novo antes de entender o estado atual pode prolongar a confusão.

8. Se funciona em uma rede e em outra não, cache/resolução local ganha peso

Quando o mesmo domínio:

• abre no celular usando uma rede;
• mas não abre no computador em outra rede;

a hipótese de falha global enfraquece.

Ganham peso:

• cache de DNS;
• resolvedor usado pela rede;
• cache local;
• caminho de rede;
• alguma política local.

Trate isso como evidência, não como prova.

Também não use como primeira resposta:

• trocar para DNS público;
• limpar caches por vários comandos;
• reiniciar repetidamente o roteador;
• alterar DNS do sistema.

O objetivo do teste é separar problema publicado no domínio de comportamento específico de um caminho de resolução.

9. Se DNS chega à hospedagem, confirme o mapeamento do hostname

Quando o domínio resolve para a infraestrutura correta, mas o site esperado não aparece, a hospedagem precisa entrar no diagnóstico.

O serviço que recebe a requisição precisa saber:

qual site deve responder por este hostname?

Esse mapeamento pode existir em:

• configuração da hospedagem;
• plataforma gerenciada;
• proxy;
• CDN;
• servidor web.

Este artigo não entra nesses painéis.

Leve ao suporte informações objetivas:

• hostname que falha;
• hostname que funciona;
• página que aparece;
• ambiente esperado;
• se a URL temporária funciona;
• quando a alteração foi feita.

Isso é mais útil do que mudar DNS novamente sem saber se ele já aponta corretamente.

10. SSL e redirecionamento são problemas diferentes de resolução DNS

Se o navegador consegue chegar ao site e mostra um alerta de certificado, a investigação já saiu da etapa “o nome resolve?”.

O foco passa para HTTPS:

• certificado apresentado;
• nomes cobertos pelo certificado;
• validade;
• configuração da hospedagem/proxy.

Não ignore o alerta e não desative HTTPS.

Da mesma forma, se o domínio abre e imediatamente redireciona para um endereço inesperado, houve resolução e resposta suficiente para produzir o redirecionamento.

A causa pode estar em:

• hospedagem;
• WordPress;
• proxy/CDN;
• regra de aplicação.

Não transforme esse caso em edição de DNS por reflexo.

Se o problema já envolve SSL, servidor ou WordPress, veja [Site WordPress está fora do ar: como separar problema de hospedagem, domínio, DNS, SSL e WordPress](/br/35/software-it/hosting-wordpress-domains/site-wordpress-fora-do-ar).

11. O que não fazer quando o domínio não abre

Não altere várias camadas ao mesmo tempo.

Evite como primeira tentativa:

• trocar nameservers aleatoriamente;
• criar ou apagar registros DNS por tentativa;
• copiar registros de outro domínio;
• trocar o DNS público do computador para “consertar” o domínio;
• definir IP estático no computador;
• usar receitas de TTL sem conhecer a configuração;
• mexer em arquivo de zona;
• reinstalar WordPress;
• refazer a hospedagem;
• restaurar backup;
• alterar certificado quando o nome nem resolve;
• mexer em DNSSEC sem evidência.

DNSSEC merece atenção apenas em casos específicos.

Uma falha de validação DNSSEC pode impedir um resolvedor validador de retornar uma resposta válida. Mas isso é uma hipótese avançada, não uma explicação padrão para qualquer domínio que parou de abrir.

Se houver evidência de problema de validação, encaminhe ao registrador ou ao provedor DNS em vez de editar registros DS no escuro.

12. Quando procurar registrador, DNS ou hospedagem

Depois da sequência anterior, o encaminhamento fica mais objetivo.

Procure o registrador quando:

• o domínio não está ativo;
• existe problema de renovação;
• transferência ou controle do domínio está em questão;
• a delegação registrada não corresponde aos nameservers esperados.

Procure o provedor DNS quando:

• a delegação está correta;
• mas as respostas autoritativas estão ausentes ou incorretas;
• há divergência entre o que deveria estar publicado e o que a zona publica;
• existe suspeita documentada de DNSSEC.

Procure a hospedagem quando:

• o DNS chega ao ambiente esperado;
• mas aparece página padrão, site errado ou ambiente antigo;
• a URL temporária funciona, mas o domínio não está associado corretamente;
• HTTPS ou redirecionamentos dependem da infraestrutura hospedada.

Leve evidências:

• domínio e hostname afetado;
• se raiz e www se comportam igual;
• nameservers atuais;
• destino esperado;
• o que aparece no navegador;
• se funciona em outra rede;
• horário e mudança recente.

Isso permite corrigir a camada certa sem reconstruir toda a configuração.

Conclusão

Quando um domínio não abre o site, siga a cadeia:

registro → delegação/nameservers → DNS → destino esperado → hospedagem/site

A ordem segura é:

comportamento visível → domínio ativo → nameservers → resolução → destino → raiz vs www → página errada/mapeamento → mudanças recentes → outra rede → SSL/redirecionamento → suporte.

Não existe vantagem em alterar DNS rapidamente se você ainda não sabe se o erro está no registro, na delegação, na resposta DNS ou na hospedagem.

Fontes públicas

• ICANN — Renewing Domain Names.
• ICANN — glossário de delegation, authoritative name server, caching resolver e time to live (TTL).
• RFC Editor — RFC 1034: Domain Names — Concepts and Facilities.
• MDN — Host header.
• ICANN — documentação sobre validadores DNSSEC.
• Let’s Encrypt — documentação de validação de nomes de domínio em certificados.