How to Stop Devices Bypassing DNS Filtering

Why bypass prevention matters

A DNS filter only protects devices that use it. Setting your router's DNS to a filtering service is the first step, but it is not enough on its own. Devices can be configured to use other resolvers, browsers can send encrypted DNS to their own providers, some apps and IoT devices have hard-coded DNS servers, and VPNs route everything elsewhere. Each is a gap in your protection.

Closing those gaps is mostly a matter of a few firewall rules and some policy settings. This article explains each bypass method and how to deal with it.

Bypass 1: manual DNS on the device

The simplest bypass is changing the DNS server in a device's network settings to a public resolver. Lookups then go straight to that resolver on port 53, ignoring the router's DNS settings. The fix is a firewall rule: allow outbound DNS (UDP and TCP port 53) only to your filtering resolver, and block it to every other destination. Some routers can also redirect all port 53 traffic to the filtering resolver, which handles devices with hard-coded DNS gracefully.

• Allow UDP/TCP 53 to your DNS filter (or to your internal DNS server only)
• Block UDP/TCP 53 to all other destinations
• Optionally redirect (NAT) port 53 traffic to the filter instead of blocking it

Bypass 2: DNS-over-TLS and DNS-over-QUIC

DoT and DoQ use port 853, TCP and UDP respectively. A device configured with a public DoT resolver, for example via Android Private DNS, sends encrypted lookups on port 853 that bypass your filter. Because the port is dedicated, the fix is easy: block outbound TCP and UDP 853 to everything except your filtering resolver. On managed Android devices, you can also set Private DNS by policy.

Bypass 3: DNS-over-HTTPS in browsers and apps

DoH is harder because it uses port 443, the same as all HTTPS traffic. Browsers such as Chrome, Edge, Firefox and Brave can use their own DoH provider, and some apps do the same. There are several complementary defences.

• Manage browser settings by policy: Chrome and Edge DnsOverHttpsMode, Firefox DNSOverHTTPS
• Point browser DoH at your filtering resolver instead of disabling it, where supported
• Block the Firefox canary domain use-application-dns.net to signal that default DoH should be disabled
• Block well-known public DoH endpoints by domain in your DNS filter and by IP on your firewall

Bypass 4: VPNs and proxies

A VPN tunnels all traffic, including DNS, to the VPN provider, completely bypassing local filtering. Proxies and some privacy apps do the same. Blocking VPNs entirely is difficult because many look like ordinary encrypted traffic. Practical measures include blocking the domains of consumer VPN services through your DNS filter so the apps cannot connect, blocking common VPN protocols and ports at the firewall, and on managed devices preventing VPN app installation. On a family network, device parental controls that restrict app installs are often the most effective approach.

[VERIFY: whether FirewallDNS offers a dedicated VPN/proxy blocking category]

Bypass 5: IPv6

On networks with IPv6, devices may receive IPv6 DNS servers through router advertisements or DHCPv6. If your filtering is only configured for IPv4, IPv6 lookups may go to your internet provider's resolver. Configure your router to advertise the filtering resolver's IPv6 addresses, or to advertise only the router itself as the DNS server, and apply the same firewall rules for port 53 and 853 to IPv6 traffic.

Bypass 6: hard-coded DNS in devices

Some smart TVs, streaming devices and IoT gadgets ignore DHCP-provided DNS and query a public resolver directly. They will never appear in your filter's query log. Port 53 blocking or redirection catches those using plain DNS. Devices using hard-coded DoH are harder; blocking the specific resolver's addresses on the firewall usually forces them to fall back to the network's DNS. Test afterwards, because some devices stop working when their preferred resolver is unreachable.

Bypass 7: mobile data and other networks

Network-level rules only apply on your network. A phone on mobile data or a laptop on hotel Wi-Fi uses whatever DNS that network provides. To keep filtering active away from home or the office, configure encrypted DNS on the device itself, pointed at your filtering resolver, and lock the setting with device controls or management. Our device guides for iPhone, Android, Windows 11, macOS and Chromebook show where these settings live. [VERIFY: per-device DoH/DoT availability in FirewallDNS]

Active Directory networks

In Windows domains, clients must use the domain controllers for DNS. Set FirewallDNS as the forwarder on each domain controller, and on the firewall allow outbound DNS only from the domain controllers to FirewallDNS. Clients that try to query external resolvers directly are then blocked, while internal names continue to resolve. Our Active Directory forwarders guide includes the PowerShell to apply this to every domain controller.

A checklist

Work through this list and most bypass routes are closed.

• Router and DHCP hand out only the filtering resolver (IPv4 and IPv6)
• Firewall allows port 53 only to the filter, or redirects it there
• Firewall blocks port 853 (TCP and UDP) except to the filter
• Browser DoH managed by policy on managed devices
• Known public DoH and VPN domains blocked in the DNS filter
• Device controls prevent changing network settings and installing VPNs where appropriate
• Query log reviewed to spot devices that never appear

Verify with the query log

The best way to confirm that bypass prevention works is the query log. Every device you expect to be filtered should produce lookups. If a device is silent, it is probably using another resolver. Test by temporarily setting a device to a public resolver: with the rules in place, its lookups should fail or be redirected and appear in your log.

Example firewall rules

The exact syntax depends on your equipment, but the logic is the same everywhere. Create an address object for your filtering resolver. Add a rule allowing UDP and TCP 53 and 853 from your internal networks to that object. Below it, add a rule denying UDP and TCP 53 and 853 from internal networks to any destination. If your router supports destination NAT, you can instead redirect port 53 traffic to the resolver, which keeps devices with hard-coded DNS working. Apply equivalent rules to IPv6.

Our guides for pfSense, OPNsense, FortiGate, MikroTik, UniFi and other platforms show where these settings live. Test the rules by setting a laptop to a public resolver and confirming that lookups fail or are redirected.

Balancing control and usability

Bypass prevention is not about locking everything down for its own sake. On a family network, a few router rules and sensible device controls are usually enough. In a business, the same rules protect the organisation from users and software that sidestep security, often without meaning to. In a school, stronger controls are expected. Decide how strict you need to be, explain the rules to the people affected and keep a simple way to request exceptions.

Summary

DNS filtering is only as strong as the controls that keep devices using it. Restrict outbound DNS on ports 53 and 853, manage browser DoH, account for IPv6, block VPN and DoH services where appropriate and use device controls for phones and laptops that leave the network. Then use the query log to prove it works.