DNS failure or MTU problem? Where the request actually stops

Two failures produce the same sentence from a user: the site does not work. They happen at different layers, and the difference decides what you change. A name resolution failure stops before any connection exists. A packet-size failure happens after the name resolved and after the handshake completed, which is why the page starts loading and then hangs. Find the stage before you find the setting.

Two failures at different layers

Resolution turns a name into an address, and nothing else in the connection can start until it succeeds. Path MTU problems happen later, when a packet larger than some link's limit is dropped and the sender is never told. One is a lookup; the other is a delivery failure that only appears above a certain size.

The symptoms differ in a way you can observe without any tooling. A DNS failure is immediate and consistent: the browser says the server cannot be found. An MTU failure is partial: the page begins, some resources arrive, and a large response or upload stalls.

If your symptom is partial, stop looking at DNS.

Stage 1: does the name resolve at all

Use the platform's lookup tools with the exact hostname the application uses. A private office name may require an internal resolver, and a browser's own secure DNS can behave differently from the operating system's resolver, so the two can disagree about the same name.

Ask the resolver the operating system would use, then compare:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

If resolution fails, the problem is that policy and its reachability. Do not send private names to arbitrary public resolvers just to get a comparison, because the comparison itself leaks the names you were trying to keep internal.

Stage 2: where the transfer stops

If the name resolves and the connection begins, record where the operation stops. A page that renders and then hangs on one resource, an upload that dies at a consistent point, or a large download that never finishes while small requests work are all size-shaped symptoms. A response that never starts at all is a different shape.

Keep the endpoint and the application destination fixed while you compare, or you will be measuring two variables at once. Other causes remain possible at this stage: service errors, loss, filter behaviour and tunnel reconnects all produce stalls.

One repeatable stall is worth more than ten anecdotal ones.

Why MTU only hurts after the handshake

A TCP handshake uses small packets, so it succeeds on a path that cannot carry a full-size segment. The failure appears when the sender emits a large packet with the do-not-fragment bit set, a link drops it, and the ICMP message that would have reported the limit never arrives because a filter ate it. The sender then retries the same size and the transfer stalls.

That is why the symptom is size-dependent and repeatable rather than random. It also explains why pinging the host proves nothing, because a small ICMP echo can cross a path that will not carry a full-size payload. Probe the size from both ends of the path if you can. A limit that appears in one direction only is a routing asymmetry rather than a tunnel MTU.

Probe the size explicitly instead of inferring it:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Change one layer, then prove it

For names, change the resolver policy and re-run the same lookup. For size, use the MTU procedure with the original values recorded and a rollback ready, because clamping MSS without knowing the tunnel's real MTU trades one stall for another.

A page that loads once after several settings changed does not identify the repair. Change one thing, re-run the same test, and keep the result next to the first failed stage you recorded.

That record is what stops DNS, packet sizing and authentication from becoming a pile of permanent workarounds nobody can explain. Testing by raw IP is a good example of a shortcut that changes TLS identity, and disabling certificate verification to make a comparison succeed is not a diagnosis.