Qu'est-ce que le transfert DNS ? Fonctionnement et importance
Qu'est-ce que le transfert DNS ? Découvrez la différence entre les redirecteurs et les résolveurs récursifs, le fonctionnement du cache et du basculement, et la place du transfert dans les réseaux modernes.
Published 23 octobre 2026
La redirection DNS est le processus par lequel un résolveur DNS envoie la requête d'un client vers un autre serveur DNS, le redirecteur, au lieu de résoudre le nom directement via la hiérarchie DNS. Le résolveur local peut toujours répondre à partir de son cache et appliquer des règles locales, tandis que le serveur en amont effectue la recherche complète si nécessaire. Mais si ce serveur en amont échoue, quelle partie du DNS est défaillante ?
Cette distinction a son importance lorsque vous configurez un réseau ou que vous tentez d'expliquer pourquoi un site web ne se charge pas. Un résolveur de redirection ne se contente pas d'acheminer des paquets : il peut répondre localement aux requêtes connues, orienter certaines requêtes sélectionnées vers différents serveurs et définir quel résolveur voit le trafic DNS d'un utilisateur.
Table des matières
- Ce que signifie réellement la redirection DNS
- Suivre une requête du client jusqu'à la réponse
- En quoi la redirection diffère de la récursion et du service d'autorité
- Redirection conditionnelle, Split-Horizon et prévention des boucles
- Comment la mise en cache et le TTL façonnent les performances de redirection
- Choisir entre redirection, récursion par Root-Hints et DNS chiffré
- Mettre en œuvre la redirection sur votre réseau
Ce que signifie réellement la redirection DNS
Considérez le résolveur local comme la réception d'un service de courrier. Un client demande un site Web par son nom, et le résolveur vérifie s'il connaît déjà la réponse. S'il dispose d'une réponse valide dans son cache, il la renvoie. Sinon, il envoie la requête à un serveur DNS en amont, le réachemineur, qui gère la recherche et renvoie une réponse.
Cette disposition sépare deux fonctions. Le résolveur local fait face aux clients du réseau et peut appliquer des règles locales. Le résolveur en amont prend en charge le travail de résolution des noms auxquels le serveur local ne peut pas répondre à partir de son cache ou de ses données locales. Le réacheminement est donc une fonction architecturale, et non automatiquement un produit de sécurité.
Le DNS est apparu en novembre 1983, lorsque les RFC 882 et RFC 883 ont introduit un système de nommage hiérarchique pour remplacer le modèle HOSTS.TXT devenu ingérable. Avant le DNS, les administrateurs s'appuyaient sur des correspondances nom-adresse gérées manuellement. En novembre 1987, les RFC 1034 et RFC 1035 ont remplacé les spécifications d'origine pour devenir les normes fondamentales de l'architecture DNS moderne, comme le rappelle la chronologie de l'histoire du DNS.
Où vous rencontrerez la redirection
Les routeurs domestiques, les réseaux d'entreprise, le WiFi public, les établissements scolaires et les environnements cloud peuvent tous utiliser la redirection. Une organisation peut l'employer pour envoyer des recherches internet générales vers un service récursif géré tout en conservant un contrôle local sur le cache, la journalisation, les noms internes ou les règles de blocage.
Le modèle mental utile est simple : le résolveur local est la réception contrôlée ; le résolveur en amont est le spécialiste qui effectue la recherche complète. Ce modèle facilite également la localisation d'un problème. Un client peut atteindre la réception avec succès même si le résolveur en amont est indisponible ou renvoie une erreur.
Suivre une requête du client jusqu'à la réponse
Une recherche type commence lorsqu'un appareil demande un nom à son résolveur local. Le résolveur consulte d'abord son cache. Si la réponse enregistrée est toujours valide, il peut la retourner sans contacter de serveur amont. S'il n'y a pas de réponse utilisable en cache, le résolveur redirige la requête vers un résolveur récursif amont.
Dans la terminologie DNS, le réacheminement implique qu'un résolveur envoie une requête avec le bit RD (recursion-desired) activé. Ce bit indique qu'il est demandé au résolveur destinataire de résoudre la requête, plutôt que de simplement relayer un paquet sans cette demande. La définition du glossaire de la RFC 7719 distingue le réacheminement du simple relais aveugle de paquets.
En cas de manque dans le cache (cache miss), le résolveur récursif en amont effectue le travail de recherche. Il peut utiliser son propre cache ou interroger la hiérarchie DNS pour obtenir la réponse. La réponse retourne ensuite au client en passant par le résolveur de réacheminement.
Les deux chemins possibles
- Succès du cache : Le résolveur local renvoie une réponse valide mise en cache. Le serveur amont n'intervient pas dans cette recherche.
- Échec du cache : Le résolveur local envoie la requête en amont, reçoit la réponse et la renvoie au client.
Le passage de relais définit également un partage utile des responsabilités. Le résolveur local peut appliquer des contrôles spécifiques au réseau, conserver des journaux, utiliser des règles de split-DNS ou appliquer une politique de validation DNSSEC. Le résolveur amont effectue la recherche récursive lorsque le résolveur local ne peut pas répondre à partir de son cache ou de ses données locales.
Indice de dépannage : Si le résolveur local répond aux clients mais que les recherches échouent lorsque son cache ne contient pas la réponse, vérifiez le chemin de redirection et la réponse en amont avant de supposer que le service DNS autoritaire est en cause.
En quoi la redirection diffère de la récursion et du service autoritaire
Le réacheminement DNS, la récursion, le proxying et le service autoritatif décrivent des rôles différents. Un seul système peut assumer plus d'un rôle, mais les termes ne sont pas interchangeables. Dans une configuration de réacheminement typique, le serveur local sert les clients et maintient un cache ou des politiques ; un résolveur récursif en amont effectue la résolution pour les échecs de cache.
| Rôle | Qui initie | Effectue la recherche complète | Détient les données d'autorité | Symptôme de défaillance typique |
|---|---|---|---|---|
| Forwarder (Relais) | Un résolveur local lui envoie une requête | Généralement, lorsqu'il agit comme résolveur récursif en amont | Pas nécessairement | Délai d'attente dépassé ou erreur du service en amont |
| Résolveur récursif | Un client ou un autre résolveur demande une résolution | Oui, en utilisant le cache ou en interrogeant la hiérarchie DNS | Pas nécessairement | Erreurs de résolution, délais dépassés ou échecs de recherche |
| Proxy | Un client ou un service lui envoie du trafic | Pas de manière inhérente ; le relais transmet les requêtes selon sa conception | Non | La requête relayée échoue ou ne peut pas atteindre sa destination |
| Serveur d'autorité | Un résolveur l'interroge pour un domaine qu'il dessert | Non, il fournit des données pour sa zone | Oui, pour les zones qu'il dessert | Enregistrements manquants, incorrects ou indisponibles pour ces zones |
La distinction clé du tableau réside dans qui effectue la recherche complète. Un résolveur de réacheminement transmet une requête sans réponse ; un résolveur récursif gère la résolution, potentiellement en interrogeant des serveurs autoritatifs. Un serveur autoritatif fournit des enregistrements pour le domaine qu'il gère plutôt que de chercher dans la hiérarchie pour le compte d'un client.
Pourquoi cette distinction modifie le dépannage
Un résolveur de redirection peut renvoyer un délai d'expiration en amont, une erreur SERVFAIL ou une réponse en cache qui n'est plus appropriée, même lorsque l'infrastructure DNS d'autorité fonctionne normalement. Résoudre uniquement les problèmes du serveur d'autorité dans cette situation peut vous orienter vers une mauvaise piste. Vérifiez quel résolveur a reçu la requête, s'il disposait d'une réponse en cache et ce qui s'est passé au saut suivant.
Il existe également une dépendance de confiance. La norme RFC 7719 aborde la terminologie des résolveurs, notamment la distinction entre les réachemineurs et les résolveurs récursifs. Les recherches sur les attaques par empoisonnement de cache distinguent ces rôles car un réachemineur dépend de l'intégrité du résolveur en amont qu'il utilise. Si le contrôle du contenu fait partie de la conception, un réseau peut également utiliser le filtrage DNS pour appliquer des politiques aux requêtes avant que les appareils ne se connectent aux destinations.
Redirection conditionnelle, Split Horizon et prévention des boucles
Le réacheminement n'a pas à envoyer chaque requête sans réponse au même serveur en amont. Avec le réacheminement conditionnel, un résolveur envoie les requêtes pour des domaines sélectionnés à un serveur désigné. Par exemple, un réseau peut diriger les demandes de noms internes vers un service DNS interne et envoyer les autres requêtes vers un résolveur récursif géré.
Un concept associé est le DNS split-horizon. Il permet à un réseau de renvoyer des réponses différentes pour un même nom en fonction de l'origine de la requête. Une personne au sein d'une organisation peut recevoir une réponse interne, tandis qu'un demandeur externe reçoit une réponse différente. Le résolveur local devient alors un point de décision pour maintenir les noms internes sur le chemin approprié.
La configuration doit indiquer clairement quel résolveur détient chaque chemin de requête. Une règle qui envoie un nom interne au mauvais serveur en amont peut produire une réponse externe, un échec de résolution ou un résultat qui diffère selon les parties du réseau.
Prévention des boucles de résolveur
Une boucle de redirection se produit lorsqu'un résolveur envoie une requête à un second résolveur qui finit par la lui renvoyer. La requête peut alors tourner en boucle entre les serveurs, provoquant des requêtes répétées, des délais d'expiration et l'épuisement des ressources. La solution consiste à cartographier les chemins de redirection et à s'assurer qu'aucune chaîne de résolveurs ne pointe vers un serveur amont.
Certains noms nécessitent également une limite explicite. La RFC 9539 souligne que des espaces de noms tels que home.arpa ne doivent pas être réacheminés au-delà de leur portée locale prévue. Un résolveur qui fonctionne jusqu'à ce qu'un second réachemineur soit ajouté a peut-être formé une boucle - un nom local qui commence à se résoudre publiquement peut nécessiter une règle de réacheminement ou de zone locale plus spécifique.
La vidéo ci-dessous fournit une autre introduction visuelle aux concepts de réacheminement DNS.
Comment la mise en cache et le TTL façonnent la performance de redirection
Le cache d'un redirecteur fonctionne comme la mémoire d'un intermédiaire utile : une fois qu'il a récupéré une réponse en amont, il peut répondre lui-même à la question identique suivante. Ce simple comportement explique la majeure partie de l'impact de la redirection sur les performances. Chaque succès de cache évite un aller-retour vers le résolveur en amont. Chaque échec en ajoute un avant même que la recherche réelle ne commence.
Le durée de vie (TTL) de chaque enregistrement définit la limite de cette mémoire. Le serveur d'autorité publie la valeur TTL, et tout résolveur le long du chemin ne peut réutiliser la réponse en cache que tant qu'elle reste valide. Des TTL courts maintiennent les réponses à jour mais envoient plus de requêtes en amont. Des TTL longs réduisent le trafic en amont mais peuvent laisser les clients avec des adresses obsolètes après un changement d'infrastructure.
La mise en cache s'empile également le long du chemin. Une requête peut être traitée par le cache du client, le cache du redirecteur ou le cache du résolveur en amont, et chaque couche exécute son propre décompte TTL. Lorsqu'un utilisateur signale une réponse obsolète, la correction dépend de la couche qui la détient ; traitez donc chaque cache comme un suspect distinct lors du dépannage au lieu de vider le premier cache venu.
Mesurer plus que la latence moyenne
Le temps de recherche moyen peut masquer des problèmes qui affectent davantage certains utilisateurs ou certaines requêtes. Suivez le taux de réussite du cache, la latence médiane et maximale, le taux de dépassement de délai en amont et le comportement du cache négatif. Ces mesures aident à distinguer un service en amont lent d'un relais qui manque constamment les opportunités de mise en cache ou qui gère mal les échecs de recherche.
DNSSEC ajoute une contrainte supplémentaire. Un résolveur de validation récupère les signatures et les clés en plus de la réponse elle-même, de sorte que les échecs de cache sur des noms signés coûtent plus cher que sur des noms non signés. Les réponses validées en cache évitent la répétition de ce travail, ce qui rend le taux de réussite du cache encore plus critique sur les chemins de validation.
Aucun chiffre unique ne permet de prédire le temps de recherche sur un réseau donné. Le résultat dépend de l'état du cache à chaque couche, de la réactivité en amont, du travail de validation, de la configuration du transport et des tentatives d'accès après un redirecteur non réactif. Un redirecteur performant transmet également les codes de réponse, le comportement de tronquage, les enregistrements DNSSEC et les indicateurs sans modification, afin que les clients voient la réponse envoyée par le serveur d'autorité.
Choisir entre redirection, récursion par racines DNS et DNS chiffré
Le réacheminement et la récursion via les indicateurs racines (root-hints) présentent des compromis différents. Avec le réacheminement, une organisation sélectionne des résolveurs en amont pour traiter les requêtes sans réponse. Cela peut simplifier les opérations locales et centraliser les politiques, mais rend le réseau dépendant des services en amont choisis. Avec la récursion par indicateurs racines, un résolveur effectue lui-même la recherche itérative, ce qui réduit la dépendance à l'égard d'un seul service récursif en amont, mais attribue une plus grande responsabilité de résolution à ce résolveur.
| Choix d'architecture | Lieu de la résolution | Principal compromis opérationnel |
|---|---|---|
| Réacheminement | Au niveau du résolveur récursif en amont sélectionné | Administration centralisée, avec une dépendance en amont |
| Récursion basée sur les root-hints | Au niveau du résolveur récursif local, qui interroge la hiérarchie | Contrôle local accru, avec plus de responsabilité pour la résolution directe |
| DNS chiffré géré par le client | Au niveau du résolveur que le client contacte via une connexion chiffrée | Le réseau local peut ne pas voir ni contrôler la requête de domaine |
Le DNS chiffré rend ce choix moins évident. DNS over TLS et DNS over QUIC peuvent protéger le trafic DNS en transit, mais la question essentielle est de savoir où se termine le chiffrement. Si un client chiffre les requêtes directement vers un résolveur externe, un réachemineur local risque de ne pas voir de requête de domaine exploitable. Si le chiffrement se termine au niveau d'un résolveur d'entreprise approuvé, ce résolveur peut toujours appliquer les politiques réseau et réacheminer les requêtes en amont.
Le WiFi public nécessite une politique délibérée
Les opérateurs de WiFi public doivent également prendre en compte les Captive Portals. Les appareils peuvent avoir besoin d'une résolution de noms de pré-authentification et de vérifications de connectivité avant que les utilisateurs ne puissent se connecter. Le DNS chiffré peut compliquer la détection du portail ou la retarder, les opérateurs doivent donc décider quels résolveurs sont approuvés, comment le secours doit fonctionner et si des exceptions sont nécessaires.
Un service DNS protecteur peut se placer sur le chemin de résolution sélectionné et évaluer les recherches avant le début des connexions. Purple Shield est conçu pour les réseaux WiFi de lieux physiques et invités, avec un filtrage de contenu par catégorie, un blocage des menaces au niveau de la couche DNS et des politiques pouvant être gérées par réseau. Il peut être déployé en tant que service indépendant ou intégré aux réseaux Purple Access. Pour les équipes qui comparent les contrôles DNS à des contrôles de trafic web plus larges, un aperçu des passerelles web sécurisées décrit un niveau d'application différent.
Mettre en œuvre la redirection sur votre réseau
Le réacheminement concentre une partie de la charge de travail DNS sur les services en amont sélectionnés par une organisation. Des mesures effectuées à l'aide des ensembles de données Day in the Life de DNS-OARC ont montré qu'environ 99 % des résolveurs récursifs généraient des volumes de requêtes modérés, tandis qu'environ 1 % adoptaient un comportement agressif. Ce groupe plus restreint représentait jusqu'à 98 % du trafic DNS observé en 2018 et 93 % en 2019 ; les chercheurs ont estimé qu'il comprenait environ 8 300 résolveurs en 2018 et plus de 14 000 en 2019 (étude sur le comportement des résolveurs agressifs). Un résolveur local peut envoyer des requêtes à des services récursifs en amont qui mettent en cache et réutilisent les réponses, mais cela concentre la dépendance sur leur disponibilité et leur comportement.
Avant de déployer ou de modifier la redirection, vérifiez que :
- Les serveurs en amont sont indépendants : Configurez au moins deux réachemineurs lorsque l'architecture le permet.
- Les échecs ont une réponse définie : Définissez le délai d'expiration et le comportement de réessai, et sachez ce que les clients reçoivent si un serveur en amont ne répond pas.
- La surveillance couvre les symptômes : Surveillez les réponses SERVFAIL, les délais d'expiration et la latence de réponse.
- Les attentes en matière de confidentialité sont claires : Décidez quel résolveur en amont peut voir les requêtes réacheminées.
Si le filtrage DNS fait partie de votre politique de réseau invité, comparez-le avec votre approche globale de filtrage de contenu WiFi. Inspectez ensuite vers quel résolveur votre réseau effectue le réacheminement et confirmez que sa politique, sa disponibilité et sa posture de confidentialité correspondent à vos attentes.
Purple Shield vérifie les requêtes DNS avant que les appareils ne se connectent et propose un filtrage de contenu ainsi qu'un blocage des menaces pour les réseaux WiFi visiteurs et d'établissements. Si vous étudiez la façon dont la redirection peut appuyer ces contrôles, visitez Purple Shield pour découvrir ses options de déploiement.