Le filtrage DNS est passé d’un outil de politique web à cocher à l’une des couches de cyberdéfense les moins chères et les plus rapides qu’une équipe informatique de taille moyenne puisse déployer. Il bloque les domaines malveillants avant toute connexion, ce qui signifie que les pages de phishing ne se chargent pas, que les ransomwares ne peuvent pas atteindre leur serveur de commande et que les employés utilisant le Wi-Fi d’un hôtel bénéficient de la même protection que ceux du siège. Ce guide explique comment le filtrage DNS dans le nuage fonctionne réellement en 2026, ce qu’il arrête, où il échoue et comment évaluer un fournisseur lorsque vous avez 200 utilisateurs, pas de SOC et une liste de contrôles NIS2 à satisfaire.
Qu’est-ce que le filtrage DNS et comment fonctionne-t-il en 2026 ?
Le filtrage DNS inspecte chaque recherche de nom de domaine effectuée par un appareil et décide, sur la base d’une politique et de renseignements sur les menaces, s’il faut la résoudre. Cinq choses à savoir avant de commencer à évaluer :
- Il agit au niveau de la couche DNS, avant la connexion. Un domaine bloqué ne renvoie jamais d’adresse IP, de sorte que la page malveillante ne se charge jamais et que le canal C2 du ransomware ne s’ouvre jamais.
- Le filtrage DNS en nuage remplace les appareils DNS sur site par un réseau mondial de résolveurs Anycast. Les mises à jour s’appliquent à chaque appareil dès qu’une nouvelle menace est identifiée.
- Le filtrage moderne analyse la requête elle-même. Les algorithmes repèrent les domaines nouvellement enregistrés, les noms générés par l’intelligence artificielle et les modèles typiques des tunnels DNS.
- Les plateformes sensibles à l’identité associent la politique à l’utilisateur et à l’appareil, et non à l’adresse IP. Les règles DNS ne sont pas les mêmes pour un financier que pour un entrepreneur utilisant un ordinateur portable non géré.
- Il s’agit d’un élément d’une architecture de sécurité plus large. Les plateformes SASE gérées dans le nuage, comme Jimber, incluent le filtrage DNS comme une couche standard, et non comme une licence distincte.
Comment fonctionne le filtrage DNS en nuage ?
Chaque fois qu’un appareil tente d’accéder à un site web, d’envoyer un courrier électronique, de synchroniser un outil SaaS ou de se connecter à un serveur de mise à jour logicielle, il envoie d’abord une requête DNS. Cette requête demande à un résolveur de traduire un nom lisible par l’homme en une adresse IP. Le filtrage DNS fourni par l’informatique en nuage se situe sur ce chemin.
Le parcours de la requête, étape par étape
Lorsqu’un utilisateur tape une URL dans un navigateur ou qu’une application ouvre une connexion, l’appareil envoie la requête DNS au résolveur configuré. Dans un modèle en nuage, ce résolveur se trouve dans un réseau mondial Anycast, qui achemine la requête vers le point de présence le plus proche. À partir de là :
- Le résolveur identifie la source. Pour les bureaux, cette identification se fait par l’intermédiaire d’une identification basée sur l’IP ou d’un tunnel IPsec ou GRE. Pour les utilisateurs mobiles et distants, un client itinérant léger identifie l’appareil et l’utilisateur.
- Le résolveur vérifie la requête par rapport à la politique. La politique combine des listes statiques de blocage et d’autorisation, des flux de renseignements sur les menaces en temps réel, des règles de catégorie (jeu, adulte, social) et le contexte de l’identité s’il est intégré à l’IdP.
- L’analyse au niveau des requêtes s’effectue en parallèle. Le résolveur examine le domaine lui-même : son enregistrement récent, le modèle lexical du nom, l’entropie du sous-domaine et si le type ou le volume de la requête semble anormal.
- C’est le résolveur qui décide. S’il est propre, il renvoie l’adresse IP. Si elle est malveillante, il applique le sinkholing, renvoyant une IP contrôlée qui pointe vers une page de blocage ou un gestionnaire de quarantaine. L’équipe informatique reçoit une alerte liée à l’utilisateur, à l’appareil et au domaine.
L’ensemble de ce processus ajoute 5 à 50 millisecondes pour les utilisateurs proches d’un point de présence, ce qui est imperceptible. Sans point de présence à proximité, la latence peut dépasser 100 ms et les utilisateurs commencent à s’en apercevoir.
Le renseignement sur les menaces et le rôle de l’IA
La qualité d’un moteur de politiques dépend de celle de ses données. Les résolveurs DNS modernes traitent des milliards de requêtes par jour dans leur base de clients. Cette échelle est la source de leurs renseignements sur les menaces. Lorsqu’un nouveau domaine de phishing est détecté chez un client à Bruxelles, le blocage s’applique à tous les clients dans le monde entier en quelques minutes.
C’est là que le filtrage DNS en nuage prend une avance décisive sur le filtrage sur site. Une étude menée par l’industrie en 2025 a révélé que la durée de vie moyenne d’un domaine d’hameçonnage est inférieure à quatre heures. Le temps qu’une liste de blocage statique soit mise à jour et transmise à un dispositif existant, la campagne est déjà passée à autre chose. Les flux de menaces en temps réel, associés à l’analyse comportementale, sont le seul mécanisme qui permette de suivre le rythme.
En 2026, l’IA de la couche DNS s’intéresse à plusieurs choses à la fois. Les domaines nouvellement observés, enregistrés au cours des dernières 24 à 72 heures, font l’objet d’un examen plus approfondi. Les modèles de l’algorithme de génération de domaines, qui produisent des milliers de noms absurdes par jour pour les ransomwares, sont repérés uniquement sur la base de caractéristiques lexicales. Le DNS à flux rapide, où l’IP derrière un nom malveillant change toutes les quelques minutes pour échapper à la saisie, est repéré par le taux de changement.
Les plateformes SASE modernes, dont Jimber, effectuent cette analyse au même point de contact que celui qui gère le SWG, le ZTNA et la politique de pare-feu. Cela signifie que le verdict DNS est instantanément partagé avec le reste de la pile de sécurité.
Quels types d’attaques le filtrage DNS bloque-t-il et où s’arrête-t-il ?
Le filtrage DNS est l’un des investissements de sécurité les plus importants par euro pour les entreprises de taille moyenne. La raison en est le volume considérable d’attaques qui dépendent d’une recherche DNS réussie.
Ce qu’il arrête
Phishing et vol de données d’identification. Le phishing reste le principal point d’entrée pour la plupart des brèches. Le rapport de l’ENISA sur le paysage des menaces en 2025 a identifié le phishing comme le principal vecteur d’accès initial, et les leurres générés par l’IA ont augmenté les taux de réussite de manière significative. Chaque campagne de phishing a besoin d’un domaine. Bloquez le domaine au niveau du DNS et la campagne échoue avant que l’utilisateur ne tombe dans le panneau.
Communication de commandement et de contrôle. Les logiciels malveillants qui atterrissent sur un terminal, que ce soit par le biais d’une pièce jointe d’hameçonnage ou d’un téléchargement à la volée, doivent atteindre leur opérateur. Cette communication passe presque toujours par le DNS. Si vous bloquez le domaine C2, le logiciel malveillant reste silencieux, incapable de recevoir des instructions ou d’exfiltrer des données.
Algorithme de génération de domaines malveillants. Les familles de rançongiciels comme Conti et ses descendants génèrent des milliers de domaines jetables par jour. Les listes statiques ne parviennent jamais à les rattraper. Le filtrage DNS avec détection DGA basée sur l’IA identifie le modèle lexical et bloque la famille entière.
Tunnels DNS pour l’exfiltration de données. Certains attaquants encodent les données volées dans les requêtes DNS elles-mêmes. Une requête adressée à c2hlbGxvd29ybGQ.attacker.com ressemble à du bruit mais contient des données utiles. Les filtres DNS en nuage détectent le volume et les types d’enregistrement anormaux et ferment le canal.
Les domaines nouvellement enregistrés en général. La plupart des infrastructures malveillantes ont moins d’une semaine. Le blocage ou l’avertissement par défaut sur les domaines nouvellement observés permet d’attraper une grande partie des campagnes qui n’ont pas encore été classées.
Les lacunes du filtrage DNS
Soyez honnête avec vos parties prenantes en ce qui concerne les limites.
- Adresses IP codées en dur. Les logiciels malveillants qui contournent entièrement le DNS et se connectent directement à une adresse IP ne seront pas détectés au niveau de la couche DNS. C’est rare, mais cela arrive.
- DNS crypté pour les résolveurs malhonnêtes. Un utilisateur ou un logiciel malveillant peut configurer DoH directement sur un résolveur public et contourner la politique de l’entreprise. Les contrôles des points finaux et les règles de pare-feu doivent imposer que tout le trafic DNS passe par le résolveur autorisé.
- Attaques au niveau de l’application. Injection SQL, scripts intersites, compromissions de la chaîne d’approvisionnement dans des logiciels légitimes. Aucun de ces problèmes n’est lié au DNS. Ils nécessitent un WAF, des contrôles des points d’extrémité et une gestion de la chaîne d’approvisionnement des logiciels.
- Utilisation abusive des domaines autorisés par les initiés. Un utilisateur qui télécharge des données sensibles vers un service en nuage sanctionné est invisible pour un filtre DNS. Le CASB et le DLP s’occupent de cette couche.
Le filtrage DNS est une couche fondamentale, pas une stratégie de sécurité complète. Considérez-le comme le premier point de contrôle d’une architecture de défense en profondeur.
Filtrage DNS en nuage par rapport au filtrage DNS sur site
Pour la plupart des responsables informatiques du marché intermédiaire en 2026, la comparaison est simple. Le travail hybride, la prolifération des SaaS et la rapidité des attaques modernes ont rendu le filtrage DNS sur site inopérant pour les organisations de 50 à 400 utilisateurs. Le tableau ci-dessous montre où se situe réellement l’écart.
| Dimension | Anciennement sur site | Fourni dans le nuage |
|---|---|---|
| Évolutivité | Liée au matériel, nécessite un redimensionnement ou un empilement | Elastique, s’adapte instantanément aux utilisateurs |
| Temps de réponse aux menaces | De quelques heures à quelques jours, en fonction de la poussée des signatures | Minutes, informations globales sur les menaces appliquées à tous les locataires |
| Couverture mobile et distante | Nécessite une liaison VPN pour les utilisateurs hors réseau | Native via le client itinérant ou le DoH |
| Intégration de l’identité | Limité au contexte IP et sous-réseau | Intégration directe de l’IdP, politique par utilisateur et par groupe |
| Frais généraux de gestion | Patching, rafraîchissement du matériel, service d’astreinte | Exploitation par le fournisseur, le service informatique définit uniquement la politique. |
| Structure des coûts | Lourdeur des dépenses d’investissement avec des cycles de rafraîchissement périodiques | OpEx prévisible par utilisateur |
Une entreprise de 200 utilisateurs utilisant un résolveur sur site consacre généralement un à deux jours par trimestre à l’application de correctifs, à la rotation des journaux et à la planification de la capacité. Une solution en nuage réduit ces tâches à l’examen des politiques et à la réponse aux incidents. Pour une petite équipe informatique, c’est la différence entre la lutte contre les incendies et le travail stratégique.
L’argument de la performance est également moins évident que ne le prétendaient les vendeurs. Les résolveurs sur site répondent en moins d’une milliseconde sur le réseau local. Les résolveurs en nuage ajoutent 5 à 50 ms en fonction de la proximité du PoP. Pour les entreprises européennes de taille moyenne, l’important est de savoir si votre fournisseur a des points de contact à Amsterdam, Bruxelles, Francfort ou Londres. Si c’est le cas, la latence est invisible. Dans le cas contraire, les utilisateurs du Benelux constateront un ralentissement du chargement des pages.
Comment évaluer une solution de filtrage DNS en 2026 ?
Le paysage des fournisseurs est très encombré. Cisco Umbrella, DNSFilter, Cloudflare Gateway et une longue série d’outils autonomes promettent tous le même résultat. Les différences résident dans la manière dont le moteur de politique est construit, dans les données qui sont traitées et dans l’endroit où elles sont stockées. Utilisez les critères ci-dessous pour filtrer le bruit.
1. Détection par l’IA de domaines nouveaux et générés par l’IA
Demandez au fournisseur comment il détecte les schémas de l’algorithme de génération de domaines et les domaines nouvellement observés. La réponse doit faire référence à l’analyse comportementale, et pas seulement à des listes de blocage plus longues. Si le seul mécanisme de détection est basé sur des signatures, le produit sera en retard sur les campagnes qu’il est censé arrêter. Demandez des données sur le délai de blocage des nouveaux domaines de menace.
2. Intégration de l’identité et de la posture de l’appareil
Un filtre DNS moderne devrait extraire l’identité de votre IdP (Microsoft Entra ID, Okta, Google Workspace) et appliquer une politique par utilisateur et par groupe. Mieux encore, il devrait intégrer le contexte de la posture de l’appareil, de sorte que le même utilisateur bénéficie d’une politique différente sur un ordinateur portable géré et sur un téléphone personnel. Si le fournisseur parle encore principalement en termes de politique basée sur l’IP, il est en retard sur la courbe.
3. Résidence des données en Europe et clarté juridictionnelle
Pour NIS2 et GDPR, l’endroit où se trouvent les logs DNS et qui peut y accéder n’est pas optionnel. Les fournisseurs ayant leur siège aux États-Unis sont soumis à la loi CLOUD, quel que soit l’endroit où se trouvent leurs points de contact. Un PoP à Francfort géré par un fournisseur américain n’équivaut pas à la souveraineté européenne en matière de données. Évaluez où les requêtes sont inspectées, où les journaux sont stockés et quel cadre juridique régit les demandes d’accès. Jimber, dont le siège est en Belgique, traite le trafic et stocke les journaux à l’intérieur des frontières de l’UE par défaut.
4. Journalisation et rapports d’audit alignés sur NIS2
Les auditeurs veulent voir les journaux de requêtes DNS qui peuvent être corrélés avec l’identité de l’utilisateur, l’appareil et le résultat. Vérifiez que le fournisseur propose une rétention configurable des journaux, un flux SIEM et des rapports prêts pour l’audit. Demandez-lui si son schéma de journalisation prend en charge les exigences en matière de preuves décrites dans les CyberFundamentals (CyFun) au niveau que votre organisation doit atteindre.
5. Feuille de route de SASE et adaptation de la plate-forme
Le filtrage DNS en tant que produit autonome est de plus en plus difficile à justifier. Le marché se consolide autour de plateformes qui combinent DNS, SWG, CASB, ZTNA et FWaaS dans un seul pipeline d’inspection. Si vous achetez un outil DNS autonome aujourd’hui, en aurez-vous encore besoin dans deux ans, lorsque votre pile de sécurité élargie passera au SASE ? Ou vaut-il mieux choisir une plateforme qui inclut le DNS comme un composant dès le départ ?
6. Support DNS crypté
DNS over HTTPS (DoH) et DNS over TLS (DoT) sont la norme de confidentialité en 2026. Un fournisseur qui s’appuie encore principalement sur UDP/53 en texte clair signale que son architecture n’a pas évolué. Tout aussi important : vérifiez que la plateforme peut intercepter et inspecter le trafic DoH afin que votre politique ne soit pas contournée par des navigateurs ou des applications utilisant leurs propres résolveurs.
7. Gestion multi-locataires pour les partenaires de services
Si votre organisation travaille avec un MSP, ou si vous êtes vous-même un MSP, la capacité multi-tenant est importante. Une seule fenêtre pour gérer les politiques entre les clients, avec des modèles partagés et une isolation par locataire, c’est ce qui rend le filtrage DNS opérationnellement viable à grande échelle.
Filtrage DNS en tant que composant SASE ou en tant que composant autonome
En toute honnêteté, les deux voies peuvent fonctionner, mais elles conviennent à des stades différents de maturité organisationnelle.
Un filtre DNS autonome se justifie lorsque vous avez besoin d’une couche de protection rapide et peu coûteuse et que le reste de votre pile de sécurité n’est pas encore prêt à être consolidé. Le déploiement peut se faire en une journée. Le rendement en menaces bloquées par euro dépensé est difficile à battre. Pour une entreprise de 50 utilisateurs qui utilise encore un pare-feu de base et un système AV pour les points finaux, l’ajout d’un filtrage DNS autonome est une solution rapide et judicieuse.
Le filtrage DNS dans le cadre d’une plateforme SASE a du sens lorsque vous évaluez déjà comment consolider les pare-feux, les VPN, le filtrage web et le contrôle d’accès. L’achat d’un outil autonome signifie maintenant un autre fournisseur, un autre contrat, une autre console. Si vous savez que vous allez passer à une architecture convergente dans les 18 mois, la meilleure solution est de choisir une plateforme SASE où le filtrage DNS est inclus en tant que couche.
C’est là que l’approche de Jimber illustre le modèle convergent. Le filtrage DNS n’est pas un ajout. Il s’exécute dans le même pipeline d’inspection à passage unique que ZTNA, SWG, FWaaS et SD-WAN, et les politiques partagent le contexte d’identité entre tous les moteurs. Pour une petite équipe informatique, la simplicité opérationnelle d’une console, d’un cadre de politique et d’un pipeline de journalisation est plus importante que n’importe quelle caractéristique sur une feuille de comparaison. La plateforme d’isolation réseau de Jimber lie par défaut la couche DNS aux politiques par utilisateur et par appareil. Pour les appareils sans agent tels que les imprimantes, les caméras IP et les équipements industriels, le matériel NIAC étend les contrôles DNS aux terminaux qui ne peuvent pas exécuter d’agents logiciels.
Pour une vue architecturale plus approfondie de la raison pour laquelle le DNS se trouve là où il se trouve dans une pile Zero Trust, notre article précédent sur la sécurité du DNS dans Zero Trust couvre le raisonnement de conception. Ce guide se concentre sur la question de l’évaluation de l’acheteur. Les deux documents sont complémentaires.
Implications de NIS2 et CyFun pour la protection au niveau du DNS
Le NIS2 est entré en vigueur en Belgique en octobre 2024. Les entités essentielles doivent atteindre la vérification des cyberfondamentaux de base ou importants d’ici le 18 avril 2026. Les entités importantes peuvent faire de même sur une base volontaire. Le filtrage DNS n’est pas explicitement mentionné à l’article 21, mais il fait partie intégrante de plusieurs mesures techniques et organisationnelles que les auditeurs attendent.
Sécurité des réseaux et détection des menaces. L’article 21 exige des mesures appropriées pour gérer les cyber-risques. Une politique documentée de filtrage du DNS avec journalisation, contexte d’identité et renseignements sur les menaces est l’une des démonstrations les plus claires de la détection des menaces au niveau du réseau à la table d’audit.
les délais de traitement et de signalement des incidents. Le NIS2 impose une notification initiale de l’incident dans les 24 heures et une évaluation détaillée dans les 72 heures. Les journaux de requêtes DNS, en corrélation avec l’utilisateur et l’appareil, constituent souvent la piste de preuves la plus rapide pour reconstituer comment une campagne de phishing a atteint l’organisation ou comment un logiciel malveillant a tenté de communiquer avec l’extérieur.
Sécurité de la chaîne d’approvisionnement. L’article 21 exige explicitement que les organisations gèrent la sécurité de leurs fournisseurs. Le filtrage DNS peut appliquer une politique sur les communications sortantes vers des domaines tiers et signaler les interactions avec des fournisseurs nouveaux ou non vérifiés.
Alignement du cadre CyFun. Le cadre CyFun du CCB est la traduction pratique de NIS2 dans la réalité organisationnelle belge. L’édition 2025 du CyFun s’aligne sur le NIST CSF 2.0 et ajoute la gouvernance comme sixième fonction. La protection au niveau du DNS touche les fonctions Identifier (visibilité du trafic sortant), Protéger (blocage des domaines malveillants) et Détecter (journalisation et alerte). Aux niveaux Important et Essentiel, les auditeurs s’attendent à voir ces contrôles fonctionner avec un contexte d’identité et des preuves prêtes à être auditées.
Pour les entités de services financiers soumises à la loi DORA, les exigences vont plus loin. L’intégrité de l’infrastructure DNS, la redondance et la validation DNSSEC sont désormais des attentes de base pour les entités critiques dans le cadre du pilier de résilience opérationnelle de la DORA.
Questions fréquemment posées
Qu’est-ce que le filtrage DNS et à quoi sert-il ?
Le filtrage DNS inspecte les recherches de noms de domaine avant qu’elles ne soient résolues et bloque celles qui sont associées à des destinations malveillantes ou indésirables. Il bloque le phishing, le trafic de commande et de contrôle des ransomwares et l’accès à des contenus inappropriés au niveau du réseau, avant toute connexion à la destination. En 2026, le filtrage DNS moderne comprend également une analyse comportementale pour détecter les domaines générés par l’IA et les tunnels DNS.
Comment fonctionne le filtrage DNS ?
Un appareil envoie une requête DNS à un résolveur. Dans un filtre DNS fourni par le cloud, ce résolveur vérifie le domaine demandé par rapport à la politique, aux flux de renseignements sur les menaces et aux règles comportementales. Si le domaine est malveillant ou contraire à la politique, le résolveur renvoie une adresse « sinkhole » au lieu de l’adresse IP réelle, ce qui empêche la connexion. L’équipe informatique reçoit un journal des événements indiquant l’utilisateur et l’appareil qui ont déclenché le blocage.
Le filtrage DNS vaut-il la peine pour une entreprise de taille moyenne ?
Oui. Le filtrage DNS offre l’un des meilleurs rendements par euro de tous les contrôles de sécurité. Il bloque une grande partie du phishing et des ransomwares sans agents de point d’extrémité, sans liaison VPN et sans personnel spécialisé. Pour une organisation de 50 à 400 utilisateurs disposant d’une petite équipe informatique, il s’agit de l’une des couches les moins contraignantes à déployer, mais dont l’impact est le plus élevé.
Qu’est-ce qu’un filtre DNS bloque qu’un pare-feu ne bloque pas ?
Un pare-feu traditionnel inspecte le trafic par adresse IP, port et protocole. Il laisse généralement passer le trafic DNS sur le port 53 avec peu d’inspection. Un filtre DNS inspecte le contenu de la requête elle-même, y compris le nom de domaine, le type d’enregistrement demandé et le modèle de recherche. Cela lui permet de détecter les domaines nouvellement enregistrés, les domaines générés par l’intelligence artificielle et les tunnels DNS, qui sont tous invisibles pour la plupart des pare-feu.
Le filtrage DNS ralentira-t-il les performances de l’internet ?
Dans un modèle en nuage avec un point de présence proche, la latence supplémentaire est généralement de 5 à 50 millisecondes, ce qui est invisible pour les utilisateurs. Si le fournisseur n’a pas de point de présence dans votre région, la latence peut dépasser 100 ms et devenir perceptible. Pour les organisations européennes, vérifiez que le fournisseur dispose de points de présence à Amsterdam, Bruxelles, Francfort ou Londres avant de signer.
Le filtrage DNS peut-il remplacer ma passerelle web ou mon pare-feu ?
Non. Le filtrage DNS bloque les domaines au niveau de la couche de résolution. Une passerelle Web sécurisée inspecte le trafic HTTP et HTTPS, y compris le contenu décrypté par TLS, les téléchargements de fichiers et les règles de navigation basées sur les catégories. Un pare-feu applique la politique en matière de ports et de protocoles. Ces trois couches fonctionnent ensemble. Une plateforme SASE unifiée les combine en un seul pipeline.
Le filtrage DNS en soi est une victoire rapide. Le filtrage DNS dans le cadre d’une plateforme SASE convergente est le fondement d’une architecture défendable. Si votre équipe évalue l’une ou l’autre voie, la prochaine étape la plus utile est de comparer votre couverture DNS actuelle avec les attentes de NIS2 et CyFun et de voir où se situent les lacunes. Réservez une démonstration avec Jimber pour voir comment le filtrage DNS, l’accès basé sur l’identité et l’isolation en ligne fonctionnent ensemble dans une seule console, avec la résidence des données européennes par défaut.
