Todos os artigos
141 artigos · atualizado semanalmente Veja nossas Ferramentas
Todos os artigos
Comparativos

Nameserver e zona DNS: qual é a diferença

Trocar o nameserver não edita a sua zona DNS: muda onde ela vive e deixa os records para trás. Por isso o e-mail quebra. Entenda a diferença de uma vez.

Nameserver e zona DNS: qual é a diferença
COVER · Comparativos

Troquei o nameserver de um domínio numa sexta à noite (erro clássico) e na manhã seguinte o e-mail tinha parado. O site continuava no ar, mas nenhuma mensagem entrava nem saía. O domínio estava certo, o DNS "tinha sido configurado", e mesmo assim algo quebrou. O problema não era o nameserver em si: era a confusão entre apontar o nameserver para um lugar novo e esquecer que a zona inteira de records ficou para trás.

Esse mal-entendido entre "editar o DNS no registrador" e "editar o DNS no provedor de DNS" derruba e-mail toda semana, quase sempre pelo mesmo detalhe. Este artigo separa dois conceitos que as interfaces misturam de propósito: o que é um nameserver e o que é uma zona DNS. Quando você entende quem hospeda o quê, parar o e-mail por acidente deixa de ser surpresa.

Nameserver: o servidor que responde

Nameserver é o servidor — a máquina — que tem autoridade para responder consultas DNS de um domínio. Quando alguém pergunta "qual é o IP de exemplo.com.br?", a resposta final vem do nameserver autoritativo daquele domínio. Os endereços costumam ter cara de ns1.provedor.com e ns2.provedor.com, e quase sempre vêm em par para redundância.

O ponto que confunde: o nameserver não é os seus dados. Ele é o endereço onde os dados moram. Trocar o nameserver é como mudar de cartório: você diz ao mundo "a partir de agora, a autoridade sobre este domínio está naquele outro lugar".

Zona DNS: o conjunto de records

A zona DNS é o conteúdo — o arquivo de configuração com todos os records do domínio. É ali que vivem o A (aponta para um IPv4), o AAAA (IPv6), o CNAME (apelido para outro nome), o MX (para onde vai o e-mail), o TXT (SPF, DKIM, verificações), além do SOA e dos próprios NS, que declaram qual servidor é autoritativo.

$ORIGIN exemplo.com.br.
@       3600  IN  SOA   ns1.provedor.com. admin.exemplo.com.br. (2026080101 7200 3600 1209600 3600)
@       3600  IN  NS    ns1.provedor.com.
@       3600  IN  NS    ns2.provedor.com.
@        300  IN  A     203.0.113.10
www      300  IN  CNAME exemplo.com.br.
@       3600  IN  MX    10 mail.exemplo.com.br.

Resumindo a relação: o nameserver é o servidor; a zona é o que ele serve. Um nameserver sem a zona não tem o que responder; uma zona sem um nameserver hospedando-a não responde a ninguém.

A cadeia de delegação: como o mundo descobre quem manda

No registrador (onde você comprou o domínio) existe um campo de nameservers. Esses valores são publicados na zona do TLD (.br, .com) e funcionam como uma placa: "para resolver este domínio, pergunte a estes servidores". Quando você define ns1.cloudflare.com ali, está delegando a autoridade — dizendo ao mundo que a zona daquele domínio é hospedada na Cloudflare, e é lá que os records devem ser lidos.

É por isso que existem dois lugares onde "se mexe em DNS" e eles não são a mesma coisa: o registrador controla para qual nameserver o domínio aponta; o provedor de DNS (que pode ser o próprio registrador, ou Cloudflare, ou Route 53) controla os records dentro da zona.

Por que o e-mail quebra quando você troca o nameserver

Aqui está o detalhe da minha sexta à noite. Quando você troca os nameservers para um novo provedor, a zona daquele provedor começa do zero — com os records padrão que ele criar, não com os que existiam no antigo. Se o provedor antigo tinha um MX apontando para o seu serviço de e-mail e o novo não tem, o e-mail simplesmente para: as consultas agora vão para um servidor que não conhece aquele MX.

A regra prática para migrar sem susto: recrie a zona inteira no novo provedor antes de trocar os nameservers. Copie todos os records (A, MX, TXT, CNAME...), confira, e só então mude a delegação no registrador. Depois, confira para qual IP o record A do domínio realmente aponta para confirmar que a mudança pegou e que é o novo provedor respondendo. Se quiser o passo a passo completo de apontar um domínio para uma hospedagem, eu detalho em como apontar um domínio para uma hospedagem.

Perguntas frequentes

Trocar o nameserver apaga meus records?

Não apaga os do provedor antigo — eles continuam lá enquanto a conta existir. Mas para de usá-los: as consultas passam a ir para o novo nameserver, que tem a própria zona, provavelmente vazia ou com defaults. O efeito prático é o mesmo de "perder" os records, porque ninguém mais os consulta. Por isso recrie a zona no destino antes de trocar a delegação.

Posso editar a zona sem trocar o nameserver?

Sim, e na maioria das vezes é o que você quer. Se a zona já está hospedada onde você precisa, basta editar os records ali (adicionar um A, mudar o MX) sem mexer na delegação. Trocar o nameserver só faz sentido quando você quer mudar qual provedor hospeda a zona.

Qual a diferença entre registrador e provedor de DNS?

O registrador é onde você registra e renova o domínio e define os nameservers. O provedor de DNS é quem hospeda a zona e responde às consultas. Muitas vezes são a mesma empresa, mas não precisam ser: é comum registrar em um lugar e hospedar a zona na Cloudflare, por exemplo. Confundir os dois é a origem de metade dos problemas.

Por que sempre tem ns1 e ns2?

Por redundância. O DNS exige pelo menos dois nameservers autoritativos para que o domínio continue resolvendo se um deles cair. Os provedores entregam um par (ou mais) e cuidam de manter as zonas sincronizadas entre eles.

O que levar deste guia

Nameserver é onde a autoridade do domínio mora; zona DNS é o conjunto de records que esse servidor entrega. O registrador aponta para o nameserver; o provedor de DNS guarda a zona. Troque os nameservers e você muda onde a zona é lida — sem recriar os records no destino, o e-mail e tudo que dependia daquele MX param. Decida onde sua zona vai viver, defina os NS uma vez, gerencie os records lá, e evite dividir records entre dois provedores. Faça isso e nenhuma sexta à noite vai mais te surpreender.

RD
Autor
Rafael Duarte
Desenvolvedor backend com passagem por fintech e SaaS B2B — trabalhou em times que escalaram APIs de zero a milhões de requisições. Carrega cicatrizes de produção suficientes para ter opiniões fortes sobre ferramentas, padrões e decisões de arquitetura. Não é acadêmico: leu a RFC do UUID quando precisou escolher entre v4 e v7 para uma tabela de alta escrita.
Ver perfil