Qu'est-ce que le DNS récursif : fonctionnement et importance
Qu'est-ce que le DNS récursif ? Découvrez comment un résolveur répond aux requêtes, utilise le cache et intègre les contrôles de sécurité, avec des exemples clairs.
Published 2 novembre 2026
Un résolveur DNS récursif est le serveur qui prend une recherche de nom depuis votre appareil et trouve l'adresse IP correspondante pour son compte en interrogeant d'autres serveurs DNS, puis enregistre la réponse pour la réutiliser.
Admettons que vous ayez modifié un paramètre sur votre WiFi invité, mais qu'un visiteur puisse toujours accéder à un site que vous souhaitiez bloquer. Avant de modifier à nouveau le pare-feu, vérifiez quel résolveur son équipement utilise et si votre politique s'applique aux réponses en cache. Ces détails expliquent souvent l'écart entre la modification d'une règle et la constatation de son application.
Table des matières
- Ce qu'un résolveur DNS récursif fait pour votre appareil
- Comparaison des serveurs DNS récursifs et autoritatifs
- Comment une recherche récursive parcourt la hiérarchie DNS
- Mise en cache, TTL et durée de prise en compte d'un changement
- Filtrage et sécurité au niveau du résolveur
- Pannes, réponses périmées et idées reçues courantes
- Confirmez quel résolveur votre réseau utilise avant de le modifier
Ce qu'un résolveur DNS récursif fait pour votre appareil
Un résolveur DNS récursif trouve des réponses DNS pour un appareil, un peu comme le concierge d'un hôtel qui contacte plusieurs services au lieu d'envoyer un client de bureau en bureau. Le client pose une question et attend une réponse, pas des instructions pour continuer la recherche.
Supposons qu'un client d'hôtel ouvre son ordinateur portable et saisisse le nom d'un site web. Si l'ordinateur ne dispose pas déjà d'une réponse utilisable localement, il envoie une requête de recherche à son service DNS configuré. Ce service peut être fourni par le réseau de l'hôtel, le fournisseur d'accès Internet ou un résolveur configuré séparément.
Les rôles derrière une recherche
- Client : l'équipement ou l'application qui demande une réponse DNS.
- Résolveur récursif : le service chargé de trouver et de retourner cette réponse.
- Serveur autoritaire : le serveur qui publie les enregistrements DNS officiels pour le domaine demandé.
L'analogie avec le concierge permet de séparer plus facilement ces responsabilités.
Pour une recherche d'adresse réussie, l'appareil reçoit une adresse IP et une durée de vie, généralement abrégée en TTL. Cette valeur indique aux systèmes de mise en cache combien de temps ils peuvent réutiliser la réponse. Le navigateur peut ensuite utiliser l'adresse pour commencer à contacter la destination.
Récursif ne signifie pas une répétition sans fin. Cela décrit la responsabilité acceptée par le résolveur : trouver la réponse finale pour le client, ou retourner une erreur appropriée s'il n'y parvient pas.
Le client de l'hôtel n'a généralement aucune idée de tout ce qui se passe. Il n'a pas besoin de choisir des serveurs racines ni de comprendre qui héberge le DNS du site Web.
Un contrôle de compréhension utile est simple : votre appareil demande une adresse, le résolveur la trouve et votre navigateur l'utilise pour initier une connexion.
Comparaison entre serveurs DNS récursifs et autoritatifs
Résolveur récursif par rapport au serveur autoritatif
| Critère | Résolveur récursif | Serveur faisant autorité |
|---|---|---|
| Rôle principal | Trouve des réponses pour les clients en interrogeant d'autres serveurs | Publie les enregistrements officiels pour les domaines dont il a la charge |
| Origine des réponses | Son cache ou des serveurs DNS en amont | Ses propres enregistrements de zone |
| Opérateur type | Fournisseur d'accès Internet, service de résolveur public, propriétaire du réseau | Propriétaire du domaine ou hébergeur |
| Contacté directement par les appareils | Oui | Généralement non ; les résolveurs le contactent |
| Mise en cache des réponses pour d'autres domaines | Oui, sous réserve du TTL et des règles de cache locales | Non, cela ne fait pas partie de son rôle d'autorité |
La distinction clé réside entre la récupération et l'autorité. Un résolveur récursif récupère des informations pour un tiers. Un serveur autoritatif publie des informations pour un domaine relevant de sa responsabilité.
Cette différence est importante lors du dépannage. Si tout le monde reçoit une mauvaise adresse pour le site web de votre organisation, vérifiez les enregistrements faisant autorité. Si seuls les visiteurs d'un réseau particulier rencontrent des problèmes, examinez le résolveur de ce réseau, son cache et sa politique.
Les opérateurs peuvent se chevaucher sans fusionner les rôles
Un fournisseur d'accès à Internet peut exécuter un DNS récursif pour ses abonnés, tandis qu'un hébergeur publie un DNS autoritaire pour ses clients. Un propriétaire de réseau peut également exploiter un résolveur interne pour les appareils de son personnel.
La même organisation, et parfois le même logiciel serveur, peut exécuter ces deux tâches. Un serveur peut répondre de manière autoritaire pour un domaine interne tout en résolvant des noms Internet non liés pour des collaborateurs. Le rôle dépend de la requête en cours de traitement, et pas seulement du nom de l'entreprise sur le service.
La redirection ajoute une autre distinction. Un serveur DNS local peut transmettre les requêtes à un résolveur en amont au lieu de contacter lui-même la hiérarchie. Comprendre le renvoi DNS vous aide à identifier quel service effectue la recherche externe.
Un serveur autoritaire n'est généralement pas le point de contrôle de filtrage de contenu du visiteur. Il publie les enregistrements du domaine, plutôt que d'appliquer les règles réseau du visiteur.
Question de diagnostic : Ce serveur répond-il à partir d'enregistrements dont il a la responsabilité, ou recherche-t-il des enregistrements pour le compte d'un client ?
Cette question est plus utile que de supposer que chaque serveur étiqueté DNS effectue le même travail.
Comment une recherche récursive parcourt la hiérarchie DNS
Prenons l'exemple d'une recherche pour www.example.com lorsque ni l'appareil ni son résolveur ne disposent des informations nécessaires pour répondre.
L'appareil envoie une requête récursive, demandant à son résolveur un résultat final. Le résolveur effectue normalement des requêtes itératives en amont : les serveurs racines et les serveurs de domaine de premier niveau fournissent des redirections, tandis que le serveur faisant autorité fournit l'enregistrement demandé.
Ce schéma montre le parcours global avant les échanges individuels.
Suivre la demande et la réponse
L'appareil contatcte le résolveur configuré. Il envoie le nom du site web car il a besoin d'une adresse avant de pouvoir contacter la destination.
Le résolveur vérifie son cache. Une réponse utilisable en cache met immédiatement fin à la recherche. Il n'y a aucune raison de demander aux serveurs en amont des informations que le résolveur peut encore réutiliser.
En cas d'échec du cache, il interroge un serveur racine. Le serveur racine le redirige vers les serveurs responsables du domaine de premier niveau concerné, dans ce cas .com.
Il interroge un serveur .com. Ce serveur identifie les serveurs de noms faisant autorité pour example.com, affinant ainsi la recherche aux autorités désignées du domaine.
Il interroge un serveur faisant autorité. Le serveur faisant autorité renvoie l'enregistrement d'adresse demandé et son TTL, exprimé en secondes.
Il stocke et renvoie la réponse. Le résolveur conserve une copie réutilisable et envoie le résultat à l'appareil.
Les requêtes ultérieures peuvent utiliser cette copie en cache. Tant que la réponse reste utilisable, le résolveur n'a pas besoin de répéter le parcours en amont pour les mêmes nom et type d'enregistrement.
La hiérarchie répartit la responsabilité. Les serveurs racines identifient les autorités de domaine de premier niveau, ces autorités identifient les serveurs de noms de domaine, et les administrateurs de domaine gèrent les enregistrements de destination.
Une réponse mise en cache reste une réponse légitime
La réponse du résolveur est normalement non autoritaire. Cela signifie qu'il transmet des informations plutôt que de répondre en tant qu'autorité du domaine, et non que la réponse n'est pas fiable.
Certains déploiements retransmettent la requête à un service récursif en amont, qui effectue ce travail pour leur compte. De plus, un résolveur disposant de redirections en cache peut ignorer certaines étapes du parcours illustré.
Les règles de cache local ont également leur importance. Les notes de l'APNIC relatives à la réunion RIPE 91 identifient des temporisateurs de cache maximal de résolveur couramment observés de 6 heures, 12 heures, 24 heures et 7 jours, ce qui montre pourquoi les administrateurs ne doivent pas supposer que chaque résolveur respecte des limites de cache identiques.
Pour un autre aperçu du processus de recherche, cette vidéo suit la résolution DNS.
Mise en cache, TTL et durée de prise en compte d'une modification
Un domaine est bloqué à 9h00, mais un ordinateur portable sur le même réseau continue de l'ouvrir à 9h40. Cet écart provient de la réutilisation. Un TTL fonctionne comme la durée de validité d'un ticket de stationnement : il indique au résolveur combien de temps il peut continuer à fournir une réponse stockée avant de devoir remonter la chaîne et poser à nouveau la question.
Pour un enregistrement mis en cache ordinaire, la quantité qui importe est la durée de vie restante. Le temporisateur de cache maximal d'un résolveur peut raccourcir cette durée de vie, tandis qu'un minimum appliqué localement peut l'étirer. Les maximums de résolveurs observés incluent 6 heures, 12 heures, 24 heures et 7 jours, selon les notes de l'APNIC relatives au RIPE 91. Ces paramètres régissent la fraîcheur des enregistrements. Ils ne décident de la durée d'un blocage que lorsque la conception du filtrage repose sur le rafraîchissement de la réponse DNS plutôt que sur la vérification de la politique actuelle.
Les paramètres de cache et leur signification pour un nouveau blocage
| Paramètre de cache | Valeur typique | Effet sur un nouveau blocage ou une modification |
|---|---|---|
| TTL de zéro seconde | Aucune durée de vie réutilisable | Sous une gestion normale du TTL, la requête suivante déclenche une recherche en amont |
| TTL court | De quelques secondes à quelques minutes | Les modifications d'enregistrements deviennent visibles peu après chaque actualisation |
| Minuteur de cache maximal du résolveur | 6 heures | Plafonne la rétention pour les enregistrements dont le TTL est plus long |
| Minuteur de cache maximal du résolveur | 12 heures | Tronque les TTL d'enregistrements plus longs à une demi-journée |
| Minuteur de cache maximal du résolveur | 24 heures | Permet à une réponse de persister pendant la nuit, jusqu'à une journée entière |
| Minuteur de cache maximal du résolveur | 7 jours | Autorise une conservation d'une semaine uniquement lorsque le TTL de l'enregistrement le permet également |
Séparer les modifications d'enregistrements des modifications de politiques
Supposons que l'adresse autoritaire d'un site change une minute après qu'un résolveur a mis en cache l'ancienne réponse. Ce résolveur peut continuer à renvoyer l'ancienne adresse jusqu'à la fin de la durée de vie effective, qui correspond au plus court entre le TTL de l'enregistrement et le maximum propre au résolveur, ajusté en fonction de tout minimum appliqué. Avec un TTL d'enregistrement de 24 heures et un plafond de 6 heures, les utilisateurs atteignent la nouvelle adresse dans les six heures. Avec un TTL d'enregistrement de 7 jours sous un plafond de 7 jours, ils peuvent attendre une semaine entière.
Désormais, l'adresse reste la même, mais une équipe de sécurité signale le domaine comme malveillant. Un résolveur qui vérifie à nouveau la politique actuelle avant de fournir une réponse en cache bloque le domaine lors de la recherche suivante. Une conception qui n'effectue une réévaluation que lorsque la réponse est rafraîchie laisse la voie ouverte pour le reste de la durée de vie effective, ce qui peut représenter une journée d'exposition avec une limite de 24 heures.
Règle pratique : Demandez à quel moment le résolveur actualise sa réponse DNS et quand il réévalue sa décision de filtrage. Une modification parvient aux utilisateurs au plus tard de ces deux moments.
Pour les modifications urgentes, testez aussi bien un domaine consulté précédemment qu'un domaine non mis en cache. Surveillez le taux de succès du cache, le volume de requêtes en amont et la diffusion des mises à jour de politique comme des mesures distinctes. Une recherche récente et rapide ne dit rien des utilisateurs disposant encore d'une réponse en cache.
Filtrage et sécurité au niveau du résolveur
Un résolveur peut appliquer des règles aux recherches qu'il reçoit avant que l'appareil ne démarre une connexion. Cependant, la récursivité seule ne fournit pas ces règles. La classification du contenu, le renseignement sur les menaces et les contrôles d'authenticité DNS sont des fonctionnalités distinctes.
Le filtrage de contenu définit les règles d'accès
Le filtrage DNS par catégorie permet au propriétaire d'un réseau de décider quelles destinations les utilisateurs peuvent atteindre. Un site touristique familial peut restreindre le contenu pour adultes sur le WiFi invité tout en maintenant des règles différentes pour un réseau administratif.
Avant qu'un appareil ne s'connecte à un site ou à une application, il demande au DNS où le trouver, et nous répondons en appliquant la politique du réseau sur lequel se trouve l'appareil. L'identité du réseau est donc importante, et pas seulement le domaine demandé.
Les fonctions principales restent distinctes, même lorsqu'un seul service les fournit.
La défense contre les menaces évalue la destination
Les contrôles de menaces peuvent refuser les recherches pour les domaines de hameçonnage et de logiciels malveillants connus. Notre solution de protection contre les menaces bloque également les rappels de commande et contrôle émis par des appareils infectés lors de la recherche, empêchant ainsi ces tentatives de connexion de démarrer via ce chemin de résolution.
C'est un confinement utile, mais cela ne supprime pas les logiciels malveillants de l'appareil. La protection des points d'accès et les contrôles du pare-feu conservent leurs propres fonctions.
DNSSEC vérifie l'authenticité, pas la sécurité
La validation DNSSEC utilise une ancres de confiance configurée et une chaîne de signatures cryptographiques pour authentifier les données DNS signées. La RFC 4033 décrit la validation sécurisée et indique qu'un résolveur sensibilisé à la sécurité doit prendre en compte la validité de la signature lors de la sélection des durées de vie en cache, en tenant compte des inexactitudes de l'horloge.
Les administrateurs ont donc besoin d'une heure système précise et d'une gestion du cache qui préserve l'état de validation. Un résolveur doit distinguer les données légitimement non signées des données signées dont la validation a échoué.
- Contrôle précoce : Le filtrage peut stopper une recherche indésirable avant le début de la connexion, mais uniquement pour les requêtes utilisant ce résolveur.
- Règles cohérentes : Les appareils utilisant la même politique réseau bénéficient d'un traitement cohérent, mais les chemins de résolution alternatifs nécessitent des contrôles distincts.
- Vérification d'authenticité : DNSSEC aide à détecter les réponses signées falsifiées, mais n'encrypte pas les requêtes et ne détermine pas si un domaine est malveillant.
Un domaine d'hameçonnage correctement signé reste un domaine d'hameçonnage. Le filtrage détermine si l'accès doit être autorisé ; DNSSEC établit si les informations DNS signées sont authentiques.
Pannes, réponses obsolètes et idées reçues courantes
Un invité ouvre un site Web alors que son serveur DNS autoritatif est inaccessible, mais la page se charge tout de même. Le résolveur dispose peut-être d'une réponse en cache non expirée, et n'a donc pas besoin de contacter ce serveur autoritatif pour cette requête.
Certains résolveurs peuvent également fournir des réponses périmées après l'expiration ordinaire lorsque les serveurs en amont sont indisponibles. Il s'agit d'une stratégie de disponibilité, et non de la preuve que les enregistrements DNS restent valides indéfiniment. Le guide explicatif DNS de Cloudflare présente la distinction fondamentale entre le résolveur qui récupère les informations et le serveur autoritaire qui les fournit.
Les réponses en cache expliquent pourquoi une panne de serveur autoritaire ne se transforme pas toujours immédiatement en une interruption de navigation.
La disponibilité et la protection nécessitent des choix explicites
Les résolveurs peuvent également mettre en cache les résultats infructueux. Le mise en cache négative conserve des informations telles que l'absence d'un nom, évitant ainsi des recherches répétées pour ce même nom manquant. Après qu'un administrateur a créé ce nom, certains clients peuvent continuer à recevoir le résultat négatif mis en cache jusqu'à ce qu'il expire.
La gestion des défaillances soulevant une question de politique distincte. Une conception de filtrage en mode fail-open autorise la résolution sans ses vérifications de politique habituelles lorsque ces vérifications ne sont pas disponibles. Une conception en mode fail-closed refuse les requêtes qu'elle ne peut pas approuver, préservant la restriction mais risquant d'interrompre des accès légitimes.
Les échecs de validation DNSSEC constituent un autre cas distinct. Les opérateurs ne doivent pas traiter des données signées invalides comme étant authentifiées uniquement pour maintenir le chargement d'une page.
Hypothèses entraînant des erreurs opérationnelles
- La récursion implique automatiquement un blocage : La récursion récupère les réponses ; les administrateurs ajoutent le blocage via une couche de politique.
- Un filtre DNS contrôle chaque connexion : Les adresses de destination codées en dur et certains chemins VPN peuvent contourner entièrement la recherche protégée.
- Modifier le DNS réseau déplace instantanément chaque client : Les paramètres existants, les baux DHCP et les choix de résolveurs au niveau du navigateur peuvent laisser des appareils sur un autre chemin.
Lors de l'analyse d'une panne, faites la distinction entre une autorité inaccessible, un enregistrement expiré, une réponse négative, un échec de validation et un rejet par la politique. Ces situations peuvent sembler similaires pour un invité, mais nécessitent des solutions différentes.
La récursion déplace les réponses. Les politiques et la résilience déterminent les réponses que le réseau fournira en fonction des conditions changeantes.
Confirmez quel résolveur votre réseau utilise avant de le modifier
Si vous demandez ce qu'est le DNS récursif parce que vous êtes sur le point de modifier un réseau en production, commencez par cartographier le chemin actuel. Enregistrez la configuration fonctionnelle afin de pouvoir la restaurer si les tests révèlent une dépendance à un nom interne ou à une application.
Vérifier le parcours avant le déploiement
- Identifier le service DNS configuré sur l'appareil. Utiliser ses paramètres réseau ou un outil de recherche DNS. L'adresse d'un routeur peut représenter un service de retransmission ; il convient donc de tracer également sa destination en amont.
- Inspecter les paramètres DHCP et du contrôleur. Confirmer quel résolveur le réseau annonce et si les clients configurés manuellement le suivent.
- Définir la politique requise par écrit. Identifier les catégories de contenu, le contrôle des logiciels malveillants, l'historique des recherches et les différences entre l'accès personnel et l'accès invité.
- Choisir le comportement de mise à jour acceptable. Préciser les délais tolérables de rafraîchissement des enregistrements et de mise à jour des politiques, ainsi que la réponse prévue en cas de défaillance du service.
- Effectuer un pilote sur un réseau limité. Tester les sites autorisés, les destinations bloquées, les ressources internes et la restauration avant d'étendre la modification.
Le déploiement s'effectue via un paramètre DNS par réseau ou une modification DHCP sur le contrôleur, sans rien installer sur les appareils clients. Cela couvre les appareils qui suivent la configuration DNS du réseau, sans pour autant garantir que chaque application l'utilise.
Testez les VPN et le DNS over HTTPS, qui peuvent créer des chemins de résolution alternatifs. Notre équipe vous montre comment le réseau gère les VPN et le DNS chiffré avant un essai.
Un résolveur récursif associé à des règles de sécurité est le choix idéal lorsque le réseau nécessite un filtrage avant l'établissement des connexions et que le propriétaire en accepte le cache et le comportement en cas d'échec.
Purple Shield fournit un DNS protecteur, du filtrage de contenu, de la protection contre les menaces et du blocage des publicitaires au niveau du DNS pour le WiFi invité et public, sans agents d'équipement. Consultez Purple Shield pour échanger sur le chemin du résolveur de votre réseau, les politiques dont vous avez besoin et la manière de tester leur application avant de déployer une modification du DNS.