Qu'est-ce que le filtrage DNS ? Comment bloquer les contenus nuisibles sur le Guest WiFi

Ce guide technique complet explique comment le filtrage DNS opère au niveau de la couche réseau pour sécuriser le Guest WiFi d'entreprise, couvrant les architectures de déploiement, la prévention de l'évasion et l'intégration du Captive Portal. Il fournit des conseils de mise en œuvre exploitables pour les responsables informatiques des secteurs de la vente au détail, de l'hôtellerie et des lieux publics qui doivent appliquer des politiques de contenu, protéger la réputation de la marque et démontrer leur conformité avec PCI DSS et GDPR. Des études de cas réelles issues d'environnements hôteliers et de vente au détail illustrent les compromis pratiques et les décisions de configuration qui déterminent le succès du déploiement.

📖 8 min de lecture📝 1,778 mots🔧 2 exemples concrets❓ 4 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast

Welcome to the Purple Technical Briefing. Today we're diving into a critical component of enterprise network security: DNS Filtering for Guest WiFi.

For IT managers, network architects, and operations directors managing public networks in hospitality, retail, or large venues, providing a seamless WiFi experience is only half the battle. The other half is ensuring that network is safe, compliant, and performant. Guest networks are inherently untrusted environments. Without robust controls, they become vectors for malware distribution, illegal downloading, and access to inappropriate content that can severely damage a venue's brand reputation.

Today, we'll explore why DNS filtering is the most effective architectural approach to mitigate these risks, how it compares to alternative methods, and the best practices for deployment.

Let's start with the technical deep-dive. How does DNS filtering actually work?

At its core, the Domain Name System, or DNS, is the phonebook of the internet. When a guest connects to your WiFi and types a website address into their browser, their device must translate that human-readable domain into a machine-readable IP address.

In a standard setup, this query goes to a default resolver, often provided by the ISP. In a secure architecture using DNS filtering, that query is intercepted. The DHCP server on your network assigns a specific, secure DNS resolver to the guest device. When the query hits this filtering engine, it doesn't just resolve the IP — it evaluates the domain against real-time threat intelligence feeds and your specific corporate policies.

If the domain is benign, the IP is returned, and the connection proceeds. This happens in milliseconds. However, if the domain is flagged as malicious — say, a known phishing site or a botnet command-and-control server — or if it violates your content policy, such as adult content or illegal streaming, the engine intervenes. It either returns a non-routable IP address, a technique known as sinkholing, or redirects the user to a branded block page.

Why is this approach superior to other methods like Deep Packet Inspection or proxy filtering? It comes down to performance and scale.

DPI requires the network hardware to inspect the payload of every packet. In a dense environment like a stadium with fifty thousand concurrent users, DPI introduces massive latency and requires incredibly expensive hardware. DNS filtering, on the other hand, operates at the very beginning of the connection lifecycle. It evaluates a lightweight UDP packet. Once the DNS resolution is complete, the actual data transfer happens directly between the client and the safe server. The filtering engine doesn't need to process the heavy data payload. This results in near-zero latency impact, typically less than two milliseconds.

Furthermore, because DNS filtering operates before the connection is established, it's completely protocol-agnostic. It blocks the connection whether the application is trying to use HTTP, HTTPS, FTP, or a custom port.

Let's look at a real-world example. Consider a five-hundred-room luxury hotel chain. They're experiencing high bandwidth utilisation due to illegal streaming, and they've received complaints about inappropriate content being accessible in public areas. Their property management system shares the same physical infrastructure via VLANs.

The correct approach here is to deploy a cloud-based DNS filtering solution and configure the DHCP scope specifically for the Guest WiFi VLAN to assign the cloud DNS IPs. Critically, you implement firewall rules on the gateway to block outbound UDP and TCP port 53 traffic from the Guest VLAN to any external IP other than the approved DNS servers. You then create a policy blocking adult content, piracy, and malware categories. The key architectural decision is ensuring the property management system VLAN continues to use internal DNS servers, completely isolating the filtering policy to the guest network.

