O que é DNS (e por que o site não abre)

Cena: o domínio 'não abre' depois de mudar hospedagem

Você acabou de trocar de hospedagem. O painel mostrou tudo verde. O site carrega no endereço técnico do servidor. Mas quando alguém digita o domínio no navegador, nada. Página em branco, erro de conexão ou aquela mensagem genérica de que o site não pode ser alcançado.

A primeira reação costuma ser culpar a hospedagem, o WordPress ou o certificado HTTPS. O problema pode ser outro: o DNS ainda não aponta para o lugar certo, ou aponta de um jeito que o navegador não entende.

Pense no domínio como o nome que as pessoas usam na lista telefônica da internet. O DNS é quem mantém essa lista atualizada e transforma o nome no endereço real da máquina que entrega o site. Se essa tradução estiver errada, atrasada ou incompleta, o domínio “não abre”, mesmo com o servidor funcionando.

Este artigo explica o DNS sem jargão desnecessário: o que ele é, quais registros você vê com mais frequência, por que a mudança demora e como checar o que está errado antes de sair mexendo em tudo.

DNS em uma frase

DNS (Domain Name System) é a lista telefônica da internet: ele liga um nome legível, como seudominio.com.br, ao endereço numérico do servidor que responde por aquele serviço.

Sem DNS, você precisaria decorar IPs. Com DNS, você digita o domínio e o sistema procura a resposta certa. Essa busca passa por vários servidores até chegar ao registro autorizado do seu domínio. No fim, o navegador recebe um IP (endereço numérico que identifica um computador na rede; IPv4 usa o formato clássico de quatro números, e IPv6 usa um formato mais longo para acomodar mais dispositivos) ou um redirecionamento interno para outro nome, e tenta abrir a conexão.

Três ideias úteis para guardar:

• Domínio é o nome.
• Hospedagem é onde o site mora.
• DNS é o mapa que diz “este nome mora aqui”.

Quando você muda de hospedagem, quase sempre precisa atualizar o mapa. Se o mapa antigo continuar ativo em algum lugar da cadeia, parte das pessoas ainda vai parar no servidor antigo (ou em lugar nenhum).

O DNS também serve para e-mail, verificação de propriedade, autenticação e alguns serviços externos. Por isso um painel de DNS parece cheio: não é só “abrir o site”. É a tabela de rotas do domínio.

Registros que mais aparecem (A, CNAME, MX, TXT)

Você não precisa decorar todos os tipos de registro. Na prática, quatro cobrem a maior parte do dia a dia.

Registro A

Aponta um nome diretamente para um endereço IPv4. Exemplo: seudominio.com.br aponta para 203.0.113.10.

É o registro usado normalmente para a raiz do domínio (o apex, ou seja, o domínio sem www na frente). Se o A estiver errado, o site da raiz não abre ou abre no servidor antigo.

Existe também o AAAA, que faz o mesmo papel para IPv6. Nem toda hospedagem exige. Se o provedor pedir, você adiciona. Se não pedir, foque no A primeiro.

Registro CNAME

Aponta um nome para outro nome, não para um IP. Exemplo: www.seudominio.com.br aponta para seudominio.com.br, ou blog.seudominio.com.br aponta para um hostname da plataforma.

Útil quando o destino muda de IP com frequência, ou quando um serviço externo pede que você “aponte o subdomínio para este hostname”. O CNAME diz: “o que vale para aquele nome também vale para este”.

Registro MX

Define para onde vai o e-mail do domínio. Se você usa Google Workspace, Microsoft 365, Zoho ou o e-mail da própria hospedagem, os MX apontam para os servidores de correio deles.

Mudar hospedagem de site não deveria, por si só, bagunçar o e-mail. Mas se você trocar os nameservers do domínio sem recriar os MX, o e-mail pode parar. Sempre separe na cabeça: site e e-mail podem depender do mesmo domínio e de registros diferentes.

Registro TXT

Carrega texto livre usado para verificações e políticas. Exemplos comuns: provar que você é dono do domínio em um painel, configurar SPF e DKIM (mecanismos em TXT que ajudam provedores de e-mail a confiar que a mensagem realmente saiu do seu domínio), ou validar um serviço de CDN (rede de servidores espalhados que entrega cópias do site mais perto de quem acessa, acelerando o carregamento).

