Arquivo de zona DNS: registros, nomes e TTLs

Um arquivo de zona DNS é uma representação em texto dos registros DNS de uma zona, como example.com. Ele descreve os nomes e os dados associados a eles, incluindo endereços, aliases, servidores de e-mail, servidores de nomes e políticas em texto. Muitos provedores gerenciados escondem o arquivo bruto atrás de uma interface web, mas as exportações e importações ainda usam os conceitos de arquivo de zona. Entender o formato é valioso durante migrações de provedor, auditorias e solução de problemas, porque um registro pode ser sintaticamente válido e, ainda assim, estar associado ao nome errado ou ser interpretado com um padrão inesperado. Uma revisão cuidadosa deve considerar tanto o conteúdo de cada registro quanto o contexto da zona em que ele aparece.

As partes de um registro de recurso

Um registro de recurso geralmente inclui um nome de proprietário, um TTL opcional, uma classe (normalmente IN, de dados da internet), um tipo de registro e dados específicos do tipo. Uma linha de registro A contém um endereço IPv4; uma linha MX contém uma preferência e o nome de host do servidor de e-mail; uma linha CNAME contém o nome canônico de destino. Os arquivos de zona podem usar nomes relativos, em que o proprietário é interpretado em relação à origem da zona, e símbolos especiais como @ para representar o apex da zona. Um ponto final pode marcar um nome totalmente qualificado. Ao importar dados, confundir nomes relativos e absolutos pode criar sem querer um sufixo de domínio repetido.

O apex da zona é o nome puro da zona, como example.com, e costuma ser representado por @ em um arquivo de zona. É nele que ficam os registros SOA e NS da zona. Os registros A e AAAA no apex publicam endereços, enquanto proprietários de subdomínio, como www ou mail, representam nomes separados. Alguns provedores oferecem recursos de ALIAS ou flattening que parecem um endereço no apex, mas seguem um nome de host por trás dos panos; são comportamentos específicos do provedor, e não registros CNAME comuns na raiz. Durante uma migração, verifique como o provedor de destino mapeia esses recursos antes de copiá-los literalmente.

Revise a zona como um mapa completo de serviços

Não trate uma exportação de DNS apenas como a configuração de um site. A entrega de e-mail pode depender de MX, além dos registros TXT de SPF, DKIM e DMARC. A validação de propriedade para análises, serviços de busca, sistemas de certificados e plataformas SaaS pode depender de registros TXT ou CNAME. A descoberta de serviços pode usar SRV, e subdomínios delegados podem ter seus próprios registros NS. Um registro antigo que parece desconhecido ainda pode sustentar uma dependência de produção. Antes de excluir qualquer coisa, identifique o responsável e a finalidade. Se a origem for desconhecida, compare o registro com a documentação da aplicação e pergunte à equipe responsável, em vez de presumir que um hostname aparentemente sem uso pode ser removido com segurança.

• Exporte a zona completa antes de uma migração de provedor ou de uma limpeza.
• Confira com cuidado os nomes do apex e dos subdomínios, incluindo as regras de nomes relativos.
• Preserve os registros de e-mail, de verificação e de subdomínios delegados.
• Revise os TTLs e os recursos de flattening ou de proxy específicos do provedor.
• Depois da importação, consulte os servidores de nomes autoritativos e compare os registros críticos.

Como importar e validar com segurança

A importação de um arquivo de zona pode falhar por causa de tipos de registro não suportados, diferenças de formatação, proprietários duplicados ou extensões específicas do provedor. Valide o arquivo exportado antes da virada e confira no relatório de importação do provedor se algum registro foi ignorado. Se o provedor de DNS mudar, certifique-se de que a nova zona esteja preenchida antes de atualizar a delegação no registrador. Quando a delegação mudar, verifique os registros NS e consulte diretamente os registros principais. Compare as respostas ativas com a exportação de origem e execute verificações específicas do serviço para o site e o e-mail. Uma importação concluída sem erros de sintaxe não equivale a uma migração verificada: ela prova apenas que a ferramenta aceitou o arquivo.

Para o significado dos registros mais comuns, consulte tipos de registro DNS explicados. Para o lado dos servidores de nomes em uma migração, leia o que faz um registro NS. Um arquivo de zona é um inventário compacto de configuração, e o seu valor é maior quando as equipes preservam o contexto junto com as linhas brutas. Anote por que registros incomuns existem, quem é o responsável por eles e quais serviços dependem deles. Essa pequena quantidade de documentação pode evitar que uma limpeza futura remova em silêncio algo importante.

Preserve a intenção, e não apenas as linhas exportadas

Uma exportação bruta da zona é um bom backup, mas raramente explica por que um registro existe ou qual equipe depende dele. Mantenha, junto ao arquivo, um inventário que identifique o responsável pela aplicação, o fornecedor, a data de renovação ou de revisão e se o valor pode ser alterado com segurança. Esse contexto é especialmente importante para registros TXT, que podem parecer tokens aleatórios, mas servem para comprovar a propriedade do domínio ou autorizar sistemas de e-mail. Em uma auditoria, diferencie os registros ativos dos obsoletos que foram mantidos durante uma transição. Depois de importar em um novo provedor, compare tanto os dados quanto o comportamento: chaves de proxy, flattening e configurações de validação específicas do provedor podem não ser representadas como linhas comuns de arquivo de zona. Uma zona é configuração operacional, e preservar a sua intenção torna as mudanças futuras mais seguras.