What is Guest WiFi Filtering?

• Legal liability: Businesses can be held responsible for illegal activity conducted on their network. Filtering reduces exposure to liability from piracy, illegal downloads, or accessing CSAM
• Brand safety: An unfiltered guest WiFi where visitors can access explicit content in a restaurant, hotel, or library creates an uncomfortable environment and damages the brand
• Malware protection: Blocking known malware and phishing domains protects guest devices and prevents compromised devices from communicating with command-and-control servers on your network
• Bandwidth management: Blocking high-bandwidth categories like streaming and file sharing preserves bandwidth for legitimate guest use
• Compliance: Organizations receiving E-Rate funding must provide CIPA-compliant filtering on all networks, including guest WiFi

DNS filtering on guest WiFi networks is straightforward:

• DHCP configuration: The guest WiFi VLAN's DHCP server is configured to hand out CleanBrowsing's DNS resolver addresses to connecting devices
• Automatic enforcement: When a guest device connects, it receives the filtered DNS servers automatically — no app or profile installation needed
• Query filtering: Every DNS query from guest devices goes through CleanBrowsing, which applies your configured blocking categories
• Firewall lockdown: Firewall rules redirect all port 53 traffic to CleanBrowsing, preventing guests from using their own DNS servers to bypass filtering

For the website and infrastructure side, NOC.org provides authoritative DNS, CDN, and WAF services that protect the websites your guests visit — while CleanBrowsing controls which websites they can access.

A captive portal is the login or splash page that appears when you first connect to a public WiFi network — the "accept terms" or "enter your email" screen at hotels, airports, coffee shops, and libraries. Captive portals work by intercepting DNS queries and HTTP requests, redirecting them to the portal page until the user completes authentication.

This creates a direct interaction with DNS filtering that businesses need to understand before deployment.

How Captive Portals Use DNS

When a device connects to a WiFi network with a captive portal, the following happens:

• DNS interception: The captive portal temporarily hijacks DNS queries, responding with its own IP address instead of the real answer. This forces the browser to load the portal page
• Device detection: Apple, Google, and Microsoft devices automatically test for captive portals by requesting specific URLs (e.g., captive.apple.com, connectivitycheck.gstatic.com, www.msftconnecttest.com). If the response is redirected, the device displays the portal login
• Post-authentication: Once the user accepts terms or logs in, DNS queries are released to the configured DNS resolver — this is where CleanBrowsing's filtering takes over

Common Issues When Combining Captive Portals with DNS Filtering

• Detection domain blocking: If your DNS filter blocks the captive portal detection domains (Apple, Google, Microsoft connectivity check URLs), devices won't detect the portal and will show "no internet connection" instead of the login page
• HTTPS redirect failures: Modern browsers use HTTPS by default. Captive portals can't intercept HTTPS traffic without triggering certificate errors, which can confuse users into thinking the network is broken
• Encrypted DNS bypass: Devices with DNS over HTTPS (DoH) enabled will bypass the captive portal's DNS interception entirely, meaning the portal never loads. This is why many networks need to disable DoH on the guest network
• Double filtering conflicts: If the captive portal appliance has its own DNS filtering and you're also using CleanBrowsing, the two systems can conflict — queries may timeout or return inconsistent block pages

Best Practices for Captive Portals with DNS Filtering

• Order of operations: Configure the captive portal to handle authentication first, then forward DNS to CleanBrowsing. The portal's DHCP should hand out CleanBrowsing resolvers so filtering is automatic post-login
• Allowlist detection domains: Add Apple, Google, and Microsoft captive portal detection domains to your allowlist so device detection works properly
• Use CleanBrowsing for filtering, not the portal: Disable any built-in content filtering on the captive portal appliance. Let CleanBrowsing handle all DNS filtering to avoid conflicts and give you centralized control
• Block DoH on the guest VLAN: Prevent devices from bypassing both the captive portal and DNS filtering by blocking outbound DoH traffic with firewall rules
• Test the full flow: After setup, test with iOS, Android, Windows, macOS, and Chromebook devices to confirm the captive portal appears correctly and DNS filtering activates after login

Most enterprise WiFi controllers (Aruba, Meraki, UniFi, Ruckus) support configuring custom DNS servers alongside captive portals. Check your controller's documentation for the specific DHCP and DNS settings, or see our WiFi service provider guide for deployment patterns.

• Separate VLANs: Always isolate guest WiFi from your internal network using VLANs — filtering alone doesn't provide network segmentation
• Appropriate filter levels: Use CleanBrowsing's Family Filter for family-friendly venues or the Security Filter for business environments where you only need malware/phishing protection
• Block DNS bypass: Configure firewall rules to prevent guests from using alternate DNS servers, VPNs, or proxies to circumvent filtering
• Friendly WiFi certification: UK venues can apply for Friendly WiFi certification, which requires verified content filtering on public networks
• Monitor and adjust: Review DNS logs to identify false positives or categories that need adjustment for your specific use case

See our solution guides for WiFi service providers, retailers and restaurants, municipalities, and transportation for deployment patterns specific to each industry.