Now, let's talk about implementation pitfalls.

The foundational step is network configuration. You must configure your gateway or DHCP server to hand out the IP addresses of your DNS filtering service to all clients on the guest VLAN.

But here is the critical rule of thumb: Block port fifty-three, or it's free.

If you simply assign the DNS servers via DHCP, savvy users or malicious applications can bypass the filter by hardcoding their own DNS settings, like Google's eight-eight-eight-eight or Cloudflare's one-one-one-one. To prevent this evasion, you must implement firewall rules at the gateway that block all outbound traffic on port fifty-three — both UDP and TCP — to any IP address other than your designated filtering servers.

Another major pitfall involves captive portals. We see this often in retail and hospitality deployments. A venue implements strict DNS filtering, and suddenly, guests can't log in. Why? Because the captive portal relies on external domains for authentication — for example, OAuth providers for social login. If your DNS filter blocks these domains before the user has authenticated, you create a catch-22. The user can't access the internet to authenticate, and they can't authenticate to access the internet.

The solution is ensuring your Walled Garden is properly configured. You must explicitly allowlist the domains required for the captive portal experience within the DNS filtering policy.

A second real-world scenario: a large retail shopping centre wants to offer free public WiFi with a captive portal for demographic data capture, while complying with strict family-friendly corporate policies. The integration of DNS filtering with the captive portal requires adding the authentication domains — Google, Facebook, and any identity provider — to the pre-authentication allowlist. The content filtering policy is then applied only after the user has successfully authenticated. This approach turns a potential technical conflict into a seamless user journey.

Now, let's move to a rapid-fire Q&A based on common scenarios we see in the field.

Question one: Can we use transparent HTTPS inspection instead of DNS filtering for our guest network?

No. Transparent HTTPS inspection requires deploying a custom root certificate to the endpoint device to decrypt the traffic. You cannot deploy certificates to unmanaged guest devices. It will break their browsing experience with severe security warnings. DNS filtering is the correct approach for bring-your-own-device environments.

Question two: How does DNS filtering handle DNS over HTTPS, or DoH?

DoH encrypts the DNS query, which can bypass traditional network-level interception. The best practice is to use threat intelligence feeds to identify and block the IP addresses of known DoH providers at the firewall, forcing the client to fall back to standard, filterable DNS.

Question three: Does DNS filtering help with compliance?

Absolutely. For frameworks like PCI DSS, demonstrating network segmentation and robust access controls is mandatory. While guest networks should always be segmented from payment networks, preventing malware execution on the guest network reduces the overall risk profile of the venue. For GDPR purposes, demonstrating that you have taken reasonable technical measures to prevent misuse of your network is a positive indicator of compliance.

To summarise today's briefing. DNS filtering is not just a security best practice — it's an operational necessity for enterprise public networks. It provides a scalable, low-latency mechanism to block malicious threats and enforce acceptable use policies.

The five key takeaways are: First, DNS filtering intercepts domain queries before a connection is established, adding less than two milliseconds of latency. Second, always block outbound port fifty-three at the firewall to prevent evasion via custom DNS settings. Third, carefully configure your walled garden to ensure captive portal authentication domains are not blocked. Fourth, use VLAN segmentation to apply filtering policies exclusively to guest traffic, protecting operational systems. And fifth, DNS filtering supports compliance with PCI DSS and GDPR by demonstrating robust network access controls.

Your next steps: audit your current guest network DNS configuration, verify that outbound port fifty-three is restricted, and review your captive portal walled garden against your active DNS filtering policy.

Thank you for listening to this Purple Technical Briefing. For more detailed deployment guides and architecture patterns, visit purple dot ai.

Points clés à retenir

