Comment fonctionne le DNS : résolution récursive, cache et TTL en diagramme

Vous modifiez un enregistrement A, lancez dig et voyez la nouvelle adresse. Une collègue dans un autre bureau obtient encore l'ancienne une heure plus tard. Un nouveau sous-domaine fonctionne pour vous et renvoie NXDOMAIN chez un client. Rien de tout cela n'est aléatoire : cela découle du fonctionnement de la résolution DNS et du cache, et dès que vous savez dessiner le chemin d'une requête, vous pouvez le prévoir.

Cet article suit une requête du navigateur jusqu'au serveur faisant autorité et retour, diagramme à l'appui, puis traite des TTL, du cache négatif, de la délégation, du transport et des pannes que l'on rencontre en production.

Les quatre rôles de chaque requête

Une requête touche jusqu'à quatre types de serveurs. Chacun connaît une partie différente de la réponse.

La racine n'est pas une seule machine. Il existe 13 identités de serveurs racine, de a à m.root-servers.net, exploitées par 12 organisations indépendantes, et l'anycast les répartit sur plus de 2 000 instances dans le monde, selon root-servers.org en novembre 2026.

Une requête, étape par étape

Supposons que votre navigateur ait besoin de app.example.com et que rien ne soit en cache nulle part :

1. Le navigateur vérifie son propre cache, puis interroge le résolveur stub du système d'exploitation.
2. Le stub envoie une requête avec le drapeau « recursion desired » au résolveur récursif configuré : quel est l'enregistrement A de app.example.com ?
3. Le résolveur n'a rien en cache, il interroge donc un serveur racine. La racine ne connaît pas la réponse, mais elle sait qui gère com ; elle renvoie donc un referral : les enregistrements NS de com et leurs adresses (glue).
4. Le résolveur interroge un serveur TLD com, qui renvoie un autre referral : les serveurs de noms de example.com.
5. Le résolveur interroge l'un de ces serveurs faisant autorité, qui renvoie la réponse : app.example.com. 300 IN A 203.0.113.10.
6. Le résolveur met en cache chaque enregistrement appris pour sa TTL et renvoie la réponse au stub, qui la transmet au navigateur.

Le stub fait une requête récursive : il veut une réponse finale. Le résolveur fait des requêtes itératives : chaque serveur renvoie soit la réponse, soit un pointeur vers quelqu'un de plus proche de celle-ci. Les serveurs racine et TLD ne vont jamais chercher les réponses à votre place.

Vous pouvez observer la partie itérative avec dig +trace, qui part de la racine au lieu d'utiliser le cache de votre résolveur (sortie abrégée) :

$ dig +trace app.example.com
.                  518400  IN  NS  a.root-servers.net.
com.               172800  IN  NS  a.gtld-servers.net.
example.com.       172800  IN  NS  ns1.example.net.
app.example.com.   300     IN  A   203.0.113.10

Les résolveurs modernes appliquent aussi la minimisation de QNAME (RFC 9156) : ils n'interrogent la racine que sur com et le TLD que sur example.com, si bien que les serveurs plus haut dans la hiérarchie ne voient jamais le nom complet que vous avez demandé.

Le cache et les TTL

Chaque enregistrement porte une durée de vie (TTL) en secondes. Un résolveur qui met app.example.com en cache avec une TTL de 300 répond depuis son cache pendant les cinq minutes suivantes, en décomptant, et ne réinterroge le serveur faisant autorité qu'ensuite. Les navigateurs et les systèmes d'exploitation ajoutent leurs propres caches courts par-dessus.

C'est ce qu'on appelle la propagation. Rien n'est poussé nulle part quand vous modifiez un enregistrement. Chaque résolveur qui a mis l'ancienne valeur en cache continue de la servir jusqu'à l'expiration de sa copie ; le pire cas correspond donc à peu près à l'ancienne TTL, pas à la nouvelle. Les résolveurs plafonnent aussi les TTL très longues : Unbound, par exemple, limite par défaut les enregistrements en cache à un jour.

Règles pratiques pour les changements :

