Allow DNS only through your VPN resolver: a walkthrough

Watch one name lookup from the moment you type it. The browser asks the operating system, the operating system asks whichever resolver its policy selects, and the query leaves through some interface with some transport. Your VPN design says the answer should come from a specific resolver by a specific path. The gap between those statements is what you configure and then enforce.

Step 1: name the resolver and the path

Write down three things before touching a firewall: the resolver address, the protocol and port you expect it to use, and the interface the query should leave by. Without that list, a rule is a guess about traffic rather than an enforcement of a decision. A VPN can carry application data while DNS follows a separate arrangement, and that is not a misconfiguration by itself. It is what happens when nobody told the client otherwise.

Naming the path explicitly is the difference between a design and an accident. It also gives you something to test later, because every observation can be compared with a written expectation. Keep that list in the change ticket rather than in someone's head.

Step 2: set the policy where it actually lives

Resolver selection belongs to the client: the operating system's network configuration, the VPN client's own settings, or a managed browser policy. Set it there first, using the mechanism the platform supports, because a firewall cannot make a client choose a resolver it was never told about. On a split-tunnel client, say explicitly which domains go to the internal resolver. On a managed fleet, a browser policy may be the only lever for DoH, since the browser can pick its own encrypted resolver independently of the system setting.

Skip this and go straight to the firewall, and you get a rule that permits the right resolver plus a client that never uses it. The rule looks correct and the resolver logs stay empty, which is a confusing pair to debug. Configure the choice first, then enforce it.

Step 3: enforce the path narrowly

Now add the network permission for the allowed path: the resolver address, the protocol and port, and the interface it should leave by. Keep the rule scoped to that resolver instead of permitting all outbound DNS. The three paths below are the ones a modern client can take, and only the first is covered by a port-53 rule.

Deciding to block DoH and DoT is legitimate; assuming a port-53 rule already blocked them is not. A browser using DoH resolves names through a path your rule never described, and an application that ships its own resolver does the same. Write down each path you intend to allow and each one you intend to refuse. A rule that does not name a path has not made a decision about it.

Step 4: follow private and public names

Split DNS deliberately sends only private namespaces to an internal resolver while public names go elsewhere, so more than one resolver in the design is not a leak. The leak is a query that should have gone to your resolver arriving somewhere else, or an unreachable intended path that makes the client fall back silently. Those two cases are what to look for. Follow an internal name and a public name under the intended policy and note which resolver answered each one.

A test site that reports your resolver is a hint, not proof, because it only sees queries that reached it. Capture the query on the client side when you need to know which path it actually took, then compare both observations. When they disagree, you have found a fallback nobody documented.

If the resolver address is right but unreachable, the problem is routing or filtering rather than policy. Trace the query to that address and confirm the reply returns on the expected interface before changing any resolver setting.

Step 5: keep a way back in

Before tightening gateway DNS access, confirm a recovery method that does not depend on name resolution. A broken resolver makes every repair tool harder to reach, including the ones you would use to undo the change. Keep a local console or an out-of-band path open until the new policy has been proven. Remove it only after the policy has survived a reconnect.

After a reconnect or a browser policy update, inspect the effective state again, because both can change the resolver without changing your rule. The requirement is a known recipient and a protected path for the queries, not a reassuring resolver label in one screenshot. The RFC 8484 DNS over HTTPS specification is the reference for the encrypted path your port rule does not see.