Browser-level DNS leak fixes work on the device you configured them on. The problem is that most networks have more than one device - phones, tablets, smart TVs, IoT devices, other people's laptops on your Wi-Fi. Every device that makes DNS queries through your ISP's resolver is leaking, regardless of what proxy or VPN is running on your primary machine.
The correct fix for network-wide DNS leak prevention is at the router level. Configure DNS correctly on the router, and every device on the network benefits automatically - no per-device configuration, no per-browser settings, no exceptions for apps that ignore system proxy settings.
This guide covers how to configure DNS at the router level on DD-WRT, pfSense/OPNsense, and OpenWrt - the three most common custom router firmware platforms - and how to verify the fix works for all devices on the network.
Why Router-Level DNS Matters
The standard DNS leak fix is "change your DNS resolver to Cloudflare or Google." That's a partial fix. It stops your ISP from seeing your queries, but the resolver still knows what you're looking up. More importantly, it only works if every application and device uses the system resolver - and many don't.
Some devices and applications have hardcoded DNS servers. Smart TVs, Chromecast, some Android apps, and IoT devices frequently ignore system DNS settings and send queries directly to 8.8.8.8 or 1.1.1.1, bypassing whatever you've configured. From a leak perspective, those queries still reveal which domains your network is visiting to the hardcoded resolver.
Router-level DNS configuration solves this with firewall rules that intercept all outbound DNS traffic on port 53, regardless of destination, and redirect it to the router's resolver. A device that hardcodes 8.8.8.8 gets its DNS answered by your router instead - transparently, without the device knowing.
This is the only configuration that gives you complete coverage across every device on the network.
Testing Before You Configure
Before changing anything, run a baseline test to understand what your network is actually leaking. From a device on the network you want to fix, open the NodeMaven DNS Leak Test in your browser - no account or setup required. The tool automatically sends a series of DNS queries from your browser and reports which resolvers responded, their ISP, and their geographic location. For a more thorough check, click Extended Test - it sends 18 queries instead of 6, which is more likely to catch intermittent leaks from different DNS paths on your network. The whole test takes under 30 seconds and the results appear inline on the page.
The baseline tells you three things:
Which resolvers are handling your queries. If you see your ISP's resolver (Comcast, BT, Verizon), every DNS query is being logged by your ISP. If you see a third-party resolver like Cloudflare or Google, you've already changed your upstream DNS but may still have hardcoded-DNS bypass issues.
Whether the resolvers are geographically consistent with your proxy. If you're running a proxy for a specific market, your DNS resolvers should be in the same region. A resolver in a different country creates a geographic inconsistency that detection systems flag.
Whether multiple resolvers are visible. Multiple resolvers in the results usually indicate that different devices or applications are using different DNS paths - a sign that per-device configuration is inconsistent and router-level interception is needed.
Run the extended test (18 queries) rather than the standard (6 queries) - it's more likely to catch intermittent leaks from different DNS paths.
DD-WRT: DNS Configuration and Port 53 Interception
DD-WRT is the most widely deployed custom router firmware. DNS configuration happens in two places: the DNSMasq settings and the firewall rules.
Step 1: Set upstream DNS resolvers
Navigate to Setup → Basic Setup → Network Setup → Static DNS.
Set Static DNS 1 and 2 to your chosen resolvers. For a privacy-focused setup:
DNS 1: 1.1.1.1 (Cloudflare)
DNS 2: 1.0.0.1 (Cloudflare secondary)
Alternatively, for DNS-over-HTTPS (DoH) via a local stub resolver - covered in Step 3.
Step 2: Configure DNSMasq
Navigate to Services → Services → DNSMasq.
Enable DNSMasq. In the Additional DNSMasq Options field, add:
no-resolv
server=1.1.1.1
server=1.0.0.1
no-resolv tells DNSMasq to ignore /etc/resolv.conf (which may contain ISP-assigned resolvers) and use only the servers you've specified explicitly. This is the most important setting - without it, DNSMasq may fall back to ISP resolvers.
Step 3: Intercept hardcoded DNS with iptables
Navigate to Administration → Commands. In the Commands field, add the following iptables rules:
Redirect all outbound DNS on port 53 to the router's DNSMasq
iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to 192.168.1.1
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to 192.168.1.1
Block DNS queries that somehow bypass the redirect
iptables -A FORWARD -p udp --dport 53 -j DROP
iptables -A FORWARD -p tcp --dport 53 -j DROP
Replace 192.168.1.1 with your router's LAN IP if different. Replace br0 with your LAN bridge interface name (check under Status → Network).
Click Save Firewall to persist these rules across reboots.
Step 4: Verify DNSMasq is the only resolver
From a client on the network, run:
Check which DNS server responded to a query
dig +short TXT whoami.ds.akahelp.net @1.1.1.1
Should return Cloudflare's resolver details
Check what your system resolver returns
dig example.com
The "SERVER:" line in the output should show 192.168.1.1 (your router)
pfSense and OPNsense: DNS Resolver Configuration
pfSense and OPNsense use Unbound as their DNS resolver by default. Unbound is a full recursive resolver that can handle DNS queries locally without forwarding to an upstream - which is the most private configuration - or forward to a specific upstream while using DNSSEC validation.
Step 1: Configure DNS Resolver (Unbound)
Navigate to Services → DNS Resolver (pfSense) or Services → Unbound DNS (OPNsense).
Enable the resolver. Under General DNS Resolver Options:
Network Interfaces: select LAN and any other internal interfaces
Outgoing Network Interfaces: select WAN
DNSSEC: enable
DNS Query Forwarding: enable if you want to forward to specific upstream resolvers rather than resolving recursively
Under Custom Options (pfSense) or Custom configuration (OPNsense), add:
Forward all queries to Cloudflare DoT
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 1.0.0.1@853#cloudflare-dns.com
This configures DNS-over-TLS forwarding, which encrypts DNS queries between your router and Cloudflare's resolver - preventing your ISP from seeing queries even at the transport layer.
Step 2: Block outbound port 53 in the firewall
Navigate to Firewall → Rules → LAN.
Add a rule with Action set to Block, Protocol TCP/UDP, Source LAN net, Destination !This Firewall (any destination except this firewall), and Destination Port 53. The !This Firewall destination means queries to Unbound on the router itself are allowed, but queries from LAN clients to any external DNS server (8.8.8.8, 1.1.1.1 directly) are blocked and must go through Unbound instead.
In OPNsense, the equivalent is under Firewall → Rules → LAN with the same logic.
Step 3: Add a NAT redirect rule (optional, for hardcoded clients)
For devices with hardcoded DNS that you want to silently redirect rather than block:
Navigate to Firewall → NAT → Port Forward.
Add a rule:
Interface: LAN
Protocol: TCP/UDP
Destination: any (except LAN address)
Destination port: 53
Redirect target IP: 127.0.0.1 (Unbound on localhost)
Redirect target port: 53
This captures all DNS traffic from LAN clients regardless of destination and answers it with Unbound - including queries from devices hardcoding 8.8.8.8 or 1.1.1.1.
OpenWrt: DNS Configuration with dnsmasq and iptables
OpenWrt uses dnsmasq for DNS and DHCP by default. The configuration approach is similar to DD-WRT but managed through the UCI (Unified Configuration Interface) or the LuCI web interface.
Step 1: Set upstream DNS via LuCI
Navigate to Network → DHCP and DNS.
Under the General Settings tab:
DNS forwardings: add 1.1.1.1 and 1.0.0.1
Under the Resolv and Hosts Files tab:
Uncheck Use /etc/resolv.conf - this prevents dnsmasq from using ISP-assigned resolvers
Step 2: Configure via UCI (command line)
SSH into your OpenWrt router and run:
Set upstream DNS resolvers
uci set dhcp.@dnsmasq[0].noresolv=1
uci add_list dhcp.@dnsmasq[0].server='1.1.1.1'
uci add_list dhcp.@dnsmasq[0].server='1.0.0.1'
Prevent rebinding attacks
uci set dhcp.@dnsmasq[0].rebind_protection=1
Apply and restart
uci commit dhcp
/etc/init.d/dnsmasq restart
Step 3: Intercept hardcoded DNS with iptables
Redirect all outbound DNS queries to the router
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 ! -d 192.168.1.1 -j DNAT --to-destination 192.168.1.1:53
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 ! -d 192.168.1.1 -j DNAT --to-destination 192.168.1.1:53
Make persistent across reboots
cat >> /etc/firewall.user << 'EOF'
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 ! -d 192.168.1.1 -j DNAT --to-destination 192.168.1.1:53
iptables -t nat -A PREROUTING -i br-lan -p tcp --dport 53 ! -d 192.168.1.1 -j DNAT --to-destination 192.168.1.1:53
EOF
Replace br-lan with your LAN bridge interface name (check with ip link show) and 192.168.1.1 with your router's IP.
Step 4: Add DNS-over-HTTPS via https-dns-proxy (optional)
For encrypted DNS on OpenWrt without running a full DoT stack:
opkg update
opkg install https-dns-proxy luci-app-https-dns-proxy
Configure to use Cloudflare DoH
uci set https-dns-proxy.@https-dns-proxy[0].bootstrap_dns='1.1.1.1,1.0.0.1'
uci set https-dns-proxy.@https-dns-proxy[0].resolver_url='https://cloudflare-dns.com/dns-query'
uci commit https-dns-proxy
/etc/init.d/https-dns-proxy restart
Verifying the Fix Across All Devices
After router-level configuration, verify from multiple devices on the network - not just the device you used for the baseline test.
From a laptop or desktop:
Verify the resolver is your router, not an external server
nslookup example.com
"Server:" should show your router's IP
Check which upstream is being used
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com
Should return the IP of your configured upstream resolver (Cloudflare's)
Not your ISP's resolver IP
From a phone or tablet:
Open a browser and run the NodeMaven DNS Leak Test extended test. The resolvers shown should be Cloudflare (or whichever upstream you configured) - not your ISP. Run this from both Wi-Fi and, if possible, temporarily disable the test device's private DNS settings to verify the router interception is catching them.
From a device with hardcoded DNS (if you have one):
If you have a device known to hardcode DNS (many smart TVs and streaming sticks do), check its network activity with the router's DNS query log:
On DD-WRT:
Enable DNSMasq logging temporarily
echo "log-queries" >> /tmp/dnsmasq.conf
killall -HUP dnsmasq
Watch the log
logread | grep dnsmasq
On OpenWrt:
Check dnsmasq query log
logread -f | grep dnsmasq
Queries from hardcoded-DNS devices should appear in the log being answered by your router rather than passing through to external resolvers.
Handling DoH Bypass
One remaining challenge: browsers with built-in DNS-over-HTTPS can bypass your router's DNS interception entirely. Chrome, Firefox, and Edge all support DoH, and some configurations enable it automatically.
DoH sends encrypted DNS queries directly to Cloudflare or Google over HTTPS (port 443), which your port 53 interception rules don't touch.
Disable automatic DoH in Firefox: In Firefox, navigate to about:config and set network.trr.mode to 5 (disabled). This forces Firefox to use the system resolver, which your router now controls.
Disable automatic DoH in Chrome: Chrome → Settings → Privacy and security → Security → Use secure DNS → Off or set to a specific provider that routes through your router.
Alternatively, block DoH at the router level by blocking outbound connections to known DoH provider endpoints - though this is a cat-and-mouse approach as providers add new endpoints.
The most complete fix for DoH bypass is a local DoH resolver on your router that intercepts DoH queries, answers them via your controlled upstream, and blocks direct DoH connections to external resolvers. This is an advanced configuration beyond the scope of this guide, but doh-proxy and AdGuard Home (both available as OpenWrt packages) can handle it.
What the Correct Configuration Looks Like
After proper router-level DNS configuration with port 53 interception:
The DNS leak test run from any device on the network shows only your configured upstream resolver - Cloudflare, Google, or your own resolver - never your ISP's servers. The geographic location of the resolver matches your configured upstream, not your physical location's ISP. Devices with hardcoded DNS are silently intercepted and answered by the router. The only remaining leak vector is browser DoH, which requires an additional configuration step if you need complete coverage.
This is the network state where every device's DNS queries are under your control, rather than being distributed across whatever each device or application decided to use by default.
Top comments (0)