Diagnostic DNS

Rechercher un seul type d'enregistrement répond à une question précise : cet enregistrement existe-t-il, et que dit-il. Un diagnostic répond à une autre question : la chaîne de délégation est-elle cohérente d'un bout à l'autre, et tiendra-t-elle en cas de panne partielle. Un domaine peut avoir un enregistrement MX parfaitement formé et perdre quand même ses emails si ses nameservers sont "lame" (non autoritaires), si le numéro de série SOA diverge entre serveurs, ou si les deux seuls nameservers du domaine se trouvent sur le même sous-réseau chez le même fournisseur.

La chaîne part de la zone parente : les serveurs du TLD portent les enregistrements NS (et, idéalement, les enregistrements glue) qui pointent vers les nameservers du domaine. Ces nameservers doivent effectivement répondre en autorité pour la zone - un serveur listé dans la délégation mais non configuré pour servir la zone est dit "lame", et une délégation lame est l'une des causes les plus fréquentes d'échecs de résolution intermittents, invisibles lors d'un simple contrôle ponctuel.

Un diagnostic complet croise aussi des valeurs qui n'ont de sens que les unes par rapport aux autres : les intervalles REFRESH et RETRY du SOA définis par la RFC 1035 pour la synchronisation secondaire-primaire, la cohérence du numéro de série SOA entre tous les nameservers, et la répartition des nameservers sur des réseaux et systèmes autonomes différents pour qu'une seule panne ne coupe pas toute la zone - un point sensible pour les hébergeurs français qui délèguent parfois chez OVHcloud ou Gandi sans vérifier cette diversité.

• Délégation parente - enregistrements NS au niveau du TLD, glue quand le nameserver vit dans le domaine lui-même
• Santé des nameservers - autoritaires (non lame), joignables publiquement, répartis sur des sous-réseaux et AS différents
• Cohérence du SOA - REFRESH/RETRY/EXPIRE/MINIMUM dans des plages raisonnables, même numéro de série partout
• Posture mail et sécurité - joignabilité des MX, présence et robustesse de SPF/DMARC, état de la chaîne DNSSEC

Les résultats sont regroupés dans les catégories que l'outil vérifie réellement : Parent, Nameservers (NS), SOA, MX, Security et WWW. Chaque contrôle renvoie pass, warning, fail ou info, et la plupart affichent le détail brut derrière le verdict - les noms des nameservers, les valeurs du SOA, la chaîne SPF - de sorte qu'un warning n'est jamais qu'une couleur, il s'accompagne toujours de l'enregistrement qui l'a produit.

La catégorie Parent confirme que le domaine est correctement délégué : les enregistrements NS existent au niveau parent, le TLD résout, et les nameservers de l'enfant apparaissent là où le parent les attend. La catégorie Nameservers va plus loin en testant chaque serveur : répond-il en autorité, accepte-t-il la récursion ouverte (un risque de sécurité), accepte-t-il TCP (nécessaire pour les réponses volumineuses ou signées DNSSEC), et les serveurs sont-ils assez diversifiés en réseau pour qu'une panne chez un seul opérateur amont ne les fasse pas tomber tous ensemble.

La catégorie SOA vérifie l'enregistrement que la plupart des administrateurs ne consultent jamais directement. Son numéro de série doit être identique sur tous les nameservers - un écart signifie qu'un transfert de zone a échoué ou est encore en cours. Ses valeurs REFRESH et RETRY déterminent la fréquence à laquelle les secondaires interrogent le primaire ; des valeurs très éloignées des pratiques courantes sont signalées en avertissement plutôt qu'en échec, la RFC 1035 ne fixant aucune borne stricte - seulement des valeurs par défaut raisonnables.

MX, Security et WWW complètent le tableau : les serveurs mail résolvent-ils et sont-ils joignables, les enregistrements SPF et DMARC existent-ils et quelle est la robustesse de leur politique (un DMARC en p=none surveille mais n'impose rien, par exemple), la signature DNSSEC est-elle présente et complète, et la chaîne A/CNAME du site lui-même est-elle publique et correctement configurée.

Les échecs à traiter en priorité sont ceux sans filet de sécurité : un nameserver lame que le parent délègue encore, une chaîne NS-vers-A cassée qui rend un serveur injoignable, ou un écart de numéro de série SOA qui signifie que des secondaires servent des données périmées. Ces cas provoquent directement des échecs de résolution intermittents ou totaux pour une partie des requêtes, et cette part grandit à mesure que les caches expirent.

Plusieurs contrôles se lisent mieux comme de la posture que comme une panne. Deux nameservers au lieu de trois est un avertissement sur la marge de redondance, pas le signe que quelque chose est cassé - la RFC 2182 recommande plusieurs serveurs sur des réseaux distincts pour la résilience mais n'impose aucun nombre précis. De même, tous les nameservers sur un seul système autonome est signalé même quand cet AS appartient à un grand réseau anycast (plusieurs fournisseurs DNS majeurs fonctionnent volontairement ainsi) - le contrôle ne distingue pas toujours "une installation ancienne chez un seul opérateur" d'un "anycast mondialement distribué", donc un résultat mono-AS mérite un second regard avant d'y voir un risque réel.

Le statut DNSSEC revient souvent en "non détecté" pour les domaines qui n'ont jamais activé la fonctionnalité, ce qui est informatif et non un échec - l'adoption de DNSSEC reste optionnelle selon la RFC 4033, et son absence n'indique pas en soi une mauvaise configuration, seulement que le résolveur ne peut pas valider cryptographiquement la chaîne pour cette zone. Pour un domaine où DNSSEC est activé et dont on veut voir le détail des enregistrements DS/DNSKEY/RRSIG et l'état de la chaîne de confiance plutôt que ce résumé pass/fail, direction le vérificateur DNSSEC dédié.