Serveur autoritatif, récursif et résolveur

L’autoritatif détient la zone

Un serveur autoritatif répond parce que la zone est configurée chez lui. Il ne devine pas, il ne va pas demander à un voisin ce qu’il devrait publier : les enregistrements sont les siens. Dans dig, le drapeau aa (authoritative answer) signale cette situation. Le 23 octobre 2026, une question A envoyée sans récursion à un serveur de noms d’example.com renvoyait flags: qr aa et les adresses 172.66.147.243 et 104.20.23.154, avec un TTL de 300 secondes. Ce TTL est celui de la zone, pas un reste de cache.

Il y a presque toujours plusieurs autoritatifs, listés par les enregistrements NS. Ils doivent servir le même contenu. Un décalage entre eux est déjà une divergence, avant même qu’un résolveur public entre en jeu. L’outil du site en interroge un par nom de NS découvert, en +norecurse, et n’utilise que des adresses publiques : une adresse privée ou réservée renvoyée par erreur n’est pas contactée.

Être autoritatif pour une zone ne donne aucun pouvoir sur les autres. Le NS d’example.com ne « connaît » pas wikipedia.org. Si on lui pose cette question sans récursion, il n’a pas à aller chercher la réponse. Il peut renvoyer un renvoi vers d’autres NS, ou refuser. C’est pour cela qu’un test sérieux sépare la colonne « résolveur public » de la colonne « serveur autoritatif ».

Le récursif cherche jusqu’au bout

La récursion est un service : le client pose une question, le serveur accepte de suivre les délégations et de revenir avec la réponse finale. Le drapeau rd (recursion desired) est mis par le client. Le drapeau ra (recursion available) est mis par le serveur s’il propose ce service. Les quatre résolveurs comparés ici — 1.1.1.1, 8.8.8.8, 9.9.9.9 et 94.140.14.14 — présentent ra sur une question ordinaire.

Un autoritatif public n’a en principe pas à offrir la récursion au monde entier. La récursion ouverte transforme le serveur en relais utilisable par n’importe qui, y compris pour des abus. On la réserve aux clients du réseau, ou on la désactive. Dans dig, +norecurse retire rd. C’est le bon réflexe pour parler à la zone, et un mauvais réflexe si vous vouliez seulement « la même chose que le navigateur », parce que le navigateur parle à un récursif.

Le travail récursif a un coût et un cache. Le serveur mémorise les NS rencontrés, les adresses et les réponses négatives. Deux questions identiques à quelques secondes d’intervalle ne provoquent pas deux voyages complets jusqu’à la zone. C’est utile, et c’est aussi la raison pour laquelle la valeur vue « sur Internet » peut traîner après une modification. Le détail est dans le guide TTL, caches et propagation.

Le résolveur est celui du client

On appelle résolveur le serveur que le client interroge en premier. Sur un poste, c’est souvent l’adresse apprise par DHCP, parfois une adresse choisie dans le système, parfois un résolveur local qui ne fait que relayer. Le résolveur peut être récursif lui-même, ou transmettre la question à un récursif plus loin. Pour la personne qui débogue, la conséquence est la même : la réponse dépend du cache de cette chaîne, pas seulement du fichier de zone.

Les résolveurs publics simplifient la comparaison parce qu’ils sont joignables de partout et indépendants les uns des autres. Ils ne partagent pas un cache unique. Le 23 octobre 2026, les quatre résolveurs citaient les mêmes adresses A pour example.com, avec des TTL différents : 66 secondes chez 1.1.1.1, 300 chez 8.8.8.8, 236 chez 9.9.9.9, 113 chez 94.140.14.14. Les adresses identiques et les durées différentes sont le signe d’un cache, pas d’une zone instable. L’autoritatif, lui, annonçait 300 secondes.

Le résolveur du fournisseur d’accès peut encore montrer autre chose, surtout s’il a mis la réponse en cache juste avant un changement. Un test qui ne regarde que 1.1.1.1 peut donc dire « c’est à jour » alors qu’une box continue de servir l’ancienne adresse. Inversement, un seul résolveur en échec pendant que les trois autres et les autoritatifs répondent ne condamne pas la zone.

Une machine peut tenir plusieurs rôles

Un logiciel comme BIND, NSD, Knot, PowerDNS ou le service DNS d’un hébergeur peut être autoritatif pour vos zones et, séparément, récursif pour votre réseau. Ce sont deux fonctions à configurer, souvent sur des adresses différentes. Les mélanger sur la même adresse exposée à Internet est une source classique d’erreurs : on croit tester la zone, on tombe sur le cache ; on croit vider le cache, on modifie la zone.

Le drapeau aa aide à trier. S’il est présent, la réponse se présente comme autoritative. S’il est absent et que ra est présent, vous parlez à un récursif qui a fait le travail ou servi son cache. S’il n’y a ni donnée ni aa, mais des NS en section authority, vous avez souvent un renvoi : le serveur vous indique qui interroger, sans répondre à votre place. L’outil marque ce cas RENVOI pour ne pas le confondre avec un enregistrement absent.

DNSSEC ajoute une nuance. Un récursif validant peut renvoyer SERVFAIL alors que l’autoritatif, interrogé directement, montre encore les enregistrements. Le 23 octobre 2026, dnssec-failed.org en type A chez 1.1.1.1 produisait exactement ce statut, avec le motif étendu « DNSKEY Missing ». Le récursif a fait son travail de vérification, et ce travail a échoué. Le guide DNSSEC reprend cet exemple.

Lequel interroger selon la question

Pour savoir ce que la zone publie maintenant, interrogez les NS, sans récursion. Pour savoir ce que voit un utilisateur d’un résolveur donné, interrogez ce résolveur, avec récursion, comme le fait le système. Pour savoir si un problème est local, comparez le résolveur de la box et un résolveur public. Pour savoir si un problème est général, comparez plusieurs résolveurs publics et les autoritatifs. Un seul échantillon ne suffit pas dès qu’il y a un cache.

Le rôle général du serveur reste le même dans tous ces cas : répondre à un type, pour un nom. Ce qui change, c’est la fraîcheur et la provenance. Le vocabulaire du lexique (résolveur, autoritatif, récursif, glue, délégation) sert à nommer cette provenance dans un ticket ou un échange avec un registrar, sans tout appeler « le DNS ».