Keep DNS on the intended path

Routing packets is half the job. Name resolution decides which packets exist in the first place, and it deserves the same attention.

Two situations force you to care where DNS goes. A private service may need a private DNS resolver: wiki.internal exists only in the company’s DNS, and no public resolver has ever heard of it. And an Internet egress VPN may want DNS queries to use the same trusted path as the traffic — otherwise the local network still sees every hostname you look up, which is most of what you were trying to hide.

A DNS leak happens when queries take a path you did not intend. The tunnel dutifully carries your traffic while your queries still flow to the home router’s resolver. The observer you were avoiding reads your browsing intentions from the query stream.

wg-quick can point the system at a resolver while the tunnel is up:

[Interface]
Address = 10.14.0.2/24
PrivateKey = LAPTOP_PRIVATE_KEY
DNS = 10.14.0.1

Then verify where queries actually go, because intent and reality diverge here constantly:

resolvectl status wg0
#   DNS Servers: 10.14.0.1

dig example.com | grep SERVER
# ;; SERVER: 10.14.0.1#53(10.14.0.1)

If the SERVER line names your home router instead, you have a leak, whatever the VPN app’s interface claims.

IPv6 can also bypass an IPv4-only tunnel. When a destination publishes an IPv6 address and your device has working IPv6, the operating system may prefer it — sailing straight past your carefully built IPv4 routes. Either carry IPv6 in the tunnel too (::/0 in AllowedIPs) or decide explicitly how IPv6 should behave.

The third trap is disconnection. A kill switch blocks selected traffic when the tunnel disappears. Without one, the operating system may return to its ordinary default route — silently, mid-session, while you keep working under assumptions that stopped being true.

Test addresses, DNS answers, IPv4, IPv6, and disconnect behavior. A connected icon proves very little.