✓DNS filtering intercepts domain resolution queries before a connection is established, adding less than 2ms of latency — making it the highest-performance content control method for high-density guest networks.
✓Assigning filtered DNS via DHCP alone is insufficient; outbound port 53 (UDP/TCP) must be blocked at the firewall to prevent users from bypassing the filter with custom DNS settings.
✓Captive portal walled gardens must be configured before any blocking policy is applied — failing to allowlist OAuth and identity provider domains is the most common cause of broken guest onboarding.
✓VLAN segmentation is essential: filtering policies must be scoped exclusively to the guest VLAN, leaving operational systems (PMS, POS) on unfiltered internal DNS.
✓DNS over HTTPS (DoH) can bypass network-level filtering; block known DoH provider IPs at the firewall to maintain comprehensive coverage.
✓DNS filtering directly supports PCI DSS network segmentation requirements and GDPR data protection by design principles, reducing compliance risk.
✓Cloud-based DNS filtering solutions offer the best combination of scalability, high availability, and automatic threat intelligence updates for multi-site enterprise deployments.

Résumé Exécutif

Pour les responsables informatiques d'entreprise gérant des réseaux publics à grande échelle, garantir une expérience de navigation sûre, conforme et performante est un impératif opérationnel critique. Les réseaux Guest WiFi dans l'hôtellerie, la vente au détail et les lieux publics sont des cibles privilégiées pour les activités malveillantes et les violations de politiques — du trafic de commande et de contrôle de botnet au streaming illégal et au contenu inapproprié. Ce guide fournit une référence technique définitive sur le filtrage DNS : le mécanisme le plus efficace pour bloquer les contenus nuisibles et atténuer les risques à la périphérie du réseau.

Contrairement à l'inspection approfondie des paquets (DPI) gourmande en ressources ou aux listes de blocage IP rigides, le filtrage DNS intercepte la requête de résolution de domaine initiale. En évaluant les requêtes par rapport à des flux d'informations sur les menaces en temps réel, il empêche les connexions à des domaines malveillants ou inappropriés avant l'échange de toute charge utile. Cette approche garantit un débit élevé et une latence minimale — essentiels pour les environnements prenant en charge des milliers d'utilisateurs simultanés.

La mise en œuvre d'un filtrage DNS robuste protège non seulement la réputation du lieu, mais soutient également la conformité aux réglementations sur la protection des données et aux politiques d'utilisation adaptées aux familles. Pour les organisations tirant parti de solutions telles que Guest WiFi et WiFi Analytics , l'intégration de contrôles au niveau DNS est une exigence de sécurité fondamentale qui sous-tend toutes les autres couches de la pile réseau invité.

Plongée Technique : Comment fonctionne le filtrage DNS

Le filtrage DNS fonctionne comme une couche de sécurité proactive au sein de l'architecture réseau. Lorsqu'un appareil client tente d'accéder à un domaine, le résolveur DNS local intercepte la requête. Au lieu de renvoyer immédiatement l'adresse IP, la requête est transmise à un moteur de filtrage qui l'évalue par rapport à la politique et aux informations sur les menaces avant de décider de la résoudre ou de la bloquer.

Le pipeline de résolution

Le pipeline de résolution du filtrage DNS fonctionne en quatre étapes distinctes. Premièrement, l'interception de requête : l'appareil invité se connecte au réseau et reçoit la configuration IP via DHCP, qui spécifie le serveur de filtrage DNS comme résolveur principal. Deuxièmement, l'évaluation de la politique : le moteur de filtrage reçoit la requête (par exemple, malicious-domain.com) et la confronte à des listes de blocage catégorisées et à des flux d'informations sur les menaces dynamiques mis à jour en temps réel. Troisièmement, la résolution ou le sinkholing : si le domaine est bénin, le moteur résout l'adresse IP réelle et la connexion se déroule normalement. Si le domaine enfreint la politique, le moteur renvoie une adresse IP non routable — une technique connue sous le nom de sinkholing — ou redirige l'utilisateur vers une page de blocage personnalisée. Quatrièmement, la journalisation : chaque requête, qu'elle soit résolue ou bloquée, est enregistrée à des fins d'audit et d'analyse.

Avantages Architecturaux

