Nameserver x zona DNS: a diferença e por que o e-mail cai

Troquei os nameservers 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. O domínio estava certo, o DNS "tinha sido configurado", e mesmo assim algo quebrou. O problema não era o nameserver novo em si: era eu ter mudado o lugar onde a zona DNS é lida sem levar junto os registros que estavam na zona antiga.

Os painéis misturam os dois conceitos o tempo todo, e o registrador ainda chama nameserver de "servidor DNS". Este post separa as duas coisas: o que é um nameserver, o que é uma zona DNS, como uma delega para a outra e por que trocar o primeiro derruba o e-mail. O passo a passo de apontar um domínio para uma hospedagem, com prazos de propagação medidos, está no post irmão como apontar domínio para hospedagem; aqui o foco é o conceito e a migração sem perder registro.

Nameserver: o servidor que responde pelo domínio

Nameserver (ou servidor DNS, como aparece no Registro.br e na maioria dos painéis brasileiros) é o servidor que tem autoridade para responder as consultas de um domínio. Quando um resolvedor quer saber o IP de exemplo.com.br, a resposta final vem do nameserver autoritativo daquele domínio. Os nomes costumam ter cara de ns1.provedor.com e ns2.provedor.com.

O nameserver não é os seus dados. Ele é o endereço onde os dados moram. Trocar o nameserver é dizer ao mundo: "a partir de agora, pergunte sobre este domínio naquele outro lugar". O que existe nesse outro lugar é problema seu.

Por que sempre vêm em par? A RFC 1034 (seção 4.1) diz que toda zona deve estar disponível em pelo menos dois servidores, "por decreto administrativo", e a RFC 2182 lembra que as regras de registro de domínio também cobram esse mínimo (e recomenda três para zonas de organizações). Tecnicamente, um domínio com um único nameserver resolve; ele só fica sem redundância, e o registrador normalmente nem deixa salvar assim.

Zona DNS: o conjunto de registros

A zona DNS é o conteúdo: todos os registros do domínio. É nela que vivem o A (IPv4), o AAAA (IPv6), o CNAME (apelido para outro nome), o MX (para onde vai o e-mail), os TXT (SPF, DKIM, DMARC, verificações de Google e afins), além do SOA e dos próprios NS. O que cada tipo faz está detalhado em tipos de registro DNS; aqui basta ver uma zona inteira:

