Recherche NS

Un enregistrement NS (nameserver) délègue l'autorité d'une zone à un ensemble précis de serveurs. Quand un résolveur cherche un enregistrement pour example.com, il interroge d'abord les serveurs racine, puis les serveurs du TLD .com, et suit les enregistrements NS à chaque étape jusqu'à atteindre les serveurs déclarés pour example.com. Ce sont ces serveurs, et eux seuls, qui font autorité sur la zone.

Les enregistrements NS existent à deux endroits qu'on confond facilement. La zone parente (le TLD) contient une délégation : des NS pointant vers les serveurs de la zone fille. La zone fille (example.com elle-même) republie sa propre copie des mêmes enregistrements, depuis l'intérieur de la zone. Un outil de lookup interroge cette seconde copie, ce que la zone déclare sur elle-même, pas la délégation détenue par le registre.

• Le nom de serveur d'un NS doit résoudre vers un enregistrement A ou AAAA ; la RFC 1035 interdit une cible CNAME ici
• Un domaine doit avoir au moins deux enregistrements NS sur des réseaux distincts, selon les recommandations de résilience de la RFC 2182
• Un nameserver présent dans la délégation mais injoignable peut provoquer des échecs de résolution intermittents sur tout le domaine

Modifier les "serveurs DNS" depuis l'interface d'un registrar (OVHcloud, Gandi) change la délégation de la zone parente : cela indique aux serveurs du TLD vers qui envoyer les résolveurs ensuite. La zone elle-même, hébergée là où ces nameservers tournent réellement, doit publier de son côté des enregistrements NS cohérents. Si les deux divergent - un fichier de zone obsolète qui liste encore un ancien prestataire, ou une délégation mise à jour côté registrar sans que la zone suive - les résolveurs peuvent obtenir des réponses incohérentes selon la copie consultée et mise en cache.

Cet écart compte surtout lors d'une migration de prestataire DNS : la délégation chez le registrar et les NS dans la nouvelle zone doivent tous les deux être mis à jour, sans méthode atomique pour le faire d'un coup. Une courte période de recouvrement où anciens et nouveaux nameservers sont listés ensemble évite la coupure.

Un glue record est un enregistrement A ou AAAA que la zone parente fournit en même temps que la délégation NS, nécessaire uniquement quand le nom d'un nameserver appartient au domaine qu'il sert lui-même - par exemple ns1.example.com comme nameserver pour example.com. Sans glue, résoudre ns1.example.com nécessiterait d'interroger les nameservers d'example.com, ce qui est circulaire. La zone parente évite cette boucle en attachant directement l'adresse IP à la réponse de délégation.

Les nameservers hébergés sur un autre domaine (ns1.fournisseur-dns.fr servant example.com) n'ont besoin d'aucun glue : leur adresse se résout indépendamment via la zone du fournisseur. Le glue est spécifiquement un artefact de la zone parente et n'apparaît pas dans une recherche sur la zone fille elle-même - une recherche NS sur example.com montre les noms des nameservers, pas les IP glue qui les accompagnent en coulisses.

L'outil renvoie deux éléments à bien distinguer. Un résumé "Nameservers" liste les serveurs que le résolveur a effectivement utilisés pour répondre à la requête - il apparaît sur chaque recherche, quel que soit le type d'enregistrement demandé. La liste d'enregistrements NS en dessous, quand NS est le type interrogé, affiche chaque nameserver comme une entrée distincte : type d'enregistrement, nom de domaine interrogé, et le nom du nameserver comme valeur. Une liste NS vide accompagnée d'un résumé de nameservers vide ou très court signale généralement une absence totale de délégation, ou l'impossibilité pour le résolveur de joindre un serveur faisant autorité.