Filtrage DNS « fail open » vs « fail closed » : que se passe-t-il lorsque le filtre est en panne ?

Le filtrage DNS en mode fail open vs fail closed correspond au choix du comportement d'un réseau lorsque son résolveur de filtrage cesse de répondre. Le mode fail open bascule sur un résolveur non filtré, de sorte que la navigation se poursuit sans protection. Le mode fail closed ne renvoie les requêtes nulle part ailleurs, conformément au contrôle SC-24 du NIST SP 800-53 (défaillance dans un état connu), garantissant que rien ne soit résolu sans filtrage.

Qu'est-ce que le filtrage DNS en mode fail open vs fail closed ?

Le filtrage DNS intervient dès la première étape de chaque connexion. Un téléphone demande à un résolveur de convertir un nom de domaine en adresse IP avant d'ouvrir une session (RFC 1035). Un résolveur DNS protecteur vérifie ce nom par rapport aux informations sur les menaces et à votre politique de contenu. Il renvoie ensuite l'adresse réelle, l'adresse d'une page de blocage ou un refus.

Cet emplacement est la raison pour laquelle le filtrage DNS fonctionne. La vérification a lieu avant même qu'un seul paquet n'atteigne la destination. Cela permet de bloquer un lien de hameçonnage ou un rappel de logiciel malveillant qu'un pare-feu ne verrait que comme du trafic autorisé sur le port 443. Le National Cyber Security Centre du Royaume-Uni exploite un service DNS protecteur pour le secteur public fondé sur ce même principe.

Cet emplacement constitue également le point faible. Si chaque recherche dépend du résolveur de filtrage, vous devez prévoir un plan pour les cas où celui-ci est inaccessible. Il n'existe que deux plans possibles.

• Fail open. Le réseau ou l'équipement envoie la requête à un autre résolveur qui n'applique aucune politique. La navigation se poursuit, mais la protection, la journalisation et les règles de contenu s'arrêtent jusqu'au retour du filtre.
• Fail closed. Aucun chemin non filtré n'existe. Les nouvelles recherches attendent la réponse d'un résolveur de filtrage, et rien n'est résolu sans une décision basée sur la politique établie.

Ce choix réside dans un arbitrage entre disponibilité et assurance. Le mode fail open privilégie le visiteur qui souhaite charger une page immédiatement. Le mode fail closed privilégie votre équipe de sécurité, votre responsable de la protection des données et votre auditeur, qui doivent prouver que le réseau a été filtré à chaque minute de l'année.

Le NIST SP 800-53 Rev. 5 formule cette même idée dans deux contrôles. SC-24 correspond à la « défaillance dans un état connu » et SC-7(18) à la « défaillance sécurisée » (NIST SP 800-53 Rev. 5).

Comment fonctionne le comportement en cas de défaillance du filtre au niveau du résolveur ?

C'est votre configuration qui détermine le comportement en cas de défaillance du filtre, et non le filtre lui-même. Trois éléments le définissent : le serveur DHCP, tout redirecteur DNS local et l'équipement client.

Les champs DNS du DHCP

Le DHCP est le protocole qui fournit à chaque équipement son adresse IP et ses paramètres réseau lorsqu'il se connecte. La plupart des réseaux invités et collaborateurs l'utilisent pour attribuer à chaque équipement deux adresses de serveurs DNS ou plus. Si toutes pointent vers des résolveurs de filtrage, la conception est en mode fail closed. Si la seconde pointe vers un FAI ou un résolveur public, la conception est en mode fail open, peu importe les promesses du fournisseur de filtrage.

Le relais local

De nombreux pare-feux et passerelles exécutent un relais DNS. Les appareils interrogent la passerelle, et la passerelle retransmet aux résoluteurs en amont. Ici, le secours réside dans la liste en amont du relais. Un relais qui répertorie un résoluteur public en dessous du filtre échoue en mode fail open, même si le DHCP semble propre.

Le comportement propre à l'appareil

La sélection du résoluteur varie selon le système d'exploitation. Certains appareils traitent le second serveur comme une veille stricte. D'autres l'interrogent dès que le premier est lent, ou envoient des requêtes aux deux. Dans une conception fail open, des réponses non filtrées peuvent donc fuiter alors que le filtre fonctionne parfaitement.

À quoi ressemble le mode fail closed