Le déploiement du filtrage DNS offre des avantages distincts par rapport aux méthodes alternatives de contrôle de contenu. La surcharge de latence est négligeable — les requêtes DNS sont des paquets UDP légers, et leur évaluation ajoute moins de 2 ms, imperceptible pour l'utilisateur final. L'approche est également agnostique au protocole : le filtrage ayant lieu avant l'établissement de la connexion, il est efficace quel que soit le protocole d'application sous-jacent (HTTP, HTTPS, FTP) ou le numéro de port. C'est un avantage significatif par rapport au filtrage proxy basé sur les URL, qui ne peut pas inspecter le trafic HTTPS chiffré sans déployer un certificat racine personnalisé sur chaque point de terminaison — une impossibilité sur les appareils invités non gérés.

L'évolutivité est un autre atout majeur. Un seul cluster DNS robuste peut gérer des millions de requêtes par seconde, ce qui le rend idéal pour les environnements à haute densité comme les stades, les grands centres de conférence ou les déploiements Retail multi-sites. Pour les topologies multi-locataires complexes, le filtrage DNS s'intègre parfaitement aux stratégies de segmentation basées sur les VLAN, comme détaillé dans Concevoir une architecture WiFi multi-locataires pour MDU .

Méthode	Complexité de déploiement	Impact sur la latence	Granularité	Adéquation au réseau invité
Filtrage DNS	Faible	Minimal (<2ms)	Niveau de domaine	Recommandé
Filtrage URL/Proxy	Moyen	Modéré (10–50ms)	Niveau URL	Limité (problèmes HTTPS)
Inspection approfondie des paquets	Élevé	Élevé (50–200ms)	Niveau de charge utile	Non recommandé
Listes de blocage IP	Faible	Aucune	Niveau IP uniquement	Supplémentaire uniquement
Pare-feu d'application	Élevé	Modéré	Niveau application	Complémentaire

Guide de mise en œuvre

Le déploiement du filtrage DNS nécessite une planification minutieuse pour assurer une couverture complète sans perturber le trafic légitime. Les étapes suivantes décrivent une stratégie de déploiement neutre vis-à-vis des fournisseurs, applicable aux environnements Hôtellerie , Santé , Transport et de vente au détail.

Étape 1 : Segmentation du réseau et configuration DHCP

La méthode de déploiement la plus robuste consiste à configurer la passerelle réseau ou le serveur DHCP pour qu'il distribue les adresses IP du serveur de filtrage DNS à tous les clients invités. Cela garantit que tout appareil rejoignant le réseau utilise automatiquement le résolveur sécurisé sans nécessiter d'installation d'agent sur le point de terminaison.

Pour les environnents with complex topologies — such as those described in Concevoir une architecture WiFi multi-locataires pour les MDU — garantissent que les VLAN dédiés au trafic invité sont strictement acheminés via le DNS filtré, tandis que les VLAN opérationnels (PMS, POS, gestion des bâtiments) continuent d'utiliser des résolveurs internes. Cette isolation basée sur les VLAN est une condition préalable à la conformité PCI DSS, qui exige une segmentation stricte du réseau entre les environnements de données des titulaires de carte et les réseaux invités non fiables.

Étape 2 : Prévention de l'évasion — Bloquer le port 53

C'est à cette étape que de nombreux déploiements échouent. L'attribution des serveurs DNS via DHCP seule est insuffisante. Un utilisateur ayant des paramètres DNS personnalisés configurés sur son appareil — pointant vers 8.8.8.8 ou 1.1.1.1 — contournera entièrement le filtre. La solution est simple : implémenter des règles de pare-feu au niveau de la passerelle qui bloquent tout le trafic sortant sur le port 53 (UDP et TCP) vers toute adresse IP autre que les serveurs de filtrage désignés. Cela force tout le trafic DNS à passer par le résolveur contrôlé.

De plus, envisagez de bloquer le DNS over HTTPS (DoH). Le DoH chiffre la requête DNS au sein du trafic HTTPS sur le port 443, le rendant indiscernable du trafic web normal au niveau du réseau. La contre-mesure la plus efficace consiste à maintenir une liste de blocage des adresses IP des fournisseurs DoH connus (Cloudflare, Google, NextDNS) et à les bloquer au niveau du pare-feu.

