Tailscale MagicDNS Works but nslookup Fails on macOS

On a Mac, ping resolves a tailnet machine name while nslookup returns a failure, and both commands are telling the truth. Applications resolve through the system resolver, which Tailscale configures per interface, while nslookup and host read a static file that MagicDNS never touches. The two paths can disagree without a single packet going missing. Decide which path your failing application took before you change any DNS setting.

Two resolution paths, two different answers

Application traffic on macOS goes through the system resolver, and scoped resolver entries per interface decide which server answers for which domain. Tailscale installs its MagicDNS entry there, which is why Safari and ssh find tailnet names. nslookup, host and dig instead read /etc/resolv.conf or take a server on the command line, and that file usually still names the router or an office server. A tailnet name sent to that file has no authoritative answer waiting for it, so the tool reports failure while the system path succeeds.

Neither tool is misbehaving. They ask different servers, and only one of those servers knows about your tailnet.

Test the same name through the system path

Use the system lookup call as the first test, then compare it with a query aimed at the MagicDNS resolver directly. Keep the spelling identical in both, including the tailnet domain, because a short name and a fully qualified name are different questions with different answers.

dscacheutil -q host -a name nas-01.tailnet-a1b2.ts.net
scutil --dns
dig @100.100.100.100 nas-01.tailnet-a1b2.ts.net

Those three outputs answer three questions: what the system returns, which resolvers are configured for which domains, and what MagicDNS itself knows. A name present in the second and third but missing from the first points at local configuration rather than at the tailnet.

Once the name resolves, test the service

A correct DNS answer proves only that a name maps to an address. The service behind it can be stopped, the port can be filtered by an access rule, and a certificate can name a different host from the one you typed.

nc -vz nas-01.tailnet-a1b2.ts.net 445
ping -c 3 nas-01.tailnet-a1b2.ts.net

Keep the original error text, because a certificate warning, a connection timeout and a name-not-found each lead somewhere different. Changing nameservers repairs the third and wastes an afternoon on the first two.

MagicDNS is not a substitute for office DNS

A name inside an office zone is not a tailnet device name even when the same client can reach both. When the destination sits behind a subnet router, the client needs split DNS for that zone pointing at the internal resolver, which is a different setting from MagicDNS and is documented alongside it.

Search domains matter as well. An unqualified short name gets each configured suffix appended in order, so a laptop that recently joined another network can resolve through a stale suffix. Check which suffix was applied before declaring the zone broken.

When both paths fail, the tailnet facts decide

If the system lookup and the direct query both fail for a device you believe exists, the problem sits upstream of the Mac's resolver.

Confirm the machine name and tailnet domain in the admin console, confirm the device is online and approved, and confirm the client's DNS settings have not been disabled locally. A device that is offline keeps its name and simply has no address to return.

Then choose by evidence. A name that resolves in the system path and fails in nslookup is a tool-path difference; a name that resolves while the service refuses is an access or certificate problem; a name that resolves nowhere is a tailnet or DNS configuration problem. Three owners, three fixes, and the MagicDNS documentation covers the macOS specifics of the first case.