Guide
Délégation, enregistrements NS et registraire
Changer « le DNS » chez le registrar modifie la délégation, pas le contenu de la zone. Ce guide suit le chemin du parent vers les NS, avec les relevés NS et SOA du 23 octobre 2026.
Le parent délègue, l’enfant publie
L’arbre DNS se descend par délégations. La racine délègue com à des serveurs de premier niveau. Le 23 octobre 2026, une question NS sur com commençait par a.gtld-servers.net, b.gtld-servers.net, et la suite de l’ensemble bien connu. Ces serveurs, eux, délèguent example.com en publiant les NS de ce domaine. Ils ne publient pas le A du site, ni le MX : ils disent seulement qui a le droit de les publier.
Ce « qui » est une liste de noms de serveurs. Pour example.com, le résolveur 1.1.1.1 renvoyait le 23 octobre 2026 hera.ns.cloudflare.com et elliott.ns.cloudflare.com. Interrogés sans récursion, ces serveurs répondaient avec le drapeau aa et le SOA dont le primaire nommé était elliott.ns.cloudflare.com. La boucle est fermée : le parent pointe vers des NS, les NS servent une zone qui se désigne elle-même avec les mêmes NS.
Si la zone enfant annonce d’autres NS que le parent, les résolveurs qui ont encore la délégation parente en cache n’iront pas vers les NS « internes » à la zone. La liste qui compte pour entrer dans la zone est celle du parent. La liste dans la zone doit la rejoindre, sinon le jour où un cache interroge l’enfant et mémorise ses NS, il part sur un ensemble différent. On aligne les deux avant de considérer la délégation comme propre.
Ce que règle le registraire
Le registraire est le prestataire auprès de qui le nom est enregistré. Il transmet au registre la liste des NS, et parfois des adresses de glue et un DS. Il ne stocke pas, dans ce geste, les A du site ni les MX. Beaucoup de registraires proposent aussi un hébergement DNS : dans ce cas, deux réglages coexistent. L’un choisit les NS (la délégation). L’autre édite la zone servie par ces NS. Modifier le second sans le premier ne change rien si les NS pointent encore ailleurs. Modifier le premier sans que la nouvelle zone soit remplie casse la résolution.
Un transfert de nom déplace le contrat d’enregistrement. Il ne copie pas automatiquement une zone hébergée chez un tiers. Un changement d’hébergeur web, à l’inverse, ne change souvent que des A ou des CNAME, et ne doit pas toucher aux NS si le DNS reste au même endroit. Les pannes les plus longues viennent de ce vocabulaire écrasé : « on a changé le DNS » peut vouloir dire trois opérations différentes.
Le registre applique des contrôles minimaux : noms de NS valides, parfois nombre minimum de serveurs, parfois cohérence de glue. Il ne vérifie pas que votre application répond. Une délégation « acceptée » dans l’interface peut quand même viser des NS injoignables. Le contrôle se fait en DNS, pas dans le statut du commandeur.
Glue, quand l’adresse doit voyager avec le NS
Pour interroger hera.ns.cloudflare.com, un résolveur a besoin de son adresse. Ce nom n’est pas sous example.com. On peut donc le résoudre dans la zone cloudflare.com, sans cercle vicieux. Le 23 octobre 2026, ce nom avait plusieurs A, dont 108.162.192.162, 172.64.32.162 et 173.245.58.162. N’importe laquelle de ces adresses publiques peut recevoir la question autoritative.
Le cercle apparaît si le NS est sous le domaine délégué, par exemple ns1.exemple.fr pour exemple.fr. Pour connaître l’adresse de ns1.exemple.fr, il faudrait interroger la zone exemple.fr, qui n’est joignable que via ns1.exemple.fr. Le parent doit alors publier l’adresse en même temps que le NS. Cette adresse accompagnatrice est le glue. Un glue faux envoie tout le monde vers une machine qui ne porte pas la zone, avec des symptômes de timeout ou de REFUSED, alors que « les NS sont les bons noms ».
Le glue n’est pas mis à jour tout seul quand vous changez le A de ns1 dans la zone. Si le nom du NS est dans la zone, il faut aussi mettre à jour l’adresse au registre. Inversement, un glue obsolète peut survivre dans des caches de délégation au TTL des NS du parent, souvent un ou deux jours. Le guide TTL et caches s’applique ici avec des durées longues.
Changer de NS sans trou
L’ordre sûr est le suivant. On crée la zone complète chez le nouvel hébergeur DNS, avec les mêmes enregistrements utiles, et l’on vérifie en interrogeant déjà ses NS par leur adresse, même s’ils ne sont pas encore délégués. On abaisse si possible le TTL des NS côté ancien serveur, et l’on attend. On ne bascule la délégation au registraire qu’ensuite. On surveille à la fois les NS vus par un résolveur et les réponses autoritatives des anciens comme des nouveaux. On ne retire l’ancienne zone qu’après expiration des caches qui la visaient encore.
DNSSEC complique la bascule si les clés changent. Le DS publié chez le parent doit correspondre à une DNSKEY de l’enfant au moment où les résolveurs validants refont la chaîne. Un trou de DS, ou un DS en avance sur la clé, produit un SERVFAIL chez 1.1.1.1 ou 9.9.9.9 alors qu’un résolveur qui ne valide pas montre encore les adresses. Le guide DNSSEC détaille le DS. Tant que la zone n’est pas signée, ce paragraphe ne vous concerne pas, mais il faut le savoir avant d’activer une option « DNSSEC en un clic » des deux côtés à la fois.
Pour contrôler la délégation d’un nom précis, demandez le type NS à l’outil, puis le type A du nom qui vous intéresse. Les deux lignes se lisent ensemble. Le lexique résume la délégation, le glue et le FQDN si un nom relatif a été saisi par erreur dans une interface.