Configurer un serveur DNS faisant autorité pour une zone
Un serveur qui fait autorité ne devine rien : il publie exactement le contenu d'une zone, et le déclare. Entre le fichier de zone, les enregistrements NS et la délégation posée chez le parent, trois niveaux doivent rester cohérents, sans quoi le domaine se résout par intermittence.
Héberger une zone, ce n'est pas héberger un domaine
Une zone est un sous-ensemble de l'espace des noms, administré comme une unité. Le domaine exemple.test peut être découpé en plusieurs zones : la zone exemple.test elle-même, et une zone déléguée pour un sous-domaine confié à une autre équipe. Un serveur autoritatif de la zone enfant n'a aucune autorité sur le parent, et inversement : c'est cette séparation qui rend la délégation possible sans coordination permanente entre les deux administrations.
Le fichier de zone décrit des ensembles d'enregistrements de même nom et de même type, appelés RRsets. Une adresse, un serveur de courrier, une clé de signature sont des enregistrements distincts, et chacun porte son propre TTL. Comprendre cette granularité évite une erreur fréquente : un TTL modifié sur un enregistrement ne s'applique pas aux autres enregistrements portant le même nom.
Le SOA, carte d'identité de la zone
L'enregistrement SOA nomme le serveur primaire de la zone, l'adresse de la personne responsable, puis cinq valeurs numériques : le numéro de série, les intervalles de rafraîchissement et de nouvelle tentative pour les secondaires, la durée d'expiration au-delà de laquelle un secondaire cesse de répondre, et le minimum, qui sert aujourd'hui de durée de cache négatif selon la RFC 2308. Ces champs ne sont pas décoratifs : ils pilotent la réplication et le comportement du cache des résolveurs.
Le numéro de série doit augmenter à chaque modification publiée. La RFC 1982 définit l'arithmétique de comparaison de ces numéros, qui autorise le passage par-dessus la limite de la représentation, mais la pratique la plus sûre reste une simple incrémentation, ou l'horodatage au format année, mois, jour et compteur. Un secondaire ne transfère une zone que s'il juge le série du primaire supérieur au sien : un série oublié produit un serveur qui répond encore l'ancien contenu, sans erreur visible.
Les NS de la zone et la question de la colle
À l'apex de la zone, les enregistrements NS désignent les serveurs qui en font autorité. Ils forment un ensemble : les résolveurs peuvent interroger n'importe lequel des serveurs cités, et il est donc impératif que tous servent le même contenu. Un serveur cité mais qui ne charge pas la zone est une délégation boiteuse, l'une des erreurs les plus courantes décrites dans la RFC 1912.
Lorsque la cible d'un NS appartient au domaine délégué lui-même, le résolveur ne peut pas trouver son adresse sans interroger ce serveur : la zone parente doit donc publier l'adresse en même temps que le NS. C'est l'enregistrement de colle. Il vit chez le parent, il est indispensable, et il doit être corrigé en priorité si l'adresse d'un serveur change, sinon le domaine devient partiellement inaccessible.
La délégation se pose chez le parent
Configurer le serveur ne suffit pas : il faut que la zone parente délègue réellement le domaine. Chez un registraire, cette opération consiste à déclarer les serveurs de noms du domaine ; techniquement, le parent publie alors des enregistrements NS dans son propre fichier de zone. Tant que cette déclaration n'existe pas, le nom reste introuvable même si la zone est parfaitement servie par son autorité.
Les deux ensembles de NS, celui du parent et celui de la zone enfant, doivent concorder. Certains registraires imposent une liste unique, d'autres tolèrent un écart temporaire, mais un résolveur qui reçoit deux listes différentes se comporte de manière imprévisible selon le serveur qu'il interroge. Vérifier la concordance, dans les deux sens, fait partie de la mise en service.
Écrire la zone et la contrôler avant de recharger
Les serveurs de noms modernes fournissent des outils de vérification syntaxique qui relisent le fichier sans l'appliquer : contrôle de la zone et contrôle de la configuration générale. Les lancer systématiquement évite le scénario classique du rechargement refusé en production, où le serveur continue de servir l'ancienne version sans que personne ne s'en aperçoive immédiatement.
Deux règles de rédaction méritent une attention particulière. Un CNAME ne peut pas coexister avec d'autres enregistrements au même nom, ni être placé à l'apex de la zone : il rendrait la zone invalide. Et un nom saisi sans point final est relatif au nom d'origine de la zone, ce qui produit des cibles inattendues : les cibles absolues s'écrivent avec leur point final.
Vérifier côté résolveur, pas seulement côté serveur
Après le rechargement, la vérification commence par une interrogation directe du serveur autoritatif, sans récursion : la réponse doit porter le bit AA et contenir l'enregistrement attendu. La même question posée au parent doit renvoyer une délégation vers les serveurs déclarés, et non une réponse autoritative : si le parent répond lui-même, la délégation n'a pas pris effet.
Le contrôle se termine sur les résolveurs publics, qui montrent ce que voit l'utilisateur. Un écart entre l'autorité et le résolveur public signale un cache, une délégation partielle ou un serveur secondaire en retard. Répéter l'opération sur chaque serveur cité dans les NS, en relevant le numéro de série renvoyé, donne une image fiable de l'état du parc en quelques secondes.
Sources
- https://www.rfc-editor.org/rfc/rfc1034.html
- https://www.rfc-editor.org/rfc/rfc1035.html
- https://www.rfc-editor.org/rfc/rfc1912.html
- https://www.rfc-editor.org/rfc/rfc1982.html
- https://www.rfc-editor.org/rfc/rfc2308.html
- https://www.rfc-editor.org/rfc/rfc8499.html
- https://bind9.readthedocs.io/en/latest/
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.