Why MagicDNS Resolves Devices but Not Office Hostnames

MagicDNS hands each device in a tailnet a name derived from its machine name and the tailnet's DNS domain. That name is created by Tailscale and answered along Tailscale's resolver path. An office hostname such as files.office.example belongs to a zone Tailscale never wrote, so renaming a device cannot create it. The two namespaces coexist; they simply have different owners.

That mechanism sits behind a very common report: the Tailscale host answers, and the file server still returns a resolution error.

Two Namespaces, Two Owners

A device name is generated from the machine's own hostname, collisions are resolved by Tailscale, and the result lives under the tailnet domain. An office zone is maintained by whoever runs the office resolver, with records created by an administrator or by dynamic registration. Short names hide the difference: files might be a search-suffix expansion answered by the office DNS, a tailnet device, or nothing at all. Querying the full name shows which system actually replied.

Changing the machine name of the subnet router does nothing for the office zone. It renames one Tailscale device and leaves the record on the office server untouched, which is why rename-and-retry never converges.

Point the Office Zone at Its Resolver

Tailscale's split DNS sends queries for chosen domains to a nameserver you specify, and everything else follows the remaining policy. Add the domain the office resolver actually serves, not the search suffix you happen to type. A search suffix tells the client what to append; it does not tell the resolver where to look. Those two settings look similar in a console and behave completely differently.

A restricted nameserver needs to be authoritative for the domain associated with it, or the answer will be a referral rather than an address.

Reachability Comes Before Resolution

The client also has to reach that nameserver. For a resolver on a private LAN, the subnet route must be advertised and accepted, the access policy must allow the query, and a return path must exist. A correct DNS address in the admin console proves only that the configuration was saved. If packets cannot reach the resolver, the symptom is a timeout, which looks different from an authoritative no-such-record answer.

That difference is diagnostic. A timeout points at routing or policy, while an immediate negative answer points at the record or the zone. Read which one you get before changing any DNS setting.

Separate the Name Failure from the Service Failure

If the resource responds at its private address but not by hostname, the investigation stays on DNS. If neither works, fix routing or the service first, because a name that resolves to an unreachable address is not progress. Query the full name and note the server that answered. On macOS some command-line tools take a different path from ordinary applications, so a terminal dig and a browser can disagree about the same name.

Repeat the test with an exit node selected if that is the normal mode for the device. Exit-node DNS handling differs from the non-exit configuration, and testing in only one mode can miss the failure users actually see.

Record the zone, the resolver address and the route that carries the query. Those three explain most MagicDNS surprises without another round of renaming.