Guide
Le rôle d’un serveur DNS
Le serveur DNS traduit un nom en information utilisable : une adresse, un relais de courrier, un alias, une règle. Ce guide décrit ce rôle sans confondre la zone, le cache et le navigateur.
Traduire un nom, pas « trouver un site »
Un serveur DNS répond à une question précise. Le client donne un nom, une classe (presque toujours IN, pour Internet) et un type. Le serveur renvoie les enregistrements de ce type, ou bien il dit qu’il n’y en a pas, ou bien il dit que le nom lui-même n’existe pas. Cette réponse est courte, signée ou non, et souvent mise en cache. Elle ne transporte pas la page web, ni le message, ni le certificat : elle indique seulement à qui parler ensuite.
Quand un navigateur ouvre https://example.com/, il a d’abord besoin d’adresses. Le 23 octobre 2026, la question A vers le résolveur 1.1.1.1 obtenait le statut NOERROR et deux enregistrements : 104.20.23.154 et 172.66.147.243. Le navigateur peut alors ouvrir une connexion TCP vers l’une de ces adresses. Si seules ces adresses changent, le nom reste le même pour la personne qui le tape. Le DNS a fait son travail dès que les adresses sont connues.
Le même nom sert à d’autres questions. Le type AAAA demande l’IPv6, le type MX demande le courrier, le type TXT demande du texte, le type NS demande qui fait autorité. Ce ne sont pas des vues différentes d’une même fiche unique : ce sont des enregistrements distincts, avec leur propre TTL. Un test « le site répond » ne prouve pas que le MX est bon, et un MX correct ne prouve pas que le A du site l’est.
Ce que le serveur ne décide pas
Le DNS ne choisit pas le certificat TLS, même si un enregistrement CAA peut limiter les autorités autorisées à en émettre un. Il ne vérifie pas que le serveur web est allumé. Une adresse juste vers une machine arrêtée donne un site injoignable avec un DNS parfaitement sain. Il ne remplace pas non plus le pare-feu, le routage ou le proxy. Quand une page ne s’affiche pas, la première question utile est : « est-ce que le nom se résout, et vers quelle adresse ? » La seconde est : « est-ce que cette adresse répond sur le port attendu ? » Mélanger les deux mène à changer des NS alors que le virtual host est faux, ou l’inverse.
Le DNS n’est pas non plus un annuaire secret. Une réponse normale circule en clair sur le port 53, sauf si le client utilise une protection de transport (DNS sur TLS ou DNS sur HTTPS) jusqu’à son résolveur. DNSSEC, décrit dans le guide DNSSEC, authentifie la donnée ; il ne la cache pas. Publier un TXT de vérification ou un nom interne par erreur, c’est le rendre lisible par quiconque interroge la zone.
Enfin, le serveur que vous configurez chez un hébergeur n’est pas « le DNS d’Internet ». C’est la source d’une zone. Le reste du réseau n’en prend connaissance qu’au fil des questions et des caches. Un changement enregistré dans l’interface n’est pas instantanément visible partout. Ce délai s’explique dans le guide sur le TTL et la propagation.
Anatomie d’une question
Une question DNS tient en trois éléments utiles au quotidien : le nom, le type, et le serveur à qui l’on s’adresse. dig @1.1.1.1 example.com A interroge le résolveur Cloudflare. dig @1.1.1.1 example.com MX pose une autre question au même serveur. Ajouter +norecurse demande au serveur de ne pas chercher à la place du client : c’est adapté quand on parle à un autoritatif, inadapté quand on veut le comportement d’un résolveur.
La réponse se lit d’abord dans l’en-tête. Le 23 octobre 2026, pour le A d’example.com, l’en-tête contenait status: NOERROR et les drapeaux qr rd ra ad. qr marque une réponse, rd rappelle que la récursion était souhaitée, ra que le serveur l’accepte, ad que le résolveur a validé DNSSEC. Plus bas, la section answer liste les enregistrements. La section authority et la section additional comptent quand il n’y a pas de donnée, ou quand des adresses de serveurs de noms accompagnent les NS.
Le code de statut ne suffit pas. NOERROR avec une answer vide signifie « pas de donnée de ce type », pas « tout va bien et voici une adresse ». NXDOMAIN signifie « ce nom n’existe pas ». SERVFAIL signifie « je n’ai pas réussi à répondre ». L’outil du site reprend ces codes tels que dig les affiche, résolveur par résolveur, pour éviter de résumer trop tôt.
Plusieurs serveurs, plusieurs rôles
Le système d’exploitation n’interroge en général qu’un résolveur : celui du réseau, ou un résolveur choisi à la main. Ce résolveur, lui, parle à d’autres serveurs. Il commence par la racine, dont il connaît des adresses en dur, puis il suit les délégations jusqu’à la zone. Une fois la réponse obtenue, il la garde pendant le TTL. Le poste de travail peut aussi garder une copie encore plus locale, dans le stub du système ou dans le navigateur.
La zone, de son côté, est servie par les NS publiés. Pour example.com, le 23 octobre 2026, 1.1.1.1 renvoyait hera.ns.cloudflare.com et elliott.ns.cloudflare.com. Ces machines répondent avec le drapeau aa parce que la zone est chez elles. Leur réponse est la référence du moment. Un résolveur qui montre encore d’anciennes adresses n’a pas « un autre Internet » : il a un cache plus vieux.
D’où l’intérêt de comparer, pour le même nom et le même type, plusieurs résolveurs publics et les autoritatifs. Si les autoritatifs sont d’accord entre eux et qu’un seul résolveur diverge, on attend ou on diagnostique ce cache. Si les autoritatifs divergent déjà, le problème est dans la zone ou dans la délégation, et attendre ne sert à rien. Le guide suivant détaille ces trois mots, souvent employés l’un pour l’autre.
Ce que l’on vérifie en pratique
Pour un site, le contrôle minimum est le couple A et AAAA du nom exact qui figure dans la barre d’adresse, y compris www s’il est utilisé. Pour le courrier, ce sont les MX, puis les A ou AAAA de leurs cibles, puis les TXT de SPF et, sur les noms prévus, de DKIM et DMARC. Pour une délégation, ce sont les NS vus depuis un résolveur et les NS vus en interrogeant la zone. Pour un certificat qui ne se renouvelle plus, le CAA. Aucun de ces contrôles ne remplace les autres.
Le relevé du 23 octobre 2026 illustre un domaine cohérent sur plusieurs types à la fois. Le MX d’example.com était 0 ., c’est-à-dire un MX nul : le domaine annonce qu’il ne reçoit pas de courrier. Le TXT v=spf1 -all dit la même chose dans le langage de SPF. Les adresses A, elles, existaient. Un outil qui ne testerait que le A conclurait à tort que « le DNS du domaine fonctionne » pour la messagerie.
Gardez le nom complet, le type et l’heure du relevé. Une capture sans ces trois éléments ne se compare pas le lendemain. L’outil de test interroge quatre résolveurs et les autoritatifs avec un délai court, et le lexique fixe le vocabulaire utilisé dans les autres guides.