Chrome, Edge and Firefox each have an encrypted DNS setting that can route lookups around a network’s DNS filter, so a site blocked by a router or filtering service loads anyway. MakeUseOf writer Afam Onyimadu showed the effect in a test published Friday.
He added goal.com to the deny list in NextDNS, his filtering service, and confirmed lookups for the site returned 0.0.0.0. He then opened chrome://settings/security, picked Google Public DNS as an external Secure DNS provider and reloaded the page. It loaded, and the NextDNS logs showed no entry for the request at all. Edge and Firefox behaved the same way. Turning Secure DNS off, or setting the provider to the operating system default, brought the block back immediately.
Why the filter never sees the request
With Secure DNS off, the lookup goes from the browser to the system resolver and on to the filter. With it pointed at an outside provider, the browser sends the query over an encrypted DNS-over-HTTPS (DoH) connection straight to that resolver, so the filter is never asked. The privacy goal is legitimate: DoH keeps an internet provider or public Wi-Fi operator from reading DNS lookups in plain text. Onyimadu noted that firewall rules or IP-based blocks can still apply, calling it “a narrow but effective bypass.” His filter ran on his own PC, but he pointed out that Mozilla documents DoH can bypass network or local DNS filtering, so the same likely holds for router-level setups.
The browsers differ in the details. Chrome and Edge call the feature Secure DNS, as does Brave. In automatic mode they can fall back to the system’s regular DNS if a secure lookup fails, and choosing a specific provider removes that fallback. Firefox’s default protection mode may switch DoH off if it detects parental controls or network signals, but its Custom and Max protection settings keep encrypted DNS on, and Max refuses to fall back to system DNS even when the secure resolver can’t be reached.
How administrators close the gap
Because DoH travels over port 443 alongside ordinary HTTPS traffic, a simple port rule won’t catch it. Filtering providers point to browser policy instead. On managed computers, Chrome and Edge both have a DnsOverHttpsMode policy that can be set to off through Group Policy, the registry, Intune or the Google Admin console, and Firefox has a DNSOverHTTPS policy that can be disabled and locked, according to DNSAFE’s bypass guide. Networks can also make Firefox leave its automatic DoH off by answering “no such domain” for the canary domain use-application-dns.net, though that doesn’t override a user who turned DoH on manually.
Other steps include blocking outbound DNS on ports 53 and 853 to anything but the filtering resolver, blocking well-known public DoH endpoints by domain, or pointing the browser’s DoH setting at the filter’s own encrypted endpoint where the service offers one, as FirewallDNS lays out.
For a quick check, Onyimadu suggests opening the filter’s query log and loading a domain you haven’t visited recently in that browser. If the page loads and the lookup never shows up in the log, that browser isn’t using the filter.
WebProNews is an iEntry Publication