Redirecting all network DNS to your resolver (router / NAT)

You stood up a filtering resolver, handed out its address over DHCP, and watched the dashboard light up. Most of the network now flows through it. But "most" is the word that should bother you. A DNS policy is only as good as its weakest client, and on any real network there is always a handful of devices that quietly do their own thing — a smart TV hard-coded to a public resolver, a phone that opens its own encrypted DNS session, a developer laptop with a leftover entry in its config. Each one is a hole in the wall you just built.

The fix is not to chase devices one by one. It is to make the network itself enforce the rule: every DNS query, from every device, ends up at your resolver whether the device likes it or not. That means intercepting plain DNS at the router, blocking the escape routes, and neutralising the encrypted-DNS bypass. This article walks through each layer, with placeholder addresses you can adapt to your own topology.

The problem: DHCP is advisory, not binding

When your DHCP server offers 192.0.2.1 as the DNS server, a well-behaved client uses it. The trouble is that nothing on the wire forces it to. A device can ship with a baked-in resolver address and never even read the DHCP option. Three categories cause almost all of the leakage:

• Hard-coded public DNS. Many IoT appliances, streaming sticks, and game consoles embed a public resolver address in firmware and query it directly on UDP/TCP port 53, ignoring whatever DHCP told them.
• User-configured overrides. A laptop or phone with a manually set DNS server, often a leftover from a past network or a privacy how-to article.
• Encrypted DNS over 443. Modern browsers and operating systems can open their own DNS-over-HTTPS session to a third party. To the network this looks like ordinary HTTPS traffic on port 443 — it never touches port 53 at all.

The first two are plain DNS and can be intercepted at the IP layer. The third is the hard one, because it hides inside the same port as the rest of the web. We handle them in that order.

Transparent redirection: dst-nat on port 53

The cleanest way to capture stray plain-DNS traffic is a destination-NAT rule on the gateway. Any packet headed for port 53 — regardless of which server the device thinks it is talking to — gets its destination rewritten to your resolver. The device believes it reached its chosen public DNS; in reality your resolver answered. No client reconfiguration, no per-device fights.

You need two rules, one for UDP and one for TCP, because DNS uses both (TCP for large responses, zone-transfer-style answers, and fallback after truncation per RFC 7766). Here is a generic RouterOS-style example. Replace 192.0.2.1 with your resolver's address on the LAN:

/ip firewall nat
add chain=dstnat action=dst-nat \
    protocol=udp dst-port=53 \
    src-address=!192.0.2.1 to-addresses=192.0.2.1 to-ports=53 \
    comment="Redirect all UDP DNS to resolver"
add chain=dstnat action=dst-nat \
    protocol=tcp dst-port=53 \
    src-address=!192.0.2.1 to-addresses=192.0.2.1 to-ports=53 \
    comment="Redirect all TCP DNS to resolver"

Two details matter. The src-address=!192.0.2.1 exclusion stops the resolver's own outbound queries from being NATed back into itself — without it you create a loop where the resolver's upstream lookups get bounced to its own port 53. And the rule lives in the dstnat chain so it fires before routing decisions, catching the packet on the way in from the LAN.

The beauty of dst-nat is that it is invisible to the client. A device pointed at 198.51.100.10 sends its query there; the router silently rewrites the destination to your resolver, which answers. The device never knows it was redirected.

One caveat: source addresses in your logs

Plain dst-nat preserves the original client source IP, which is what you want — your resolver's per-client statistics stay accurate. If your topology ever forces you to add a matching src-nat (masquerade) on the way to the resolver, you will lose client identity and every query will appear to come from the gateway. Avoid that unless you genuinely route the redirected traffic across a boundary that requires it.

Block outbound 53 to everywhere else

Redirection handles devices that send to port 53 and accept whatever answers. But a determined client can sometimes detect that the answer did not come from the server it addressed. Belt and braces: in addition to redirecting, drop any port-53 traffic that tries to leave the network toward a server that is not your resolver. Anything legitimate is already being redirected; anything still trying to exit is either misconfigured or evasive.

/ip firewall filter
add chain=forward action=drop \
    protocol=udp dst-port=53 src-address=!192.0.2.1 \
    out-interface=WAN \
    comment="Block outbound UDP DNS bypass"
add chain=forward action=drop \
    protocol=tcp dst-port=53 src-address=!192.0.2.1 \
    out-interface=WAN \
    comment="Block outbound TCP DNS bypass"