TXT quase nunca “abre o site”. Ele costuma aparecer quando você conecta ferramentas externas. Se o site não carrega, TXT raramente é o culpado imediato. Ainda assim, vale não apagar registros TXT sem saber para que servem.

Nameservers (NS), um detalhe que muda o jogo

Além dos registros acima, o domínio tem nameservers. Eles dizem quem é a autoridade que responde as perguntas de DNS. Se você aponta os NS para a Cloudflare, a Hostinger, a AWS Route 53 ou outro DNS, é lá que os registros A, CNAME, MX e TXT precisam existir.

Erro clássico: editar o A no painel antigo depois de já ter mudado os nameservers. Você altera um lugar que a internet não consulta mais.

Para aprofundar outros blocos técnicos do mesmo jeito prático, veja também o que é uma API e o que é JSON.

Propagação: por que demora

Propagação é o tempo até a mudança de DNS “pegar” de forma ampla. Não é mágica e não é um botão universal. É cache.

Cada resposta de DNS pode carregar um TTL (Time To Live): por quanto tempo resolvedores (programas ou servidores que fazem a consulta do nome e devolvem o IP ao seu dispositivo) e provedores podem guardar aquela resposta. Se o TTL era de 1 hora, muitos lugares só vão buscar de novo depois desse prazo. Se era alto, a espera cresce.

Por isso você vê cenários estranhos:

• No seu celular com 4G o site já abre.
• No Wi-Fi de casa ainda cai no servidor antigo.
• Em outra cidade, ou em outra operadora, o resultado é diferente.

Não é que o DNS “esteja quebrado em pedaços do Brasil”. É que caches diferentes ainda guardam versões diferentes da resposta.

O que costuma influenciar o tempo:

• TTL alto antes da mudança.
• Troca de nameservers (em geral demora mais do que só editar um A).
• Cache do provedor de internet, do sistema operacional e às vezes do próprio navegador.
• Registros incompletos (você atualizou a raiz e esqueceu o www, ou o contrário).

Mudanças simples de A ou CNAME com TTL baixo podem aparecer em minutos para muita gente. Trocas de nameservers ou TTLs altos podem levar horas até o resultado ficar consistente em praticamente todos os lugares.

Enquanto isso, o servidor novo pode estar perfeito. O problema não é “o site”, é “quem ainda não leu o mapa novo”.

Ferramentas simples para checar

Antes de recriar o site ou abrir ticket em pânico, confira o que o DNS está respondendo de verdade. Você faz isso para não tratar sintoma de cache como se fosse falha no servidor.

1. Painel do registrador e painel de DNS

Confirme onde os nameservers apontam. Depois abra exatamente esse provedor de DNS e verifique:

• Existe um A (ou ALIAS/ANAME, se o provedor oferecer) na raiz?
• Existe CNAME ou A para www?
• Os MX do e-mail ainda estão lá?
• Você editou o painel certo?

Essa checagem sozinha já elimina muitos falsos alarmes, porque o erro costuma ser painel errado ou registro faltando, não o site em si.

2. Consulta pública de DNS

Use um resolvedor público na web (muitos provedores e sites de “DNS checker” fazem isso) e consulte:

• A de seudominio.com.br
• A ou CNAME de www.seudominio.com.br
• NS do domínio
• MX se o e-mail importa

Compare o IP retornado com o IP que a hospedagem nova te passou. Se não bater, a causa já apareceu.

3. Terminal, se você se sentir confortável

No Linux ou macOS, comandos como dig seudominio.com.br A +short, dig www.seudominio.com.br +short e dig seudominio.com.br NS +short mostram a resposta atual sem abrir o navegador.

No Windows, o equivalente simples é nslookup seudominio.com.br.

O objetivo não é virar especialista em rede. É ver, com evidência, para onde o nome está indo agora.

4. Teste fora da sua rede

Abra o site no celular com dados móveis, ou peça para alguém em outra rede testar. Se só a sua casa falha, pode ser cache local ou DNS do roteador. Reiniciar o roteador ou trocar temporariamente o DNS do dispositivo (por exemplo para um resolvedor público) ajuda a isolar o problema.

5. HTTPS e certificado