$ORIGIN exemplo.com.br.
@       3600  IN  SOA   ns1.provedor.com. admin.exemplo.com.br. (2026110901 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 mx.provedor-de-email.com.
@       3600  IN  TXT   "v=spf1 include:_spf.provedor-de-email.com ~all"
sel1._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

A relação cabe numa frase: o nameserver é o servidor; a zona é o que ele serve. Um nameserver sem a sua zona não tem o que responder, e uma zona que nenhum nameserver delegado hospeda não é consultada por ninguém.

Delegação: como o mundo descobre quem manda

No registrador existe um campo de nameservers. O que você põe ali é publicado na zona do TLD (.br, .com) como registros NS, e funciona como placa de sinalização: "para este domínio, pergunte a estes servidores". Dá para ver a placa perguntando direto ao servidor do TLD, sem cache no meio:

$ dig uol.com.br NS @a.dns.br +norec
;; AUTHORITY SECTION:
uol.com.br.   3600  IN  NS  eliot.uol.com.br.
uol.com.br.   3600  IN  NS  borges.uol.com.br.
uol.com.br.   3600  IN  NS  charles.uol.com.br.

(Saída real, consultada em 9 de novembro de 2026.) Repare na seção: AUTHORITY, não ANSWER. O servidor do .br não sabe o IP de uol.com.br; ele só sabe quem sabe. O caminho inteiro de uma consulta, da raiz ao autoritativo, está em como funciona uma consulta DNS.

Daí vêm os dois lugares onde "se mexe em DNS", que não são a mesma coisa:

• Registrador (onde você registrou o domínio): define para quais nameservers o domínio é delegado.
• Provedor de DNS (o próprio registrador, a hospedagem, Cloudflare, Route 53): guarda a zona e responde as consultas.

Podem ser a mesma empresa, e muitas vezes são, o que piora a confusão. Se os nameservers apontam para a Cloudflare, editar a zona no painel do registrador não muda nada: aquela zona continua existindo, só que ninguém mais pergunta por ela.

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

Foi exatamente isso na minha sexta à noite. Ao trocar os nameservers, a zona que passa a valer é a do provedor novo. Ela pode estar vazia, ter só os registros padrão que o provedor cria, ou ter uma cópia parcial. Alguns provedores varrem o DNS atual e importam registros quando você adiciona o domínio; a Cloudflare faz isso, mas a própria documentação avisa que a varredura é baseada em nomes comuns e não garante encontrar tudo. Um seletor DKIM com nome próprio, como sel1._domainkey, é o tipo de registro que fica para trás.

Sem o MX, quem tenta te mandar e-mail não acha o servidor de e-mail. Pior: pela RFC 5321 (seção 5.1), quando o domínio não tem MX, o remetente tenta entregar no próprio endereço do domínio (o A), que agora é o servidor do site, que não recebe e-mail. Sem o SPF e o DKIM, o que você envia passa a cair em spam ou ser rejeitado. O site continua no ar, porque o A foi a única coisa que você lembrou de criar.

E tem a transição. A delegação no TLD tem TTL próprio, de horas a dois dias dependendo do TLD (os números medidos estão no guia de apontamento). Durante esse tempo, parte dos resolvedores ainda consulta os nameservers antigos e parte já consulta os novos. Se você apagou a zona antiga, ou cancelou a conta, quem ainda está no cache antigo também fica sem resposta. Os dois lados precisam estar corretos ao mesmo tempo.

Como migrar a zona sem derrubar nada

A regra é uma só: a zona nova precisa estar completa antes de você trocar a delegação. Na prática:

1. Exporte a zona antiga. Muitos painéis oferecem exportar em formato de arquivo de zona (BIND). Se não oferecer, liste tudo na tela. Não confie em dig ANY nem em transferência de zona (AXFR): a RFC 8482 permite que o servidor responda ANY com uma resposta mínima, e o AXFR quase sempre é recusado para quem não é servidor secundário. Pedi um AXFR aos nameservers da Cloudflare para um domínio meu e a resposta foi Transfer failed.
2. Recrie tudo no provedor novo, com atenção ao que a varredura costuma perder: MX, TXT de SPF e DMARC na raiz, DKIM em seletor._domainkey, subdomínios e o AAAA, se existir.
3. Compare as duas zonas perguntando direto a cada nameserver, antes da troca. Na maioria dos provedores, o nameserver novo já responde pela zona assim que você cadastra o domínio, mesmo antes de a delegação apontar para ele:

# o que a zona antiga responde
dig @ns1.provedor-antigo.com exemplo.com.br MX +short
dig @ns1.provedor-antigo.com exemplo.com.br TXT +short

# o que a zona nova vai responder depois da troca
dig @ns1.provedor-novo.com exemplo.com.br MX +short
dig @ns1.provedor-novo.com exemplo.com.br TXT +short

Se a zona nova devolve vazio onde a antiga tem MX, você acabou de evitar a minha sexta-feira.

4. Troque os nameservers no registrador e mantenha a zona antiga intacta por pelo menos alguns dias, até o TTL da delegação vencer em todo lugar.

Um teste a mais vale para o AAAA: abra o Qual é meu IP e veja se a sua conexão sai por IPv6. Se sair, o seu navegador vai seguir o AAAA da zona nova; se você esqueceu de copiá-lo, ou copiou um velho, é por IPv6 que o problema aparece primeiro, e só para quem tem IPv6.

Perguntas frequentes

Trocar o nameserver apaga meus registros?

Não apaga os do provedor antigo: eles continuam lá enquanto a conta existir. Mas deixam de ser consultados, porque as perguntas passam a ir para o nameserver novo, com a zona dele. Na prática, é como perder os registros. Recrie a zona no destino antes de trocar a delegação.

Posso editar a zona sem trocar o nameserver?

Pode, e na maioria das vezes é o que você quer. Se a zona já está hospedada onde precisa, basta editar os registros ali (criar um A, mudar o MX). 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 hospeda a zona e responde as consultas. Podem ser a mesma empresa, mas é comum registrar num lugar e hospedar a zona em outro.

Quanto tempo leva para a troca de nameserver valer?

Depende do TTL da delegação no TLD e do cache de cada resolvedor: de minutos a cerca de dois dias. Durante a transição as duas zonas são consultadas, por isso as duas precisam estar certas. Os prazos medidos em .com.br e .com estão no guia de apontamento.

Nameserver diz onde, zona diz o quê

Nameserver é o endereço da autoridade; zona DNS é o conteúdo que essa autoridade entrega. O registrador aponta para o nameserver, o provedor de DNS guarda a zona. Trocar os nameservers muda onde a zona é lida, não copia nada: monte a zona nova completa, compare com dig direto nos dois nameservers, e só então troque a delegação, deixando a zona antiga viva até o cache vencer. E não troque nameserver numa sexta à noite.