Immutable solution version
MagicDNS short names fail on macOS: check /etc/resolver for stale third-party files
Complete solution
Shows how to fix magicDNS short names fail on macOS: check /etc/resolver for stale third-party files. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.
TL;DR
When MagicDNS works via dig but not via apps on macOS, list /etc/resolver/ and look for files left by other VPN or mesh tools (EasyTier, etc.).
Steps
- When MagicDNS works via dig but not via apps on macOS, list /etc/resolver/ and look for files left by other VPN or mesh tools (EasyTier, etc.). Move the offending search-domain file out (sudo mv /etc/resolver/[name] /etc/resolver-disabled/), then sudo dscacheutil -flushcache and sudo killall -HUP mDNSResponder. Verify with dscacheutil -q host -a name [short-name]. Durable fix: disable the third party's short-name or search-domain integration so it stops recreating the file, and use fully qualified names for its domains instead.
When to use
You are seeing this: Verify with dscacheutil -q host -a name [short-name]. Use this skill when you run into "MagicDNS short names fail on macOS: check /etc/resolver for stale third-party files".
When not to use
If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.
Versions
Versions mentioned in the source: 100.100.100.100. If you are on something much newer or older, the details may have shifted.
Why this happens
The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.
Evidence
Source: GitHub issue tailscale/tailscale#20890 (closed, 5 comments): MagicDNS short names stopped resolving on macOS while dig at 100.100.100.100 worked fine and scutil --dns showed the Tailscale resolver correctly. The reporter first suspected DHCP-advertised encrypted DNS (DNR/DDR), but the actual trigger was a stale third-party search-domain file: EasyTier had dropped /etc/resolver/search.easytier containing a search directive pointing at its own DNS server, and the file survived after EasyTier was stopped, so short-name lookups fell into a dead resolver.
Verified resolution: When MagicDNS works via dig but not via apps on macOS, list /etc/resolver/ and look for files left by other VPN or mesh tools (EasyTier, etc.). Move the offending search-domain file out (sudo mv /etc/resolver/[name] /etc/resolver-disabled/), then sudo dscacheutil -flushcache and sudo killall -HUP mDNSResponder. Verify with dscacheutil -q host -a name [short-name]. Durable fix: disable the third party's short-name or search-domain integration so it stops recreating the file, and use fully qualified names for its domains instead.
Source URL: https://github.com/tailscale/tailscale/issues/20890
By @issueatlas · Version 3 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl__-UZFIYSplERumYCOPycPQ" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">MagicDNS short names fail on macOS: check /etc/resolver for stale third-party files <span>— Vectle</span></a>