Order your rules so the dst-nat redirect (in the NAT table) runs first and the forward-chain drop (in the filter table) only ever sees traffic that somehow escaped redirection. On most gateways these tables are evaluated at different stages, so the two coexist naturally. The combination means: legitimate DNS is silently redirected, and anything that wriggles past gets dropped at the edge.

The encrypted-DNS bypass (DoH on 443)

This is where most "we filter everything" setups quietly fail. A device running its own DNS-over-HTTPS (RFC 8484) sends DNS queries inside TLS to a third party on port 443. Your port-53 rules never see it. To the firewall it is indistinguishable from a visit to any website, because that is precisely the design goal of DoH — to make DNS look like web traffic.

You cannot block "DoH" by port, because you would have to block all of HTTPS. But you can attack the thing that turns it on. Browsers and operating systems that auto-enable encrypted DNS first perform a discovery check: they look up a special control signal in DNS, and if your resolver answers in a particular way, the client concludes the network does not want it to use its own encrypted DNS and stands down. Your resolver can answer those control lookups so that the device disables its own DoH and falls back to the local resolver — which is now you.

This covers the clients that honour the discovery mechanism, which is the large majority of mainstream browsers and operating systems. A manually pinned DoH endpoint that skips discovery entirely is a different animal — for those you fall back to segmentation and, where policy demands it, TLS inspection or an explicit allowlist of permitted 443 destinations. The pragmatic posture is: neutralise the automatic bypass for everyone, then deal with the small set of deliberate hold-outs by policy rather than by packet.

Why not just block the known DoH provider IPs?

You can maintain a deny-list of public DoH endpoint addresses, and a good resolver will keep curated lists of bypass infrastructure current for you. It helps, but treat it as a supplement, not the foundation. Provider IP ranges shift, new endpoints appear weekly, and some hide behind large CDNs you cannot wholesale block. The discovery-signal approach scales because it does not require you to enumerate every possible destination — it persuades the client to stand down on its own.

Segment the devices you can't trust

Redirection and bypass control assume devices that mostly behave. The ones that don't — cheap IoT gear, anything with firmware you can't update, guests' personal phones — deserve their own perimeter. Put them on separate VLANs and apply the DNS rules per segment rather than trusting the flat network.

1. Guest VLAN. Internet access, no path to internal hosts, DNS forcibly redirected to your resolver with a stricter filtering profile. Guests get safe browsing without touching your infrastructure.
2. IoT VLAN. The same port-53 redirect plus a hard drop on outbound 443 to anything outside a small allowlist, since most appliances only need to reach a handful of vendor endpoints. A toaster has no reason to run its own DoH.
3. Trusted VLAN. Managed workstations where you can also push DNS settings through device management, making the network-level enforcement a backstop rather than the only line.

Segmentation turns "I hope this device behaves" into "this device physically cannot reach anything I haven't allowed." It also limits the blast radius if one segment is compromised, which is the same reasoning NIS2 and similar frameworks apply to network zoning.

Verify that enforcement actually holds

Rules that look right in the config and rules that work on the wire are two different things. Test from a real client on the network, not from the gateway. Point a test device at a public resolver you do not run, then confirm the answer still comes from your policy.

# Aim at a public resolver you don't control — the redirect should
# capture it. If your resolver blocks a domain, you'll see the block,
# proving the query was intercepted.
dig @198.51.100.10 a-domain-you-block.example +short

# Force TCP to confirm the TCP redirect rule fires too.
dig @198.51.100.10 +tcp example.com

# Confirm the device's own encrypted-DNS bypass is disabled
# (browser behaviour: check that secure DNS reports "not available
# on this network" rather than silently active).

Then watch it from the other side. Your resolver's per-client view should show the test device's real IP making those queries — if it shows the gateway instead, you have an unwanted src-nat in the path. The two checks together close the loop: the client thinks it reached a public server, and your resolver confirms it actually answered, under the real client identity.

Run these checks again after firmware updates and after any router config change. Vendors revise their encrypted-DNS behaviour regularly, and a rule that worked last quarter can be silently routed around by a device that learned a new trick. Enforcement is not a one-time setup; it is a property you re-verify.

A filtering resolver you can bypass is a suggestion box. Redirect the plain queries, drop the strays, neutralise the encrypted bypass, and segment what you can't trust — then test it from a device that is actively trying to leave. Only when the escape attempt lands back in your own logs is the policy real.