Étape 3 : Définition de la politique et gestion des catégories

Établissez des politiques granulaires basées sur les exigences et l'audience du lieu. Une politique de base typique pour le WiFi public comprend le blocage des menaces de sécurité (logiciels malveillants, phishing, serveurs C2 de botnet), du contenu pour adultes et des activités illégales (piratage, streaming illégal). Dans des secteurs spécifiques, des catégories supplémentaires peuvent être appropriées : jeux de hasard et armes pour les établissements de santé , ou les médias sociaux pendant les heures de bureau pour les réseaux invités d'entreprise.

Étape 4 : Intégration du Captive Portal — Le jardin clos

C'est l'aspect le plus techniquement nuancé du déploiement. Les Captive Portals exigent que les invités s'authentifient avant de recevoir un accès complet à Internet. Pendant la phase de pré-authentification, l'appareil invité est dans un état restreint — il ne peut atteindre que le Captive Portal lui-même. Si le filtrage DNS est actif pendant cette phase, il peut bloquer les domaines externes requis pour la connexion sociale (Google OAuth, Facebook Login) ou les pages d'acceptation des conditions de service.

La solution est un jardin clos correctement configuré : un ensemble de domaines explicitement autorisés dans la politique de filtrage DNS avant que l'authentification ne soit complète. Cette liste doit inclure le propre domaine du Captive Portal, tous les domaines des fournisseurs d'identité OAuth et tous les points de terminaison CDN nécessaires pour afficher les ressources du portail. Ne pas configurer cela correctement est la cause la plus fréquente d'expériences d'intégration des invités défectueuses. Cette considération d'intégration s'applique également aux environnements de bureau, comme discuté dans Wi-Fi de bureau : Optimisez votre réseau Wi-Fi de bureau moderne .

Étape 5 : Personnalisation de la page de blocage et communication avec l'utilisateur

Fournissez des pages de blocage claires et personnalisées qui expliquent pourquoi le contenu a été restreint et offrent un moyen de demander une révision si le blocage est un faux positif. Cela réduit considérablement les tickets d'assistance et renforce l'engagement du lieu envers un environnement de navigation sécurisé. Une page de blocage bien conçue transforme une restriction en un point de contact de la marque.

Meilleures pratiques

Pour maximiser l'efficacité du filtrage DNS, respectez les recommandations standard de l'industrie suivantes.

Architecture haute disponibilité : Configurez des résolveurs DNS secondaires et tertiaires. Si le moteur de filtrage principal devient inaccessible, le trafic doit basculer de manière transparente vers un résolveur secondaire. Évitez de configurer le résolveur par défaut du FAI comme solution de secours, car cela contournerait entièrement le filtrage en cas de panne.

Audits réguliers des politiques : Examinez continuellement les journaux et les analyses pour identifier les faux positifs et les modèles de menaces émergents. Intégrez les journaux de requêtes DNS à votre plateforme WiFi Analytics pour corréler le comportement de navigation avec les métriques de performance du réseau.

Qualité du flux de renseignements sur les menaces : L'efficacité du filtrage DNS est directement proportionnelle à la qualité et à la fraîcheur du flux de renseignements sur les menaces. Évaluez les fournisseurs sur la fréquence des mises à jour du flux (horaire est la base ; en temps réel est préférable), l'étendue de la couverture des catégories et le taux de faux positifs.

Validation DNSSEC : Lorsque cela est pris en charge, activez la validation DNSSEC sur le résolveur de filtrage. Cela empêche les attaques par empoisonnement du cache DNS, où un attaquant injecte de faux enregistrements DNS pour rediriger les utilisateurs vers des sites malveillants.

Dépannage et atténuation des risques

Même avec une architecture robuste, des problèmes opérationnels surviennent. Voici les modes de défaillance les plus courants et leurs mesures d'atténuation.

