Auditer la santé DNS d'un domaine

Pourquoi faire un audit complet ?

Un domaine bien configuré répond vite et de façon prévisible. Quand la délégation au parent est exacte, que chaque serveur est joignable en IPv4 et en IPv6, que le SOA est synchronisé et que les réglages de base sont propres, les pannes disparaissent presque toujours. Cet audit vérifie tout cela en remontant la chaîne réelle de résolution. Il compare d'abord la vue du parent avec la vue de votre zone, puis interroge chaque serveur pour voir s'il répond en autoritaire, s'il accepte UDP et TCP, et si ses réponses sont cohérentes avec celles de ses pairs. Vous obtenez une lecture fidèle de l'état du domaine à l'instant où vous lancez le contrôle.

Comment fonctionne l'audit ?

Le contrôle commence côté parent. Il lit la liste des NS publiée au registre, ainsi que les adresses collées au parent quand elles sont nécessaires. Ces adresses d'assistance s'appellent des glue. Elles ne servent que si le nom du serveur appartient au domaine que vous auditez. L'audit récupère ensuite la liste des NS dans la zone elle-même et compare les deux vues. S'il y a un écart, la résolution devient aléatoire. Un résolveur peut suivre la piste du parent, un autre suivre la zone. Le diagnostic remonte alors un écart parent-zone et vous dit que corriger.

Une fois la délégation validée, l'outil interroge chaque serveur. Il teste la résolution en IPv4 et en IPv6 quand c'est possible. Il mesure la latence et vérifie que le serveur répond en autoritaire pour le domaine. Il vérifie aussi que la récursion est désactivée sur un serveur autoritaire et que les transferts de zone ne sont pas ouverts à n'importe qui. Si une réponse est tronquée en UDP, il vérifie que TCP prend le relais. Ces points évitent des erreurs subtiles qui ne se voient que sous charge ou lors d'une réponse volumineuse.

Délégation, glue et lame delegation

La délégation au parent doit pointer vers des serveurs qui savent répondre en autoritaire pour votre zone. Quand le parent pointe vers un hôte qui n'est pas autoritaire, on parle de lame delegation. Les résolveurs perdent du temps, parfois renoncent, et vous voyez des SERVFAIL. L'audit repère ce cas et indique clairement le serveur qui pose souci. Il vérifie aussi la fraîcheur des glue. Une glue obsolète arrive quand l'adresse d'un NS a changé, mais que la fiche du parent n'a pas été mise à jour. Résultat simple : certains résolveurs ont l'adresse correcte via la zone, d'autres continuent d'essayer l'ancienne adresse via le parent. Le rapport vous guide pour remettre les glue à jour chez le bureau d'enregistrement.

Accessibilité réseau et transport

Un serveur autoritaire doit répondre en UDP. Il doit aussi accepter TCP quand une réponse dépasse la taille prévue. Des pare-feux trop stricts cassent ce repli. L'audit tente les deux modes et vous dit si TCP est bloqué. Il vérifie la présence d'IPv4. Il signale l'absence d'IPv6 comme une amélioration possible plutôt qu'une erreur bloquante. Il rappelle enfin qu'un serveur autoritaire ne doit pas faire de récursion et qu'un transfert de zone ne doit pas être ouvert au public. Ces points concernent la sécurité et la stabilité.

Cohérence des réponses et SOA

Tous les serveurs d'une même zone doivent publier le même ensemble NS, le même serial SOA et les mêmes données à l'instant T. Quand un serveur n'a pas reçu la dernière version, vous voyez des réponses différentes selon le serveur interrogé. Le diagnostic lit le SOA sur chaque hôte et vérifie que le serial avance de façon monotone. Il examine aussi les temporisations du SOA. Un refresh raisonnable permet aux secondaires de suivre le primaire. Un retry court accélère la reprise après un échec. Un expire suffisant évite qu'un secondaire abandonne trop vite la zone. Le minimum TTL sert au cache négatif et doit rester mesuré. Le rapport commente ces valeurs de manière pratique, sans dogme, pour coller à votre rythme de changement.

