DNS over HTTPS and web filtering
Encrypted DNS protects lookups from snooping and tampering. It can also send them straight past the DNS filter your network relies on. This guide shows how both goals can live together.
Filter stays in the path
Lookups are private on the wire and still checked against category policy.
Filter is bypassed
Lookups never reach your resolver, so DNS-layer policy does not apply.
Encrypted DNS in brief
Classic DNS travels in plain text on port 53. Anyone on the path can read which names a device looks up, and in some cases change the answers. Encrypted DNS wraps the lookup in a secure transport so it cannot be read or altered in transit.
For filtering, the important question is not whether DNS is encrypted. It is which resolver receives the encrypted lookup. If it is yours, policy still applies. If it is someone else's, your DNS filter never sees the request.
Classic plain-text DNS. Easy to filter and redirect, offers no privacy in transit.
DNS over TLS, RFC 7858. Encrypted on its own port, so networks can spot and manage it.
DNS over HTTPS, RFC 8484. Looks like ordinary web traffic, which makes it hard to tell apart.
DNS over QUIC, RFC 9250. Encrypted with low latency, still less common in practice.
Why encrypted DNS is a good thing
- Stops others on public Wi-Fi from reading which sites you visit
- Prevents lookups being changed in transit to send users to fake sites
- Makes tracking by network operators harder
- Works well with filtering when the resolver is the right one
Why filtering teams pay attention
- Apps can choose a resolver without the network knowing
- DoH on port 443 looks like ordinary web traffic
- Threat blocks at the DNS layer stop working for those apps
- Logs lose the lookups that help find infected devices
How encrypted DNS arrived
| Year | Standard | What it added |
|---|---|---|
| 2016 | DNS over TLS (RFC 7858) | Encrypted lookups on a dedicated port, mainly between devices and resolvers |
| 2018 | DNS over HTTPS (RFC 8484) | Lookups inside HTTPS, which browsers could adopt without operating system changes |
| 2022 | DNS over QUIC (RFC 9250) | Encrypted lookups over QUIC for lower latency |
| 2023 | Resolver discovery (RFC 9462, RFC 9463) | Ways for networks to tell devices about their own encrypted resolver |
| Recent | Encrypted Client Hello (RFC 9849) | Hostname hidden in the TLS handshake, relying on DNS for keys |
The aim is not to fight encryption. It is to make sure encrypted lookups land on a resolver that applies the policy the organization, school or household chose.
If you need a refresher on the filtering side, what is DNS filtering covers how category checks work at lookup time.
Three situations you will meet on real networks
Encrypted DNS is not one problem. Devices behave differently depending on who configured them, and each case needs a different response.
App picks its own resolver
A browser or app has encrypted DNS enabled with a built-in public provider. Lookups go there directly, and your DNS filter is skipped.
Response: device policy, network signals and endpoint blocking.
Upgrade to the same provider
Some software only switches to encrypted DNS if the resolver it already uses supports it. If that resolver is your filter, policy still applies.
Response: offer an encrypted endpoint on your own resolver.
Network tells devices its encrypted resolver
Newer standards let a network advertise its own encrypted resolver, so devices encrypt lookups to it automatically.
Response: publish your endpoint through DHCP, router advertisements or resolver discovery.
Standards to know: Discovery of Designated Resolvers (RFC 9462) lets a device ask its current resolver for an encrypted alternative. DHCP and router advertisement options for encrypted DNS (RFC 9463) let a network announce one directly. Support varies by operating system, so check current versions.
Does DNS over HTTPS bypass web filtering?
It depends on which layer does the filtering. DoH only affects the DNS step. Filters that work on the connection itself are not affected by how the name was looked up.
In practice, the networks most exposed are those that rely on DNS filtering alone: homes, small offices, guest Wi-Fi and many schools. Larger sites with a gateway or agents lose some visibility but keep enforcement.
| Filtering layer | Affected by outside DoH? | Why |
|---|---|---|
| Network DNS filter | Yes | The lookup never reaches it |
| Router with built-in DNS filtering | Yes | Same reason, unless the router also filters connections |
| Firewall with hostname or SNI rules | Mostly no | It reads the hostname from the TLS handshake, until Encrypted Client Hello hides it |
| Secure web gateway or proxy | No | Explicit proxies receive the hostname in the request itself |
| Endpoint agent | No, if designed for it | It sees connections on the device before they leave |
| Browser extension | No | It sees the URL inside the browser |
Encrypted Client Hello: the next step
Encrypted DNS hides the lookup. Encrypted Client Hello, now standardized as RFC 9849, hides the hostname in the TLS handshake as well. Together they leave a passive network device with little more than an IP address, often a shared CDN address.
Encrypted Client Hello depends on keys published through DNS. If devices use your resolver, you control what they learn, and policy keeps working. That makes "use our resolver" the foundation for every other layer, not just the DNS filter.
This is one reason many teams layer DNS filtering with a URL-aware control. The trade-offs are covered in DNS filtering vs web filtering, and the inspection side in SSL inspection and URL categories.
How to keep DNS filtering working with encrypted DNS
No single setting solves this. A layered approach covers managed devices, unmanaged guests and apps that hard-code their own resolvers. Work from the top of the list down, since the first two layers carry most of the weight.
Run DoH and DoT endpoints on your filtering resolver. Devices that want encryption get it, and policy still applies. This removes most of the reason to bypass.
On managed devices, use browser and operating system policy to set your encrypted resolver or turn off app-level DNS. This is the most reliable control.
Some browsers check a canary domain, use-application-dns.net, before enabling encrypted DNS by default. Returning no answer for it tells them the network filters DNS.
Block well-known public DoH hostnames at your resolver, and their addresses at the firewall. Block outbound port 853 except from your resolvers.
Block the VPN / Proxy / Anonymizers category, because a VPN carries DNS out with everything else.
For laptops and phones that leave the network, an agent or managed encrypted DNS profile keeps lookups on your resolver from anywhere.
Policy settings to look for on managed devices
| Setting type | What to set | Effect |
|---|---|---|
| Browser encrypted DNS mode | Off, or on with your resolver's DoH address | The browser stops using a built-in provider |
| Browser DoH template | Your endpoint URL, per tenant if needed | Encrypted lookups go to your filter |
| Operating system encrypted DNS | Your resolver address with its DoH or DoT name | All apps that use the system resolver are covered |
| Lock against user changes | Enforced policy rather than default | Users cannot switch it back |
| Privacy relay features | Disabled on managed devices if policy requires | Lookups and traffic stay on your path |
Operating system privacy relays: some platforms offer relay features that route lookups and traffic through outside servers. They publish documented ways for networks to signal that the relay is not available, and device management can disable it. Check the current platform guidance.
A category for encrypted DNS resolvers
Public DoH endpoints are just hostnames. Blocking them by name works best when your category data identifies them, together with proxies and anonymizers, and keeps that list current as new ones appear.
What to block at your resolver
- Public DoH and DoT resolver hostnames not under your control
- Web proxies and anonymizer sites
- VPN service domains used for sign-in and configuration
- Remote access tools not approved by IT
- Newly registered domains for strict groups
What to block at the firewall
- Outbound UDP and TCP 53 from anything but your resolvers
- Outbound TCP and UDP 853 from anything but your resolvers
- Known address ranges of public encrypted resolvers
- Common VPN protocols for restricted groups
- UDP 443 where you need inspectable TCP instead
Why category data beats a static list
Fresh resolvers, proxies and VPN brands appear every week. About 300,000 newly registered domains are categorized daily, so new ones pick up a label quickly.
Services change hostnames and add mirrors. Monthly refreshes of the full set keep existing entries accurate.
Some domains host both a resolver and ordinary content. Ranked categories show which use dominates, so rules can be precise.
Data runs inside your resolver as files, so blocking decisions need no outside lookup at all.
For step-by-step guides, see how to block VPN apps, how to block proxy sites and how to block Tor. Lists can be exported for resolvers in the formats described in blocklist formats.
Encrypted DNS by device type
The right control depends on whether you manage the device. Guests and personal phones need network-level measures, company devices can be configured directly.
Most networks have all of these at once. Start with the group that carries the most risk for your organization, often managed laptops for businesses and student devices for schools, then work down the table.
| Device | Main risk | Best control |
|---|---|---|
| Managed laptops | Browser DoH to an outside provider | Browser and OS policy pointing to your encrypted resolver |
| Managed phones and tablets | App-level resolvers, relay features | Device management DNS profile and relay settings |
| School devices | Students switching settings or using proxies | Locked policy, extension or agent, anonymizer category blocked |
| Guest and personal devices | Any setting, no management | Network signals, outside resolver blocking, anonymizer category |
| Smart TVs and IoT | Hard-coded resolvers in firmware | Firewall redirect of port 53, address blocking of public resolvers |
| Servers | Rarely an issue | Point to internal resolvers, restrict outbound DNS |
Public and guest networks have their own constraints, covered in guest Wi-Fi content filtering.
Running your own filtered DoH resolver
For MSPs, ISPs and filtering vendors, offering an encrypted endpoint is now a standard expectation. Customers want privacy in transit and the policy they pay for. The setup has a few parts.
Terminate DoH and DoT
Put an HTTPS front end and a TLS listener in front of the resolver, with valid certificates for your endpoint names.
Identify the customer
Plain DNS uses the source address. Encrypted endpoints can use a path or hostname per customer or device, which works even behind shared addresses.
Load category data locally
Hold the domain category database in memory next to the resolver, so each check adds almost no delay.
Apply policy and answer
Return real answers, block page addresses or empty answers according to the customer's category rules.
Advertise the endpoint
Use resolver discovery or network options where supported, and provide device profiles for managed fleets.
Monitor and update
Load daily new-domain deltas and the monthly refresh, and watch query volume per customer for capacity planning.
Notes for ISPs
- Offer encrypted endpoints for subscribers who opt into family filtering
- Use a per-subscriber endpoint name so policy follows the account, not the address
- Keep unfiltered encrypted resolvers available for everyone else
- See ISP-level content filtering
Notes for MSPs
- Give each client its own DoH path for clean reporting
- Push the endpoint with device management during onboarding
- Include outside-resolver blocking in the standard firewall template
- Report devices that stop sending lookups as a health alert
Our hosted option is described on the managed DNS filter page. Vendors who embed category data in their own resolvers can read about OEM licensing.
A quick audit: is encrypted DNS bypassing your filter?
Run these checks from a test device on each network segment. They take less than an hour and show where to act first. Repeat them after major browser or operating system updates, since defaults can change.
Checks
- Look up a known blocked test domain in a browser with default settings
- Turn on the browser's encrypted DNS option and try again
- Query a public resolver directly on port 53 and 853
- Open a public DoH resolver's web endpoint
- Connect a common VPN app and try the test domain
- Repeat on guest Wi-Fi and on a phone
What to look at in the logs
- Devices that stopped sending any DNS to your resolver
- Connections to known resolver addresses on port 443
- Lookups for public DoH hostnames
- Traffic in the anonymizer and VPN categories
- Spikes of UDP 443 from devices you expect on TCP
If the test domain loads in any of these tests, you have found a gap. Fix the device or network control for that path, then retest.
Four myths about DoH and filtering
"DoH makes filtering impossible"
Filtering still works when encrypted lookups reach your resolver. Most of the work is making sure they do.
"Block port 443 to stop DoH"
That blocks the web. Block known resolver hostnames and addresses instead, and manage device settings.
"Only browsers use DoH"
Operating systems, apps, games and IoT firmware can all use encrypted DNS, sometimes with resolvers built in.
And the fourth: "turning encryption off is the safe choice." Plain DNS on a shared network can be read and altered by anyone on the path. Encrypted lookups to your own filter give the best of both.
Frequently asked questions
What is DNS over HTTPS?
DNS lookups carried inside encrypted HTTPS connections, usually on port 443, as defined in RFC 8484. It protects lookups in transit.
Does DNS over HTTPS bypass web filtering?
It bypasses DNS-based filtering when an app uses its own outside resolver. It does not when the encrypted resolver is your filtered one.
How do I stop DoH from bypassing my DNS filter?
Use device policy, network signals, block outside resolvers and the anonymizer category, and offer your own filtered encrypted endpoint.
What is the difference between DoH and DoT?
DoT uses its own port, 853. DoH runs inside HTTPS on 443 and blends with web traffic, which makes it harder to manage.
Should I disable DNS over HTTPS?
On managed networks, point devices to your own resolver over an encrypted transport instead. You keep privacy in transit and your policy.
Can a URL filter still work if DNS is encrypted?
Yes. Proxies, firewalls and agents read the hostname from the connection. Encrypted Client Hello is the bigger challenge for those layers.
Can we license your data for an encrypted DNS service?
Yes. Starter database tiers from $999; enterprise and OEM licences are quoted per deployment. Licensed customers can export RPZ and other resolver formats.
Encrypted lookups, consistent policy
Run 120 million categorized domains inside your own DoH and DoT resolvers, with daily new-domain updates.