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.
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.
- 01 Salt, pepper, bcrypt e Argon2id: como proteger senhas de verdade Em 2012, o LinkedIn expôs 117mi de senhas. SHA-1 sem salt — 90% quebradas em 4h. Entenda o que cada camada de proteção resolve e por que Argon2id é a escolha certa hoje.
- 02 Licenças MIT, Apache e GPL: diferenças práticas para devs MIT, Apache 2.0 e GPL não são a mesma coisa. Entenda permissiva vs copyleft, proteção de patentes e compatibilidade antes de colocar código em produção.