Erreurs fréquentes de délégation DNS et méthode de diagnostic
Un domaine qui se résout par intermittence, un sous-domaine introuvable, une zone modifiée sans effet : presque toujours la même poignée d'erreurs de délégation. Les reconnaître suppose une méthode qui part du parent et descend, au lieu d'interroger au hasard.
La méthode : partir du parent, descendre
Le réflexe est d'interroger le résolveur local, qui répond souvent depuis son cache et masque l'état réel. La bonne séquence remonte à la racine et suit la délégation : demander à la racine, puis au serveur du domaine de premier niveau, puis à l'autorité. Chaque étape doit renvoyer soit une délégation vers des serveurs nommés, soit une réponse autoritative.
Les outils de résolution permettent de suivre ce chemin pas à pas, et surtout d'interroger un serveur précis en désactivant la récursion. Cette dernière option est la plus utile du diagnostic : elle montre ce que le serveur sait réellement, sans qu'un cache ne vienne fausser la lecture.
Un troisième contrôle complète la méthode : interroger chaque serveur cité dans les enregistrements NS, séparément. Un ensemble de NS dont un membre ne répond pas, ou répond sans autorité, produit exactement le symptôme d'une résolution intermittente, sans qu'aucune erreur n'apparaisse côté zone enfant.
La délégation boiteuse
Une délégation est dite boiteuse lorsqu'un serveur est cité dans la délégation mais ne fait pas autorité sur la zone : il ne la charge pas, ou la charge avec un autre nom. Interrogé, il renvoie une référence vers un autre serveur, ou une erreur. Le résolveur qui tombe sur lui doit alors réessayer ailleurs, ce qui ajoute latence et échecs selon la distribution des requêtes.
Le symptôme typique est un domaine qui fonctionne la plupart du temps et échoue parfois, avec des erreurs de résolution temporaires. Le diagnostic est direct : interroger le serveur suspect sans récursion pour le nom de la zone doit renvoyer une réponse autoritative. Toute autre réponse désigne le serveur à corriger, ou à retirer de la délégation.
La colle manquante ou périmée
Lorsque la cible d'un enregistrement NS appartient au domaine délégué, la zone parente doit fournir son adresse. Sans cet enregistrement de colle, le résolveur ne peut pas joindre le serveur sans résoudre le nom qu'il cherche, et la résolution entre dans une impasse. C'est une erreur de la zone parente, donc souvent du côté du registraire, pas du serveur.
Le cas le plus fréquent n'est pas la colle absente mais la colle périmée : un serveur change d'adresse, la zone enfant est mise à jour, la zone parente conserve l'ancienne adresse. Le domaine paraît alors cassé alors que tout est correct côté hébergement. Après toute migration d'adresse, la vérification doit porter sur les enregistrements publiés par le parent.
Les ensembles NS divergents
La zone enfant publie ses propres NS à l'apex, et le parent publie la délégation. Ces deux ensembles devraient concorder. Quand ils diffèrent, le comportement dépend du serveur interrogé : certains résolveurs suivent le parent, d'autres la zone enfant, et les utilisateurs ne voient pas la même chose selon leur position dans le réseau.
Ce cas se produit lors d'un changement d'hébergement incomplet : les nouveaux serveurs sont déclarés chez le registraire, mais l'ancien fournisseur continue de publier ses propres NS dans la zone. Il se produit aussi lorsqu'un serveur est retiré d'un côté seulement. Vérifier les deux ensembles fait partie des contrôles de fin de migration, au même titre que le contenu de la zone.
Les erreurs de contenu qui cassent la résolution
Certaines erreurs, décrites dans la RFC 1912, rendent une zone invalide ou un nom inutilisable. Un CNAME à l'apex de la zone empêche la coexistence avec les enregistrements NS et SOA : le nom de domaine lui-même devient impossible à servir correctement. Un CNAME au même nom qu'un enregistrement de courrier ou d'adresse produit une contradiction que les résolveurs traitent de façon variable.
Deux autres pièges reviennent souvent : la cible d'un MX ou d'un NS pointant vers un nom qui est lui-même un CNAME, et l'oubli du point final sur une cible absolue, qui transforme un nom externe en nom interne à la zone. Ce dernier cas produit fréquemment des enregistrements qui semblent corrects à la lecture et ne fonctionnent pas.
Le contrôle syntaxique du fichier de zone détecte une partie de ces erreurs, mais pas les incohérences entre zones. D'où l'intérêt de la vérification par interrogation, qui mesure ce que les résolveurs verront réellement.
Les erreurs de série et de durée de vie
Une modification publiée sans augmentation du numéro de série ne sera jamais transférée aux secondaires : la zone enfant paraît à jour sur le primaire, et les autres serveurs servent l'ancienne version. L'écart ne se voit qu'en comparant les séries, serveur par serveur, ce qui en fait une erreur durable et silencieuse.
À l'inverse, un TTL très bas appliqué partout pour éviter les problèmes de cache multiplie les requêtes vers l'autorité et réduit la résistance du service en cas d'incident. Un minimum de SOA trop élevé fige les réponses négatives et fait persister des noms introuvables. Ces réglages se décident par usage, pas par précaution uniforme.
La séquence de contrôle finale tient en cinq questions : le parent délègue-t-il vers les bons serveurs, la colle est-elle à jour, chaque serveur cité répond-il avec autorité, les séries sont-elles identiques, et les durées de vie sont-elles cohérentes avec l'usage. Un domaine qui passe ces cinq contrôles se résout, sauf panne réseau.
Sources
- https://www.rfc-editor.org/rfc/rfc1912.html
- https://www.rfc-editor.org/rfc/rfc1034.html
- https://www.rfc-editor.org/rfc/rfc1035.html
- https://www.rfc-editor.org/rfc/rfc2181.html
- https://www.rfc-editor.org/rfc/rfc8499.html
Pour vérifier un nom de domaine en direct — racine, TLD, serveurs de noms — utilisez l'outil de test DNS. Demarcq.net assure l'exploitation de serveurs DNS : les prestations d'exploitation.