Depois que o DNS aponta certo, o navegador ainda pode reclamar de certificado se o SSL não foi emitido para aquele domínio no servidor novo. Isso é etapa seguinte. Primeiro o DNS precisa resolver para o lugar certo; depois o HTTPS se acomoda.

Erros comuns (CNAME no apex, TTL, www vs raiz)

Alguns erros se repetem tanto que vale reconhecer de longe.

CNAME no apex (na raiz do domínio)

A regra clássica do DNS não permite CNAME no apex (seudominio.com.br) misturado com outros registros necessários, como NS e MX. Alguns painéis modernos oferecem ALIAS, ANAME ou “CNAME flattening” para imitar esse comportamento com segurança. Se o seu provedor não oferece isso e alguém pediu “ponha um CNAME na raiz”, desconfie. Para a raiz, o caminho usual é registro A (ou o recurso equivalente do provedor).

TTL alto demais na véspera da migração

Se você sabe que vai mudar de hospedagem amanhã, baixe o TTL com antecedência (por exemplo, 300 segundos, ou seja, 5 minutos) e espere esse TTL antigo expirar. Na hora da virada, a propagação fica bem menos dramática porque os caches renovam a resposta mais rápido. Depois que estabilizar, você pode subir o TTL de novo se quiser menos consultas.

www abre e a raiz não (ou o contrário)

São nomes diferentes para o DNS. Configurar só www não configura automaticamente a raiz. Configurar só a raiz não configura automaticamente o www. Na prática, você normalmente quer:

• raiz apontando para o servidor (A ou ALIAS)
• www apontando para a raiz (CNAME) ou também para o mesmo IP (A)
• redirecionamento HTTP de um para o outro no servidor ou na CDN, para não ter duas versões soltas do site

Mexer no lugar errado

Você alterou registros no registrador, mas os nameservers estão na Cloudflare. Ou alterou na hospedagem antiga depois da transferência de DNS. O painel bonito não importa se ele não é a autoridade atual.

Apagar MX sem querer

Na pressa de “fazer o site abrir”, alguém limpa a zona DNS e recria só o A. O site volta. O e-mail some. Antes de salvar uma zona nova, tire um print ou exporte os registros atuais.

Achar que propagação explica tudo para sempre

Se depois de um tempo razoável (e com TTL baixo) o IP continua errado em consultas públicas, não é “só esperar”. É configuração errada. Propagação não corrige apontamento incorreto.

Misturar DNS e problema de aplicação

DNS resolvendo para o IP certo e o site ainda falhando pode ser firewall, virtual host, documento raiz, banco de dados ou SSL. Aí o DNS já fez a parte dele. Separe as camadas para não caçar fantasma.

O que fazer agora

Se o domínio não abre depois de uma mudança, siga uma ordem curta e objetiva:

1. Anote o IP ou hostname que a hospedagem nova pediu.
2. Confirme quais são os nameservers atuais do domínio.
3. Abra o painel de DNS correspondente a esses nameservers.
4. Ajuste a raiz com A (ou ALIAS/ANAME, se for o caso) e o www com CNAME ou A.
5. Preserve MX e TXT se e-mail e verificações importam.
6. Consulte o DNS em uma ferramenta pública e compare com o IP esperado.
7. Teste em outra rede.
8. Só depois trate SSL, redirecionamentos e o app em si.

Se você ainda não migrou, prepare o terreno: baixe o TTL com antecedência (por exemplo, 300 segundos, ou seja, 5 minutos), documente os registros atuais e decida se a mudança será só de A/CNAME ou também de nameservers. Uma migração calma de DNS parece chata. Uma migração improvisada parece misteriosa, e mistério custa tempo.

DNS não é um detalhe de bastidores reservado a gente de infraestrutura. É a lista telefônica que precisa estar certa para o domínio levar o visitante à casa nova. Entender esse mapa não transforma você em administrador de redes. Só evita que você mexa nas peças erradas enquanto o endereço na lista ainda aponta para o servidor antigo.

Próximo passo: abra o painel onde os nameservers do seu domínio estão configurados hoje, confira o registro A da raiz e o de www, e compare o IP que aparece em uma consulta pública de DNS com o que a hospedagem nova informou. Se os valores não coincidirem, corrija no painel certo antes de qualquer outra mudança.