Qu'est-ce qu'une recherche DNS et pourquoi les réseaux l'utilisent
Découvrez ce qu'est une recherche DNS, comment fonctionnent les étapes de résolution, et pourquoi ce moment constitue un contrôle pratique de sécurité et de performance sur un réseau WiFi partagé.
Published 24 octobre 2026
Une recherche DNS est la manière dont un résolveur trouve les informations associées à un nom de domaine lisible par l'homme, le plus souvent une adresse IP. Le processus classique vérifie les informations locales, trouve les meilleurs serveurs, les interroge pour obtenir une réponse, puis renvoie et met en cache le résultat.
Vous lisez peut-être ceci sur le réseau WiFi d'un hôtel, d'une école ou d'un hôpital après avoir cliqué sur un site familier. Votre appareil est connecté, mais avant que la page ne puisse se charger, le réseau doit trouver où ce site réside. Pensez au DNS comme à un annuaire distribué qui aide votre appareil à localiser des services, et non comme à un simple annuaire téléphonique de sites web.
Cette distinction a son importance sur un WiFi partagé. Le résolveur qui traite une recherche peut influer sur la vitesse d'ouverture d'une page, le blocage d'un domaine et la capacité du réseau de l'établissement à voir ou gérer la requête. Le chiffrement, l'authenticité, l'application des politiques et l'anonymat sont des propriétés distinctes, et les confondre peut conduire à de mauvaises décisions de sécurité.
Table des matières
- Ce qu'accomplit réellement une recherche DNS
- Les étapes d'une recherche DNS
- La hiérarchie qui permet l'évolutivité des recherches
- Pourquoi une recherche DNS est un point d'application des règles
- Ce que le DNS chiffré change réellement
- Lorsqu'une recherche DNS échoue sur un WiFi partagé
- Comment choisir ensuite un DNS protecteur
Ce que fait réellement une recherche DNS
Un client clique sur un lien sur le réseau WiFi d'un hôtel. Le navigateur connaît le nom de domaine, mais les équipements réseau acheminent le trafic en utilisant des adresses IP. Une recherche DNS correspond au résolveur qui trouve les informations associées à ce nom lisible par l'homme, le plus souvent une adresse IP, afin que l'appareil puisse commencer à joindre le service.
L'analogie de l'annuaire téléphonique est un bon point de départ, mais le DNS ressemble davantage à un annuaire distribué en direct. Différents types d'enregistrements prennent en charge la distribution du courrier électronique, les alias, la découverte de services, les recherches inverses et d'autres fonctions réseau. Le DNS ne se contente pas d'associer des noms de sites web à des adresses. Il aide les applications à trouver toute une gamme de services réseau.
Les spécifications DNS fondamentales sont apparues en novembre 1987, lorsque l'Internet Engineering Task Force a publié l'RFC 1034. Ce document décrivait un algorithme en quatre étapes : vérifier les informations locales, trouver les meilleurs serveurs, les interroger jusqu'à ce qu'une réponse arrive, puis retourner et mettre en cache le résultat le cas échéant (RFC 1034). La mise en cache est importante car un résolveur peut déjà disposer d'une réponse utilisable provenant d'une requête précédente.
Une requête d'annuaire, pas une demande de page
Lorsque votre appareil demande un nom, il ne demande pas au DNS de fournir la page web. Il demande des informations qui aident l'application à atteindre le service concerné. Le navigateur utilise ensuite la réponse dans le cadre de son processus de connexion.
Sur un WiFi invité, cela fait de la recherche un point de décision partagé utile. Le résolveur voit le nom demandé avant de renvoyer une adresse, ce qui permet aux opérateurs réseau d'utiliser ce moment pour appliquer des politiques. Pour un aperçu pratique de la façon dont les problèmes de DNS peuvent affecter la disponibilité, consultez ce guide pour prévenir les temps d'arrêt causés par des défaillances DNS.
Comprendre ce processus vous aide à retracer l'acheminement d'une recherche, à comprendre pourquoi les réponses en cache peuvent être plus rapides et à identifier ce que le DNS peut et ne peut pas contrôler sur un WiFi partagé. La vitesse, les politiques, le chiffrement et les échecs de recherche sont liés, mais ils ne représentent pas le même problème.
Étapes au sein d'une recherche DNS
Un client d'hôtel saisit example.com dans son navigateur et appuie sur Entrée. La page n'est pas encore chargée. Avant qu'elle ne puisse l'être, le nom passe par une séquence fixe de recherches, et sur un réseau WiFi partagé, chaque étape offre au réseau de l'établissement une nouvelle opportunité d'observer ou de diriger la requête.
Le résolveur stub de l'appareil démarre la séquence en transmettant une requête récursive à un résolveur de mise en cache. Un établissement, un fournisseur d'accès Internet ou un service DNS indépendant peut exploiter ce résolveur, et ce choix est crucial car il détermine qui voit la requête en premier.
Succès de cache ou échec de cache
Le résolveur de mise en cache vérifie d'abord sa mémoire. Un enregistrement toujours valide est renvoyé directement, un succès de cache (cache hit) qui évite tout échange en amont. Un enregistrement manquant ou expiré constitue un échec de cache (cache miss), et le résolveur parcourt alors la hiérarchie DNS : un serveur racine l'oriente vers le bon domaine de premier niveau (TLD), un serveur TLD l'oriente vers le serveur de noms faisant autorité pour le domaine, et ce serveur de noms renvoie l'enregistrement.
Pour un site web, la réponse est généralement un enregistrement A contenant une adresse IPv4 ou un enregistrement AAAA contenant une adresse IPv6. D'autres types d'enregistrements couvrent des fonctions telles que le routage des e-mails et les alias.
Ces étapes soulèvent également des questions distinctes. Le chiffrement détermine qui peut lire la requête en transit. L'authenticité détermine si la réponse provient bien de l'opérateur du domaine. La politique détermine si le résolveur la renvoie ou non. L'anonymat détermine quelles parties ont appris le nom en premier lieu.
Le TTL maintient les réponses en cache à jour
Chaque ensemble d'enregistrements porte un durée de vie (TTL), à savoir le temps maximum pendant lequel un résolveur peut le conserver. Le résolveur doit supprimer l'enregistrement à son expiration, ce qui permet de réintégrer les adresses et politiques mises à jour dans la circulation.
L'absence de cache pour un client permet d'alimenter le cache pour les visiteurs suivants. Des valeurs TTL courtes permettent d'appliquer les modifications plus rapidement ; des valeurs TTL longues réduisent les recherches répétées en amont. Les opérateurs de zone définissent le bon compromis, et tous les utilisateurs du réseau partagé en héritent du résultat.
Certains réseaux insèrent une étape de redirection au sein de cette séquence, en envoyant les requêtes à un autre résolveur plutôt qu'en parcourant directement la hiérarchie. Cette explication sur la manière dont la redirection DNS modifie ce parcours détaille l'endroit où le détournement se produit.
La hiérarchie qui permet l'évolutivité des recherches
La hiérarchie DNS divise la responsabilité. Au sommet se trouvent les identités des serveurs racines, qui dirigent les résolveurs vers le bon domaine de premier niveau. Les serveurs TLD gèrent les domaines tels que .com et .org, tandis que les serveurs faisant autorité de chaque domaine fournissent les enregistrements pour les noms au sein de ce domaine.
L'image habituelle de 13 serveurs racines peut être trompeuse. Il existe 13 identités définies historiquement, désignées de A à M, exploitées par 12 organisations indépendantes. Il ne s'agit pas simplement de 13 ordinateurs physiques. Le routage Anycast permet de desservir ces mêmes identités à partir de plus de 900 instances réparties dans le monde entier, ce qui aide les requêtes à atteindre une instance proche et renforce la résilience (présentation des serveurs racines par l'ICANN).
Comment le système racine s'est développé
Le système racine s'est développé au rythme de l'évolution des besoins du réseau. Le premier serveur racine a été établi à l'Information Sciences Institute de l'Université de Californie du Sud en 1984. Le système comptait quatre serveurs en 1985, sept en 1987, neuf en 1993 et 13 en 1997. Aujourd'hui, le système racine utilise à la fois IPv4 et IPv6. Une présentation technique identifie 26 points de terminaison d'adresses principaux, soit 13 pour chaque protocole, aux côtés des instances anycast distribuées.
Ces chiffres décrivent différentes parties de la conception. Les 13 identités sont les noms identifiables des serveurs racines ; les points de terminaison d'adresses prennent en charge IPv4 et IPv6 ; les instances distribuées aident à fournir le service depuis des emplacements à travers le monde. Perdre l'accès à une instance ne revient pas à perdre une identité racine partout.
Cette conception explique pourquoi une recherche peut sembler locale même lorsqu'elle s'appuie sur un système mondial multi-niveaux. Le résolveur peut atteindre une instance à proximité, tandis que la hiérarchie continue de répartir la responsabilité entre les opérateurs racines, TLD et autoritaires.
Pourquoi une recherche DNS est un point d'application des politiques
Un ordinateur portable connecté au WiFi d'un hôtel sollicite le résolveur du réseau pour un domaine avant de pouvoir accéder à quoi que ce soit. Cette requête passe par des équipements contrôlés par l'établissement, ce qui fait de cette recherche le dernier point de décision partagé avant que l'appareil ne poursuive sa navigation. Un service DNS protecteur peut répondre normalement, refuser la requête ou renvoyer une réponse qui n'aboutit nulle part. Si aucune adresse utilisable n'est retournée, la connexion ne démarre généralement jamais.
Cette position est précisément ce qui donne aux politiques DNS toute leur portée sur les réseaux invités. Les téléphones et ordinateurs portables des visiteurs intègrent rarement un logiciel de gestion, l'établissement ne peut donc pas installer de contrôles sur l'appareil lui-même. Le résolveur est le seul point de contrôle par lequel chaque appareil passe déjà. Les politiques qui y sont appliquées peuvent bloquer les domaines associés au hameçonnage, aux logiciels malveillants ou au trafic de commande et contrôle, appliquer des catégories comme le contenu adulte ou les jeux d'argent, et imposer les paramètres de recherche sécurisée (Safe Search).
L'aspect temporel renforce le dossier. L'application de la politique intervient dès l'étape de la requête, avant que l'application ne reçoive une adresse via ce résolveur. Pour les protections fonctionnant à d'autres couches d'un réseau, consultez ce guide pour protéger votre réseau d'entreprise Microsoft 365.
Ce qu'une politique DNS peut et ne peut pas couvrir
L'application des règles DNS régit la résolution de noms, mais les connexions peuvent la contourner. Une application peut réutiliser une adresse en cache, contacter directement une IP, accéder à un service n'ayant jamais utilisé de nom DNS ou envoyer des requêtes via un résolveur chiffré non attribué par l'établissement.
Les opérateurs évaluent donc le comportement du DNS chiffré, les caches d'applications et le trafic IP direct aux côtés du filtrage. Le filtrage DNS fonctionne comme une couche au sein d'un ensemble de contrôles plus large. Un guide sur le filtrage DNS et la façon dont les politiques s'appliquent aux recherches détaille ce rôle de filtrage.
La politique n'est également qu'un axe de confiance parmi d'autres. Qu'un domaine soit autorisé, qu'une réponse soit authentique et que quelqu'un puisse lire la requête en transit sont des questions distinctes, traitées par des mécanismes différents.
Les réponses négatives méritent également une attention particulière. Un résolveur peut mettre en cache une réponse NXDOMAIN, qui indique que le domaine demandé n'existe pas, au lieu de solliciter à nouveau les serveurs en amont pour le même nom manquant. La norme RFC 8020 décrit une coupure NXDOMAIN, où une réponse négative validée établit également que les noms situés sous le domaine manquant n'existent pas (RFC 8020). Des directives IETF plus récentes préconisent de mettre aussi en cache les échecs de résolution, réduisant ainsi les requêtes répétées inutilement.
Ce que le DNS chiffré change réellement
Un invité se connecte au WiFi d'un hôtel et visite un site web. La recherche DNS est l'un des derniers points de décision partagés avant la connexion : l'appareil demande à un résolveur quelle adresse utiliser, et le résolveur peut appliquer les règles de l'établissement. Chiffrer cette requête modifie qui peut la lire en transit. Cela ne change pas, en soi, ce que le résolveur peut voir et ne rend pas l'invité anonyme.
L'appareil envoie sa requête à un résolveur récursif, qui recherche la réponse et la renvoie. DNS over HTTPS (DoH) chiffre la connexion entre l'appareil et ce résolveur. Une personne surveillant le WiFi aura plus de difficultés à lire ou modifier la requête, mais le résolveur reçoit toujours le domaine demandé.
DNSSEC traite un problème distinct : il permet à un résolveur de validation de vérifier l'authenticité et l'intégrité des données DNS signées. Il ne chiffre pas la requête. Le chiffrement, l'authenticité, l'application des politiques et l'anonymat sont des caractéristiques différentes.
Le compromis sur le WiFi partagé
Un navigateur utilisant DoH peut envoyer des requêtes à un résolveur choisi par le navigateur ou l'utilisateur, plutôt qu'au résolveur attribué par un hôtel, une école, un établissement de santé ou un opérateur de WiFi public. Cela peut limiter ce que l'établissement voit et quelles règles DNS il peut appliquer. Cela peut également rendre le dépannage plus difficile si le réseau de l'établissement dépend de son propre résolveur.
La différence pratique est claire : DoH protège la requête sur son trajet vers le résolveur ; il ne masque pas la requête à ce résolveur. DNSSEC aide à vérifier les réponses signées. Un établissement ne peut appliquer une politique DNS que lorsque les requêtes concernées passent par un résolveur qu'il contrôle ou avec lequel il s'est intégré, et aucune de ces technologies ne rend un utilisateur anonyme.
Lorsqu'une recherche DNS échoue sur un WiFi partagé
Deux visiteurs se connectent au même réseau WiFi d'un hôtel. L'un ouvre un site web familier ; l'autre voit une erreur, même si les deux appareils indiquent qu'ils sont connectés. La différence peut résider dans le chemin de recherche, le cache de l'appareil ou le résolveur utilisé par chaque client.
Un résolveur peut être inatteignable, renvoyer une réponse incomplète ou être incapable de résoudre un nom qui existe uniquement au sein du réseau d'une entreprise. Un réseau peut également bloquer le trafic DNS traditionnel via le port UDP ou TCP 53, ou renvoyer délibérément un échec en raison d'une politique bloquant le domaine demandé.
Séparez les symptômes avant de modifier les paramètres
Prenons l'exemple du portail interne d'une école qui fonctionne via le résolveur désigné de l'établissement, mais pas via un résolveur public externe. L'école peut utiliser un DNS split-horizon, où les noms internes ne sont accessibles que via le résolveur du réseau. Modifier la configuration DNS d'un appareil peut permettre de charger un site web public tout en bloquant l'accès au portail interne.
Le DNS chiffré peut ajouter un point de défaillance supplémentaire. Une étude de 2025 indique que les requêtes DNS HTTPS représentaient environ 8 % du trafic DNS observé, et que les réponses incomplètes augmentaient le volume de requêtes (étude sur le trafic DNS chiffré). Des recherches distinctes sur les résolveurs ont révélé qu'un résolveur chiffré annoncé sur trois ne répondait pas, comme mentionné précédemment. Un client pourrait donc utiliser un résolveur chiffré qui ne répond pas comme prévu, même si le résolveur attribué par le site est disponible.
Règle de dépannage : Confirmez le résolveur réellement utilisé par le client avant de lui demander de modifier ses paramètres DNS.
Pour les opérateurs, triez les causes probables plutôt que de traiter chaque erreur de recherche de la même manière :
- Captive Portal : L'appareil n'a pas terminé la connexion WiFi ou validé la page des conditions d'utilisation.
- Cache obsolète : Le client ou le résolveur conserve une réponse périmée.
- Panne en amont : Le résolveur configuré ne peut pas traiter la requête.
- Port 53 bloqué : Le trafic DNS traditionnel est bloqué ou ne peut pas atteindre le résolveur.
- DoH ou DoT non pris en charge : Le comportement DNS chiffré du client n'est pas pris en charge ni géré par le réseau.
- Blocage par politique : Le résolveur refuse intentionnellement de fournir une réponse.
Une erreur DNS peut également signaler un problème de sécurité WiFi plutôt qu'un problème de résolveur. Pour savoir comment reconnaître un point d'accès frauduleux, consultez le guide de prévention contre les attaques Evil Twin par RDE Technologies.
Comment choisir ensuite votre DNS de protection
Chaque appareil invité qui rejoint votre WiFi doit toujours demander son chemin avant de se connecter. Le véritable choix de l'opérateur est de savoir qui répond à cette question : le résolveur que l'appareil utilise par défaut, le jeu de règles d'un pare-feu vieillissant ou un service DNS protecteur que vous contrôlez. Chaque option modifie le niveau de politique que vous pouvez appliquer et la quantité de preuves que vous conservez à ce dernier point de décision partagé.
| Approche | Appareils non gérés | Point de décision | Preuves pour l'opérateur |
|---|---|---|---|
| Résolveurs sélectionnés par le client | Souvent hors de la politique DNS de l'établissement | Résolveur choisi par l'appareil ou le navigateur | Visibilité limitée sur l'ensemble du réseau |
| Pare-feu vieillissant seul | La couverture dépend des règles du pare-feu et de l'acheminement du trafic | Contrôles de pare-feu disponibles pour ce réseau | Journaux et alertes du pare-feu |
| Résolveur DNS protecteur cloud | Peut couvrir les appareils utilisant le résolveur attribué par le réseau | Recherche de domaine avant le renvoi d'une adresse | Rapports de recherche et de blocage du résolveur |
Pour les réseaux de l'hôtellerie, de l'éducation, de la santé, du secteur public et des sites multiples, Purple Shield constitue une option de protection DNS, comme mentionné précédemment. Il évalue les recherches avant le début des connexions, applique des catégories de contenu telles que le contenu adulte et les jeux d'argent, impose le mode Safe Search sur Google, Bing et YouTube, et bloque les domaines de commande et contrôle, de hameçonnage et de logiciels malveillants. Le fournisseur décrit également des signaux assistés par IA destinés à signaler les menaces émergentes avant les listes de blocage standard, ainsi qu'un blocage des publicités et des traqueurs au niveau de la couche DNS qui, selon lui, réduit le poids des pages et le volume de trafic.
Comparer la politique et l'adéquation opérationnelle
Le service prend en charge des politiques par SSID, VLAN, établissement et calendrier, aux côtés de tableaux de bord, de pages de blocage personnalisées et d'un fonctionnement à blocage automatique en cas de panne (fail-closed). La description du service indique qu'il ne nécessite aucun agent client ni modification de pare-feu, mentionne un SLA de disponibilité publié et indique une conformité avec les normes Friendly WiFi et Internet Watch Foundation. Considérez cela comme des affirmations du fournisseur et évaluez-les au regard de vos propres exigences de suivi et de résilience.
Le filtrage DNS ne répond également qu'à une partie des enjeux de sécurité. Le chiffrement masque la recherche aux observateurs sur le parcours, les contrôles d'authenticité confirment que la réponse provient du bon résolveur, la politique décide d'y répondre ou non, et l'anonymat dépend de l'entité qui exploite ce résolveur. Un passerelle web sécurisée peut couvrir une plus grande partie de cette pile, comparez donc les différences entre ces deux rôles avant de vous engager.
Commencez par un SSID invité. Notez quel résolveur ses appareils utilisent aujourd'hui, puis testez Purple Shield sur ce réseau avant d'étendre la politique à l'ensemble des établissements.