Why Does a Hotspot Redirect DNS Before the VPN Connects?
A hotspot rewrites lookups on its own network, and a hostname endpoint is resolved before any tunnel exists. Trace which resolver answered each query.
Joining a hotel network puts two DNS decisions in front of you at different moments: the lookups the device makes while signing in, and the lookups made once the tunnel is up. A hotspot can influence the first through the network it controls. The second depends on the client's own policy, which is a separate thing to inspect.
Walk the connection in order, from the first DHCP lease to the query that resolved a private name. Two failures that look identical in a support ticket then separate cleanly: one happened before the tunnel existed, and the other happened inside it.
What the hotspot can and cannot touch
The access network hands out a resolver address in DHCP and can intercept port 53 toward that address. That is enough to answer every unprotected lookup with a portal address or a block page. It is also enough to break a VPN client whose endpoint is written as a hostname.
What the hotspot cannot do is read or rewrite a query once it travels inside an established tunnel, assuming the tunnel really carries it. Interception depends on seeing the plaintext question.
Queries leave the tunnel anyway for reasons unrelated to the hotspot: the browser's secure DNS setting, a split-DNS rule that keeps a corporate suffix on the local resolver, or a client configured to exclude DNS from the tunnel. Each is a client-side choice, and each looks like hotspot interference when viewed from outside.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
The bootstrap lookup happens before the tunnel exists
A client given a hostname must resolve it first, and at that instant no tunnel protects the query. If the hotspot answers with a portal address, negotiation fails or hangs. If it answers with nothing, the client reports a name error and the tunnel never starts. Either outcome explains an empty tunnel log that otherwise looks innocent.
Operating systems run their own connectivity checks and portal discovery as well, described in RFC 8910 and RFC 8952, and those requests leave before any VPN is up. Seeing them in a proxy log is expected behaviour rather than proof of a leak.
The practical fix is to give the client an endpoint that needs no lookup. When that is impossible, finish sign-in first and connect afterwards.
Find out which resolver answered
Ask the system rather than the browser, and run the query twice: once through whatever resolver the device currently uses, once against a fixed address.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
An answer from the first command that differs from the third tells you the local resolver is returning something else, which is what a redirecting hotspot does. A failure from the third alongside a success from the first points at the portal: the local resolver served a sign-in address while outbound port 53 was dropped. Timeouts on both mean the network discards DNS until authentication completes.
Repeat after connecting and compare. A cached answer survives the transition, so flush the cache or query a fresh name for the second observation.
Keep later lookups on the path you intended
A full-tunnel profile that also captures DNS is the simplest arrangement: every query from every application goes to the resolver the tunnel pushes, and the local network sees only encrypted traffic. Prove it by resolving an internal name and a public one after connecting, then comparing both answers with what the tunnel resolver returns on its own.
Split-DNS needs a domain list written with intent: corporate suffixes through the tunnel, everything else locally, and no overlap between the two.
Browser secure DNS sits outside that policy, so if it has to be off for the profile to behave predictably, disable it for that profile rather than for the machine. Do it in the browser settings, not by editing the system resolver, so the change is visible next time. Record the answer, the resolver and the connection stage in one line per test. A report saying DNS failed on hotel Wi-Fi describes a symptom with at least three different causes.