Block DoH first: otherwise your DNS web filter is a suggestion

Part of our guide on why tech fails after update

Your DNS filter stops working when a browser chooses encrypted DNS. Close that gap, then compare coverage, consent, cost, and maintenance.

The best way to filter websites for employees starts with device ownership

A small office may need one filter for laptops, phones, and guest devices. No single layer sees or controls all three in the same way.

A router covers devices on your network, but it sees destination IP addresses rather than page content. A DNS resolver sees domain names, not HTTPS paths. An endpoint agent filters one device wherever it connects.

A browser policy controls one browser, while an MDM profile controls enrolled devices. Choose the layer after listing device ownership, travel needs, and the information you actually need.

Company hardware allows stronger controls. Personal hardware brings consent, privacy, and employment-law limits. For the detail, see our notes on compare coverage and price per GB.

• Router: covers the network and sees destination IP addresses.
• DNS resolver: classifies domain names but not complete HTTPS URLs.
• Endpoint agent: filters one managed device on and off the network.
• Browser policy: controls one browser and needs separate policies for other browsers.

Why DNS filtering fails when browsers use DoH

DNS over HTTPS, or DoH, sends lookups inside HTTPS traffic. A network DNS service cannot classify a lookup it never receives.

Do not rely on a supposed universal IP address. Each browser ships with its own set of DoH endpoints; enumerate them from the vendor's published list. Include Apple services separately if your network allows iCloud Private Relay.

Create an egress rule for each current endpoint on TCP and UDP port 443, where your firewall supports both. A generic rule might read: “Deny outbound TCP/UDP 443 to approved DoH endpoint objects from employee VLANs.” It helps to understand iPhone content restrictions for kids before going further.

New endpoints and browser changes create maintenance work. Review firewall logs monthly, then update the endpoint group after checking the vendor documentation.

Managed laptops and phones need different controls

Apple and Android expose named management controls, but enrollment decides what they can enforce. On Apple devices, use the DNS Settings payload for approved resolvers and the Web Content Filter payload for site restrictions.

A supervised iPhone or iPad can receive stronger restrictions through an MDM service. A personally owned device usually needs user-approved enrollment, and the worker must understand the scope before accepting it. We go through troubleshooting pi-hole after vpn connects step by step elsewhere on the site.

Android Enterprise work profiles can separate work applications from personal applications. A managed configuration or always-on VPN can cover work traffic, while a fully managed company device permits wider controls.

Do not promise silent filtering on a personal phone. Explain the purpose, data collected, retention, and removal process before enrollment.

Browser policies need a real deployment method

A policy file is not universal. Windows commonly uses registry-based Chrome Enterprise policies, macOS uses managed preference plists, and Linux Chrome deployments use JSON policy files. Before you commit to anything, it is worth looking at how to improve email deliverability for campaigns.

For Chrome on Windows, an administrator can deploy the Chrome Enterprise policy that disables the built-in DNS client, then enforce the approved resolver through the operating system or network. Confirm the exact policy name in Google's current enterprise documentation.

For Firefox, deploy enterprise policies through the Windows registry, a macOS plist, or a Linux policies.json file. A representative JSON structure is: {"policies":{"DNSOverHTTPS":{"Enabled":false}}}. Validate the syntax against Mozilla's current schema before rollout.

Mobile browsers are an exclusion unless the device is enrolled and the platform supports the relevant profile. A desktop browser policy will not control a personal phone. It helps to understand how to know if slow internet is router or isp before going further.

HTTPS inspection needs a certificate and a legal reason

DNS filtering gives you domain-level control. Full URL and page-content inspection requires a proxy that decrypts and re-encrypts HTTPS traffic.

Every managed device must trust the proxy's root certificate. Certificate-pinned banking, healthcare, and messaging apps can fail even when the certificate installation succeeds.

Use inspection only for a documented purpose. GDPR requires a lawful basis, transparency, data minimisation, and retention limits in relevant workplaces. A works council may need consultation before monitoring begins. It helps to understand windows license oem or retail before going further.

A DPIA can record the purpose, affected workers, data fields, access controls, and deletion schedule. ISO 27001 controls can support access and audit processes, but certification does not replace local employment law.

Logging needs a written retention choice

A blocked-domain log can show a timestamp, device, account, and category. It does not prove what appeared on the page, and shared devices can make attribution uncertain.

A 30-day raw-log window is a policy recommendation, not a universal rule. Choose it only after a DPIA, privacy review, and any local works-council process. Some jurisdictions require shorter retention or stronger notice.

Record the reason for retention, who can access logs, and how deletion works. Review a sample each month, then delete records when the approved window ends.

GDPR transparency duties and local labour rules can limit monitoring without notice. Tell employees what is filtered, what is logged, and whether personal browsing is included.

• Device identifier: links an event to a machine without assuming a person used it.
• Account: supports attribution when accounts are individual and current.
• Timestamp: shows patterns without collecting page content.
• Domain and category: often enough for enforcement and review.

Cost and false positives decide the total price

Vendor prices change, so compare a current quote rather than trusting an old article. Ask for per-user or per-device pricing, minimum seats, setup fees, support tiers, and log-storage charges.

A small DNS service may cost less per user than an endpoint platform, but it stops at the office network. An agent can cover travelling laptops, yet it adds deployment, troubleshooting, battery impact, and offboarding work.

Calculate total cost as licences plus administrator hours, help-desk tickets, policy maintenance, certificate work, and legal review. Track those hours for one month during a pilot before signing a longer contract.

False positives are the operational cost people notice first. A blocklist can misclassify shared hosting, URL shorteners, translations, or newly registered domains. Record every override and review the top repeated complaints.

TLS ClientHello inspection is the fallback when DNS fails

Some traffic will bypass DNS controls entirely. A firewall can inspect the TLS ClientHello and use the server name indication, or SNI, to classify destinations before encryption hides the HTTP request.

SNI inspection still cannot reveal the full URL or page content. Encrypted ClientHello can hide the server name, and some applications use certificate pinning or private protocols.

Use SNI rules only where local law, notice, and technical testing support them. A representative rule might read: “Deny outbound TLS to SNI category Gambling from managed employee VLANs,” with an approved exception process.

Do not treat SNI as a replacement for an endpoint agent on travelling laptops. It belongs at a network enforcement point and needs testing against business applications.

Test every path before you call the filter finished

An office desktop test proves only one path. Test managed and unmanaged browsers, mobile data, guest networks, and a clean device before deployment.

Record the expected result, actual result, and layer responsible. Track false positives during the pilot, then adjust categories before employees depend on the service.

A failure rate is specific to your blocklist and users. Measure it by dividing confirmed false-positive events by blocked events during the pilot. Keep the sample period and event definitions with the result.

Repeat the test after browser, MDM, firewall, and resolver changes.

1. Turn off Wi-Fi on a phone and test a blocked domain on mobile data.
2. Open the domain in a guest or private browser window.
3. Install a clean browser and check its managed policy status.
4. Test a company laptop away from the office network.
5. Record bypasses, false positives, and support time.
6. Review the result against your written privacy and access policy.

Questions people still ask

I have set up filters on home routers, school networks, and company laptops. The mobile-data test still reveals gaps that office testing misses.