Dans une architecture fail closed, chaque adresse DNS qu'un appareil ou un relais peut utiliser pointe vers un résoluteur de filtrage appliquant la même politique. Si l'un cesse de répondre, l'appareil réessaie avec le suivant. La recherche n'échoue que lorsque tous les résoluteurs de filtrage sont inaccessibles. L'appareil obtient alors un délai dépassé ou SERVFAIL, la réponse d'erreur standard de "défaillance du serveur" DNS, au lieu d'une réponse non filtrée.

Lorsqu'il est correctement mis en œuvre, le mode fail closed n'est pas fragile. La résilience provient de la redondance des résolveurs de filtrage, et non d'une porte de sortie non filtrée.

Fail open, fail closed, fail secure : quels termes sont souvent confondus ?

Quatre termes proches apparaissent dans la documentation des fournisseurs, les résultats d'audit et les tickets de modification. Ils décrivent des éléments différents, et les confondre conduit à une conception erronée.

Fail closed n'est pas default deny

Default deny est un choix de politique concernant les domaines non catégorisés. Il s'exécute lorsque le filtre fonctionne correctement. Le fail closed concerne ce qui se produit lorsque le filtre est absent. Vous pouvez utiliser le fail closed avec une politique permissive, ou le fail open avec une politique stricte.

Serve-stale se situe entre les deux

La RFC 8767 permet à un résolveur de répondre à partir du cache expiré lorsqu'il ne peut pas atteindre les serveurs en amont. Cela permet aux noms populaires de continuer à fonctionner pendant les courtes pannes. Il rejoue la dernière décision, de sorte qu'un domaine devenu malveillant entre-temps n'est pas intercepté.

Le contournement n'est pas une défaillance

Un appareil utilisant le DNS over HTTPS (DoH, RFC 8484) ou le DNS over TLS (DoT, RFC 7858) vers un résolveur public ne touche jamais votre filtre. Les paramètres de fail closed n'y changent rien. Vous gérez le contournement avec des règles de sortie (egress).

Où rencontrez-vous une panne de filtrage DNS en pratique ?

Une panne de filtrage DNS n'a d'importance que si le lien Internet est actif mais que le filtre est inaccessible. Si l'ensemble de la liaison descend, les deux modes semblent identiques. En pratique, l'écart se crée lors d'événements opérationnels ordinaires :

• une modification du pare-feu qui bloque le port 53 sortant vers les adresses du filtre ;
• un redirecteur local qui plante ou cesse de rediriger en amont ;
• un changement de routage sur un WAN de filiale qui envoie le DNS dans la mauvaise direction ;
• un prestataire modifiant une plage DHCP et ajoutant un résolveur public "pour la résilience" ;
• un incident chez le fournisseur de filtrage lui-même.

Chacun de ces éléments semble inoffensif sur un réseau qui bloque en cas de panne (fail closed). Chacun d'eux supprime silencieusement la protection sur un réseau qui laisse passer en cas de panne (fail open).

Réseaux WiFi invités dans l'hôtellerie et la restauration

Les hôtels et les groupes de pubs appliquent une politique de filtrage de contenu pour garder un réseau WiFi invité adapté aux familles et à l'abri des logiciels malveillants. Un réseau invité en mode fail open abandonne cette politique sans en avertir quiconque. Pour les grands acteurs de l'hôtellerie, une faille dans l'application de la politique sur le WiFi public engendre un risque d'image en plus du risque de sécurité.

Santé

Purple Shield bloque environ 241 000 menaces par semaine au St George's Healthcare NHS Trust. Selon nos calculs, cela représente une moyenne d'environ 1 400 menaces par heure. Une fenêtre d'interruption en mode fail open d'une heure laisserait ces requêtes se résoudre sans aucun contrôle, sur les appareils des patients, des visiteurs et du personnel.

Hubs de transport

Les aéroports accueillent des milliers d'appareils de passagers sur des réseaux publics, dont beaucoup ne sont pas gérés. Dans un terminal, une interruption en fail open signifie un réseau public non filtré en plein pic de fréquentation.

Réseaux d'entreprise et du personnel

Les réseaux réservés au personnel augmentent les enjeux de disponibilité. Les applications professionnelles doivent continuer à fonctionner, la stratégie fail closed a donc besoin d'une véritable redondance. Les noms internes se résolvent généralement sur des serveurs DNS internes, qui transmettent ensuite les requêtes externes au filtre. Assurez-vous que cet étage de redirection ne comporte aucun serveur en amont non filtré.