IPv4 et IPv6

La présence d'IPv6 n'est pas obligatoire, mais elle devient un standard. Activer IPv6 sur vos NS supprime une source d'erreurs côté visiteurs et robots qui privilégient cette pile quand elle existe. L'audit teste les deux piles quand elles sont publiées. Il signale l'absence d'AAAA comme une piste d'amélioration et non comme une panne.

DNSSEC si vous l'utilisez

Si votre domaine est signé, l'audit vérifie que le parent publie bien un DS qui correspond aux clés de la zone. Il lit les DNSKEY et regarde si les signatures sont valides à l'apex. Un décalage entre DS et clés casse la chaîne de confiance. Le rapport explique ce qu'il faut mettre à jour en premier et rappelle l'ordre des opérations lors d'un changement de clé.

Lire le résultat et agir

Le haut du rapport résume l'état général. Les points classés en erreurs bloquent ou dégradent franchement la résolution. Corrigez les écarts parent-zone, les glue manquantes, un TCP fermé, une lame delegation ou un serial divergent en priorité. Les points classés en avertissements améliorent la qualité sans être bloquants. Un IPv6 absent, une dispersion de NS faible, des temporisations SOA peu réalistes entrent dans cette catégorie. Chaque point s'accompagne d'une phrase d'action concrète. Vous savez que faire et où le faire, dans la zone ou chez le bureau d'enregistrement.

Scénarios concrets

Avant de changer de prestataire DNS, lancez l'audit puis réduisez les TTL des enregistrements critiques. Ajoutez les nouveaux NS, mettez la délégation à jour chez le registre, déclarez les glue si vos NS sont dans votre domaine, attendez la fin des caches, puis relancez l'audit. Vous validez que le parent et la zone racontent la même histoire et que tous les serveurs répondent en autoritaire avec le même SOA.

Après un changement d'adresse sur un NS, vérifiez immédiatement la glue au parent. Tant que l'ancienne adresse reste publiée, une partie du trafic continue d'aller au mauvais endroit. L'audit met ce point en face de vous avec l'adresse exacte à corriger.

Si des utilisateurs voient des erreurs aléatoires, consultez la section cohérence. Un serial figé ou un NS qui n'a pas reçu la dernière zone explique souvent un comportement intermittent. Le contrôle vous montre quel serveur est en retard et vous donne l'ordre de remise en ligne.

Bonnes pratiques simples

• Gardez au moins deux NS sur des réseaux distincts.
• Mettez à jour la délégation et les glue à chaque changement.
• Laissez TCP ouvert sur les autoritaires.
• Désactivez la récursion et verrouillez les transferts de zone.
• Choisissez des temporisations SOA adaptées à votre cadence de mise à jour.
• Activez IPv6 quand vous le pouvez.
• Documentez chaque modification avec la date et la raison.

Ce sont des gestes courts qui évitent des incidents longs.

Ce que vous gagnez

Un domaine qui passe l'audit ce résout partout de la même manière. Les changements se propagent selon le TTL choisi et non au hasard. Vous réduisez les tickets liés à une "propagation" interminable qui n'est en réalité qu'un cache mal anticipé. Vous détectez aussi des faiblesses qui ne se voient pas lors d'un simple lookup, comme une lame delegation ou un TCP fermé. Le résultat tient en un plan d'action clair. Vous corrigez, vous vérifiez, vous tournez la page.

Confidentialité et périmètre

Le contrôle interroge uniquement des informations publiques. Il contacte votre zone et le parent comme le ferait un résolveur. Aucune donnée privée n'est requise. L'outil ne stocke pas votre configuration. Seules des métriques techniques anonymes sont conservées pour suivre la disponibilité du service.

Avec cet audit, vous partez des faits. Parent et zone sont alignés ou ne le sont pas. Les serveurs répondent en autoritaire ou ne le font pas. Le SOA est synchronisé ou reste en arrière. Vous gagnez une vision nette de votre domaine et un chemin simple pour corriger ce qui doit l'être.