OK so this one has been driving me absolutely crazy. You’re on your Mac, everything is working great except when you try to log to one of those pesky Public Hotspots. These are the ones that do DNS magic (they basically seize any DNS request and redirect them to the logon screen. I tried the usual things, is NordVPN or ProtonVPN active, if so, it will try to do a connection and prevents the public page from happening.
Sign, then I somehow remember to look at the actual DNS settings for the WiFi and instead of some grey numbers (which indicates that the Mac is using the default DNS and so that the public logon screen will show, I see 100.100.100.100. What the heck is that and why is it stuck there? The answer is at one time you installed Tailscale on this machine and it borked and left this there. The result is that nothing works and this menu item is BURIED deep, try System Settings > WiFi > Details > DNS
TL;DR
Tailscale sets your Mac’s DNS to 100.100.100.100, which is a local DNS resolver running inside the Tailscale daemon on your own machine. When Tailscale crashes, disconnects, or gets confused (especially after sleep or network changes), that resolver goes dead but macOS still points at it. Result: total DNS failure. The fix is to toggle Tailscale off/on, flush DNS, or manually set your DNS back. Read on for the gory details. Or if you don’t need Tailscale just uninstall it.
What is 100.100.100.100 anyway?
First things first. This address is what Tailscale calls “Quad100” (like Cloudflare’s “Quad1” at 1.1.1.1 or Google’s “Quad8” at 8.8.8.8 which are both well know DNS servers, note that if you hard set your DNS to these, then the public WiFi Hotspots won’t work). But unlike those, it’s not a public DNS server. It’s a virtual DNS resolver built into every Tailscale node that runs locally inside the tailscaled process on your device. The address sits in the CGNAT range (100.64.0.0/10, RFC 6598) which is not routable on the public internet, so DNS queries to it literally never leave your machine.
When Tailscale is running and healthy, this is actually pretty clever. Your machine sends DNS queries to 100.100.100.100, the TUN device intercepts them, and Tailscale’s internal resolver answers tailnet names instantly from an in-memory map (MagicDNS) and forwards everything else to your upstream DNS servers. Zero network round trips for tailnet names. Nice.
The problem is what happens when Tailscale is not healthy.
How it gets set on macOS
On Mac, Tailscale runs as a Network Extension using Apple’s NEPacketTunnelProvider API. When the VPN tunnel starts, the Swift code calls setTunnelNetworkSettings() with DNS settings that include 100.100.100.100 as the nameserver plus your tailnet search domains. The OS registers this on the utun interface via configd. You can see it with scutil --dns.
There are three ways to run Tailscale on macOS: the Mac App Store version (sandboxed), the standalone .pkg version (System Extension with root), and the open-source CLI (tailscaled). The first two automatically configure DNS this way. The CLI version does not automatically set system DNS — you’d have to manually configure resolv.conf or point your DNS to 100.100.100.100 yourself.
Why it gets stuck: the known bugs
This is where the pain lives. There are multiple open GitHub issues going back years, and the root cause is always the same: macOS still points at 100.100.100.100 but the Tailscale resolver is no longer answering.
1. tailscale down doesn’t restore DNS
Issue #16466 (July 2025). After running tailscale up, your /etc/resolv.conf gets set to 100.100.100.100. When you run tailscale down, the DNS settings are not restored. All name resolution breaks. The only fix reported was revoking network permissions for Tailscale entirely in System Settings. This is on macOS Sequoia 15.1 with Tailscale 1.84.1.
2. Wake from sleep breaks DNS
Issue #14867 (February 2025). On an M2 Max MacBook, waking from sleep means you’re connected to Wi-Fi but can’t resolve anything. Tailscale takes DNS precedence but the resolver isn’t ready yet after sleep. Disabling Tailscale immediately fixes it. Re-enabling also works. So the workaround is toggle off/on every time you open your laptop lid. Annoying.
3. Network changes and captive portals
Issue #12664 (June 2024). After changing Wi-Fi networks or hitting a captive portal, Tailscale gets into a state where MagicDNS names resolve fine but internet DNS is broken. The reporter got in the habit of toggling Tailscale off and on after every connectivity change. That’s macOS 14.5 with Tailscale 1.68.1.
4. macOS firewall interaction
Issue #13511 (September 2024). This is the scary one. On macOS with “Block all incoming connections” firewall setting, UDP sessions get transiently blocked. dig against 100.100.100.100 still works but system DNS APIs hang. In one case, this progressively locked up the entire system to the point of requiring a hard power cycle. The team confirmed this is substantially more likely with the firewall’s “block all incoming” setting enabled.
5. macOS Sequoia and macOS 26 specific issues
Issue #13423 (September 2024). On macOS Sequoia 15.0, enabling “Use Tailscale DNS settings” causes most apps except Safari to fail DNS lookups. Safari uses a different resolution path which is why it keeps working.
Issue #18668 (February 2026). Same thing on macOS 26.2 with Tailscale 1.94.1. Connecting Tailscale breaks web browsing (ping works), disconnecting restores it. Turning off “Use Tailscale DNS Settings” fixes it. Works fine on macOS 15.7 with the same Tailscale version.
6. /etc/resolv.conf stuck at 100.100.100.100
Issue #3817 (January 2022). Even with custom DNS set (not MagicDNS), /etc/resolv.conf shows 100.100.100.100 instead of the configured upstream servers. This one is from 2022 and the pattern keeps repeating.
7. MagicDNS plus network disconnect
Issue #15385 (March 2025). Tailscale running but not logged in, /etc/resolv.conf stuck with just 100.100.100.100 as resolver, and it doesn’t resolve anything. The machine was completely stuck — tailscaled kept trying bootstrap DNS lookups against DERP servers for hours. The reporter noted they’d assume Tailscale wouldn’t break DNS resolution for the whole system, but would fall back to previous entries. It didn’t.
8. Rapid connect/disconnect cycling
Issue #16505 (July 2025). Tailscale enters a rapid connect/disconnect loop causing routing table conflicts between the regular internet gateway (en0) and the VPN tunnel (utun6). The constant flapping confuses the OS and breaks DNS resolution along with general connectivity. Even worse, Tailscale doesn’t respect the “Not Connected” state and forcibly attempts reconnection even with Connect On Demand off.
Other related issues
There are more open issues touching this same DNS-stuck pattern including split DNS on macOS apps that read /etc/resolv.conf, custom DNS resolver not properly configured on macOS, iOS encrypted DNS not working with Tailscale active, and IPv6 support for the Network Extension on macOS/iOS. The DNS subsystem architecture is documented in the Go net/dns package if you want to read the code, and DeepWiki has a good walkthrough of the resolver, forwarder, and OS manager components.
Why this happens architecturally
The Network Extension sets DNS via NEPacketTunnelNetworkSettings, which registers 100.100.100.100 with macOS’s configd. The cleanup path — restoring original DNS when Tailscale disconnects — depends on the Network Extension gracefully calling setTunnelNetworkSettings with nil or the tunnel properly tearing down.
If the daemon crashes, the system extension stalls, or the IPC between the GUI app and the network extension breaks (which happens on wake, network changes, and crashes), the OS is left pointing at a dead resolver with no fallback. macOS does not automatically fall back to the DHCP-provided DNS when the VPN DNS stops responding. It just… waits. And times out. On every single query.
The Tailscale troubleshooting docs mention you can use the Debug menu > Reset option which deletes and reinstalls the VPN configuration, and Debug > Flush DNS Cache to clear the macOS DNS cache. But these are band-aids on a systemic problem.
How to fix it right now
If you’re stuck right now with dead DNS, here’s what to do in order of least to most disruptive:
Toggle Tailscale. Click the Tailscale menu bar icon, turn it off, wait a few seconds, turn it back on. This forces a clean tunnel teardown and rebuild, which usually restores DNS properly.
Flush the DNS cache. Open Terminal and run:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Manually reset your DNS. Go to System Settings → Wi-Fi → Details (on your network) → DNS, and manually add 8.8.8.8 or 1.1.1.1 or your router’s IP. This overrides whatever Tailscale left behind.
Use the Debug > Reset option. In the Tailscale menu bar, hold Option and click to get the Debug menu (or it may be visible by default depending on version). Select Reset to delete and reinstall the VPN configuration from scratch.
Disable “Use Tailscale DNS Settings.” If you don’t actually need MagicDNS (resolving tailnet hostnames by name), turn this off either in the Tailscale admin console under DNS settings, or per-device. This is the nuclear option but it’s the most reliable long-term fix if you keep hitting this bug.
Check your macOS firewall. If you have “Block all incoming connections” enabled in System Settings → Network → Firewall, be aware this dramatically increases the likelihood of the DNS hang bug. Consider adding Tailscale as an exception or switching to “allow incoming” while Tailscale is active.
The bottom line
This has been an open class of bugs since at least January 2022 and spans macOS Monterey through macOS 26. Tailscale knows about it. The fundamental issue is that Apple’s Network Extension framework doesn’t have a great story for “the VPN died unexpectedly, please restore the original DNS.” Every VPN that configures DNS through NEPacketTunnelProvidercan potentially hit this, but Tailscale’s always-on daemon-plus-GUI-app architecture with its local Quad100 resolvermakes it especially prone to the failure mode where the DNS target address exists in the routing table but nothing is listening there.
Until there’s a real fix, keep that toggle-off-and-on muscle memory ready. And maybe bookmark this post for the next time your Mac decides 100.100.100.100 is the only DNS server in the world. 🙂
Leave a Reply