Récupérer les zones DNS d’un domaine révèle la réalité derrière chaque réponse. Avec une récupération de zone fiable et une vérification de configuration rigoureuse, vous réduisez les surprises.
Des TTL mal calibrés, des enregistrements orphelins ou des NS incohérents provoquent des pannes discrètes et des résolutions aléatoires. En pratiquant un diagnostic DNS précis et en menant un audit de domaine documenté, vous exposez les écarts, hiérarchisez les corrections et sécurisez vos changements avant toute propagation.
Préparer l’environnement : accès au registrar et au serveur DNS
Préparez un poste d’audit avec dig, nslookup et un terminal à jour, sur un réseau fiable. Prévoyez un tableur de suivi et un référentiel où consigner chaque requête et chaque sortie. Dès le départ, vérifiez l’accès au registrar pour savoir quels NS sont publiés et quelle zone est active. Un carnet d’adresses technique à jour facilite les échanges.
Côté accès, validez qui a les permissions et comment l’authentification est protégée. Assurez-vous que vos comptes administrateur utilisent une MFA et des clés d’API limitées par IP. Identifiez le serveur DNS maître déclaré par votre fournisseur, puis notez l’emplacement des secondaires et la politique de transfert. Exemple : zone gérée chez OVH, résolue sur des NS dédiés, avec un transfert limité par ACL.
Identifier le serveur faisant autorité pour le domaine (whois, NS, délégation)
Pour déterminer l’autorité, partez des données publiques et suivez la chaîne de réponse pas à pas. Lancez des requêtes whois afin d’identifier le bureau d’enregistrement, les contacts et les NS annoncés. Interrogez ensuite les serveurs de noms listés avec dig NS et dig SOA, et vérifiez qu’ils renvoient les mêmes informations. Un changement récent de TLD ou de registrar ? Les disparités se repèrent vite en comparant les réponses.
- whois exemple.tld pour les contacts et les NS annoncés.
- dig NS exemple.tld +trace pour suivre la chaîne d’autorité.
- dig SOA exemple.tld pour vérifier le serial et l’horodatage.
- Contrôler DNSSEC avec dig DS et dig DNSKEY si activé.
Astuce : un serial SOA différent entre NS indique une zone désynchronisée.
Pour valider l’autorité réelle, suivez le parcours depuis la racine jusqu’au domaine. Le +trace révèle la délégation DNS effective et les NS référencés par la TLD. Comparez les réponses des NS avec un résolveur récursif public, afin d’identifier un cache obsolète ou une propagation incomplète. Un dig A www.exemple.tld @ns-auth vs @9.9.9.9 met rapidement en évidence toute divergence.
Méthodes pour récupérer les enregistrements avec dig et nslookup
Pour interroger un domaine, utilisez dig avec des requêtes ciblées A, AAAA, MX, TXT, CNAME, NS et SOA. Ajoutez +trace pour suivre la délégation et +dnssec pour voir les drapeaux AD et CD. Avec la commande dig, précisez le résolveur @8.8.8.8 ou un NS faisant autorité, et comparez les réponses.
Sur Windows, testez nslookup interactif, puis validez les codes retour NOERROR, NXDOMAIN ou SERVFAIL. Lancez une interrogation DNS vers chaque serveur déclaré pour repérer les écarts. Avec l’outil nslookup, définissez server ns.example.tld et vérifiez les types d’enregistrements critiques via set type=MX, TXT, SRV, puis consignez les TTL et les adresses.
Extraire l’ensemble de la zone via AXFR quand c’est autorisé
Pour obtenir l’intégralité des enregistrements, ciblez le maître DNS avec dig AXFR et spécifiez le nom du domaine. Vérifiez le SOA et le serial pour confirmer l’exhaustivité. Un transfert de zone doit être lancé vers chaque serveur autoritaire identifié par les NS, car certains n’exposent pas la copie complète publiquement.
Sécurisez l’échange avec TSIG et vérifiez que TCP 53 est ouvert côté pairs. Selon la politique du fournisseur, une requête AXFR aboutit seulement depuis des adresses autorisées. Mettez à jour le contrôle d’accès, ajustez les ACL et validez l’IP source, puis journalisez la taille de la zone ainsi que la durée de transfert.
Alternatives en cas d’AXFR refusé : recensement des enregistrements visibles
Quand l’AXFR est refusé, combinez sources ouvertes et requêtes ciblées pour recenser ce qui répond publiquement. Pour amorcer l’inventaire, appuyez‑vous sur des catalogues de certificats, des bases historiques et des moteurs spécialisés. Cette approche relève de la recherche passive adaptée. Voici des points de départ efficaces.
- Archives de transparence des certificats (crt.sh, Google CT).
- Bases DNS historiques et passives (DNSDB, SecurityTrails).
- Collecteurs de surfaces d’attaque (DNSDumpster, LeakIX).
- Scanners réseau publics (Shodan, Censys).
Terminez par des vérifications dig et nslookup sur A, AAAA, MX, CNAME, TXT et SRV, puis tentez le walking NSEC si DNSSEC est présent. Pour élargir raisonnablement, introduisez un dictionnaire ciblé pour la découverte de sous-domaines et corrélez les réponses croisées. Centralisez les sources et marquez les enregistrements publics par date afin d’identifier les écarts relevés.
Vérifier la cohérence : SOA, TTL, NS, glue et propagation
Pour évaluer la cohérence, interrogez les serveurs faisant autorité et comparez leurs réponses sur plusieurs points. Contrôlez l’enregistrement SOA : numéro de série, mname, rname, refresh, retry et expire, puis auditez les valeurs TTL par type. Vérifiez l’alignement des NS au registrar et côté autorité, et testez la colle DNS glue lorsque les NS sont hébergés sous le même domaine.
Multipliez les résolutions via des FAI et résolveurs publics variés pour repérer les écarts. Surveillez la propagation globale avec des points de mesure géographiquement dispersés et utilisez dig +trace pour visualiser la chaîne de délégation. En cas de divergence, comparez les séries SOA et identifiez le serveur fautif avant d’appliquer la correction visée.
Astuce : avant une modification, abaissez temporairement le TTL puis augmentez le numéro de série SOA pour accélérer la visibilité, et restaurez un TTL plus haut après validation.
Comparer l’extrait obtenu avec la configuration du fournisseur DNS
Pour confronter vos relevés publics aux valeurs attendues, harmonisez le format : FQDN, points finaux, TTL en secondes, encodage IDN. Exposez les données dans un CSV unique, puis récupérez un export fournisseur depuis le tableau de bord du DNS. Alignez les colonnes nom, type, valeur, priorité, et ajoutez un identifiant d’environnement afin de distinguer production et préproduction.
Scriptiez un diff stable qui ignore l’ordre des enregistrements et compare les champs clés. Intégrez une comparaison de configuration qui signale les divergences : valeurs MX, SPF tronqués, CNAME en boucle ou TTL incohérents. Formalisez la gestion des écarts dans un ticketing, en traçant l’impact, le propriétaire de la correction et la date de mise en service, puis validez par un contrôle post-déploiement.
Sécuriser le processus : journalisation, export, sauvegarde et contrôle d’accès
Consignez vos opérations avec des journaux horodatés et immuables : commandes, serveurs interrogés, empreintes des fichiers. Intégrez une journalisation technique centralisée avec alertes de dérive. Limitez qui peut lire ou télécharger les exports via un contrôle d’accès fondé sur les rôles, l’authentification forte et des autorisations temporaires.
Protégez les artefacts en mettant en place une sauvegarde chiffrée hors site, testée par restauration périodique. Gérez les secrets avec un coffre et programmez la rotation des clés selon une politique définie, tout en appliquant le principe du moindre privilège, l’expiration des liens de partage et des checksums pour détecter toute altération.