Une recherche DNS récursive, saut après saut
Navigateur
veut example.com
Résolveur
votre FAI / 1.1.1.1
Racine + TLD
qui gère .com ?
Faisant autorité
la vraie réponse
Chaque saut de cette chaîne est lui-même une recherche DNS, ensuite mise en cache
La résolution DNS expliquée : de la requête à la réponse
La résolution DNS est le processus qui transforme un nom de domaine en données dont une application a besoin, souvent une adresse IP. Lorsqu'un navigateur doit se connecter à www.example.com, il demande un résultat à la pile réseau locale. Un résolveur stub transmet généralement la question à un résolveur récursif. Celui-ci peut déjà avoir une réponse en cache ; sinon, il suit les délégations DNS jusqu'à atteindre un serveur faisant autorité pour la zone concernée. La réponse finale revient par la même chaîne et peut être mise en cache pour une durée limitée. Le processus est distribué : aucun serveur mondial unique ne stocke l'ensemble complet des enregistrements de tous les domaines.
La requête commence par un nom et un type précis
Une question DNS ne se résume pas à « trouver ce site web ». Elle comprend un nom et un type d'enregistrement. Une requête A demande l'IPv4 ; AAAA demande l'IPv6 ; MX interroge les serveurs de messagerie ; NS interroge les serveurs de noms. Le résolveur récursif utilise le type pour décider quelles données récupérer et renvoyer. Si le navigateur a besoin d'une adresse web, il peut demander à la fois les enregistrements A et AAAA, tandis qu'un système de messagerie demande MX. Demander le mauvais type peut produire une réponse vide même si d'autres enregistrements existent pour ce nom. Les résultats DNS n'ont de sens que si la question elle-même est claire.
- Le client consulte son cache local et le résolveur configuré.
- Le résolveur récursif consulte son cache ; si nécessaire, il interroge un serveur racine.
- Une délégation de la racine oriente vers les serveurs du domaine de premier niveau (TLD) concerné.
- La délégation du TLD identifie les serveurs de noms autoritaires du domaine.
- La réponse autoritaire est renvoyée et mise en cache pour la durée autorisée.
Le résolveur récursif effectue la plus grande partie de ce travail pour le compte du client. Les délégations sont des pointeurs vers l'autorité suivante, pas nécessairement l'enregistrement final. Les serveurs racine n'ont pas besoin de connaître l'adresse de chaque site web, et les serveurs de TLD n'hébergent pas la zone complète de chaque domaine. Chaque niveau fournit des indications vers le suivant. Les serveurs autoritaires détiennent les enregistrements réellement configurés par l'exploitant du domaine ou son fournisseur DNS. Une fois que le résolveur les atteint, la réponse peut contenir une adresse, un alias, une réponse négative ou une autre valeur propre au type demandé.
Alias, cache et réponses négatives
Si un nom possède un CNAME, la résolution peut impliquer un autre nom d'hôte avant qu'une adresse ne soit trouvée. Chaque réponse concernée a son propre comportement de cache, de sorte que la chaîne peut contenir des entrées avec des TTL différents. Un résolveur peut aussi mettre en cache des résultats négatifs, comme le fait qu'un nom interrogé n'existe pas, pendant une période limitée. Cela peut expliquer pourquoi un nouveau nom n'apparaît pas instantanément après sa création. Vider un cache local n'affecte que cet appareil ou cette couche ; cela n'efface pas les réponses en cache détenues par des résolveurs récursifs indépendants à travers l'internet.
| Réponse | Ce qu'elle vous indique |
|---|---|
| Réponse d'adresse | Le type demandé a renvoyé une ou plusieurs valeurs |
| Délégation (referral) | Poursuivre la requête auprès d'un serveur délégué |
| NXDOMAIN | Le nom interrogé n'existe pas dans la vue DNS |
| NODATA | Le nom existe mais n'a pas le type d'enregistrement demandé |
| SERVFAIL | Le résolveur n'a pas pu mener la requête à son terme |
Un diagnostic pratique consiste à comparer le même nom et le même type à différentes couches. Une recherche récursive décrit ce que reçoit un client utilisant ce résolveur. Une requête autoritaire permet de déterminer ce que la zone publie actuellement. Si ces valeurs diffèrent, examinez le TTL, l'heure de la dernière modification et la délégation réelle. Si le résultat DNS est correct mais que l'application échoue toujours, passez au routage réseau, à TLS ou aux journaux du serveur. Cela évite un piège courant du dépannage : modifier le DNS à répétition alors que la résolution fonctionne déjà et que la panne se situe plus loin sur le chemin de connexion.
La résolution DNS est fiable précisément parce qu'elle est stratifiée, mise en cache et déléguée, mais ces mêmes propriétés rendent les changements incohérents en apparence pendant une migration. Conservez la réponse, le type d'enregistrement interrogé, le résolveur et l'horodatage lorsque vous comparez des observations. Le guide sur les résolveurs récursifs et autoritaires explique ces rôles plus en détail, tandis que le TTL DNS traite de la durée de vie du cache. Ces notions offrent un modèle plus juste que l'idée que chaque appareil lit un annuaire mondial unique, mis à jour instantanément.
La résolution est un processus, pas une simple lecture de base de données
Comme la résolution fait intervenir plusieurs serveurs exploités indépendamment, une réponse DNS peut être affectée par bien plus que l'enregistrement A ou AAAA final. Une délégation obsolète peut envoyer le résolveur vers la mauvaise autorité ; un serveur autoritaire indisponible peut provoquer un délai dépassé ; une chaîne DNSSEC rompue peut amener un résolveur validant à rejeter des données ; et une réponse négative en cache peut retarder la reconnaissance d'un nom tout juste créé. Chaque couche laisse des indices différents. Le code de réponse, la section d'autorité, le TTL et le serveur interrogé peuvent aider à cerner la cause. Lorsque vous collectez des diagnostics, évitez de reformuler un délai dépassé en « le domaine n'existe pas », car cela change le sens. Conservez la réponse d'erreur exacte et comparez-la avec une requête autoritaire. Cette méthode par couches mène à une réparation précise plutôt qu'à une modification à l'aveugle de l'enregistrement d'adresse.
Besoin de vérifier les adresses DNS publiques d'un domaine ? Utilisez l'outil Domain IP Lookup.
À lire aussi
Les enregistrements que vous croiserez dans presque toutes les zones
Qu'est-ce qu'un enregistrement SOA ? L'autorité de zone DNS
Comprenez l'enregistrement DNS SOA, son numéro de série, ses minuteurs de rafraîchissement et de nouvelle tentative, et son rôle dans une zone.
Trois rôles, souvent trois entreprises différentes
Qu'est-ce qu'un enregistrement NS ? Serveurs de noms DNS
Enregistrements NS, délégation par la zone parente, serveurs faisant autorité : comment confirmer quel fournisseur DNS sert les enregistrements d'un domaine.
Les enregistrements que vous croiserez dans presque toutes les zones
Fichiers de zone DNS : enregistrements, noms et TTL
Découvrez comment un fichier de zone DNS organise enregistrements, noms propriétaires et TTL, avec une liste de contrôle pour réviser ou migrer une zone.