A whitelist (allowlist) environment is the most restrictive form of content filtering -- it blocks all websites by default and only permits access to domains you explicitly approve. This guide shows you how to set it up with CleanBrowsing.
Get Started
A whitelist (or allowlist) environment blocks access to all websites by default and only permits access to domains you explicitly approve. This is the most restrictive filtering approach -- instead of blocking bad sites and allowing everything else, you block everything and allow only what is needed.
This inverted approach is fundamentally different from standard DNS filtering, where specific categories of content are blocked while the rest of the internet remains accessible. In a whitelist environment, the default state is "denied" and every allowed domain must be explicitly approved by an administrator.
Whitelist environments are not suitable for general-purpose browsing, but they are the right choice for specific scenarios where tight control is required:
The whitelist approach requires more upfront configuration than category-based filtering, but it provides the strongest possible control over what can be accessed from your network. It is available on all CleanBrowsing paid plans.
Setting up a whitelist environment in CleanBrowsing is straightforward. The configuration is done entirely through the CleanBrowsing dashboard -- no command-line work or special hardware is required.
Once enabled, only the domains you have listed (plus my.cleanbrowsing.org for dashboard access) will be accessible. All other domains will be blocked and users will see your configured block page.
It is important to note that the "Block Everything" option applies to all DNS queries from networks associated with that profile. If you need some users to have whitelist-only access while others have standard filtered access, you can create separate profiles with different filtering policies and assign them to different network segments or IP addresses.
After enabling the whitelist, test it immediately by trying to access a domain that is not on your allowlist. You should see the block page. Then verify that your approved domains load correctly. This initial testing helps catch configuration issues before rolling out to users.
Start with the domains your users actually need. The goal is to be comprehensive enough that users can do their work without being blocked on legitimate resources, while keeping the list as short as possible to maintain control.
Tip: Review your CleanBrowsing activity logs before switching to whitelist mode. The logs show which domains are being queried, helping you identify all the domains your users regularly access. This data-driven approach helps you build a comprehensive allowlist without guesswork.
Another effective technique is to enable whitelist mode and then monitor the blocked queries in your dashboard. As users report issues, you can review the blocked domains and add legitimate ones to the allowlist. This iterative approach works well in environments where you are not sure exactly which domains are needed.
A whitelist environment requires ongoing maintenance. Here are the practices that will keep your configuration effective and your users productive:
Begin by monitoring which domains users need in normal filtered mode. Review the DNS activity logs to understand traffic patterns. Once you have a solid list of required domains, switch to whitelist mode. This phased approach minimizes disruption and reduces the number of urgent allowlist additions after deployment.
Many websites depend on third-party domains for fonts, scripts, APIs, analytics, and media. For example, a website might load JavaScript from a CDN, fonts from Google Fonts, and images from an image hosting service. If any of these third-party domains are blocked, the primary website may not function correctly even though its domain is on the allowlist. Use browser developer tools (F12 > Network tab) to identify all domains a website loads resources from.
A whitelist is only effective if users cannot bypass it. Combine whitelist DNS with locked DNS settings to prevent users from changing their DNS configuration to a different resolver. See our guide on how to disable DoH to prevent browser-level DNS bypasses, and our guide on configuring standard user accounts on Windows to prevent system-level DNS changes. For router-level protection, use firewall rules to redirect all DNS traffic (port 53 and port 853) to CleanBrowsing's resolvers.
Your allowlist is a living document. Review it regularly as needs change -- new platforms may be adopted, old ones retired, and infrastructure domains may change. Set a schedule (monthly or quarterly) to review the allowlist and the blocked query logs to ensure the configuration still meets your organization's needs.
For environments with multiple administrators, document why each domain was added to the allowlist. This prevents confusion when reviewing the list later and makes it easier to remove domains that are no longer needed.