• Baissez la TTL avant un changement planifié. Si un enregistrement a une TTL de 86400, passez-la à 300 au moins un jour avant la migration, attendez que l'ancienne TTL soit écoulée, faites le changement, puis remontez-la.
• N'utilisez des TTL courtes que là où il faut un basculement rapide. Une TTL de 60 secondes signifie plus de requêtes chez votre fournisseur et plus d'échecs de cache pour les utilisateurs, chacun coûtant une résolution complète.
• Changer de serveurs de noms est plus lent. Les enregistrements NS de la zone parente pour example.com ont leur propre TTL, 172800 secondes (deux jours) dans com, et vous ne pouvez pas la raccourcir.

Le basculement par DNS dépend de ces chiffres. Le diagramme d'architecture AWS multirégion et le diagramme d'architecture de reprise après sinistre montrent où se place un enregistrement DNS avec health check et pourquoi sa TTL borne votre temps de reprise.

Le cache négatif : le piège du NXDOMAIN

Les résolveurs mettent aussi en cache « n'existe pas ». Quand un nom manque, le serveur faisant autorité renvoie NXDOMAIN avec l'enregistrement SOA de la zone, et le résolveur met cette réponse négative en cache pour la plus petite des deux valeurs entre la TTL du SOA et son champ MINIMUM (RFC 2308).

La panne classique : quelqu'un interroge api.example.com avant que l'enregistrement n'existe, un résolveur met NXDOMAIN en cache pour une heure, vous créez l'enregistrement, et ce résolveur continue d'affirmer qu'il n'existe pas jusqu'à la fin de l'heure. Vérifiez la TTL négative avec dig example.com SOA avant d'annoncer un nouveau nom d'hôte, et créez les enregistrements avant que quiconque ne les teste.

Délégation, glue et serveurs boiteux

Une zone existe dans le DNS parce que sa zone parente la lui délègue. La zone com contient des enregistrements NS qui indiquent quels serveurs font autorité pour example.com. Si ces serveurs de noms se trouvent dans la zone qu'ils servent, comme ns1.example.com, la zone parente conserve aussi leurs adresses sous forme d'enregistrements glue ; sinon, les résolveurs ne pourraient pas les trouver.

La délégation casse de deux façons courantes. Une délégation boiteuse (lame delegation) est une zone parente qui pointe vers un serveur qui ne sert plus la zone, souvent après un changement de fournisseur ; elle provoque des timeouts ou des SERVFAIL chez certains utilisateurs. Un écart entre les enregistrements NS de la zone parente et ceux de la zone elle-même fait dépendre le comportement du jeu qu'un résolveur a mis en cache.

Transport et confidentialité

La majeure partie du trafic DNS passe en UDP sur le port 53. Les réponses trop grandes positionnent le drapeau de troncature, et le client réessaie en TCP ; le port TCP 53 doit donc être ouvert lui aussi. Depuis le DNS Flag Day 2020, les principaux logiciels DNS utilisent par défaut une taille de tampon EDNS de 1 232 octets pour éviter la fragmentation IP, ce qui rend le repli sur TCP plus fréquent pour les grandes réponses comme les enregistrements signés DNSSEC.

Le DNS classique n'est pas chiffré. DNS over TLS (port 853), DNS over HTTPS et DNS over QUIC chiffrent le tronçon entre le stub et le résolveur récursif ; les tronçons du résolveur vers les serveurs racine, TLD et faisant autorité restent pour la plupart en clair.

DNSSEC résout un autre problème : l'authenticité, pas la confidentialité. Chaque zone signe ses enregistrements, et la zone parente se porte garante de la clé de la zone enfant, jusqu'à la clé racine à laquelle font confiance les résolveurs validants. Le 11 octobre 2026, la zone racine a achevé le roulement vers une nouvelle clé de signature de clés, KSK-2024. Un résolveur validant qui n'a jamais récupéré la nouvelle ancre de confiance échoue à chaque requête avec SERVFAIL.

Quand les requêtes échouent

Interroger directement le serveur faisant autorité avec dig @ns1.example.net app.example.com vous dit ce qui est vrai ; interroger un résolveur vous dit ce que voient les utilisateurs.

Le diagramme de résolution DNS

Comment le lire :

