Aller au contenu
IPeek

Diagnostic DNS

Un bilan complet de délégation et de DNS

Vérification…

Qu'est-ce qu'un diagnostic DNS ?

Un diagnostic DNS inspecte la façon dont un domaine est délégué et configuré de bout en bout, et pas seulement un seul type d'enregistrement. Il demande aux serveurs du parent (le TLD) ce qu'ils publient pour votre domaine, puis interroge directement vos propres serveurs de noms, et compare les deux. Les écarts entre le parent et vos serveurs — glue manquant, listes de NS qui divergent, séries SOA désynchronisées, serveurs lame ou à récursion ouverte — sont précisément les problèmes qui rendent le DNS lent, intermittent ou silencieusement cassé. IPeek effectue chaque contrôle et vous explique, en langage clair, pourquoi chacun compte et comment le corriger.

Délégation du parent, glue et la chaîne qui trouve votre domaine

Chaque requête vers votre domaine commence à la zone parente — le registre du TLD (par exemple .fr ou .com) — qui détient les enregistrements NS pointant les résolveurs vers vos serveurs de noms. Si ces serveurs se trouvent à l'intérieur de votre propre domaine, le parent doit aussi publier leurs adresses IP sous forme de « glue », faute de quoi les résolveurs se retrouvent dans une boucle de l'œuf et de la poule. Une délégation saine voit le parent et vos propres serveurs s'accorder sur le même ensemble de NS, avec le glue présent là où il le faut. Quand ils divergent, certains résolveurs suivent des informations obsolètes et vos changements semblent fonctionner pour certains utilisateurs mais pas pour d'autres.

Santé des serveurs de noms : redondance, autorité et récursion

La RFC 2182 recommande plusieurs serveurs de noms sur des réseaux différents afin qu'une seule panne ne mette jamais votre domaine hors ligne. Chacun doit répondre de façon autoritative pour votre zone — un serveur « lame » qui ne le fait pas est un trou de fiabilité silencieux. Vos serveurs autoritatifs devraient aussi refuser la récursion aux inconnus : un serveur récursif ouvert peut être détourné pour l'empoisonnement de cache et l'amplification DDoS. IPeek interroge chacun de vos serveurs de noms directement pour confirmer qu'ils répondent, qu'ils le font de façon autoritative, qu'ils s'accordent entre eux, qu'ils prennent en charge le TCP et qu'ils gardent la récursion fermée.

Cohérence du SOA, des MX et du domaine racine

L'enregistrement SOA porte le numéro de série de votre zone et ses valeurs de temporisation ; chaque serveur de noms doit rapporter le même numéro de série, sinon votre zone est désynchronisée et les changements se propagent de façon inégale. Le numéro de série devrait suivre la convention YYYYMMDDnn, et les minuteurs refresh/retry/expire/minimum devraient se situer dans les plages recommandées par les RFC. Côté courrier, les enregistrements MX doivent être des noms d'hôte (jamais des IP nues ni des CNAME) qui résolvent vers des adresses publiques. Enfin, le domaine racine (votre domaine nu) devrait publier une adresse mais pas un CNAME, ce que la RFC 1912 interdit aux côtés d'autres enregistrements.

Questions fréquentes

En quoi est-ce différent d'une recherche DNS classique ?

Une recherche DNS vous montre les enregistrements tels qu'ils apparaissent à travers un résolveur récursif. Un diagnostic va plus loin : il interroge les serveurs du TLD parent et chacun de vos propres serveurs de noms directement, puis les compare. Cela lui permet de détecter des problèmes de délégation qu'une simple recherche masque — glue manquant, divergences de NS entre parent et enfant, serveurs lame ou en désaccord, et séries SOA désynchronisées.

Qu'est-ce que le glue et pourquoi un enregistrement glue manquant importe-t-il ?

Le glue est l'adresse IP d'un serveur de noms, publiée par la zone parente aux côtés de l'enregistrement NS. Il est requis lorsque vos serveurs de noms se trouvent dans le même domaine qu'ils servent (par exemple ns1.exemple.com servant exemple.com), car les résolveurs devraient sinon résoudre le serveur de noms avant de pouvoir résoudre quoi que ce soit. Un glue manquant dans ce cas casse la résolution ; si vos serveurs de noms sont sur un autre domaine, le glue est facultatif et ne fait qu'économiser une recherche supplémentaire.

Pourquoi mes serveurs de noms ne devraient-ils pas autoriser la récursion ?

Les serveurs de noms autoritatifs ne devraient répondre que pour les zones qu'ils hébergent. Un serveur de noms qui effectue de la récursion pour n'importe qui (un « résolveur ouvert ») peut être détourné pour des attaques DDoS par amplification DNS et est plus exposé à l'empoisonnement de cache. Si le diagnostic signale une récursion ouverte, désactivez la récursion sur le serveur autoritatif ou séparez vos rôles autoritatif et récursif sur des hôtes différents.

Que signifie le fait que mes serveurs de noms divergent sur la série SOA ?

La série SOA est un numéro de version de votre zone. Quand vos serveurs de noms rapportent des séries différentes, au moins l'un d'eux sert des données obsolètes — généralement un secondaire qui n'a pas réussi à transférer la dernière zone depuis le primaire. Le résultat, ce sont des réponses incohérentes selon le serveur que touche un résolveur. Vérifiez les transferts de zone (AXFR/IXFR), la configuration NOTIFY du primaire et le minuteur refresh du SOA.

Un seul enregistrement MX ou deux serveurs de noms posent-ils problème ?

Aucun n'est une erreur, mais les deux sont des points uniques de défaillance. Avec un seul MX, le courrier peut être perdu si ce serveur reste hors ligne assez longtemps ; un MX de secours ajoute de la résilience. Deux serveurs de noms est acceptable selon la RFC 2182, mais trois ou plus sur des réseaux différents est plus sûr. Le diagnostic signale ces points comme des avertissements, pas comme des échecs — ils méritent d'être améliorés, ce ne sont pas des urgences.