DNS Over HTTPS (DoH): Implications for Public WiFi Filtering

Welcome to the Purple Technical Briefing. I'm your host for today's session, and we're going to spend the next ten minutes on a topic that's quietly undermining content filtering policies across thousands of public WiFi deployments right now — DNS over HTTPS, or DoH. If you're running guest WiFi at a hotel, a retail estate, a stadium, or a public sector facility, and you haven't specifically addressed DoH in your network architecture, there's a reasonable chance your filtering policy has a significant gap in it. Let's work through exactly what that gap is, why it matters, and what you can do about it. Section one — context and the problem statement. Let's start with a quick recap of how traditional DNS filtering works, because understanding the bypass mechanism requires understanding what's being bypassed. When a guest device connects to your WiFi and tries to visit a website, the first thing it does is send a DNS query — essentially asking what's the IP address for this domain? That query travels over UDP or TCP on port 53. Your network infrastructure intercepts that query, routes it to your chosen DNS resolver, and that resolver checks the domain against your filtering policy. If the domain is on a blocklist — malware, adult content, gambling, whatever your acceptable use policy specifies — the resolver refuses to return the IP address, and the connection never happens. This is the foundation of every DNS-based content filtering deployment. It's cost-effective, it doesn't impact throughput, and it's been the standard approach for venue operators for the better part of a decade. DNS over HTTPS breaks this model. Here's how. DoH wraps DNS queries inside standard HTTPS traffic on port 443. From your network's perspective, it looks identical to any other encrypted web traffic. There's no way to distinguish a DoH query from a user loading a webpage, streaming a video, or accessing a banking app. The query goes directly to an external DoH resolver — Google's 8.8.8.8, Cloudflare's 1.1.1.1, or any number of others — over an encrypted channel that your DNS filter cannot inspect. The result? Your carefully configured DNS filtering policy is completely bypassed. The device resolves the domain directly, without your resolver ever seeing the query. Now, this isn't a deliberate attack by your guests. In most cases, it's entirely passive. Firefox has had DoH enabled by default since 2020. Chrome auto-upgrades DNS queries to DoH if the configured resolver supports it. Android 9 and above supports Private DNS with DNS over TLS by default. iOS has supported DoH configuration profiles since iOS 14. These are mainstream consumer devices doing what their manufacturers intended. Your guests aren't trying to bypass your filtering. Their devices are just doing it automatically. Section two — the technical deep dive. Let's get into the mechanics. There are two primary DoH implementation patterns you'll encounter in the field. The first is application-level DoH, where the application — typically a browser — maintains its own DoH configuration independently of the operating system's DNS settings. Firefox is the canonical example. When Firefox is installed and DoH is enabled, it ignores the system DNS resolver entirely and sends all its DNS queries to its configured DoH provider, which defaults to Cloudflare. Your DHCP-assigned DNS server is irrelevant. Your port 53 interception rules are irrelevant. Firefox is having a completely separate DNS conversation over port 443 that you cannot see. The second pattern is OS-level DoH, where the operating system itself handles the upgrade. Chrome and Windows 10 and 11 take this approach. They check whether the system's configured DNS resolver — the one assigned by your DHCP server — has a corresponding DoH endpoint. If it does, they automatically upgrade to DoH. This is called opportunistic DoH. If you're assigning 8.8.8.8 as your guest DNS server, Chrome will automatically use Google's DoH endpoint. If you're assigning 1.1.1.1, it'll use Cloudflare's DoH endpoint. The distinction matters for your mitigation strategy, which we'll get to shortly. There's a third vector worth mentioning: DNS over TLS, or DoT. This operates on port 853 and encrypts DNS queries using TLS rather than wrapping them in HTTPS. It's easier to block than DoH because it uses a dedicated port, but it's increasingly common on Android devices with Private DNS enabled. Your mitigation strategy needs to address both. Now let's talk about why this is a compliance and operational risk, not just a technical curiosity. Under GDPR, if your acceptable use policy states that you filter certain categories of content, and your technical controls don't actually enforce that policy, you have a gap between your stated data protection and content governance commitments and your actual technical implementation. That's a defensibility problem if you ever face a regulatory inquiry or an incident. Under the UK's Online Safety Act, venue operators providing public internet access have obligations around protecting users — particularly minors — from harmful content. If DoH is silently bypassing your content filtering, you may not be meeting those obligations. For venues that fall under PCI DSS scope — particularly those where payment card data flows over networks adjacent to guest WiFi — PCI DSS version 4.0 requires that you monitor and control DNS traffic as part of your network security controls. Unmonitored DoH traffic is a gap in that control framework. And from a pure security standpoint, DoH has been actively exploited by malware. Threat actors have used DoH as a command-and-control channel because it blends into normal HTTPS traffic. The GodLua backdoor used DoH for command-and-control communications. PsiXBot malware used Google's DoH service. If your security monitoring relies on DNS visibility to detect malicious activity, DoH blind spots are a real threat. Section three — implementation recommendations. Right, let's get practical. There are three primary mitigation strategies, and in most venue deployments, you'll want to implement all three in combination. Strategy one: block known DoH resolver endpoints at the firewall. This is your first line of defence and the most immediately deployable option. Maintain a blocklist of known DoH resolver IP addresses and domains — Google, Cloudflare, Quad9, NextDNS, AdGuard, and others — and deny outbound HTTPS traffic to those endpoints from your guest VLAN. The IETF and various security vendors publish and maintain these lists. The curl project on GitHub maintains a comprehensive list of known DoH resolvers that's a good starting point. This approach handles the majority of DoH traffic because, as research from Carnegie Mellon's Software Engineering Institute has shown, most DoH traffic goes to a small number of well-known resolvers. Users who know enough about DNS to configure a custom DoH resolver are a very small minority. The limitation of this approach is that it's a blocklist, and blocklists require maintenance. New DoH resolvers appear regularly. But combined with the other strategies, it provides solid coverage. Strategy two: TLS inspection on your next-generation firewall. Next-generation firewalls from vendors including Palo Alto Networks, Fortinet, Check Point, and Cisco Firepower support TLS inspection — also called SSL inspection or deep packet inspection. When enabled, the firewall acts as a man-in-the-middle for HTTPS traffic, decrypting it, inspecting the payload, and re-encrypting it before forwarding. This allows the firewall to identify DoH traffic even when it's going to an unknown resolver. Palo Alto's App-ID can identify DoH traffic specifically and apply policy to it. Fortinet's FortiGate has similar capability. The key configuration step is to ensure your guest VLAN traffic is routed through the inspection policy. The operational consideration here is certificate trust. For TLS inspection to work on guest devices, those devices need to trust your inspection certificate. On managed corporate devices, this is straightforward — you push the certificate via MDM. On unmanaged guest devices, it's more complex. The practical approach for guest WiFi is to use the Captive Portal acceptance flow to inform users that traffic may be inspected for content filtering purposes, and to rely on the combination of DoH resolver blocking and DNS interception as your primary controls, with TLS inspection as a secondary layer for higher-risk environments. Strategy three: force DNS interception and redirect. Configure your firewall or wireless controller to intercept all outbound DNS traffic on UDP and TCP port 53 and redirect it to your compliant DNS resolver. This doesn't stop DoH, but it ensures that any DNS traffic that does fall back to port 53 — because DoH failed or wasn't available — is captured and filtered. Combine this with blocking port 853 outbound from the guest VLAN to prevent DNS over TLS from bypassing your controls. For managed endpoints — corporate devices, staff devices — you have an additional option: Group Policy or MDM configuration to disable DoH at the browser and OS level. In Firefox, the network.trr.mode preference set to 5 disables DoH entirely. In Chrome, the disable-features equals DnsOverHttps flag achieves the same. Windows 10 and 11 have Group Policy settings to control DoH behaviour. This is the most reliable control for managed devices, but it's not applicable to unmanaged guest devices. Section four — implementation pitfalls. A few things that commonly go wrong in the field. The most frequent failure mode is incomplete port 53 interception. Teams configure their DNS filtering service correctly but forget to add the firewall rule that redirects all outbound port 53 traffic. Devices with hardcoded DNS settings — 8.8.8.8, 1.1.1.1 — bypass the filter entirely. Always verify this rule is in place and test it by configuring a test device with a hardcoded DNS server and confirming that filtered domains are still blocked. The second common failure is not accounting for IPv6. DNS queries over IPv6 are increasingly common, and many firewall rules are written for IPv4 only. Ensure your port 53 interception and DoH resolver blocklists cover both IPv4 and IPv6 addresses. Third: stale DoH resolver blocklists. If you're maintaining a static blocklist of DoH resolver IPs, it will become outdated. Automate the update process or use a DNS filtering service that maintains this list for you. Cloudflare Gateway, Cisco Umbrella, and similar enterprise DNS services include DoH bypass detection as a managed capability. Fourth: over-reliance on a single mitigation layer. DoH mitigation is a defence-in-depth problem. No single control is sufficient. Blocking known resolvers handles most cases. TLS inspection handles edge cases. DNS interception provides a safety net. Layer all three. Section five — rapid-fire questions. Does DoH mitigation break legitimate privacy tools? Potentially, yes. If a user is running a legitimate privacy-focused browser configuration, your DoH blocking will force them to use your DNS resolver. Your acceptable use policy should make clear that the venue's DNS resolver is used for content filtering purposes. This is standard practice and legally defensible. Can DoH be used to exfiltrate data from my network? Yes, and this is a real threat vector. DNS tunnelling over DoH has been demonstrated in the wild. Your next-generation firewall's DoH detection capability should include anomaly detection for unusually high query volumes or query patterns consistent with tunnelling. What about mobile apps that use DoH? This is the hardest case. Mobile apps that implement their own DoH stack — rather than using the OS DNS settings — are difficult to control without TLS inspection. Your best mitigation is the combination of known resolver blocking and TLS inspection. Is WPA3 relevant here? WPA3 improves over-the-air encryption and provides forward secrecy, which is excellent for guest privacy. But WPA3 doesn't address DoH — that's a layer 7 application protocol issue, not a layer 2 wireless security issue. They're complementary controls addressing different threat vectors. Section six — ROI and business impact. Let me close with the business case for addressing this properly. The cost of not addressing DoH is asymmetric. A single incident — a guest accessing illegal content on your network, a malware callback going undetected because your DNS monitoring had a blind spot, a regulatory inquiry about your content filtering compliance — can cost significantly more than the investment in proper mitigation. For a hotel group operating across 20 properties, deploying DoH mitigation typically involves a one-time configuration effort of two to four hours per property for the firewall rules and DNS interception configuration, plus an ongoing operational overhead of maintaining resolver blocklists — which is largely automated if you're using a managed DNS filtering service. The total investment is modest relative to the risk reduction. For retail chains operating under PCI DSS, the compliance benefit is directly quantifiable. Demonstrating that your network security controls include DoH mitigation reduces the risk of a PCI DSS audit finding and the associated remediation costs. For public sector venues and those operating under the Online Safety Act, documented DoH mitigation is part of your evidence base that you've taken reasonable technical steps to enforce your content filtering policy. The bottom line: DoH is not a future problem. It's a present one. Firefox, Chrome, Android, and iOS are all shipping DoH-capable configurations to your guests' devices right now. If you haven't audited your DNS filtering architecture for DoH bypass vectors in the last 12 months, that audit should be on your near-term roadmap. To summarise the key takeaways from today's briefing. One: DoH encrypts DNS queries inside HTTPS on port 443, making them invisible to traditional port 53 DNS filtering. This is happening by default on mainstream browsers and operating systems. Two: The three-layer mitigation strategy — block known DoH resolver IPs, implement TLS inspection on your next-generation firewall, and enforce port 53 interception — provides defence-in-depth coverage for both managed and unmanaged guest devices. Three: This is a compliance issue, not just a technical one. GDPR, the Online Safety Act, and PCI DSS all have implications for venues where DoH is silently bypassing content filtering policies. Four: The most common implementation failure is incomplete port 53 interception. Test it. Verify it. Don't assume it's working. Five: Managed DNS filtering services — Cloudflare Gateway, Cisco Umbrella, and similar — increasingly include DoH bypass detection as a managed capability, which reduces the operational overhead of maintaining static blocklists. That's a wrap for today's Purple Technical Briefing. If you're looking to audit your current DNS filtering architecture or implement DoH mitigation across your venue estate, the Purple platform provides the network intelligence and guest WiFi management layer to support that deployment. Thanks for listening, and we'll see you in the next session.