Short Internal Names Fail on VPN: The Suffix You Never See
A short name only works because a search suffix completes it. Compare the full name and the short one to separate a suffix gap from a resolver failure.
The short name worked in the office and fails on the VPN, while the full name resolves fine. Nothing is broken. A bare name like intranet is not a complete name; the client appends a suffix from its search list and asks for the result. If the VPN profile does not supply that suffix, the familiar short form stops existing.
That is the whole myth. DNS did not break, the search policy changed.
A bare name is not a name
When you type a single label, the resolver has to decide what to ask for. It tries the name as given, then appends entries from the search list one at a time until something answers. On Linux, resolv.conf controls that order with the search and ndots settings. On Windows, the suffix list and the name-resolution policy do the equivalent. Remove the suffix and the resolver has nothing to append.
A working short name is therefore evidence of a policy, not evidence of a healthy DNS server.
What the suffix list and the resolver address each do
These get conflated constantly. The resolver address says who to ask; the suffix list says what name to ask about. A VPN can hand you a private resolver and no suffix, or a suffix and the wrong resolver. Only one of those failures looks like a DNS outage.
Check them separately, because fixing the wrong one burns a support window.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Three symptoms, three different owners.
Test the full name first
Ask for the administrator's documented fully qualified name, not a guess. A working FQDN proves the resolver is reachable and the record exists, which removes half the possible causes in one query. Use a tool that shows which server answered, so you are not reading a cached result.
Keep the test private. Sending internal variants to a public resolver discloses names and tests a policy nobody intended.
Where the fix belongs
Correct the owning profile or the management system that generates it. A manual edit to the local resolver configuration usually disappears at reconnect, or applies to every network the machine joins, which is worse.
On Windows, inspect the effective policy rather than the checkbox you remember. Get-DnsClientNrptPolicy shows the name-resolution rules actually in force.
On macOS, scutil --dns prints the resolver configuration per scoped interface, including the search domains the VPN pushed.
On Linux, read the search line in /etc/resolv.conf, but check whether a VPN client rewrote it. If the file is managed, edit the source of truth rather than the rendered file. A stale search line left over from a previous network is a common cause.
What to keep with the profile
Store the corrected full name, the suffix list and the resolver address next to the client profile. The next person who reports that the intranet site is down can compare three known values instead of starting from a blank page.
And if only the short form fails, say so in the ticket. That sentence saves the resolver team an afternoon.