Les fichiers de zone DNS expliqués : structure, accès et usages concrets

Un fichier de zone DNS est ce que le secteur du domaine possède de plus proche d'un recensement : pour un domaine de premier niveau donné, il répertorie ce qui est enregistré et la manière dont la délégation s'opère. C'est donc le point de départ naturel de toute recherche sur les domaines — mais un fichier de zone brut reste très éloigné d'une liste exploitable. Cet article détaille ce que ce fichier contient réellement, en quoi l'accès diffère entre gTLD et ccTLD, et ce qu'il faut faire subir aux données avant qu'elles ne deviennent utiles pour le SEO, l'investissement ou la prospection.

L'anatomie d'un fichier de zone DNS

Un fichier de zone DNS est un fichier texte brut qui décrit une zone DNS. Il associe des noms de domaine à des adresses IP et à d'autres ressources, définissant ainsi la manière dont le trafic d'un domaine est acheminé. À l'échelle d'un TLD, ces fichiers sont volumineux : la zone .com couvre 157,775,115 domaines, tandis qu'un ccTLD de taille moyenne peut en compter quelques centaines de milliers. Toute approche d'analyse syntaxique doit être dimensionnée pour la zone visée : ce qui fonctionne pour un petit ccTLD dans un tableur ne tiendra pas face à .com.

Les enregistrements SOA : les métadonnées de la zone

Tout fichier de zone commence par un enregistrement Start of Authority (SOA). Il porte les métadonnées de la zone : le serveur de noms primaire, l'adresse e-mail de l'administrateur en notation DNS, un numéro de série et des paramètres temporels. La valeur de rafraîchissement — la fréquence à laquelle un serveur secondaire doit interroger le primaire pour vérifier les mises à jour — se situe couramment entre une heure et 24 heures. Le numéro de série est le champ réellement utile : il s'incrémente à chaque modification, ce qui en fait un moyen économique de confirmer que la copie de zone consultée est plus récente que celle déjà en votre possession.

Les enregistrements NS : la délégation d'autorité

Les enregistrements de serveur de noms (NS) indiquent quels serveurs DNS font autorité pour un domaine. Dans un fichier de zone TLD, ce sont les enregistrements de délégation, et il s'agit généralement des seules données présentes pour chaque domaine — un fichier de zone de registre contient le plus souvent des délégations plutôt que le jeu complet des enregistrements de chaque domaine. Ils restent utiles : les configurations de serveurs de noms permettent d'identifier le registrar ou la plateforme d'hébergement derrière un domaine, et les serveurs de noms de parking connus peuvent être écartés avant tout traitement ultérieur.

Les enregistrements A et AAAA : le lien avec l'adresse IP

Les enregistrements A (IPv4) et enregistrements AAAA (IPv6) relient un domaine ou un sous-domaine à une adresse IP. Ils résident dans la zone propre au domaine, servie par les serveurs de noms auxquels le TLD délègue : les obtenir suppose donc de résoudre chaque domaine plutôt que de lire le fichier du TLD. C'est de cette étape de résolution que proviennent l'attribution de l'hébergeur et la localisation géographique, et elle coûte considérablement plus cher que l'analyse du fichier de zone lui-même.

Les enregistrements MX : les gardiens de la messagerie

Les enregistrements Mail Exchanger (MX) définissent quels serveurs traitent les e-mails d'un domaine, et dans quel ordre de priorité. Ce sont aussi, en pratique, les enregistrements qui évoluent le plus vite : un domaine peut changer de prestataire de messagerie sans aucun autre changement visible. Pour qui exploite des données de domaines afin de préparer des actions par e-mail, mieux vaut revérifier la validité des MX juste avant utilisation que de se fier à un enregistrement capturé plusieurs semaines plus tôt.

Se procurer les fichiers de zone : la fracture gTLD / ccTLD

Obtenir des données de fichiers de zone n'a rien d'un processus uniforme. L'accès varie fortement entre les domaines génériques de premier niveau (gTLD) et les domaines nationaux de premier niveau (ccTLD).