Faux positifs : Domaines légitimes mal classés comme malveillants ou violant la politique. Maintenez un processus de gestion de liste blanche facilement accessible et un SLA de réponse rapide pour les rapports d'utilisateurs. Surveillez le rapport entre les requêtes bloquées et le total des requêtes ; un taux de blocage inhabituellement élevé est un indicateur fort de paramètres de politique trop agressifs.

Défaillance du Captive Portal : Comme décrit ci-dessus, cela est dû à des entrées manquantes dans le jardin clos. Diagnostiquez en capturant les requêtes DNS d'un appareil de test pendant la phase de pré-authentification et en identifiant les requêtes bloquées. Ajoutez ces domaines à la liste blanche de pré-authentification.

Dégradation des performances : Une infrastructure DNS inadéquate peut entraîner une navigation lente, se manifestant par des temps de chargement de page élevés plutôt que par des échecs purs et simples. Déployez des résolveurs de mise en cache locaux pour réduire la charge de requêtes sur les moteurs de filtrage en amont. Surveillez les temps de réponse des requêtes DNS ; tout ce qui dépasse 50 ms justifie une enquête.

Contournement du DoH : Si les analyses montrent du trafic vers des fournisseurs DoH connus malgré les règles de pare-feu, vérifiez que la liste de blocage des adresses IP des fournisseurs DoH est à jour et que les règles de pare-feu s'appliquent à tous les VLAN invités epoints d'accès.

ROI et impact commercial

Le retour sur investissement du filtrage DNS va bien au-delà de la simple atténuation des risques. Pour les établissements Hôtellerie , garantir un environnement familial a un impact direct sur la réputation de la marque et les Net Promoter Scores. Un seul incident où un client — en particulier un mineur — accède à du contenu inapproprié sur le réseau d'un établissement peut générer une exposition réputationnelle et juridique significative.

En bloquant le streaming illicite gourmand en bande passante, les établissements peuvent également optimiser les performances du réseau, retardant ainsi des mises à niveau d'infrastructure coûteuses. Dans un hôtel de 500 chambres où une proportion significative de clients diffusaient du contenu depuis des sites de piratage, le déploiement du filtrage DNS pour bloquer ces domaines peut réduire l'utilisation de la bande passante de pointe de 20 à 35 %, améliorant directement l'expérience de tous les clients et reportant la nécessité d'une capacité de liaison montante supplémentaire.

Du point de vue de la conformité, la démonstration de contrôles de sécurité réseau robustes est souvent une condition préalable à la certification PCI DSS et soutient le principe GDPR de protection des données dès la conception. Le coût d'un déploiement de filtrage DNS — généralement une fraction de centime par utilisateur et par mois pour les solutions basées sur le cloud — est négligeable comparé au coût potentiel d'une amende réglementaire ou d'un incident de sécurité nuisible à la marque.

Pour les équipes informatiques gérant des déploiements à haute fréquence sur plusieurs sites, la surcharge opérationnelle est minimale. Les solutions de filtrage DNS basées sur le cloud ne nécessitent aucun matériel sur site, mettent à jour automatiquement les informations sur les menaces et offrent une gestion centralisée des politiques sur des centaines d'emplacements à partir d'un tableau de bord unique.

Définitions clés

DNS Filtering

A security technique that intercepts DNS queries and evaluates them against policy and threat intelligence before resolving or blocking the requested domain.

The primary mechanism for content control on enterprise guest WiFi networks, operating at the network layer without requiring endpoint agents.

DNS Sinkholing

The practice of returning a false, non-routable IP address in response to a DNS query for a malicious or policy-violating domain, preventing the connection from being established.

Used to neutralise malware command-and-control traffic and prevent access to harmful sites without the user receiving a standard connection error.

Captive Portal

A web page that a user of a public-access network is required to interact with before full internet access is granted, typically used for terms acceptance, authentication, or data capture.

Crucial for guest onboarding and data collection; must be carefully integrated with DNS filtering to prevent the walled garden catch-22.

Walled Garden

A set of domains that are explicitly allowed in the DNS filtering policy during the pre-authentication phase, enabling the captive portal and authentication services to function before the user has accepted terms.

