Arquivos de Zona DNS Explicados: Estrutura, Acesso e Uso Prático

Um arquivo de zona DNS é o que a indústria de domínios tem de mais próximo a um censo: para um determinado domínio de topo, ele lista o que está registrado e como está delegado. Isso o torna o ponto de partida natural para pesquisa de domínios — mas um arquivo de zona bruto está longe de ser uma lista acionável. Este artigo explica o que o arquivo realmente contém, como o acesso difere entre gTLDs e ccTLDs e o que precisa acontecer com os dados antes que eles sirvam para trabalhos de SEO, investimento ou prospecção.

A anatomia de um arquivo de zona DNS

Um arquivo de zona DNS é um arquivo de texto simples que descreve uma zona DNS. Ele associa nomes de domínio a endereços IP e outros recursos, definindo como o tráfego de um domínio é roteado. Na escala de um TLD, esses arquivos são enormes: a zona .com abrange 157.775.115 domínios, enquanto um ccTLD de porte médio pode conter algumas centenas de milhares. Qualquer abordagem de parsing precisa ser dimensionada para a zona que se pretende processar — o que funciona para um ccTLD pequeno em uma planilha não sobrevive ao .com.

Registros SOA: os metadados da zona

Todo arquivo de zona começa com um registro Start of Authority (SOA). Ele contém os metadados da zona: o nameserver primário, o endereço de e-mail do administrador em notação DNS, um número de série e parâmetros de temporização. O valor de refresh — com que frequência um servidor secundário deve consultar o primário em busca de atualizações — costuma ficar entre uma hora e 24 horas. O número de série é o campo mais prático: ele é incrementado a cada alteração, o que oferece uma forma barata de confirmar que você está diante de uma cópia mais recente da zona do que a que já possui.

Registros NS: delegação de autoridade

Os registros de nameserver (NS) indicam quais servidores DNS são autoritativos para um domínio. No arquivo de zona de um TLD, eles são os registros de delegação e normalmente são o único dado presente por domínio — um arquivo de zona de registry costuma conter delegações, e não o conjunto completo de registros de cada domínio. Ainda assim são úteis: padrões de nameserver identificam o registrar ou a plataforma de hospedagem por trás de um domínio, e nameservers de parking conhecidos podem ser filtrados antes de qualquer processamento posterior.

Registros A e AAAA: a ligação com o endereço IP

Os registros A (IPv4) e registros AAAA (IPv6) associam um domínio ou subdomínio a um endereço IP. Eles residem na zona do próprio domínio, servida pelos nameservers para os quais o TLD delega, de modo que obtê-los exige resolver cada domínio em vez de ler o arquivo do TLD. É nessa etapa de resolução que surgem a atribuição de provedor de hospedagem e de localização geográfica, e ela é consideravelmente mais cara do que fazer o parsing do próprio arquivo de zona.

Registros MX: os porteiros do e-mail

Os registros Mail Exchanger (MX) definem quais servidores tratam o e-mail de um domínio e em que ordem de prioridade. Na prática, também são os registros que mudam mais rápido: um domínio pode trocar de provedor de e-mail sem nenhuma outra alteração visível. Para quem usa dados de domínio no planejamento de ações por e-mail, vale reverificar a validade dos MX próximo ao momento do uso, em vez de confiar em um registro capturado semanas antes.

Como obter arquivos de zona: a divisão entre gTLD e ccTLD

Obter dados de arquivos de zona não é um processo uniforme. O acesso varia bastante entre Domínios Genéricos de Topo (gTLDs) e Domínios de Topo de Código de País (ccTLDs).

Arquivos de zona de gTLD: relativamente acessíveis

Para gTLDs como .com, .net, .org, .xyz e .app, o acesso é regido pelo Centralized Zone Data Service (CZDS) da ICANN. Os registries que operam sob contrato com a ICANN são obrigados a disponibilizar arquivos de zona a solicitantes aprovados, que se candidatam por TLD e aceitam os termos de uso. A aprovação é concedida por registry e pode ser negada ou revogada, e os arquivos são publicados em ciclo diário. O processo é viável, mas burocrático: cada TLD exige uma solicitação separada, e o acesso precisa ser mantido.

Arquivos de zona de ccTLD: o desafio de aquisição de dados

Arquivos de zona de ccTLD são consideravelmente mais difíceis de obter do que os de gTLD. Os registries de ccTLD operam fora dos contratos de gTLD da ICANN e definem suas próprias políticas. Alguns publicam dados de zona para pesquisadores mediante acordo, outros não publicam absolutamente nada, e jurisdições sensíveis à privacidade costumam ficar no segundo grupo — DENIC, para o .de, e AFNIC, para o .fr, restringem o acesso em massa à zona em vez de publicá-la abertamente. É por isso que, quando um registry não publica, a cobertura precisa ser montada a partir de outras fontes: DNS passivo, logs de certificate transparency, dados de crawling e conjuntos de dados comerciais agregados. E é por isso que um banco de dados de domínios verdadeiramente global nunca é um único pipeline.

O problema do ruído em domínios recém-registrados

As listas de domínios recém-registrados, derivadas de diffs diários de arquivos de zona, são úteis, mas ruidosas. Boa parte dos novos registros de qualquer dia são páginas de parking, placeholders de PPC, registros defensivos ou registros em massa que jamais hospedarão um site real. Trabalhar com o diff bruto significa trabalhar principalmente com esse tipo de domínio.