• Commencez par l'ordinateur portable. Son résolveur stub envoie une requête récursive au résolveur (étape 1) et reçoit une réponse (étape 8).
• C'est le résolveur qui parcourt la hiérarchie. Les étapes 2 à 7 sont des requêtes itératives : la racine et les serveurs com renvoient des referrals, et le serveur faisant autorité pour example.com renvoie l'enregistrement.
• Les TTL figurent sur les réponses. L'enregistrement A revient avec une TTL de 300 secondes ; c'est le temps pendant lequel le résolveur le réutilisera sans redemander.
• Le cadre regroupe la hiérarchie que vous n'exploitez pas, à l'exception du serveur faisant autorité, qui est le vôtre ou celui de votre fournisseur DNS.
• Le bloc Markdown liste les couches de cache et les TTL qui déterminent la vitesse à laquelle un changement atteint les utilisateurs.

Dessiner des diagrammes DNS qui répondent à de vraies questions

• Numérotez les étapes. Les questions DNS portent sur l'ordre : qui interroge qui, et quand le cache répond à la place.
• Séparez le trafic récursif du trafic itératif. Une requête du client, plusieurs du résolveur. S'ils se ressemblent, le diagramme cache l'idée la plus importante.
• Écrivez les TTL sur les réponses. Elles expliquent la propagation mieux qu'un paragraphe.
• Montrez qui possède quoi. Indiquez les serveurs que vous contrôlez. Pendant un incident, c'est ce qui décide qui vous appelez.
• Dessinez le changement d'enregistrement dans un diagramme à part. Une chronologie de migration avec la TTL abaissée, la bascule et la TTL remontée est plus claire que des annotations sur le diagramme de résolution.

Si l'ordre des messages est l'essentiel, un diagramme de séquence fonctionne aussi, avec le résolveur et chaque serveur comme lignes de vie. Pour le côté physique, l'emplacement des résolveurs dans votre réseau, consultez le guide du diagramme de topologie réseau.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un nœud Appareil du pack Réseau pour l'ordinateur portable et un nœud DNS pour le résolveur récursif.
3. Ajoutez un Cadre du pack Base nommé d'après la hiérarchie DNS et placez-y trois autres nœuds DNS : la racine, le TLD com et le serveur faisant autorité pour example.com.
4. Ajoutez un nœud Serveur du pack Réseau pour app.example.com, l'hôte auquel le navigateur se connecte après la résolution.
5. Dessinez les arêtes dans l'ordre et numérotez leurs étiquettes : la requête du client et sa réponse, puis une requête et une réponse entre le résolveur et chaque serveur. Indiquez la TTL sur la réponse finale.
6. Ajoutez un bloc Markdown du pack Base avec les couches de cache et les règles de TTL.

L'exemple utilise 8 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Combien de temps dure la propagation DNS ? Jusqu'à la TTL de l'ancien enregistrement, pour chaque résolveur qui l'a mis en cache. Rien n'est poussé ; les caches expirent. Les changements de serveurs de noms prennent plus longtemps, car les enregistrements NS de la zone parente ont leur propre TTL, deux jours dans com.

Quelle est la différence entre un serveur DNS récursif et un serveur faisant autorité ? Un résolveur récursif trouve les réponses pour le compte des clients et les met en cache. Un serveur faisant autorité détient les enregistrements d'une zone et ne répond que pour cette zone.

Pourquoi vois-je encore l'ancienne adresse IP après avoir modifié un enregistrement ? Un cache entre vous et le serveur faisant autorité détient encore l'ancien enregistrement : votre navigateur, votre système d'exploitation ou votre résolveur. Interrogez directement le serveur faisant autorité pour confirmer le changement, puis attendez l'expiration de la TTL.

Une TTL très basse pose-t-elle problème ? Elle coûte plus de requêtes chez votre fournisseur DNS et plus de résolutions complètes pour les utilisateurs, ce qui ajoute de la latence lors des échecs de cache. Utilisez des TTL basses pour les enregistrements que vous pourriez devoir basculer, et plus longues pour les enregistrements stables.

Le trafic DNS est-il chiffré ? Pas par défaut. DNS over TLS, HTTPS ou QUIC chiffre le tronçon entre votre appareil et le résolveur. DNSSEC ajoute des signatures qui prouvent l'authenticité des enregistrements, mais ne chiffre rien.

Commencez gratuitement — un siège, sans carte bancaire.