Misconfiguration of the walled garden is the most common cause of broken captive portal experiences in DNS-filtered guest networks.

Deep Packet Inspection (DPI)

A form of network packet filtering that examines the data payload of packets as they pass through an inspection point, enabling content-level analysis.

A more resource-intensive alternative to DNS filtering; impractical for high-throughput guest networks and unable to inspect encrypted HTTPS traffic without certificate interception.

DNS over HTTPS (DoH)

A protocol that encrypts DNS queries within HTTPS traffic, preventing network-level interception of DNS lookups.

Can be used to bypass traditional DNS filtering; administrators should block known DoH provider IPs at the firewall to maintain filtering coverage.

VLAN (Virtual Local Area Network)

A logical network segment that groups devices independently of their physical location, enforced at the switch or router level.

Essential for isolating guest WiFi traffic from internal corporate or operational networks, a prerequisite for PCI DSS compliance.

Threat Intelligence Feed

A continuously updated data stream containing information about known malicious domains, IP addresses, and URLs, used to power security systems.

The quality and freshness of the threat intelligence feed directly determines the effectiveness of a DNS filtering deployment against newly registered malicious domains.

DNSSEC (DNS Security Extensions)

A suite of IETF specifications that add cryptographic authentication to DNS responses, preventing cache poisoning and spoofing attacks.

Should be enabled on DNS filtering resolvers where supported to prevent attackers from injecting false DNS records to redirect users.

Exemples concrets

A 500-room luxury hotel chain needs to implement content filtering on their guest WiFi. They currently experience high bandwidth utilisation due to illegal streaming and have received complaints about inappropriate content accessible in public areas. They require a solution that does not impact the performance of their property management system (PMS) which shares the same physical infrastructure via VLANs.

Deploy a cloud-based DNS filtering solution. Configure the DHCP scope for the Guest WiFi VLAN to assign the cloud DNS filtering IPs as the primary and secondary resolvers. 2. Implement firewall rules on the gateway to block all outbound UDP and TCP traffic on port 53 from the Guest VLAN to any external IP other than the approved DNS filtering servers. 3. Create a content filtering policy blocking 'Adult Content', 'Piracy/Copyright Theft', 'Malware/Phishing', and 'Botnet C2'. 4. Configure a branded block page with the hotel's logo and a clear message. 5. Critically, ensure the PMS VLAN DHCP scope continues to use the internal DNS servers. The firewall rules blocking port 53 must be scoped exclusively to the Guest VLAN, not applied globally. 6. Monitor DNS query logs for the first 30 days to identify and resolve any false positives affecting legitimate guest services.

Commentaire de l'examinateur : This approach correctly isolates the guest traffic using VLANs, ensuring the critical PMS infrastructure is completely unaffected. The VLAN-scoped firewall rules are the key architectural decision — applying the port 53 block globally would break internal DNS resolution for operational systems. By blocking outbound port 53, it prevents users from bypassing the filter using custom DNS settings, addressing the most common vulnerability in public network deployments. The 30-day monitoring period is essential for tuning the policy and building confidence before escalating to stricter settings.

A large retail shopping centre wants to offer free public WiFi but must comply with strict family-friendly corporate policies. They also need to gather demographic data through a captive portal with social login options. How should they configure DNS filtering to support both requirements without breaking the onboarding flow?

Integrate the DNS filtering solution with the existing network gateway, assigning filtering DNS IPs via DHCP on the guest SSID. 2. Before applying any blocking policy, configure the walled garden. Add the following to the pre-authentication allowlist: the captive portal's own domain and CDN endpoints, Google OAuth domains (accounts.google.com, oauth2.googleapis.com), Facebook Login domains ( www.facebook.com , graph.facebook.com), and any other identity providers in use. 3. Apply the content filtering policy (adult, gambling, malware, piracy categories) to activate only after successful authentication. 4. Implement port 53 egress blocking on the guest VLAN. 5. Customise the block page with the retail centre's branding and a clear, friendly message about family-friendly browsing. 6. Test the complete onboarding flow with multiple device types (iOS, Android, Windows) before go-live.

