Qu'est-ce que le filtrage DNS et comment fonctionne-t-il ?
Qu'est-ce que le filtrage DNS ? Découvrez comment il bloque les domaines dangereux, améliore la sécurité du WiFi public et protège les appareils non gérés avant le début de la connexion.
Published 20 octobre 2026
Le filtrage DNS vérifie chaque requête de nom de domaine avant qu'un appareil ne se connecte, puis l'autorise, la bloque ou la redirige en fonction du contenu, de la menace ou de la politique du réseau.
Vous lisez actuellement ceci sur un téléphone connecté au WiFi d'un café. À la table voisine, un ordinateur portable charge un tableau de bord professionnel, un enfant regarde des vidéos sur une tablette et la montre connectée de quelqu'un se synchronise en arrière-plan. L'exploitant du café ne gère aucun de ces appareils. Pourtant, chacun d'entre eux doit répondre à la même question avant de se connecter : où se trouve ce domaine ? Chaque requête passe par le résolveur du réseau, et ce point de passage partagé est précisément l'endroit où une barrière peut être installée. Le filtrage DNS place cette barrière sur le trajet de chaque résolution, en vérifiant les destinations avant que les connexions ne s'établissent pour n'importe quel appareil du réseau, sans aucun logiciel à installer ni paramètre à modifier du côté du visiteur.
Table des matières
- Pourquoi le filtrage DNS est essentiel sur les réseaux partagés
- Comment fonctionne le filtrage DNS
- En quoi le filtrage DNS diffère des autres contrôles de sécurité
- Avantages et résultats mesurables sur le réseau
- Cas d'usage pour le WiFi invité et public
- Risques de contournement et faux positifs
- Comment évaluer le filtrage DNS pour votre réseau
Pourquoi le filtrage DNS est essentiel sur les réseaux partagés
Dans un hôtel, les visiteurs apportent leurs propres téléphones, ordinateurs portables, tablettes et parfois des appareils de streaming. Une personne a besoin d'accéder à ses outils de travail, une autre navigue depuis une tablette familiale, et le téléphone d'un client peut être infecté par un logiciel malveillant qui tente de contacter un domaine dangereux. Une équipe réseau ne peut pas supposer qu'elle est en mesure d'installer des logiciels ou de modifier des paramètres sur chaque appareil. C'est tout le défi des réseaux partagés, et c'est aussi là que la sécurité BYOD devient une préoccupation opérationnelle.
Le filtrage DNS place une passerelle au niveau du réseau sur le parcours des recherches de domaines. Plutôt que de n'inspecter qu'un seul navigateur ou un seul ordinateur portable géré, il peut appliquer une politique aux appareils qui utilisent le résolveur DNS du réseau. Le filtre évalue une destination demandée avant que l'appareil ne puisse s'y connecter, ce qui permet à l'opérateur réseau de bloquer de manière centralisée des catégories ou des menaces connues.
Ce modèle peut aider les hôtels, les écoles, les hôpitaux, les aéroports, les bibliothèques, les bureaux et d'autres lieux publics à gérer l'accès partagé. Une école peut définir des règles différentes pour le personnel et les élèves. Un hôtel peut fournir un réseau invités tout en protégeant les systèmes du personnel grâce à une politique distincte. Dans chaque cas, l'opérateur peut appliquer des règles au niveau du réseau sans transformer le filtrage DNS en un outil de gestion des appareils.
Modèle mental : Le filtre vérifie le nom de la destination à la passerelle du réseau. Il ne voit pas automatiquement tout ce qu'un visiteur fait après avoir accédé à un site autorisé.
Cette distinction a son importance. Le filtrage DNS peut contribuer à la protection, à la défense contre les menaces et au reporting sur les appareils non gérés, mais il ne peut pas garantir que chaque page ou chaque application sur un appareil est sûre. C'est une couche de politique réseau, et non un remplacement complet de la sécurité des endpoints ou d'autres contrôles.
Comment fonctionne le filtrage DNS
Votre appareil a besoin d'une adresse pour accéder à un service Internet, mais les utilisateurs saisissent généralement des noms tels que example.com plutôt que des adresses réseau numériques. Le Système de Noms de Domaine, ou DNS, traduit un nom lisible par l'homme en informations nécessaires pour trouver la destination. Cette traduction commence lorsqu'une application ou un navigateur demande à un résolveur de rechercher un nom.
Un résolveur récursif gère la requête pour le compte de l'appareil. Lorsque le filtrage DNS est en place, le résolveur vérifie le nom d'hôte demandé par rapport aux politiques, aux catégories, aux données de réputation ou aux listes de domaines nocifs connus avant de renvoyer une réponse normale. Pour un aperçu utile de la configuration DNS, il est important de distinguer cette décision du résolveur de ce que fait un navigateur après avoir reçu une réponse.
Le parcours de la requête
Pensez au DNS comme à une porte d'embarquement dans un aéroport. Un voyageur indique le nom de sa destination à l'agent d'embarquement, et l'agent vérifie si ce voyage est autorisé avant d'orienter le voyageur. Dans cette analogie, l'appareil est le voyageur, le nom d'hôte est la destination et le résolveur est la porte où s'effectue la décision de politique.
Par exemple, lorsqu'un navigateur demande example.com, l'appareil envoie une requête DNS à son résolveur configuré. Le filtre peut alors :
- Autoriser la requête et renvoyer les informations nécessaires pour continuer.
- Bloquer la requête en refusant de la résoudre.
- Rediriger la requête vers une destination contrôlée, telle qu'une page de blocage.
- Renvoyer une réponse non routable afin que l'appareil ne reçoive pas d'adresse de destination exploitable.
Si le résolveur autorise la recherche, l'appareil peut continuer vers le site. S'il bloque la recherche, le navigateur ne peut généralement pas atteindre la destination demandée via ce nom. La décision intervient avant que le trafic applicatif vers ce nom d'hôte ne commence, c'est pourquoi ce contrôle peut couvrir différents appareils utilisant le résolveur géré.
Ce que le filtre peut et ne peut pas voir
Le filtrage DNS évalue les noms de domaine, et non le contenu complet de chaque page. Il peut bloquer un domaine associé au phishing ou aux logiciels malveillants, mais il n'inspecte pas automatiquement chaque image, message ou action au sein d'un site web autorisé. Une page nocive hébergée sur un domaine légitime peut donc nécessiter d'autres contrôles de sécurité.
Le DNSSEC est également différent du filtrage. Il permet d'authentifier les informations DNS et de vérifier que les données n'ont pas été altérées ; il ne décide pas si un domaine doit être autorisé selon la politique de contenu d'une organisation. Le NIST décrit le filtrage comme un filtrage de résolution de noms et identifie le DNS récursif sécurisé basé sur le cloud, les zones de politique de réponse (RPZ) sur site, ou une combinaison des deux comme des approches de mise en œuvre possibles (Directives du NIST sur la sécurité DNS).
En quoi le filtrage DNS diffère des autres contrôles de sécurité
Le filtrage DNS intervient lors de la phase de résolution du nom d'hôte. Ce calendrier lui donne un rôle utile sur les réseaux partagés, mais ne le rend pas interchangeable avec un logiciel d'endpoint, des pare-feux, Safe Search ou DNSSEC. Chaque contrôle observe une partie différente de l'activité.
| Contrôle | Où il agit | Ce avec quoi il aide | Ce qu'il ne garantit pas |
|---|---|---|---|
| Filtrage DNS | Lors de la recherche de nom d'hôte | Bloquer les destinations nommées avant l'établissement d'une connexion | Inspection de chaque page ou activité d'application |
| Logiciel d'endpoint | Sur un appareil installé ou géré | Surveillance et protection au niveau de l'appareil | Couverture sur les appareils visiteurs non gérés |
| Pare-feu réseau | Sur le trafic réseau et les connexions | Appliquer les règles réseau et contrôler les flux de trafic | La même politique au niveau du nom d'hôte dans chaque configuration |
| Safe Search | Au sein des services de recherche pris en charge | Limiter certains résultats de recherche | Filtrer chaque site web ou application |
| DNSSEC | Pendant la validation des données DNS | Authentifier les réponses DNS | Appliquer les règles de contenu d'une organisation |
Différents contrôles comblent différentes lacunes
Un logiciel d'endpoint peut surveiller un ordinateur géré de manière plus étroite que le filtrage DNS. Mais un hôtel ou un aéroport ne peut pas supposer que les visiteurs installeront un agent sur leur téléphone personnel. Le filtrage DNS peut s'appliquer de façon centralisée aux appareils utilisant le résolveur du réseau, aidant à combler cet écart sans nécessiter de logiciel sur chaque appareil.
Un pare-feu et le filtrage DNS répondent également à des questions différentes. Un pare-feu contrôle le trafic réseau et les connexions, tandis qu'un filtre DNS évalue le nom qu'un appareil demande à résoudre. Ils peuvent se compléter, mais le filtrage DNS ne remplace pas le rôle réseau plus large d'un pare-feu. Pour un aperçu connexe de la manière dont les contrôles du trafic web s'articulent, consultez ce guide sur la passerelle web sécurisée.
Safe Search est encore plus restreint. Il peut influencer les résultats sur les moteurs de recherche pris en charge, mais il ne détermine pas si chaque destination à travers le réseau est autorisée. DNSSEC aide à vérifier l'authenticité des données DNS, mais il ne prend pas la décision administrative de bloquer un domaine.
Règle pratique : Considérez le filtrage DNS comme une couche de politique centrale pour les destinations, puis utilisez des contrôles au niveau des terminaux, des pare-feu et des applications pour les risques que les vérifications de domaines ne peuvent pas détecter.
Bénéfices et résultats réseau mesurables
Sur un réseau partagé, le bénéfice le plus évident réside dans l'emplacement : le filtrage DNS agit comme un filtre qui vérifie le nom demandé avant que la connexion ne commence. Si un téléphone sur un réseau WiFi public demande un domaine lié au hameçonnage, à des logiciels malveillants ou à des activités de commande et contrôle, le résolveur peut refuser la recherche avant même qu'une page ne se charge, tant que cet appareil utilise le résolveur géré. Ce même mécanisme peut appliquer des règles de catégorie pour des destinations telles que les contenus pour adultes ou les jeux d'argent, offrant aux opérateurs un point de contrôle unique et cohérent pour de nombreux appareils non gérés.
Cette position centrale modifie également le contrôle quotidien. Les équipes réseau peuvent attribuer des politiques par groupe ou par réseau, examiner les requêtes bloquées et afficher un message de blocage clair aux visiteurs au lieu d'une erreur silencieuse. Si les domaines publicitaires ou de suivi sont bloqués, certaines pages peuvent effectuer moins de requêtes et transférer moins de ressources, bien que l'effet dépende des sites visités.
Ce que signifient les preuves rapportées
L'évaluation universitaire présentée précédemment décrivait comment les répondants ont évalué un système basé sur RPZ, mais la perception ne constitue pas un taux de blocage mesuré. Considérez cela comme la preuve que les utilisateurs ont remarqué une différence, et non comme la preuve que chaque domaine malveillant a été intercepté.
Une étude distincte sur le sinkhole DNS basé sur le cloud a fait état d'une réduction de 53 % du nombre total de requêtes, de 48 % de ressources transférées en moins et d'un temps de chargement 57 % plus rapide après le blocage des domaines publicitaires (référence de recherche RFC 8198 et sinkhole DNS). Ces chiffres décrivent cette charge de travail spécifique. Un centre de conférences avec des pages riches en vidéos peut observer une tendance différente de celle d'un bureau calme.
Pour un site accueillant du public, vérifiez la passerelle au moyen d'un test rapide. Avant l'ouverture, testez les services reconnus comme fiables depuis le réseau invités, puis demandez volontairement un domaine de test bloqué pour confirmer l'affichage de la page de blocage. Après le déploiement, comparez la latence du résolveur, la disponibilité, les réussites en cache, les requêtes bloquées répétées, les signalements de faux positifs et les signes de contournement tels que l'utilisation de DNS définis en dur ou de VPN.
Cas d'usage pour le WiFi public et invité
Les réseaux d'un hôtel ne servent pas tous les mêmes personnes. Les clients ont besoin d'une connexion internet fonctionnelle, le personnel peut avoir besoin d'un accès différent pour travailler, et une offre payante peut avoir sa propre politique. Un filtre DNS peut appliquer des règles différentes à ces groupes lorsque la conception du réseau les sépare, au lieu de supposer qu'une seule politique convient à tout le monde.
Les établissements d'enseignement et les résidences étudiantes sont confrontés à un défi similaire. Les élèves, le personnel et les résidents peuvent utiliser le même réseau de bâtiment tout en nécessitant des politiques distinctes. Dans le secteur de la santé, les opérateurs peuvent utiliser le filtrage au niveau du réseau comme couche de protection, tout en reconnaissant que les vérifications de domaine ne remplacent pas les contrôles des systèmes cliniques et n'inspectent pas chaque partie d'un service en ligne.
| Environnement | Besoin en matière de politique | Rôle du filtrage DNS |
|---|---|---|
| Hôtel | Distinguer les réseaux visiteurs, personnel et payants | Appliquer différentes règles de catégories et de menaces selon le réseau |
| École ou résidence | Définir des règles appropriées pour les élèves, le personnel et les résidents | Soutenir la protection et la visibilité des politiques sur les appareils personnels |
| Hôpital | Ajouter une couche de protection pour le WiFi visiteurs et public | Bloquer les destinations sélectionnées tout en maintenant les contrôles de sécurité clinique |
| Aéroport ou bibliothèque | Gérer l'accès public sur des appareils partagés | Appliquer des politiques de réseau cohérentes et examiner les rapports |
| Organisation multi-sites | Garder des politiques faciles à gérer sur l'ensemble des sites | Centraliser les règles et comparer l'activité entre les groupes de réseaux |
Adapter les politiques au lieu d'accueil
Les opérateurs peuvent définir des règles relatives à l'identité du réseau, comme un SSID ou un VLAN, et les ajuster par établissement ou par calendrier. Ils peuvent choisir des contrôles de catégories, le blocage des menaces, l'application de Safe Search, des listes d'autorisation ou de blocage, des rapports et une page de blocage personnalisée. Ces fonctionnalités aident le personnel à expliquer une restriction et à vérifier si la règle fonctionne, mais elles ne révèlent pas la totalité des intentions d'un utilisateur ni chaque action au sein d'un service autorisé.
Purple Shield est un exemple de service DNS protecteur conçu pour le WiFi public et invités. Il offre des contrôles par catégorie, Safe Search, une protection contre les menaces, le blocage des publicités et des traceurs au niveau DNS, des rapports, ainsi que des politiques pouvant être définies par SSID, VLAN, site ou calendrier. Son modèle de déploiement dans le cloud est conçu pour fonctionner sans installer d'agents clients, bien que l'opérateur doive toujours maintenir une stratégie de sécurité plus large pour les contournements et les menaces que le filtrage DNS ne peut pas inspecter.
Risques de contournement et faux positifs
Sur un réseau partagé, le modèle de passerelle présente un point faible : il ne peut vérifier que les requêtes de destination qui atteignent le résolveur. Le portable d'un hôtel, le téléphone d'un étudiant et la tablette d'un visiteur se connectent de manière non gérée ; l'un peut donc utiliser le DNS du site tandis qu'un autre envoie des requêtes à un résolveur public ou qu'une application suit son propre chemin. La règle existe toujours, mais le trafic n'atteint jamais le point de contrôle.
Un VPN ou un proxy peut détourner l'ensemble de la session du résolveur local. Le DNS chiffré est plus restreint : DoH et DoT protègent la recherche elle-même, tandis que HTTPS protège le trafic web entre le navigateur et le site. Cette différence est importante car une navigation HTTPS normale ne prouve pas que la requête DNS a utilisé le DNS chiffré. NLnet Labs avertit que le DoH peut contourner la politique de sécurité DNS locale et être difficile à détecter dans des environnements mixtes (présentation de NLnet Labs sur le DoH).
La couverture et la précision nécessitent un examen régulier
Ces données doivent être interprétées comme un avertissement concernant la couverture, et non comme une évaluation universelle. Une étude de 2026 sur les réseaux éducatifs a fait état d'une précision de 98,53 % dans des conditions de test normales, tombant à 50 % lorsque des contournements via VPN ou DoH étaient introduits, avec une précision, un rappel et un F1-score rapportés à 0 % dans ce cas de contournement, et des échantillons distincts montrant des taux de blocage de 85 % et 96 % ainsi que des taux de faux positifs de 12 % et 8 % (étude sur le filtrage DNS des réseaux éducatifs).
Ces chiffres mettent en évidence deux défaillances perçues différemment par les utilisateurs. Un manquement laisse passer une destination interdite. Un faux positif bloque un domaine inoffensif, générant des tickets de support, des contournements et une pression pour assouplir la politique.
Un blocage n'est utile que si la politique est digne de confiance. Fournissez aux utilisateurs une explication claire, proposez une procédure pour demander un réexamen et conservez un historique des exceptions et des décisions politiques.
Des catégories claires, des pages de blocage simples, des exceptions temporaires, des registres d'audit et une voie de révision aident les équipes à corriger les erreurs sans tout bloquer. Augmenter le blocage n'est pas automatiquement préférable si cela interrompt les études, les soins, les actualités ou le travail de l'entreprise ; évaluez conjointement les éléments bloqués et les réclamations.
Comment évaluer le filtrage DNS pour votre réseau
Commencez par lister les réseaux et les groupes qui nécessitent des règles différentes. Un hôtel, une école ou un lieu public peut avoir besoin de politiques distinctes pour les invités, le personnel, les élèves, les résidents ou les accès payants. Décidez si un service doit fonctionner avec un pare-feu existant et sans équipements matériels ni agents d'endpoint.
Demandez-vous ensuite comment la politique sera appliquée. Quels contrôles sont nécessaires pour les catégories, Safe Search, les menaces, la publicité, les plannings, les rapports et les pages de blocage personnalisées ? Comment le réseau gérera-t-il les résolveurs externes, les VPN et le DNS chiffré ? Demandez comment le service se comporte si un résolveur ou un centre de données n'est pas disponible, et si le comportement de défaillance choisi correspond aux besoins de sécurité et de disponibilité de l'établissement.
Examinez les preuves qu'un fournisseur peut fournir, notamment les requêtes bloquées, l'examen des faux positifs, la disponibilité du résolveur et la couverture des politiques. Si le renseignement sur les menaces fait partie de la proposition, comprenez comment ses listes sont alimentées et maintenues grâce à des conseils sur les flux de renseignement sur les menaces DNS. Le bon choix doit répondre aux exigences opérationnelles, et non reposer sur des affirmations générales selon lesquelles un seul contrôle peut résoudre tous les problèmes de sécurité en ligne.
Purple Shield fournit un DNS protecteur et un filtrage de contenu pour le WiFi invité et public, avec des politiques spécifiques au réseau, le blocage des menaces, des rapports et sans aucun agent client. Visitez Purple Shield pour découvrir comment ses contrôles au niveau DNS peuvent s'intégrer à votre sécurité réseau existante.