A filtragem que ajuda é simples em princípio. Descarte domínios delegados a nameservers de parking conhecidos. Reduza a prioridade de registrars cujo volume de novos registros é dominado por atividade em massa. Resolva os que sobraram e verifique se algo responde em HTTP. Cada camada elimina uma parte do ruído, e as camadas são baratas de construir em comparação com o custo de rodar prospecção ou análise sobre uma lista não filtrada.

Uma ressalva importante: a filtragem agressiva baseada em nameservers tem uma taxa real de falsos positivos. Pequenas empresas e projetos pessoais frequentemente começam na hospedagem mais barata disponível, cujos nameservers são indistinguíveis dos de registros em massa de baixo valor. Filtrar apenas por nameserver descarta domínios legítimos, então é melhor usá-lo como um sinal entre vários do que como um corte definitivo.

Listas atualizadas x despejos velhos de marketplace

Na prospecção de domínios recém-registrados, a atualidade importa mais do que o volume. A razão é mecânica, não estatística: o valor de um novo registro como prospect está no fato de que o proprietário está configurando o domínio naquele momento e tomando ativamente decisões sobre hospedagem, design e marketing. Uma lista com 30 ou 60 dias já perdeu essa janela — muitos desses domínios já estão prontos, já foram abandonados ou já foram sinalizados.

Listas em massa vendidas a preço baixo em marketplaces genéricos costumam ser montadas uma única vez e revendidas repetidamente, o que significa que as datas de registro se espalham por meses e que os destinatários muitas vezes já foram contatados antes. Uma lista menor, gerada a partir de um diff de zona atual e filtrada para os TLDs e as plataformas que você de fato quer atingir, é um ativo de outra natureza, ainda que custe mais por linha.

Conclusões práticas

1. Valide os registros MX próximo ao uso. Os dados de MX envelhecem mais rápido do que quase qualquer outro registro de domínio. Reverifique antes de uma campanha em vez de confiar em um registro capturado antes. Dificuldade: moderada.
2. Filtre novos registros com mais de um sinal. Combine detecção de nameservers de parking, padrões de registrar e uma checagem básica de HTTP. Qualquer um deles isoladamente gera ruído demais ou falsos negativos demais. Dificuldade: alta.
3. Priorize atualidade em vez de volume na prospecção. Uma lista atual e enxuta, gerada em cadência semanal ou diária, rende mais do que um grande despejo desatualizado. Dificuldade: baixa a moderada.
4. Não presuma um formato de arquivo uniforme. Os arquivos de zona variam em tipos de registro, convenções de comentário e codificação de um registry para outro. Construa o parser para falhar de forma explícita diante de entradas inesperadas, em vez de descartar registros silenciosamente. Dificuldade: moderada.
5. Compre dados agregados onde o acesso direto está fechado. Quando um registry não publica, negociar acesso raramente compensa o tempo investido. O catálogo da WebTrackly cobre 716 zonas de TLD como downloads CSV prontos para uso. Dificuldade: baixa.

Perguntas frequentes

Com que frequência os arquivos de zona DNS são atualizados?

A frequência de atualização varia conforme o TLD. Os principais gTLDs, como .com e .net, publicam diariamente, em geral nas primeiras horas UTC. Alguns ccTLDs publicam semanalmente, com menor frequência ou simplesmente não publicam. Os arquivos da WebTrackly são gerados no momento da compra a partir de uma fonte atualizada diariamente, de modo que o download reflete o estado atual e não uma exportação armazenada.

É possível obter a lista completa de todos os domínios a partir de um arquivo de zona?

Um arquivo de zona de TLD contém os domínios delegados registrados sob aquele TLD, portanto, em princípio, sim — para aquela extensão específica. Fazer isso para todos os TLDs é a parte difícil: o acesso a gTLDs passa pelo CZDS da ICANN, com uma solicitação separada por registry, e muitos ccTLDs não oferecem acesso público algum. O catálogo de zonas da WebTrackly cobre 716 zonas, e o conjunto de dados de todos os domínios registrados reúne 272.614.863 linhas.

Qual é a diferença entre um arquivo de zona DNS e um banco de dados WHOIS?

Um arquivo de zona DNS lista nomes de domínio e seus registros de delegação, descrevendo como o tráfego é roteado. Um banco de dados WHOIS guarda metadados de registro — registrar, datas de registro e expiração e, quando não estão ocultos, os dados do titular. Os dois respondem a perguntas diferentes. Os pacotes da WebTrackly cobrem o lado da zona e das tecnologias; eles contêm domínios, não dados de contato pessoais.

Quão úteis são os dados de domínios recém-registrados para geração de leads?

Eles dizem com segurança quais domínios foram registrados e quando, o que é um sinal de timing genuíno. Não dizem quem os registrou nem se o registro corresponde a um negócio real — boa parte dos novos registros de qualquer dia é de domínios em parking ou defensivos. Filtrar por nameserver, registrar e uma checagem básica de HTTP é o que transforma o diff bruto em algo que vale a pena acionar, e a descoberta de contatos continua sendo uma etapa à parte, feita com suas próprias ferramentas.