Commentaire de l'examinateur : This scenario highlights the critical interaction between captive portals and DNS filtering. Failing to whitelist the authentication domains — the walled garden — would result in a broken onboarding experience where users cannot complete social login, generating high volumes of helpdesk contacts. The multi-device testing step is non-negotiable: different operating systems handle captive portal detection differently, and some will attempt DNS lookups to specific Apple or Google domains to verify connectivity. These must also be in the walled garden. The branded block page turns a restriction into a positive brand reinforcement, communicating the venue's commitment to a safe environment.

Questions d'entraînement

Q1. A stadium IT director reports that since deploying DNS filtering on the guest WiFi, guests are unable to complete the social login process on the captive portal. The portal uses Google and Facebook OAuth. What is the most likely architectural flaw and how would you resolve it?

Conseil : Consider what external resources are required during the pre-authentication phase, before the user has accepted the terms of service.

Voir la réponse type

The social login domains (accounts.google.com, oauth2.googleapis.com, www.facebook.com , graph.facebook.com) have not been added to the walled garden — the pre-authentication allowlist in the DNS filtering policy. The filter is blocking these queries because the user has not yet authenticated, creating a catch-22. The resolution is to explicitly add all required OAuth and identity provider domains to the pre-authentication allowlist, then re-test the full onboarding flow across iOS, Android, and Windows devices before re-deploying.

Q2. To improve network performance, a network architect proposes implementing a transparent HTTPS proxy to inspect all guest traffic instead of DNS filtering. Why is this approach fundamentally unsuitable for a public guest WiFi environment?

Conseil : Think about the requirements for inspecting encrypted HTTPS traffic and the nature of unmanaged guest devices.

Voir la réponse type

Transparent HTTPS inspection requires deploying a custom root certificate to every client device to perform a man-in-the-middle decryption of TLS traffic. On a managed corporate network this is achievable via MDM or Group Policy. On a public guest network, the venue has no control over guest endpoints, making certificate deployment impossible. Without the certificate, the proxy will generate severe TLS certificate warnings on every HTTPS site, completely breaking the browsing experience. DNS filtering is the correct approach for BYOD environments as it requires no endpoint agent or certificate.

Q3. A retail chain has deployed DNS filtering by assigning the filtering DNS IPs via DHCP on the guest SSID. Analytics show that a significant volume of adult content is still being accessed. What network configuration step was most likely missed, and what is the remediation?

Conseil : How might a technically capable user override the DNS settings assigned by DHCP?

Voir la réponse type

The network administrator failed to implement outbound firewall rules blocking port 53 (UDP and TCP) from the guest VLAN to any external IP other than the approved DNS filtering servers. Users with custom DNS settings hardcoded on their devices (e.g., 8.8.8.8) are bypassing the DHCP-assigned filtering resolvers entirely. The remediation is to add gateway firewall rules that redirect or drop all outbound port 53 traffic not destined for the filtering servers. Additionally, consider blocking known DoH provider IPs on port 443 to prevent encrypted DNS bypass.

Q4. A conference centre is planning a major international event. They expect 8,000 concurrent WiFi users over three days. Their current DNS infrastructure consists of a single on-premises filtering appliance. What architectural risks does this present and what changes would you recommend?

Conseil : Consider both performance capacity and availability. What happens if the single appliance fails or becomes overloaded?

Voir la réponse type

The single on-premises appliance presents two critical risks: a single point of failure (if it goes offline, all DNS resolution fails, taking down the entire guest network) and potential performance bottleneck under peak load. Recommendations: 1) Migrate to a cloud-based DNS filtering service with geographically distributed resolver infrastructure, capable of handling millions of queries per second. 2) Configure at least two resolver IPs in the DHCP scope (primary and secondary) pointing to different cloud resolver endpoints. 3) Implement local caching resolvers at the venue to reduce upstream query load and improve response times. 4) Conduct a load test prior to the event simulating peak concurrent users to validate the architecture.