Should you block DNS over HTTPS? Stopping encrypted DNS bypass

Why DNS over HTTPS is a bypass risk

Protective DNS and DNS filtering work by answering, or refusing to answer, the lookups devices send to your resolver. DNS over HTTPS lets a browser, app or piece of malware send its lookups to a different resolver, inside ordinary HTTPS on port 443. When that happens:

• your security and content policies are not applied to those lookups
• your DNS logs, and any SIEM alerts built on them, miss them
• blocking port 53 at the firewall does not help, because DoH does not use it
• in schools, pupils may reach content the filter is meant to block

Malware can do the same. A device infected with something that resolves its command-and-control domains over DoH to an outside resolver hides that activity from DNS-based detection. That makes DNS tunnelling and DNS exfiltration harder to spot as well.

What the NCSC recommends

The NCSC's guidance on protective DNS for the private sector includes a short section on preventing circumvention. In summary, it says organisations should:

• consider how to prevent end users and client applications, such as browsers, from using different DNS resolvers
• configure firewalls to block outbound DNS requests on port 53 or 853 that do not go via the protective DNS resolver
• ensure DNS over HTTPS is either disabled on client operating systems, or configured to go via the protective resolver in a way that still allows logging
• manage this through Group Policy for Microsoft systems, mobile device management and allow and deny lists for applications, as part of the general management of end user and remote devices

So the NCSC does not insist on blocking DoH outright. It accepts encrypted DNS as long as it goes to your protective resolver and you keep the logs. That is the approach we recommend too: encrypted where it should be, blocked where it should not.

A practical plan to stop encrypted DNS bypass

No single control closes every gap, so work through the layers in order:

1. Choose the resolver everything should use. That is your protective DNS service, or internal DNS servers that forward to it.
2. Set browser policies. Use the DoH policies for Chrome and Edge (DnsOverHttpsMode, with off or your own DoH template) and Firefox's DNSOverHTTPS policy, deployed through Group Policy or MDM. See secure DNS for what each does.
3. Set operating system policies. On Windows, use the DNS Client Group Policy to prohibit DoH, or allow it only to resolvers you have added. On Android, manage Private DNS through MDM.
4. Lock down the firewall. Allow outbound port 53 and 853 only from your DNS servers or to your protective resolvers, and block it from everything else. Consider UDP 853 too, which DNS over QUIC uses.
5. Block known third-party DoH services. Use your DNS or web filter's category for encrypted DNS and filter avoidance, so devices cannot resolve the names of public DoH servers. In Cisco Umbrella, the Low content preset already includes encrypted DNS and filter avoidance.
6. Cover devices off site. Install a roaming agent so laptops use the protective resolver at home and on public Wi-Fi. See DNS roaming clients.
7. Watch for what slips through. Review blocked DoH lookups and unusual outbound HTTPS to resolver addresses, and retest regularly with the checks in our DNS security test guide.

Steps 2 and 3 handle managed devices. Steps 4 and 5 handle apps, unmanaged browsers and guest devices that ignore policy. Step 6 handles everything that leaves the building.

Signs that DoH is bypassing your filter

Before you change anything, it helps to know whether encrypted DNS is already escaping. Useful signs to look for:

• a device appears in firewall or proxy logs browsing actively, but sends few or no lookups to your protective resolver
• blocked test domains load in one browser on a device but not in another, which points to a browser using its own Secure DNS
• your DNS filter shows lookups for the names of public DoH services, a sign that browsers or apps are trying to reach them
• outbound connections on port 853 from devices rather than from your DNS servers, which suggests DNS over TLS or DNS over QUIC
• internal names failing to resolve in one browser only, a common side effect of a browser resolving through an outside provider

None of these proves a bypass on its own, but together they tell you where to look. Our DNS security test guide sets out a repeatable way to check each device type.

Blocking known DoH services by category

Because DoH runs on port 443, you cannot block it by port. What you can do is stop devices finding the DoH servers in the first place. Before a browser can send DoH to a public resolver, it usually has to look up that resolver's name, and that lookup goes through your DNS. If your protective DNS refuses to resolve known DoH services, the browser cannot reach them by name, and in Chrome's default automatic mode it falls back to normal DNS.

Most protective DNS services we supply include a category for this. Cisco Umbrella's content categories include encrypted DNS and filter avoidance, and the Low preset turns them on; the Cisco Umbrella content categories page has the detail. Other services use their own category names, so check the current list when you set up policy.

Category blocking is not complete. A determined app can hard-code a resolver's IP address and skip the name lookup altogether. That is why firewall rules, endpoint protection and device policies sit alongside it, and why a proxy or secure web gateway can add another layer where you need page-level control (see DNS filtering vs URL filtering).

Off-site devices and roaming agents

Firewall rules only apply on your network. A laptop at home or on hotel Wi-Fi follows whatever its own settings and the local network say. The answer is a roaming agent from your protective DNS provider, which keeps lookups going to the protective resolver wherever the device is. Several of these use encrypted DNS themselves: the NCSC's PDNS Roaming uses DoH, Webroot's DNS Protection agent supports DoH, and Sophos's endpoint DNS Protection forwards lookups over HTTPS.

That gives you the best of both: encrypted lookups on untrusted networks, sent to a resolver that applies your policy and keeps your logs. Our DNS roaming client guide compares the agents, including the Cisco Secure Client roaming module and DNSFilter's roaming clients.

Schools: what the UK Safer Internet Centre expects

For schools, this is not just good practice. The UK Safer Internet Centre's appropriate filtering definition lists circumvention as a system feature to consider: the extent and ability to identify and manage technologies used to get round the filter, naming VPNs, proxy services, DNS over HTTPS and ECH. It also warns that relying solely on network-level filters may become increasingly challenging, and suggests combining network filtering with device-level configuration on school-owned devices.

In practice that means the same plan as above, plus a check of pupil devices off site. Our web filtering for schools guide covers the wider requirements and our school web filter test guide covers testing. For Encrypted Client Hello, the other technique the definition names, see our dedicated page.

How we help

Forever Systems can review where encrypted DNS is escaping your controls today and help you close the gaps without breaking legitimate encryption. We can help with browser and Windows policies, firewall rules for ports 53 and 853, DoH category blocking in your protective DNS, and roaming agents for laptops, using services such as Cisco DNS-layer security, DNSFilter, Webroot DNS Protection and others we supply.

Contact us to arrange a conversation. What we deliver is confirmed at quote, and pricing depends on your devices and the service you choose, so ask us for a quote.