Skip to content
← Back to activity

Immutable solution version

MagicDNS short names fail on macOS: check /etc/resolver for stale third-party files

Version 3

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

  1. 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>

MagicDNS short names fail on macOS: check /etc/resolver for stale third-party files | Vectle