The Names That Only Exist on Your Own Network

Some of the names your device resolves every day exist nowhere except the network you are attached to. A printer, a network drive, a router’s own admin page, a media server: each answers to a short name that no public nameserver has ever heard of, resolved by a mechanism that has nothing to do with the chain of servers a public hostname goes through. Once a tunnel is in the picture, this second name space is where two distinct problems appear — local names stop working, or they escape to a resolver that had no business seeing them.

Both are common, both look like something else, and telling them apart takes about a minute if you know the mechanisms involved.

Two name spaces, resolved by different machinery

A public hostname is resolved by asking a resolver, which walks a hierarchy on your behalf — the sequence set out in how DNS resolution works. A local name is resolved by one of three much smaller mechanisms instead.

A multicast query on the segment. Your device asks the local network directly, and whichever device owns the name answers for itself. No resolver is involved at all. This is the mechanism behind names ending in .local, and it is a name space reserved for exactly this purpose.

A small resolver on the router. Many home routers keep a table of the names of devices that have asked them for an address, and answer for those names under a suffix of the router’s choosing. Some vendors use a suffix genuinely set aside for local use; some invent one that also exists on the public internet.

An entry in the hosts file. A name mapped to an address in a plain text file on the machine, which wins outright and produces no query of any kind.

The important structural point: only the third of these is a setting on your device. The first two are properties of the network you happen to be attached to, so the same short name can mean different things in different places, or nothing at all.

The suffix your network quietly appends

Networks can hand out a search domain along with an address, and your device will append it to any name that does not contain a dot. Type a bare name and your device may well ask for that name plus the suffix, then try the bare name, or the other way around, depending on the platform.

This is why a bare name works at home and fails in a café, and why the same name resolves to different things on two networks without anybody configuring anything. It is also the mechanism that turns a harmless local lookup into an outbound one, which is the second failure below.

Failure one: the tunnel swallows the local name space

When a client replaces your resolvers with one inside the tunnel, that resolver has never heard of your printer. Multicast names often survive, because they never needed a resolver. Router-suffix names usually do not, because the only machine that could answer is no longer being asked.

Layered on top of that is a second, separate failure with the same symptom. If the client’s routing does not leave an exception for your own subnet, then even a name that resolved correctly points at an address your device can no longer reach. A resolution failure and a reachability failure present identically: the printer is gone.

Separating them takes one step. Try the device by its address rather than its name. If the address works and the name does not, it is resolution. If neither works, it is routing, and the entry to look for is the one covered in which route wins when the tunnel and the local network disagree.

Failure two: the local name leaves the building

The suffix-appending behaviour does not know that a name is local, so a query for something that only exists on one network can be sent to whatever resolver is currently in effect.

Three ways this happens in ordinary use. A device asks for a bare name plus a suffix it picked up from a network it is no longer on. A laptop that has been configured for an employer’s network keeps that suffix or a per-domain rule and keeps asking about internal names from a hotel Wi-Fi. Or a router hands out an invented suffix that also exists publicly, so the query does not stop at the edge — it is answered by somebody.

What that discloses is not traffic; it is inventory and vocabulary. The naming convention of an internal network, the fact that a particular internal domain exists, the model names of devices you own, the fact that this laptop belongs to somewhere in particular. Whoever operates the resolver receives it along with everything else, which is why who runs your DNS resolver matters for queries you never intended to make as much as for the ones you did.

Per-domain rules that outlive their network

Some clients and managed configurations do not replace your resolver wholesale; they install a rule saying that one domain is resolved over there and everything else stays as it was.

This is a sensible design and it is also the reason a single domain on your machine can behave unlike every other. The rules are installed by software, they are not usually visible in the same panel as your ordinary resolver settings, and they have a habit of surviving the removal of whatever installed them. If exactly one name misbehaves, and nothing else does, look for a rule rather than a general fault — what your VPN’s DNS setting actually changes covers where these settings live and why setting a resolver is not the same as enforcing one.

Working out which mechanism answered

A short sequence, in order of how cheaply it eliminates a possibility:

1. Does the name contain a dot? If not, a suffix is probably being appended and you do not yet know what was actually asked.
2. Check the hosts file. An entry there ends the investigation immediately, and stale entries are a classic cause of one name behaving strangely for months.
3. Try the fully-qualified form — the name with the local suffix spelled out. If that works and the bare name does not, appending is the variable.
4. Compare with the tunnel down. A local name that resolves with the tunnel down and fails with it up tells you the resolver changed, not that the device did.
5. Reach the device by address. This separates resolution from reachability, as above.
6. Clear the caches before concluding anything, since a stale answer imitates every fault on this list and will keep doing so until the record’s lifetime expires.

Keeping the two name spaces apart

The goal is that local names fail locally rather than travelling. In practice that means preferring the reserved multicast name space for devices that support it, checking what suffix your router hands out and changing it if it is a name somebody else owns, and referring to anything that must always work — a router’s admin page, a backup target — by address.

It also means keeping per-domain exceptions few enough to enumerate. A name space you can describe in a sentence is one whose failures you can diagnose; one that accumulated over years of joining other people’s networks is not.