Fichiers de zone gTLD : relativement accessibles

Pour les gTLD tels que .com, .net, .org, .xyz et .app, l'accès est encadré par le Centralized Zone Data Service (CZDS) de l'ICANN. Les registres opérant sous contrat ICANN sont tenus de mettre leurs fichiers de zone à disposition des demandeurs approuvés, qui déposent une demande par TLD et acceptent des conditions d'utilisation. L'approbation se fait registre par registre et peut être refusée ou révoquée, et les fichiers sont publiés selon un cycle quotidien. Le processus est praticable, mais administratif : chaque TLD fait l'objet d'une demande distincte, et l'accès doit être entretenu.

Fichiers de zone ccTLD : le défi de l'acquisition de données

Les fichiers de zone ccTLD sont nettement plus difficiles à obtenir que ceux des gTLD. Les registres ccTLD opèrent en dehors des contrats gTLD de l'ICANN et fixent leurs propres règles. Certains publient des données de zone aux chercheurs sous convention, d'autres ne publient rien du tout, et les juridictions sensibles à la protection de la vie privée relèvent fréquemment de la seconde catégorie : DENIC pour .de et AFNIC pour .fr restreignent tous deux l'accès en masse aux zones plutôt que de les publier ouvertement. Là où un registre ne publie pas, la couverture doit être reconstituée à partir d'autres sources : DNS passif, journaux de transparence des certificats, données de crawl et jeux de données commerciaux agrégés. C'est pourquoi une base de données de domaines véritablement mondiale n'est jamais issue d'un pipeline unique.

Le problème du bruit dans les domaines nouvellement enregistrés

Les listes de domaines nouvellement enregistrés, issues des différentiels quotidiens de fichiers de zone, sont utiles mais bruitées. Une part importante des nouveaux enregistrements d'une journée correspond à des pages parkées, à des espaces réservés PPC, à des enregistrements défensifs ou à des enregistrements en masse qui n'hébergeront jamais de site réel. Travailler sur le différentiel brut, c'est travailler essentiellement sur ceux-là.

Le filtrage qui fonctionne est simple dans son principe. Écartez les domaines délégués à des serveurs de noms de parking connus. Dépriorisez les registrars dont le volume de nouveaux enregistrements est dominé par l'activité en masse. Résolvez les domaines restants et vérifiez si quelque chose répond en HTTP. Chaque couche retire une part du bruit, et ces couches sont peu coûteuses à construire au regard du coût d'une campagne de prospection ou d'une analyse menée sur une liste non filtrée.

Une mise en garde mérite d'être formulée : un filtrage agressif fondé sur les serveurs de noms produit un taux de faux positifs bien réel. Les petites entreprises et les projets personnels démarrent fréquemment sur l'hébergement le moins cher disponible, dont les serveurs de noms sont impossibles à distinguer de ceux des enregistrements en masse sans valeur. Filtrer sur les seuls serveurs de noms conduira à éliminer des domaines légitimes : mieux vaut en faire un signal parmi d'autres qu'un critère éliminatoire.

Listes fraîches contre exports périmés des marketplaces

Pour la prospection auprès de domaines nouvellement enregistrés, la fraîcheur compte davantage que le volume. La raison est mécanique plutôt que statistique : la valeur d'un nouvel enregistrement en tant que prospect tient au fait que son propriétaire est en train de configurer le domaine et prend activement des décisions d'hébergement, de design et de marketing. Une liste vieille de 30 ou 60 jours a laissé passer cette fenêtre — beaucoup de ces domaines sont déjà construits, déjà abandonnés ou déjà signalés.

Les listes en masse vendues à bas prix sur les marketplaces généralistes sont le plus souvent constituées une seule fois puis revendues à répétition, ce qui signifie que les dates d'enregistrement s'étalent sur plusieurs mois et que les destinataires ont souvent déjà été contactés. Une liste plus restreinte, générée à partir d'un différentiel de zone actuel et filtrée sur les TLD et les plateformes que vous ciblez réellement, constitue un actif d'une tout autre nature, même si son coût par ligne est plus élevé.

