Android VPN Resolves the Full Hostname but Not the Short Name

You type files into a terminal emulator and nothing comes back; you type files.corp.example and the same server answers immediately. Nothing about the VPN credentials changed, and the private DNS server was never broken. On Android the short label and the full name take different paths through the resolver, and one of those paths depends on a setting the tunnel's owner has to supply. The decision in front of you is not which DNS server to change, but who controls the network the app is actually using.

A search domain is not an address. It is a list of suffixes the resolver appends to a bare label before giving up.

A search suffix and a DNS server are separate fields

The resolver address tells Android where to ask. The search suffix tells it what to ask for when you supply only the leftmost label. Both live on the same network object, and either can be missing on its own.

That independence is exactly why the full hostname works. A fully qualified name needs no suffix, because it is already the string that goes to the server.

Android exposes the split through LinkProperties. The DNS server list and the domain search list sit on the same object, and the second one is routinely empty even when the first is fully populated. A network with a resolver but no domain is a network where the suffix was never applied — not a server that refused the short name.

Read the effective network before you change anything

Wi-Fi, cellular and a VPN interface are three separate networks, and the tunnel becomes the default once it comes up. The suffix that worked on office Wi-Fi is therefore not automatically the suffix in force while the tunnel is active. Inspect the network the app is actually selected on, not the one you configured last week.

A terminal shell on the device is a poor witness here, because its resolv.conf reflects one view of the resolver rather than every app's.

Browser address bars add another layer on top: a bare word may be treated as a search query, or resolved through the browser's own encrypted-DNS policy, so a page loading in Chrome proves nothing about system lookups. Test with something that uses the platform resolver and prints what came back. Then run the short form and the full form in the same session, on the same network, and note which one produced an answer.

If you build the VPN app, attach the suffix in the builder

When your app establishes the interface through VpnService, addSearchDomain is the supported input for this. It takes a domain string such as corp.example, and it is not an alternative way to pass a server address.

The call binds the suffix to the network you are building, so there is no global setting to flip afterwards. If the app tears the interface down and rebuilds it on reconnect, the new builder needs the suffix added again, or the replacement network comes up without it.

This is where a lot of desktop profile imports lose the field. The exporter writes the domain into its own model, the Android frontend maps only the options it knows about, and the resulting interface looks correct in every other respect. A profile that works on a laptop and fails on a phone is usually a mapping gap, not a protocol problem.

If you only consume the VPN, this is not yours to set

There is no client-side edit that adds a suffix, and no global property you can change to fake one. The value is delivered by whoever owns the tunnel: in the managed client's profile, in its per-platform mapping, or through whatever the server pushes. Say which platform you are on and which name fails, because the desktop and mobile frontends diverge on precisely this field.

Importing a desktop profile again proves nothing about the mobile mapping.

Three conditions decide whether you have a defect or an expected limitation. First, does the organization treat the short label as a supported name at all, or is it a convenience that only ever worked on office Wi-Fi? Second, is the failing lookup coming from a browser, which may bypass the system resolver entirely? Third, is the short name meant to be reachable over the tunnel, or only from the LAN? If the last answer is LAN-only, adding a suffix would create a name that resolves outside the office and then fails to route.

When the suffix is present and short names still fail

If the domain search list already shows corp.example, stop blaming the suffix. Check whether the resolver returns an answer for the expanded name at all, because a suffix only changes the question you ask. It never makes the server authoritative for a zone it does not host.

Then check the route. An address that resolves but is not carried by the tunnel fails at connect time, which looks identical to a lookup failure in a browser that gives up quietly.

Certificates deserve their own mention. HTTPS validation uses the hostname you actually typed, so a short name that expands correctly still presents files in the handshake. A certificate issued for files.corp.example will not validate for it, and that error is correct behaviour rather than a symptom of the DNS problem you started with.

What to do next

Confirm the split before touching anything: full name resolves, short name does not, same app, same session. Then find the selected network and read its domain search list alongside its resolver list. Whichever of the two is empty tells you who has to act — you, if you own the app; the tunnel operator, if you do not.

Finally, prefer the full service hostname in bookmarks and client configuration wherever portability matters. It survives a network switch, it does not depend on a mapping the mobile frontend may not implement, and it matches the name a certificate was issued for.