Le DNS protecteur expliqué : fonctionnement et enjeux
Published
Un invité dans le hall d'un hôtel appuie sur un lien et la page commence à se charger. Avant que le navigateur ne puisse se connecter au site Web, l'appareil de l'invité doit trouver où ce site se situe sur Internet. Cette recherche discrète est l'occasion de vérifier si la destination doit être autorisée.
Le DNS protecteur ajoute une décision de sécurité à cette étape de routine. Il aide les organisations à protéger les utilisateurs et les appareils sur les réseaux partagés, mais il ne fonctionne que lorsque leur trafic utilise le résolveur géré. Bien comprendre cette distinction permet de mieux anticiper les performances, les exceptions, les voies de contournement et la confidentialité.
Table des matières
- Pourquoi chaque visite de site Web commence par une recherche DNS
- Ce que fait le DNS protecteur lors de l'étape de résolution de nom
- Comment fonctionne l'application des politiques sur l'ensemble d'un réseau
- Impact sur les performances et gains mesurables en temps de chargement des pages
- Cas d'usage réels dans les établissements et les entreprises
- Choisir la bonne approche pour votre réseau
- Mesurer la valeur du DNS protecteur au-delà du nombre de blocages
- Prochaines étapes pour planifier le déploiement de votre DNS protecteur
Pourquoi chaque visite de site web commence par une recherche DNS
Le nom d'un site web est facile à retenir pour les humains. Les ordinateurs ont besoin d'une adresse réseau pour se connecter. Le Domain Name System (DNS) assure la traduction, à la manière d'un annuaire téléphonique qui transforme le nom d'une personne en un numéro à composer.
L'invité appuie sur le lien et le navigateur demande à un résolveur DNS l'adresse associée au nom du site Web. Le résolveur recherche la réponse et la renvoie. Le navigateur peut ensuite tenter de se connecter à la destination. Le DNS ne transporte pas la page elle-même, mais il aide l'appareil à trouver où la demander.
Cette séquence crée un point de contrôle de sécurité efficace. Si le résolveur identifie un domaine demandé comme une menace connue, il peut refuser de fournir une réponse exploitable avant que le navigateur ne se connecte. Un service de DNS protecteur applique des politiques de sécurité dès cette étape de recherche, plutôt que d'attendre le téléchargement d'un fichier ou une action suspecte sur le terminal.
La distinction pratique : Le DNS aide un appareil à trouver une destination. Le DNS protecteur ajoute une décision concernant le succès ou non de la recherche.
Cela est particulièrement important dans les espaces où de nombreux utilisateurs et appareils partagent la même infrastructure réseau. Dans un hôtel, les téléphones des clients, les ordinateurs du personnel, les terminaux de paiement et les équipements connectés du bâtiment peuvent utiliser différentes parties d'un même réseau global. Un bureau, un immeuble résidentiel ou un lieu public est confronté à un défi similaire, même si les utilisateurs et les appareils varient.
Le DNS de protection peut fournir un point de contrôle commun pour ces recherches, mais il ne constitue pas un programme de sécurité complet. Il ne protégera pas un appareil qui évite le résolveur géré et ne remplace pas la protection des points d'accès, les contrôles d'accès ou une conception réseau rigoureuse. Les questions utiles sont de savoir comment le résolveur prend sa décision, comment une organisation maintient les appareils sur la voie prévue et quelles preuves démontrent que le service apporte de l'aide sans causer de perturbations.
Ce que fait le DNS protecteur au stade de la résolution de noms
Le DNS protecteur est un résolveur récursif appliquant des politiques. Un résolveur récursif gère les requêtes pour le compte d'un appareil, tandis que le DNS protecteur applique des règles pour décider si une destination demandée doit recevoir une réponse DNS normale. Il ne s'agit pas simplement d'un DNS accéléré ou chiffré.
Suivez une recherche du début à la fin :
- L'appareil demande un nom de domaine. Un navigateur, une application ou un autre processus a besoin d'une adresse avant de pouvoir tenter de se connecter à une destination nommée.
- Le résolveur vérifie la requête. Il compare le domaine aux politiques configurées et aux renseignements sur les menaces. Des implémentations plus solides peuvent également vérifier une adresse IP résolue, ce qui aide à évaluer l'infrastructure derrière un nom.
- Le résolveur renvoie un résultat. Si la politique autorise la requête, le résolveur fournit une réponse. Si ce n'est pas le cas, le service peut bloquer la résolution, renvoyer une réponse vide ou rediriger le client vers une page d'avertissement. Le comportement exact dépend du produit et de la politique.
Certaines implémentations recherchent des domaines générés par algorithme, ou DGA, que les logiciels malveillants peuvent utiliser pour trouver une infrastructure de commande et de contrôle. Des motifs inhabituels dans les caractères d'un domaine, notamment une entropie élevée, peuvent servir de signal pour une évaluation ultérieure des politiques. Ce type d'analyse peut compléter les flux de renseignements sur les menaces, mais les organisations doivent toujours valider la manière dont le service choisi gère la détection et les exceptions.
Le chiffrement et l'authenticité ne remplacent pas une décision de sécurité
DNSSEC permet de vérifier l'intégrité et l'authenticité des données DNS signées. DNS over HTTPS (DoH) et DNS over TLS (DoT) protègent les requêtes DNS en transit. Ces caractéristiques sont essentielles, mais elles ne permettent pas à elles seules de déterminer si un domaine existant est malveillant. Le DNS protecteur prend cette décision d'application de la politique directement au niveau du résolveur.
Pour les équipes qui examinent les contrôles d'accès au web et aux services cloud, cette distinction peut s'ajouter à des recommandations plus larges sur la sécurisation des environnements d'entreprise Microsoft 365. L'essentiel est d'éviter de traiter le transport chiffré ou les données authentifiées comme un substitut à une décision sur le risque lié à la destination.
Comment fonctionne l'application des politiques sur un réseau
Un résolveur peut prendre une décision judicieuse pour une requête unique et pourtant ne pas réussir à protéger un réseau si les appareils peuvent contourner son acheminement DNS. Le déploiement à l'échelle du parc repose donc sur deux éléments liés : une politique cohérente et un chemin fiable vers le résolveur.
Une architecture centralisée achemine les requêtes DNS de plusieurs sites vers un service géré. Cela facilite l'application de règles partagées et le suivi de l'activité sur l'ensemble des sites. Cela fait également de la disponibilité une exigence de sécurité. Si le résolveur est inaccessible, l'accès web habituel et les services qui dépendent du DNS peuvent échouer, même lorsque le reste du réseau fonctionne correctement.
Le service Protective DNS du gouvernement américain est devenu accessible aux agences de la branche exécutive civile fédérale en septembre 2022. En août 2024, plus de 104 agences avaient été intégrées, générant une moyenne de 1,6 milliard de requêtes DNS sécurisées par jour ; le programme a enregistré un taux de disponibilité du résolveur de 99,999 % (fiche d'information sur le Protective DNS de la CISA). La leçon opérationnelle est que la qualité du filtrage et la disponibilité du service doivent être évaluées ensemble.
Appliquez l'identité sans multiplier les politiques
Le personnel, les visiteurs, les résidents et les équipements connectés n'ont pas nécessairement besoin des mêmes règles. Un réseau peut attribuer différentes politiques en fonction de l'identité ou du segment réseau, comme un réseau réservé au personnel, un WiFi invités et un réseau isolé pour les équipements du bâtiment. L'objectif est d'adapter la politique à l'utilisateur ou à l'appareil tout en maintenant une gestion simple.
Les contrôles d'accès aident à établir cette séparation, tandis que la surveillance du trafic réseau peut aider les équipes à analyser l'activité réseau inhabituelle. Pour un aperçu complémentaire de la manière dont le contrôle d'accès réseau s'intègre dans un environnement géré, consultez ces solutions de contrôle d'accès réseau.
Fermez délibérément les voies de contournement
Si un appareil peut envoyer directement des requêtes DNS ordinaires à un résolveur externe, le service protecteur risque de ne jamais voir la requête. DoH et DoT créent une autre difficulté : le chiffrement peut protéger les requêtes en transit, mais un résolveur non géré peut également les soustraire à la politique et à la visibilité de l'organisation.
Lorsque l'application est requise, les équipes doivent identifier les chemins DNS directs et les destinations DNS chiffrées non autorisées, puis décider de la manière dont les contrôles du réseau, des points d'accès et du navigateur les traiteront. Testez également les exceptions. Les Captive Portals, les appareils mobiles, l'IPv6 et les applications disposant de leurs propres paramètres de résolveur peuvent se comporter différemment d'un ordinateur portable géré sur un réseau d'entreprise. La politique ne fonctionne que sur les chemins que l'organisation peut régir.
Impact sur les performances et gains mesurables de chargement des pages
Un service de DNS protecteur n'a pas à ralentir la navigation de manière perceptible. L'impact dépend moins de l'action de filtrage que des choix de conception pratiques : l'emplacement du résolveur, la façon dont il met en cache les réponses, la manière dont il maintient les connexions et le fait que les appareils le contournent ou non.
Le DNS chiffré peut ajouter du temps de configuration lorsqu'une connexion doit établir TCP, TLS ou HTTP avant d'envoyer une requête. Réutiliser une session persistante évite de répéter une grande partie de cette configuration. TLS 1.3, 0-RTT, le multiplexage HTTP/2 et QUIC peuvent également réduire le surcoût de connexion, selon des mesures indépendantes des performances du DNS chiffré. Dans des conditions de réseau saines, la latence brute de recherche peut être négligeable, mais cela n'est pas garanti pour tous les clients ou tous les chemins réseau.
Testez la recherche, pas seulement l'impression
Un résolveur proche, hautement disponible et doté d'une mise en cache conforme aux normes permet de maintenir la réactivité des requêtes ordinaires. Cependant, une valeur moyenne de latence peut masquer des lenteurs pour un sous-ensemble d'utilisateurs, ou lorsque le résolveur doit récupérer une réponse qui n'est pas encore en cache.
Mesurez la latence de recherche p50, p90 et p99 séparément pour les caches froids et chauds. La médiane indique une recherche typique ; les percentiles plus élevés révèlent des cas plus lents qui peuvent impacter plus fortement les utilisateurs. Séparez la vitesse de recherche du temps de chargement complet de la page, car le DNS n'est qu'une étape du parcours du navigateur.
Inclure les conditions qui révèlent les imprévus
Effectuez des tests à partir des types de réseaux et d'appareils utilisés par le public, notamment les clients mobiles, IPv6 et les Captive Portals. Vérifiez les applications et navigateurs susceptibles de sélectionner leur propre service DoH ou DoT, car ils peuvent modifier à la fois la route et la visibilité des requêtes DNS.
Dans le cadre de mesures distribuées, il a été observé que DoQ (DNS over QUIC) s'approche des performances du texte brut et améliore certains cas de chargement de pages par rapport au DoH. Considérez ces résultats comme une raison de tester les choix de transport dans votre propre environnement, et non comme la promesse d'un résultat particulier. L'objectif pratique est d'obtenir un résolveur proche, un cache efficace, des sessions chiffrées réutilisables et une architecture qui ne laisse pas de parcours non gérés ouverts.
Cas d'usage concrets dans les établissements et les entreprises
Un déploiement national montre ce que le DNS protecteur peut accomplir lorsque de nombreuses organisations partagent une couche de sécurité gérée. Au Royaume-Uni, le nombre d'organisations utilisant le service Protective Domain Name System est passé de 944 à 1 173 en 2022, soit une augmentation de 24 %. Au cours de cette année, le service a traité environ 0,55 billion de requêtes DNS et a bloqué 11 milliards de requêtes associées à des destinations malveillantes, soit environ 2 % de l'ensemble des requêtes (résumé NCSC PDNS du Royaume-Uni).
Cette échelle illustre l'intérêt de prendre une décision avant même qu'une tentative de connexion ne soit effectuée. Cela ne prouve pas que chaque requête bloquée se serait transformée en incident, ni que le DNS a arrêté à lui seul tous les vecteurs de menace. Pour un opérateur multi-sites, la comparaison utile consiste à déterminer si le service peut appliquer une politique de manière cohérente, produire des données de télémétrie exploitables, et gérer le volume ainsi que les exceptions de cet environnement.
Examinez comment ce même point de contrôle s'adapte à différents types d'établissements :
- Hôtels et résidences : Séparer l'accès des clients ou résidents de celui du personnel et des équipements du bâtiment. Un Captive Portal, un appareil plus ancien ou le résolveur chiffré préféré d'un résident peuvent créer des exceptions à anticiper.
- Aéroports et stades : Appliquer une référence commune à l'accès public à forte rotation tout en maintenant la distinction entre les réseaux opérationnels et ceux du personnel. Surveiller les appareils non gérés et les besoins de connectivité nécessitant une exception documentée.
- Santé et éducation : Restreindre l'accès aux destinations dangereuses sans bloquer les services légitimes utilisés pour les soins, l'enseignement ou l'administration. Proposer une procédure d'examen claire lorsqu'une politique bloque un élément nécessaire au travail.
- Commerce et centres commerciaux : Distinguer le trafic des visiteurs de celui des caisses, des appareils du personnel et des autres équipements opérationnels. Les équipes commerciales qui planifient l'accès des visiteurs trouveront également ces solutions WiFi pour le commerce utiles pour réfléchir à l'articulation entre l'accès et les politiques.
Une courte introduction au sujet peut également aider les équipes à s'aligner sur ce que la couche DNS fait et ne fait pas :
Dans chaque configuration, le filtrage DNS constitue un contrôle partiel et non une garantie que toutes les menaces seront arrêtées. Un utilisateur peut atteindre une infrastructure via un autre résolveur ou une adresse IP directe, et une application peut utiliser des protocoles qui ne reposent pas sur le chemin DNS de l'entreprise. Le déploiement nécessite donc une gestion des exceptions et une surveillance en plus de la politique elle-même.
Choisir la bonne approche pour votre réseau
Le DNS protecteur intervient au niveau du résolveur. Les agents d'équipement terminal, les paramètres du navigateur et les contrôles réseau opèrent à des endroits différents. Les équipes choisissent donc généralement une combinaison plutôt qu'un remplacement unique. Le bon dosage dépend de qui gère l'appareil, du trafic visible par le réseau et de la manière dont les exceptions doivent être traitées.
| Contrôle | Utilisation idéale | Visibilité | Limitation fréquente |
|---|---|---|---|
| DNS protecteur | Réseaux partagés, parcs gérés et application des politiques DNS | Requêtes DNS qui passent par le résolveur | Les résolveurs non gérés et les chemins non-DNS peuvent le contourner |
| Agent d'endpoint | Ordinateurs portables et appareils mobiles gérés nécessitant une protection hors réseau | Activité visible par l'agent installé | La couverture dépend de l'installation, de l'état et de la gestion de l'agent |
| Politique de navigateur | Navigateurs gérés dont les paramètres de résolveur et de navigation peuvent être régis | Configuration du navigateur et activité de navigation sélectionnée | Ne régit pas toutes les applications ni les navigateurs non gérés |
| Contrôles au niveau du réseau | Réseaux segmentés et trafic passant par une infrastructure gérée | Flux réseau couverts par le contrôle | Le trafic chiffré ou hors réseau peut limiter l'inspection |
| Contrôles d'identité et d'accès | Personnel, invités, résidents et groupes d'appareils aux besoins d'accès distincts | Décisions de connexion et d'accès liées à l'identité ou au segment | Une connexion autorisée n'évalue pas en soi chaque destination |
Pour les ordinateurs portables gérés, les contrôles sur les points d'accès et les navigateurs peuvent compléter la politique du résolveur, en particulier lorsque les employés travaillent à distance. Le WiFi invités et les appareils personnels (BYOD) sont plus difficiles à gérer à l'aide d'agents, ce qui rend les contrôles au niveau du réseau plus pratiques, à condition que l'entreprise puisse orienter le DNS vers le service qu'elle a choisi. Les appareils IoT et domestiques nécessitent souvent une segmentation et une politique qui prend en compte les options limitées de gestion des appareils.
Pour les équipes qui comparent l'identité réseau, le filtrage et les vérifications destinées aux utilisateurs, les vérifications gratuites DNS et e-mail de mailX peuvent constituer une ressource pertinente aux côtés d'un examen plus large des contrôles d'accès. Si des environnements de paiement font partie du parc, déterminez également comment la conception WiFi et les exigences de conformité PCI-DSS affectent la séparation du réseau et son administration.
Purple Access combine des options de réseau ouvertes, sécurisées et xPSK sur les points d'accès existants, avec une intégration par Captive Portal et une attribution de réseau basée sur l'identité. Purple Shield ajoute un DNS protecteur et un filtrage de contenu avec des contrôles par politique. Ces fonctionnalités peuvent coexister avec les contrôles de points d'accès et de navigateurs, mais elles ne dispensent pas de définir l'application du résolveur, les exceptions et la surveillance. Choisissez vos outils en fonction des chemins et des appareils que vous devez protéger, puis vérifiez que leurs politiques fonctionnent ensemble.
Mesurer la valeur du DNS protecteur au-delà du nombre de blocages
Un total de requêtes bloquées vous indique simplement que le résolveur a agi. À lui seul, il ne vous dit pas s'il a intercepté les bonnes requêtes, interrompu des tâches utiles ou manqué du trafic qui a emprunté une autre route. Comptabilisez la décision, mais mesurez le contrôle.
L'atelier DNS de l'Association européenne de l'industrie Internet a signalé 2,3 millions de rapports d'abus couvrant 780 000 domaines uniques au cours des six mois précédents, les rapports mensuels passant de 220 000 à 380 000 (rapport de l'atelier). Ces chiffres montrent l'ampleur des abus signalés. Ils ne permettent pas d'établir combien d'incidents un résolveur a évités, si un blocage était correct ou si le trafic affecté a atteint une destination via un VPN, un résolveur alternatif, une adresse IP codée en dur ou un protocole d'application chiffré.
Concevoir un tableau de bord axé sur les résultats et les exceptions
Un suivi efficace associe sécurité, qualité de service et réactivité opérationnelle. Suivez si le résolveur a détecté des domaines malveillants connus, la rapidité avec laquelle les équipes traitent les demandes de faux positifs, et si les modifications de politiques atteignent rapidement les sites concernés. Associez ces mesures à la disponibilité du résolveur ainsi qu'à la latence médiane et maximale des requêtes.
Mesurez également les tentatives de contournement. Un faible nombre de requêtes bloquées peut signifier que l'environnement présente peu d'activité malveillante, ou que les appareils n'utilisent pas le résolveur de protection. Associez les événements pertinents à l'identité réseau, comme un SSID, un VLAN, un site ou un groupe d'utilisateurs, afin que les analystes puissent voir où s'applique une politique et où une exception peut se cacher. Comparez l'activité DNS aux données des points d'accès ou des incidents plutôt que de prétendre que chaque recherche bloquée représente un incident évité.
Traitez les journaux DNS comme des données opérationnelles sensibles
Les journaux DNS peuvent révéler des habitudes de navigation, ce qui exige une grande vigilance dans les secteurs de la santé, de l'éducation, de l'hôtellerie et des résidences. Définissez des limites de conservation, restreignez l'accès par rôle et séparez la télémétrie de sécurité des données marketing destinées aux invités. Déterminez qui peut enquêter sur un incident de sécurité et de quelles données ces personnes ont besoin avant de collecter des journaux à grande échelle.
Prochaines étapes pour planifier le déploiement de votre DNS protecteur
Commencez par analyser le chemin d'accès plutôt que le tableau de bord. Identifiez les appareils qui utilisent le résolveur géré, repérez les accès où un DNS direct ou un DNS chiffré non autorisé pourrait le contourner, et déterminez comment l'application des règles s'effectuera pour les appareils non gérés par l'organisation. Intégrez une procédure de dérogation pour les services légitimes bloqués par une politique.
Avant le déploiement, définissez la manière dont l'équipe évaluera à la fois la sécurité et la qualité de service :
- Confirmer l'utilisation du résolveur : Vérifiez les appareils gérés, les réseaux invités et les appareils moins prévisibles tels que l'IoT.
- Tester le chemin réseau : Là où l'application est requise, examinez le DNS direct et les routes DNS chiffrées non autorisées.
- Mesurer la performance : Comparez la latence de recherche sur cache froid et chaud, y compris les percentiles plus lents.
- Définir le tableau de bord : Suivez la gestion des faux positifs, la disponibilité, la propagation des politiques, les tentatives de contournement et les résultats d'incidents.
- Définir les règles de confidentialité : Établissez les limites d'accès aux journaux et de conservation avant le début d'une collecte globale.
Pour un déploiement multisite, rassemblez les équipes réseau et sécurité afin de cartographier les identités, les segments de réseau, les routes de résolveur et les exceptions dont chaque site a besoin. Purple propose des sessions de conception dirigées par des ingénieurs réseau pour façonner et valider les plans de déploiement. Le DNS de protection peut rendre les destinations dangereuses plus difficiles à atteindre via le chemin de recherche géré, mais il ne remplacera pas la sécurité des points d'accès, la segmentation du réseau ou la gouvernance de la confidentialité.
Purple Access prend en charge les réseaux WiFi ouverts, sécurisés et xPSK, avec une attribution de réseau basée sur l'identité et un intégration des invités ou BYOD sur les points d'accès existants. Pour planifier la façon dont ces contrôles d'accès peuvent fonctionner aux côtés du DNS protecteur sur l'ensemble de vos sites, consultez Purple Access.
