Test DNS › Guides DNS

Comprendre le rôle d'un serveur DNS dans la chaîne de résolution

Derrière chaque nom de domaine se cache une suite de questions posées à des serveurs spécialisés, dans un ordre précis et selon des règles écrites il y a quarante ans. Comprendre cette chaîne de résolution permet de diagnostiquer une panne en quelques commandes, au lieu de modifier des enregistrements au hasard.

Baie de brassage avec câbles Ethernet rangés et commutateurs dont les diodes sont allumées — Chaque réponse DNS traverse un réseau physique avant d'atteindre un serveur : le câblage fait partie de la chaîne de résolution.

Une requête part toujours du poste de travail

Un navigateur ne connaît pas l'adresse d'un site : il confie le nom à un résolveur de stub, petit composant du système d'exploitation qui se contente de relayer la question vers un résolveur configuré, celui du fournisseur d'accès ou un résolveur public. Le stub ne mène aucune enquête : il envoie une requête marquée du bit RD, pour Recursion Desired, et attend une réponse complète. Cette séparation explique pourquoi changer de résolveur dans les réglages du poste modifie le comportement de toutes les applications à la fois.

La question porte sur un nom, un type et une classe : par exemple le type A pour une adresse IPv4, AAAA pour IPv6, MX pour le courrier, NS pour les serveurs de noms. Les types et leur format sont décrits dans la RFC 1035, complétée depuis par de nombreuses extensions. Un nom saisi sans point final est complété par le suffixe de recherche local, ce qui produit parfois une requête pour un nom qui n'existe pas avant celle qui aboutit, et un délai perceptible à l'écran.

Récursif et itératif ne désignent pas la même chose

Un résolveur récursif prend la responsabilité d'obtenir la réponse : il interroge les serveurs les uns après les autres jusqu'à trouver celui qui fait autorité, puis renvoie la réponse finale au poste, avec le bit RA pour Recursion Available, qui signale qu'il accepte ce travail. Un serveur interrogé de façon itérative fait l'inverse : il renvoie seulement ce qu'il sait, le plus souvent une délégation vers un serveur plus proche de la réponse cherchée.

Le bit AA, pour Authoritative Answer, distingue la réponse d'un serveur qui héberge réellement la zone. Un résolveur qui répond depuis son cache ne le positionne pas, même lorsque la réponse est exacte. C'est précisément cette différence qui permet de savoir, pendant un diagnostic, si l'on parle au bon serveur : une machine censée faire autorité et qui répond sans AA, ou qui refuse la question, présente une configuration incomplète.

La descente dans la hiérarchie

Le résolveur part des serveurs racine, dont la liste lui est fournie dans un fichier de hints livré avec son logiciel. La racine ne connaît pas les domaines eux-mêmes : elle délègue chaque domaine de premier niveau à un ensemble de serveurs, qu'elle cite par leurs noms et, si nécessaire, par leurs adresses dans des enregistrements appelés enregistrements de colle. Le résolveur répète l'opération auprès du serveur du domaine de premier niveau, qui délègue à son tour vers la zone visée, jusqu'au serveur qui porte l'enregistrement demandé.

Chaque étape renvoie une référence, en anglais referral : une liste d'enregistrements NS et, quand le serveur nommé appartient au domaine délégué, les adresses correspondantes. Sans ces adresses de colle, le résolveur devrait résoudre le nom du serveur qu'il est justement en train de chercher, et la boucle ne se fermerait pas. C'est l'une des raisons pour lesquelles un enregistrement NS dont la cible est interne à la zone déléguée doit être accompagné de sa colle dans la zone parente.

Le cache raccourcit la boucle

Chaque réponse porte une durée de vie, le TTL, exprimée en secondes. Le résolveur conserve la réponse pendant ce temps et sert les requêtes suivantes depuis sa mémoire : la descente complète n'a lieu qu'à l'expiration, ou pour un nom jamais demandé auparavant. Un TTL long réduit la charge et la latence, un TTL court accélère la prise en compte d'un changement au prix d'un plus grand nombre de requêtes vers l'autorité.

Les réponses négatives sont mises en cache elles aussi. La RFC 2308 fixe la durée de ce cache à partir du champ minimum de l'enregistrement SOA de la zone, avec des plafonds recommandés pour éviter d'immobiliser trop longtemps une erreur. Un champ mal réglé se traduit par des noms qui restent introuvables longtemps après leur création, ou par un flux de requêtes répétées vers l'autorité pour un nom qui n'existe pas.

UDP, TCP et la taille des réponses

Une requête voyage normalement en UDP sur le port 53, avec une limite historique de 512 octets pour la réponse. Quand la réponse dépasse cette taille, le serveur la tronque et positionne le bit TC ; le résolveur repose alors la question en TCP, sur le même port. Cette bascule est prévue par la norme et transparente pour l'utilisateur, mais elle coûte un aller-retour supplémentaire et doit être surveillée sur les zones à forte volumétrie.

L'extension EDNS(0), décrite dans la RFC 6891, permet d'annoncer une taille de tampon plus grande et transporte des options entre les deux interlocuteurs. Elle est devenue indispensable à DNSSEC, dont les signatures alourdissent nettement les réponses. Les transports chiffrés, DNS sur TLS et DNS sur HTTPS, changent le canal d'échange mais pas le modèle : la hiérarchie, les délégations et le cache restent identiques.

Ce qu'un administrateur doit retenir

Un diagnostic DNS sérieux commence par identifier à quel acteur on s'adresse. Interroger directement l'autorité, sans récursion, montre ce que la zone publie réellement ; interroger le résolveur du poste montre ce que voit l'utilisateur. Comparer les deux réponses sépare en quelques secondes un défaut de zone d'un problème de cache ou de transport.

Les mêmes vérifications, répétées sur les deux serveurs autoritatifs d'une zone, révèlent une réplication en retard ou un transfert interrompu. Un écart entre les deux réponses est un signal d'alarme plus fiable que n'importe quelle supervision indicative, parce qu'il porte sur l'état réellement servi.

Le poste de travail délègue tout au résolveur : c'est lui qu'il faut interroger pour reproduire une panne.
Le bit AA dit si la réponse vient de l'autorité ; vérifier qu'on parle au bon serveur passe avant toute correction.
Une délégation se juge des deux côtés : la zone enfant et la zone parente doivent publier le même ensemble de NS.
Le TTL explique les délais ressentis après un changement : il s'agit d'une expiration, pas d'une propagation.
Le TCP n'est pas une anomalie : c'est le recours prévu par la norme quand la réponse ne tient pas en UDP.

Sources

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.

← début de la série Configurer un serveur DNS faisant autorité pour une zone →