À retenir

1. Validez les enregistrements MX juste avant utilisation. Les données MX vieillissent plus vite que presque tout le reste dans un enregistrement de domaine. Revérifiez avant une campagne plutôt que de faire confiance à un enregistrement capturé plus tôt. Difficulté : modérée.
2. Filtrez les nouveaux enregistrements sur plusieurs signaux. Combinez la détection des serveurs de noms de parking, les schémas par registrar et une vérification HTTP basique. Pris isolément, chacun de ces critères produit soit trop de bruit, soit trop de faux négatifs. Difficulté : élevée.
3. Privilégiez la fraîcheur au volume pour la prospection. Une liste actuelle et ciblée, générée à un rythme hebdomadaire ou quotidien, surpasse un gros export périmé. Difficulté : faible à modérée.
4. Ne présumez pas d'un format de fichier uniforme. Les fichiers de zone diffèrent d'un registre à l'autre par les types d'enregistrements, les conventions de commentaires et l'encodage. Concevez l'analyseur pour qu'il échoue bruyamment sur une entrée inattendue plutôt qu'il n'abandonne silencieusement des enregistrements. Difficulté : modérée.
5. Achetez des données agrégées là où l'accès direct est fermé. Lorsqu'un registre ne publie pas, négocier un accès vaut rarement le temps investi. Le catalogue WebTrackly couvre 716 zones TLD sous forme de téléchargements CSV prêts à l'emploi. Difficulté : faible.

Foire aux questions

À quelle fréquence les fichiers de zone DNS sont-ils mis à jour ?

La fréquence de mise à jour varie selon le TLD. Les grands gTLD comme .com et .net publient quotidiennement, généralement en tout début de journée UTC. Certains ccTLD publient chaque semaine, plus rarement encore, voire jamais. Les fichiers de WebTrackly sont générés au moment de l'achat à partir d'une source actualisée quotidiennement : un téléchargement reflète donc l'état courant, et non un export stocké.

Puis-je obtenir la liste complète de tous les domaines à partir d'un fichier de zone ?

Un fichier de zone TLD contient les domaines délégués enregistrés sous ce TLD : en principe, oui, pour cette extension. La difficulté commence lorsqu'il s'agit de couvrir l'ensemble des TLD : l'accès aux gTLD passe par le CZDS de l'ICANN, avec une demande distincte par registre, et de nombreux ccTLD n'offrent aucun accès public. Le catalogue de zones de WebTrackly couvre 716 zones, et le jeu de données de tous les domaines enregistrés compte 272,614,863 lignes.

Quelle est la différence entre un fichier de zone DNS et une base de données WHOIS ?

Un fichier de zone DNS répertorie des noms de domaine et leurs enregistrements de délégation, décrivant ainsi la manière dont le trafic est acheminé. Une base de données WHOIS contient les métadonnées d'enregistrement — registrar, dates d'enregistrement et d'expiration et, lorsqu'elles ne sont pas masquées, les coordonnées du titulaire. Les deux répondent à des questions différentes. Les packs WebTrackly couvrent le volet zones et technologies ; ils contiennent des domaines, pas des données de contact personnelles.

Quelle est l'utilité des données de domaines nouvellement enregistrés pour la génération de leads ?

Elles indiquent de façon fiable quels domaines ont été enregistrés et à quel moment, ce qui constitue un véritable signal temporel. Elles ne disent pas qui les a enregistrés, ni si l'enregistrement correspond à une activité réelle — une part importante des nouveaux enregistrements d'une journée sont parkés ou défensifs. C'est le filtrage par serveur de noms, par registrar et par une vérification HTTP basique qui transforme le différentiel brut en matière exploitable, la recherche des contacts restant une étape distincte, menée avec vos propres outils.