Quelles sont les limites et les cas particuliers du DNS fail closed ?

Le mode fail closed est le choix par défaut idéal pour la plupart des réseaux WiFi invités et du personnel. Il présente néanmoins des limites qu'il convient de connaître avant de concevoir votre architecture.

Le fail closed avec un seul résolveur équivaut à un plan d'interruption

Si le réseau ne liste qu'une seule adresse de filtrage, le fail closed signifie que chaque panne de cette adresse interrompt le service DNS. La redondance entre plusieurs résolveurs de filtrage est ce qui rend le fail closed viable. Demandez à votre fournisseur combien d'adresses de résolveur vous pouvez configurer et testez chacune d'elles.

Le cache conserve certains noms actifs

Chaque réponse DNS comporte un TTL (time to live), c'est-à-dire le nombre de secondes pendant lesquelles un appareil ou un résolveur peut la conserver en cache. Lors d'une courte panne, les noms en cache continuent de fonctionner et les nouveaux échouent. Les visiteurs constatent cela par le fait que "certains sites fonctionnent et d'autres non", ce qui peut induire votre support informatique en erreur.

Les portails captifs nécessitent le DNS avant la connexion

Un Captive Portal est la page d'accueil qu'un invité voit avant d'accéder à Internet. L'appareil doit résoudre le domaine du portail et tous les domaines du jardin clôturé (walled garden) avant de s'authentifier. Si le réseau pré-connexion utilise un résolveur non filtré, le portail devient la faille. S'il est configuré en fail closed sans redondance, les invités ne peuvent pas du tout se connecter.

Une panne se présente différemment d'un blocage

Un domaine bloqué doit renvoyer une page de blocage ou un refus clair. Une recherche échouée renvoie un délai d'attente (timeout) ou SERVFAIL. L' RFC 8914 (Extended DNS Errors) ajoute des codes qui les distinguent, tels que Bloqué (15) et Filtré (17) par opposition à Autorité non joignable (22). Informez votre support technique de cette distinction afin qu'il puisse faire la différence entre un blocage de politique et une panne.

Le DNS ne peut pas voir au-delà du nom

Le fonctionnement en échec sécurisé (fail closed) garantit une décision de politique sur chaque recherche, mais pas une couverture totale. Les connexions aux adresses IP brutes contournent entièrement le DNS. Les connexions déjà ouvertes avant la panne se poursuivent. De plus, le DNS ne voit que le domaine, jamais le chemin d'accès, ce qui est expliqué dans pourquoi le filtrage DNS ne peut pas voir les URL complètes.

Pour comprendre comment ces limites s'intègrent dans une architecture plus large, consultez le filtrage DNS est-il suffisant ? et la vue d'ensemble sur les limites du filtrage DNS.

Quel est le lien entre le DNS en mode fail closed et Purple Shield ?

Purple Shield est une solution de DNS protecteur et de filtrage de contenu pour chaque réseau. Shield fonctionne en mode fail closed, de sorte qu'une panne ne laisse jamais un réseau sans filtrage. Chaque recherche obtient une décision de politique ou aucune réponse, mais jamais une réponse non vérifiée.

Vous pouvez exécuter Shield de manière autonome sur n'importe quel réseau WiFi ou parallèlement à Purple Access. Vous définissez une politique par réseau et par VLAN (LAN virtuel, un réseau logiquement séparé sur un matériel partagé). Les réseaux invités, le personnel et le back-office d'un même site peuvent chacun appliquer des règles différentes. Shield ne nécessite aucun nouveau matériel et s'installe sous forme de superposition cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet.

DNSFilter et Cisco Umbrella filtrent également lors de la résolution DNS, l'argument d'emplacement s'applique donc aux trois solutions. La question à poser à chaque fournisseur est de savoir où se trouve la solution de repli. Demandez comment se comportent leurs agents nomades lorsque les résoluteurs sont inaccessibles, et combien d'adresses de filtrage vous pouvez configurer. Vérifiez ensuite que vos propres paramètres DHCP et de redirecteur ne réintroduisent pas un chemin non filtré.

Shield fonctionne sur l'ensemble de l'empreinte de Purple, soit plus de 80 000 sites dans 90 pays. Consultez comment fonctionne Shield pour obtenir des détails sur le déploiement. Le guide de sécurité WiFi pour entreprises montre où se situe le filtrage DNS aux côtés de l'identité et de la segmentation.

