Migrar zonas de outro servidor DNS
Trazer as zonas de um BIND9 ou de outro autoritativo para o Made4DNS, sem tirar os domínios do ar.
Quase toda implantação começa aqui: já existe um servidor DNS respondendo pelos domínios dos clientes, e ele precisa ser substituído sem que nenhum domínio pare.
A boa notícia é que DNS foi feito para isso. As zonas podem viver nos dois servidores ao mesmo tempo enquanto você valida, e a troca é feita depois, num único passo controlado.
A regra que torna a migração segura
Traga as zonas primeiro, troque a delegação por último. Enquanto os servidores de nomes publicados no registrador continuarem apontando para o servidor antigo, nada muda para o usuário final — você pode importar, conferir e corrigir com calma.
Antes de começar
Levante a lista de zonas do servidor antigo, e de onde ele responde.
Confirme que o Made4DNS alcança o servidor antigo na porta 53, TCP. A A transferência de uma zona inteira do servidor primário para o secundário, protegida por TSIG e por lista de IPs. usa TCP, não UDP — teste em Ferramentas → Porta. É a causa número um de importação que não sai do lugar.
Peça a quem administra o servidor antigo para autorizar este servidor a transferir as zonas. Sem isso, ele recusa — e é o segundo motivo mais comum de falha.
Onde clicar, passo a passo
As opções de importação ficam no menu ao lado de Nova Zona.
| Caminho | Traz | Use quando |
|---|---|---|
| Importar via AXFR | A zona ao vivo, direto do servidor antigo | Há conectividade entre os dois. É o caminho preferido: sem cópia manual, sem erro de digitação |
| Importar BIND/Knot | A zona a partir do arquivo | Não há conectividade, ou o servidor antigo é de terceiros e só te entregam o arquivo |
O resultado é o mesmo. A diferença é operacional.
O próprio formulário mostra o que precisa estar no servidor de origem — as duas linhas que autorizam este servidor a transferir e a receber aviso de mudança. Copie e entregue a quem administra o servidor antigo.
Informe o endereço dele e o nome da zona. A autenticação por chave de transferência é opcional, e obrigatória se o servidor antigo exigir.
Repita zona por zona. Ao fim, confira a contagem de registros de cada uma contra o servidor antigo — importação parcial é silenciosa.
Aceita o arquivo no formato padrão, o mesmo que o BIND usa. O produto interpreta e mostra o que entendeu antes de criar — vale conferir aí, não depois.
Há um caso específico e chato: durante a convivência, o servidor antigo manda aviso de mudança para este servidor, e o aviso chega na camada de entrada em vez de chegar ao autoritativo.
Para isso existe um modelo aditivo de firewall que redireciona esse tráfego. Ele é temporário: aplique durante a migração e remova depois — o próprio modelo avisa disso.
A ordem da virada
O diagrama resume o estado durante a convivência: os dois servidores no ar, a zona vindo do antigo por transferência, e a delegação — a linha tracejada — sendo o último item a mudar.
Importar e conferir
Todas as zonas trazidas, com a contagem de registros batendo. Consulte cada uma direto neste servidor, em Ferramentas, e compare com a resposta do servidor antigo. Elas têm que ser idênticas.
Reduzir o tempo de cache dos registros de delegação
Um a dois dias antes da virada, no servidor antigo. É isso que faz a troca ser rápida em vez de arrastada — sem esse passo, parte do mundo continua indo ao servidor antigo por até o Por quantos segundos uma resposta pode ficar em cache antes de ser consultada de novo. antigo, que costuma ser longo.
Manter os dois no ar
Enquanto a delegação não muda, o servidor antigo continua atendendo. Este aqui já responde certo para quem perguntar diretamente — e é assim que você testa sem risco.
Trocar a delegação no registrador
Os servidores de nomes do domínio passam a apontar para este servidor. É o único passo que muda o que o usuário final enxerga.
Acompanhar a migração do tráfego
O volume sobe aqui e cai no servidor antigo. Acompanhe no Dashboard e em Relatórios → Consumo.
Só então desligar o antigo
Espere o tempo de cache antigo expirar inteiro e o tráfego lá zerar. Desligar cedo tira do ar quem ainda tinha a delegação antiga em cache.
Depois de migrar
- Configure a replicação para os secundários — as autorizações de transferência do servidor antigo não vêm junto;
- Reveja o tempo de cache dos registros que você reduziu para a virada;
- Se as zonas eram assinadas, A assinatura criptográfica das respostas DNS, que permite detectar adulteração no caminho. não migra sozinho — veja abaixo;
- Remova o modelo aditivo de firewall, se usou.
Zona assinada com DNSSEC exige um plano próprio
As chaves ficam no servidor antigo e não são transferidas com a zona. Migrar uma zona assinada sem tratar isso quebra o domínio para quem valida assinaturas.
O caminho seguro é remover o registro DS no registrador, esperar a propagação completa, migrar, e só então assinar de novo aqui e publicar o DS novo.
Armadilhas
- Trocar a delegação antes de conferir — se a importação veio incompleta, o domínio quebra.
- Esquecer que transferência de zona é TCP. Firewall que só libera UDP/53 deixa tudo parado.
- Não pedir a autorização no servidor antigo, e culpar a rede.
- Não reduzir o tempo de cache antes — a virada arrasta por horas ou dias.
- Desligar o servidor antigo cedo demais.
- Migrar zona assinada sem plano de DNSSEC.
- Importar e achar que a réplica interna está pronta: os secundários são configuração à parte.