Domínios e DNS para quem tem servidor
O servidor pode ser trocado em uma noite, mas o domínio fica com o projeto por anos. Pelo DNS, o domínio aponta para o servidor, o e-mail e serviços de terceiros, e um único registro errado derruba o site ou manda as mensagens para o spam. Veja os registros de que o dono de uma VPS vai precisar, como funciona o cache, onde manter a zona e como migrar para um servidor novo sem que os visitantes percebam.
Um domínio tem três partes independentes, e vale distingui-las. O registrador vende e renova o próprio domínio. Os servidores DNS indicados no registrador, nos registros NS, guardam a zona, ou seja, a lista de registros do domínio. O provedor de hospedagem fornece o servidor com o endereço IP para o qual esses registros apontam. As três funções podem ser de uma só empresa ou de três diferentes, e disso depende o que será preciso trocar numa migração.
Os principais registros DNS
- A: o endereço IPv4 do servidor para um nome (RFC 1035). Um site normalmente precisa de dois: para
example.come parawww.example.com. - AAAA: o mesmo para IPv6 (RFC 3596). Adicione-o só se o servidor realmente responde por IPv6: os navegadores tentam esse endereço primeiro, e um IPv6 que não funciona causa atrasos para parte dos visitantes. Mais detalhes no artigo IPv4 e IPv6 no servidor.
- CNAME: um apelido, em que um nome aponta para outro nome, por exemplo
wwwparaexample.comou um subdomínio para o endereço de uma CDN. Pela RFC 2181, um nome com CNAME não pode ter outros registros, por isso não se usa CNAME no próprio domínio sem subdomínio: ali já existem os registros NS e SOA. Alguns provedores de DNS contornam isso com tipos próprios, ALIAS ou ANAME, mas é uma extensão de um serviço específico, e não um padrão. - MX: os servidores que recebem o e-mail do domínio, com prioridade: o número menor é o principal. O MX deve apontar para um nome com registro A ou AAAA, e não para um endereço IP nem para um CNAME.
- TXT: texto livre. Nele ficam o SPF, o DKIM e o DMARC do e-mail e os códigos de verificação do domínio para buscadores e outros serviços. Como montar os registros de e-mail está no artigo Servidor de e-mail em VPS: SPF, DKIM, DMARC.
- CAA: quais autoridades certificadoras podem emitir certificados para o domínio (RFC 8659). O registro é opcional, mas, se existir, a autoridade que não constar nele recusará a emissão. Sobre certificados, veja o artigo Certificados SSL: gratuitos e pagos.
A zona típica de um site em VPS com e-mail em um serviço externo é assim: registros A e AAAA para o domínio e para o www, o MX do serviço de e-mail, TXT com SPF e DMARC, CNAME ou TXT para o DKIM e alguns TXT com verificações de serviços.
TTL: por que as mudanças não aparecem na hora
O TTL é o tempo, em segundos, durante o qual os servidores DNS dos provedores de acesso e os dispositivos dos visitantes guardam a resposta (RFC 2181, seção 8). Enquanto o prazo não acaba, eles não consultam a zona de novo, então o registro novo só chega a todos depois do TTL do antigo. Daí vem o famoso «o DNS leva até 72 horas para propagar»: na prática, tudo é definido pelo TTL que você mesmo configurou.
- 3.600 segundos (uma hora): um valor razoável para o dia a dia;
- 300 segundos: durante uma migração ou configuração, quando pode ser preciso trocar o endereço rapidamente;
- um dia ou mais: para registros que não mudam por anos, como o MX.
A ausência de um registro também vai para o cache. Se você consultar um subdomínio antes de criá-lo, a resposta negativa fica guardada pelo prazo definido no registro SOA da zona (RFC 2308), muitas vezes uma hora. Por isso, primeiro crie o registro e só depois teste.
Um caso à parte são os registros NS no registrador. O TTL deles não é definido pelo dono do domínio, mas pela zona de nível superior. Uma consulta aos servidores das zonas em 6 de novembro de 2026 mostrou que, para domínios .com, os registros NS ficam em cache por 172.800 segundos, ou seja, dois dias, e para .ru, por 345.600 segundos, quatro dias. Por isso, trocar os servidores DNS de um domínio sempre demora mais do que trocar um registro A.
PTR: o registro reverso para o e-mail
Os registros comuns traduzem um nome em endereço, e o PTR traduz um endereço em nome: 203.0.113.10 → mail.example.com. Ele não fica na zona do seu domínio, mas na zona de endereços in-addr.arpa ou ip6.arpa, controlada pelo dono do endereço IP, ou seja, o provedor de hospedagem. Ele é configurado no painel do provedor ou pelo suporte.
Um site não precisa de PTR, mas o e-mail precisa: o Google exige dos remetentes que o IP do servidor tenha PTR e que o nome indicado nele aponte de volta para o mesmo endereço. Antes de comprar uma VPS para e-mail, confira se o provedor permite alterar o PTR e se a porta 25 de saída está aberta; a seleção desses servidores está em VPS para servidor de e-mail.
Onde manter a zona: registrador, provedor de hospedagem ou serviço de DNS à parte
- No registrador. É gratuito e não depende do provedor de hospedagem: ao trocar de servidor, você muda um único registro A. As desvantagens são a escolha modesta de tipos de registro, a falta de API ou uma API limitada, e a velocidade de resposta, que depende da infraestrutura do registrador.
- No provedor de hospedagem. É prático ter tudo num só painel, e alguns provedores preenchem a zona sozinhos. Mas, ao mudar para outro provedor, será preciso migrar também a zona, e, se a conta for bloqueada ou houver uma disputa, junto com o servidor fica indisponível o DNS, ou seja, o e-mail e todos os subdomínios.
- Serviço de DNS à parte. Servidores em vários países com anycast, respostas rápidas, API para automação e para emitir certificados wildcard, histórico de alterações. Em muitos deles os planos básicos são gratuitos. Serve para projetos com vários servidores ou que usam CDN.
Regra para qualquer opção: o registrador e a conta do domínio devem pertencer ao dono do projeto, e não a um prestador de serviços ou ao provedor de hospedagem. Segundo o catálogo da accsly.io (novembro de 2026), o domínio gratuito é mencionado em 494 planos de hospedagem compartilhada de 153 dos 1.655 provedores, normalmente com pagamento anual. Diante de uma oferta assim, descubra em nome de quem o domínio é registrado e quanto custa a renovação no segundo ano. Os planos de hospedagem estão reunidos na seção hospedagem de sites.
Proteja o próprio domínio como se fosse dinheiro: login com dois fatores no registrador, renovação automática com um cartão válido, e-mail do titular atualizado. Pelas regras da ICANN em vigor, um domínio em zonas genéricas como .com não pode ser transferido para outro registrador por 60 dias após o registro ou a transferência, então é melhor escolher o registrador certo desde o início.
Como migrar o site sem tempo fora do ar
- Um ou dois dias antes, reduza o TTL dos registros A e AAAA para 300 segundos e espere o TTL antigo expirar.
- Prepare o servidor novo e teste o site nele antes de trocar o DNS:
curl --resolve example.com:443:203.0.113.10 https://example.com/ou uma linha no arquivohostsdo seu computador. - Troque os registros A e AAAA para o endereço novo. Em poucos minutos, a maior parte dos visitantes estará no servidor novo.
- Não desligue o servidor antigo por pelo menos um dia: dispositivos com o endereço em cache ainda vão acessá-lo. Se o site recebe dados, bloqueie a gravação na cópia antiga durante a migração, para que pedidos e comentários não fiquem divididos entre dois bancos de dados.
- Volte o TTL ao valor normal quando tudo estiver funcionando.
O passo a passo completo para migrar arquivos, banco de dados e e-mail está no artigo Como migrar um site da hospedagem para uma VPS.
Se, junto com o servidor, você também troca os servidores DNS do domínio, faça isso em uma etapa separada. Primeiro, passe todos os registros para a nova zona e compare as respostas dos servidores antigos e novos: dig @novo-ns example.com MX, e assim para cada tipo. Só depois troque os NS no registrador e mantenha a zona antiga funcionando por pelo menos o TTL da delegação: dois dias para .com e quatro para .ru. Se o DNSSEC estiver ativado no domínio, antes de trocar os NS remova o registro DS no registrador ou transfira as chaves pelo esquema da RFC 6781: caso contrário, os resolvedores que validam DNSSEC deixarão de abrir o domínio.
Como verificar
O comando dig example.com A +short mostra a resposta atual, e dig example.com A +trace, o caminho dos servidores raiz até os seus, o que ajuda a entender qual servidor entrega o registro antigo. dig -x 203.0.113.10 verifica o PTR. Para ver o TTL que resta no cache de um resolvedor específico, consulte-o diretamente sem +short. Se o site está atrás de uma CDN, o registro A apontará para a CDN, e não para o seu servidor; como isso funciona está no artigo CDN: quando um site precisa de uma.