Ce concept montre sa vraie valeur lors de la fenêtre de modification, pas dans la brochure. La règle de pare-feu, la modification DHCP ou la secondaire publique « résiliente » déterminent si votre réseau reste filtré. Auditez ces trois paramètres ce trimestre. Ensuite, lisez DNS sur TLS et filtrage : ce que change le port 853, car un résolveur qui échoue en mode fermé ne protège que les appareils qui l'utilisent réellement.

Foire aux questions

Le filtrage DNS en mode fermé entraîne-t-il la mise hors ligne de mon WiFi en cas de panne ?

Non, pas lorsque le filtre s'exécute sur des résolveurs redondants. Le mode fermé bloque uniquement les nouvelles requêtes lorsque tous les résolveurs de filtrage sont inaccessibles en même temps. Les appareils réessayent d'abord sur la seconde adresse de filtrage. Les réponses en cache permettent de continuer à résoudre les sites récemment visités lors de courtes interruptions. Concevez la redondance avant d'être en production, puis testez-la en bloquant un résolveur à la fois depuis un VLAN de test.

Shield fonctionne-t-il avec les points d'accès et pare-feux dont je dispose déjà ?

Oui. Shield filtre au niveau de la résolution DNS, il ne nécessite donc aucun nouveau matériel et fonctionne de manière autonome sur n'importe quel réseau WiFi. Purple fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Vous pointez le DNS de chaque réseau ou VLAN vers Shield, supprimez tout secours non filtré et appliquez une politique par réseau. La page du produit détaille ces étapes.

Comment est calculé le prix de Shield ?

Purple établit un devis Shield personnalisé pour votre parc plutôt que de publier un tarif public dans ce guide. Shield est un module complémentaire de sécurité que vous pouvez exécuter de manière autonome sur n'importe quel réseau WiFi ou parallèlement à Purple Access. Le devis reflète donc vos réseaux et sites, et non du nouveau matériel. Demandez un devis en précisant le nombre de sites, le nombre de réseaux et de VLAN, et si vous utilisez déjà Purple.

Comment passer de DNSFilter ou Cisco Umbrella sans interruption du filtrage ?

Effectuez la bascule d'un réseau ou VLAN à la fois. Pointez le DNS DHCP d'un VLAN de test vers Shield, confirmez les blocages et les journaux, puis migrez les réseaux en production lors d'une fenêtre de modification. Supprimez complètement les anciennes adresses de résolveur au lieu de les laisser en DNS secondaire. Vérifiez également les agents itinérants sur les appareils du personnel, car leurs paramètres de secours se trouvent en dehors de votre étendue DHCP.

Une réglementation exige-t-elle un filtrage DNS en mode fermé ?

Aucune réglementation ne nomme explicitement le DNS en mode fermé, mais les cadres de contrôle exigent que les contrôles de sécurité échouent dans un état sécurisé et connu. Le contrôle SC-24 du NIST SP 800-53 Rev. 5 couvre la défaillance dans un état connu. Le contrôle SC-7(18) couvre la protection des limites avec défaillance sécurisée. Le filtrage en mode fermé vous fournit la preuve que la politique est appliquée à chaque minute, ce qui est utile lors des audits ou des demandes des responsables de la protection des données.

Comment tester le comportement actuel de mon filtre en cas de défaillance ?

Bloquez le trafic DNS sortant vers vos résolveurs de filtrage à partir d'un seul VLAN de test et observez la réaction de l'appareil. Si les sites web continuent de s'afficher et que le filtre n'enregistre rien, le réseau échoue en mode ouvert. Vérifiez les champs DNS DHCP, les listes de réacheminement en amont et tous les paramètres d'appareil configurés en dur. Répétez l'opération en bloquant un résolveur de filtrage à la fois pour confirmer que la redondance fonctionne.

Le filtrage DNS suffit-il à lui seul, ou ai-je besoin d'une passerelle web sécurisée ?

Le filtrage DNS couvre la protection contre les menaces et la politique de contenu pour la plupart des réseaux d'invités et d'établissements, mais pas l'inspection complète des URL ni la prévention des pertes de données. Il voit les noms de domaine, pas les chemins ni le contenu des fichiers. Si vous avez besoin de ces contrôles, ajoutez une passerelle web sécurisée sur les appareils gérés. Consultez Filtrage DNS vs passerelle web sécurisée pour savoir où se situe la limite.