La résolution DNS est le processus qui transforme un nom de domaine comme example.com en une adresse IP à laquelle un ordinateur peut se connecter. Elle consiste à parcourir une chaîne de serveurs (votre résolveur récursif, la racine, le TLD et enfin le serveur de noms faisant autorité pour le domaine) jusqu'à ce que l'un d'eux renvoie l'enregistrement réel. Comprendre cette chaîne est le moyen le plus rapide de diagnostiquer pourquoi un site « ne se résout pas » ou se résout vers la mauvaise destination.
Résolveur DNS récursif ou serveur DNS faisant autorité
Ces deux rôles sont constamment confondus, mais la distinction compte pour le dépannage.
- Résolveur récursif : le serveur avec lequel votre appareil communique réellement (le résolveur de votre FAI, ou un résolveur public comme
8.8.8.8de Google ou1.1.1.1de Cloudflare). Il se charge de trouver la réponse à votre place et met le résultat en cache. - Serveur de noms faisant autorité : le serveur qui détient les enregistrements DNS réels d'une zone (par exemple les enregistrements A, MX et TXT de votre domaine). C'est la source de référence ; il ne demande jamais rien à personne.
Votre ordinateur portable ou votre téléphone exécute un résolveur minimal (stub resolver) qui n'effectue lui-même aucun de ces parcours : il se contente de transmettre la question à un résolveur récursif et d'attendre une réponse.
Le parcours racine → TLD → serveur faisant autorité
Lorsqu'un résolveur récursif n'a rien en cache pour un nom, il effectue une recherche itérative, en suivant les renvois le long de la hiérarchie DNS :
- Serveurs racine. Le résolveur interroge l'un des 13 identifiants de serveurs racine (de
a.root-servers.netàm.root-servers.net, chacun routé en anycast vers de nombreux emplacements physiques). La racine ne sait pas où se trouveexample.com, mais elle sait quels serveurs gèrent.comet renvoie ce renvoi. - Serveurs TLD. Le résolveur interroge un serveur TLD
.com. Celui-ci ne connaît pas non plus l'IP deexample.com, mais il sait quels serveurs de noms font autorité pour ce domaine et y renvoie le résolveur. - Serveurs faisant autorité. Le résolveur interroge directement le serveur de noms faisant autorité pour
example.com. Ce serveur détient l'enregistrement réel et le renvoie : plus besoin de deviner.
Le résolveur récursif transmet ensuite cette réponse à votre appareil et la met en cache pour la prochaine fois, selon le TTL (time to live, durée de vie) de l'enregistrement.
Note« Itératif » (de serveur à serveur, chacun pointant vers le suivant) et « récursif » (le client demande à un seul serveur de faire tout le travail) décrivent le même processus global sous deux angles différents : votre résolveur effectue un travail récursif pour vous en envoyant une série de requêtes itératives.
Pourquoi le cache DNS et le TTL sont importants
Chaque enregistrement DNS porte un TTL, une valeur en secondes qui indique aux résolveurs combien de temps ils peuvent le conserver en cache avant de redemander. Un TTL bas (par exemple 300 secondes) signifie que les modifications se propagent vite, mais génère davantage de trafic de requêtes ; un TTL élevé (par exemple 86400 secondes / 24 heures) réduit la charge, mais un enregistrement obsolète peut alors subsister dans les caches pendant une journée entière après votre modification.
C'est aussi pourquoi une migration ratée semble fonctionner « partiellement » : certains résolveurs conservent l'ancienne réponse en cache tandis que d'autres ont déjà récupéré la nouvelle. Si vous êtes en pleine migration ou si vous déboguez une propagation, interrogez directement différents résolveurs et comparez les réponses plutôt que de vous fier au cache de votre navigateur.
| Scénario de modification d'enregistrement | TTL recommandé avant la modification |
|---|---|
| Migration de serveur planifiée | Abaisser à 300 s la veille, puis remonter après confirmation |
| Enregistrement de production stable | 3600–86400 s est courant et réduit le volume de requêtes |
| Basculement / mises à jour d'IP dynamique | Garder bas (60–300 s) pour que les clients récupèrent vite les modifications |
Même les réponses « aucun enregistrement n'existe » sont mises en cache : c'est le cache négatif, régi par le TTL de l'enregistrement SOA de la zone, si bien qu'un NXDOMAIN peut lui aussi persister un certain temps.
Ce que contient réellement une requête DNS
Les messages DNS ont une structure fixe : un en-tête plus les sections Question, Answer, Authority et Additional. Les requêtes standard passent par le port UDP 53, initialement limitées à 512 octets ; les résolveurs modernes utilisent EDNS0 pour annoncer des tailles de tampon plus grandes et éviter des replis inutiles. Lorsqu'une réponse est trop volumineuse, ou pour des opérations comme les transferts de zone, le DNS se replie sur le port TCP 53.
Une sortie dig typique pour un enregistrement A résolu ressemble à ceci :
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34
Ce 300 est le TTL en secondes, IN est la classe (internet) et A est le type d'enregistrement. Vous pouvez effectuer la même recherche vous-même, depuis n'importe quel navigateur, avec l'outil de recherche DNS : pratique pour vérifier exactement ce qu'un serveur faisant autorité sert actuellement, indépendamment de votre cache local.
DNS chiffré : DoH et DoT
Les requêtes DNS standard sont envoyées en clair, ce qui permet aux réseaux (et à quiconque se trouve sur le chemin) de voir quels domaines vous résolvez. Deux transports plus récents répondent à ce problème :
- DNS over TLS (DoT) : le DNS encapsulé dans TLS sur le port TCP 853.
- DNS over HTTPS (DoH) : le DNS acheminé dans une connexion HTTPS, généralement sur le port 443, ce qui le rend plus difficile à distinguer du trafic web ordinaire.
Les deux protègent la requête en transit entre votre appareil et le résolveur, mais ils ne modifient pas le parcours racine→TLD→serveur faisant autorité décrit plus haut : le chiffrement intervient au niveau de la couche de transport, pas dans la logique de résolution.
DNSSEC : l'authenticité sans le chiffrement
Les extensions de sécurité du DNS (DNSSEC) ajoutent des signatures cryptographiques (enregistrements RRSIG, DNSKEY, DS) afin qu'un résolveur puisse vérifier qu'une réponse provient bien de la source faisant autorité de la zone et n'a pas été altérée en transit. Il faut souligner que DNSSEC garantit l'authenticité, pas la confidentialité : n'importe qui peut toujours voir la requête ; DNSSEC l'empêche simplement de falsifier une fausse réponse.
Erreurs de résolution DNS courantes et leurs causes
| Symptôme | Cause probable |
|---|---|
| Fonctionne sur votre téléphone, pas sur votre ordinateur portable | Résolveurs différents avec des TTL en cache différents |
| Fonctionne après un changement de VPN | Le résolveur local du FAI a un enregistrement obsolète en cache |
| NXDOMAIN alors que l'enregistrement existe | Cache négatif dû au TTL du SOA, ou faute de frappe dans la délégation |
| Résolution intermittente | Délégation NS mal configurée ou partiellement propagée entre le registrar et l'hébergeur DNS |
| Fonctionne pour certains types d'enregistrement, pas pour d'autres | Enregistrement réellement absent au niveau du serveur faisant autorité : vérifiez directement, pas via un cache |
Lorsque vous gérez le DNS chez plusieurs registrars et fournisseurs, ces symptômes se multiplient : une délégation correcte chez un registrar mais obsolète chez un autre est une source classique de tickets de support du type « chez moi, ça marche ».
Si vous centralisez la gestion DNS de plusieurs domaines pour ne plus courir après les problèmes de propagation sur une douzaine de tableaux de bord, la fonctionnalité DNS d'InfraNest vous offre un seul endroit pour gérer zones, TTL et enregistrements chez tous vos fournisseurs.
Essayez par vous-même
Lancez une recherche en direct auprès des serveurs faisant autorité avec l'outil de recherche DNS pour voir exactement ce qui est servi en ce moment, sans passer par ce que votre résolveur local a mis en cache.
Questions fréquentes
#Quelle est la différence entre une requête DNS récursive et une requête itérative ?
Une requête récursive demande à un seul serveur (votre résolveur) de résoudre entièrement le nom et de renvoyer une réponse finale ; une requête itérative est ce que ce résolveur fait ensuite en coulisses, en suivant les renvois de la racine vers le TLD puis vers les serveurs faisant autorité.
#Pourquoi une modification DNS met-elle du temps à apparaître partout ?
Parce que les résolveurs du monde entier mettent les réponses en cache pendant la durée du TTL de l'enregistrement, et que chacun ne se met à jour qu'à l'expiration de sa propre copie en cache : la propagation n'est donc ni instantanée ni uniforme.
#DNSSEC chiffre-t-il mes requêtes DNS ?
Non : DNSSEC prouve uniquement qu'une réponse est authentique et non modifiée ; il ne masque pas la requête elle-même. Pour cela, il vous faut un transport chiffré comme DNS over TLS ou DNS over HTTPS.
#Pourquoi les résolveurs publics comme 8.8.8.8 ou 1.1.1.1 donnent-ils parfois des réponses différentes de celles du DNS de mon FAI ?
Chaque résolveur gère son propre cache indépendant avec ses propres délais d'expiration : si un enregistrement a récemment changé, un résolveur peut encore servir l'ancienne valeur en cache tandis qu'un autre l'a déjà actualisée.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
