Tailscale MagicDNS vs Pi-hole: Which Resolver Wins When Both Claim Your LAN

MagicDNS wants to name every tailnet node with a friendly hostname. Pi-hole wants to be the DNS brain of your LAN: blocklists, local records, maybe Unbound upstream. Point phones at both philosophies at once and you get the classic household mystery—some devices resolve nas one way, some another, and ad blocking vanishes the moment Tailscale’s DNS settings win the race.

This is about which resolver should win on which path, how to stop them from fighting, and what “wins” even means when the question is split between LAN browsing and tailnet reachability.

Two jobs that look like one job

Pi-hole’s job is LAN-centric DNS policy: filter queries, answer local names, forward the rest. It sits in the living-room trust boundary.

MagicDNS’s job is tailnet-centric naming: give nodes stable names inside Tailscale’s namespace so peers find each other without memorizing 100.x addresses. It sits in the mesh trust boundary.

Problems start when both claim to be “the” resolver for a device that lives in both worlds—every phone with Tailscale installed.

How devices actually choose

Operating systems do not hold a seminar about your homelab intentions. They follow DHCP DNS, private DNS settings, DoH in browsers, and VPN/mesh DNS configuration. Tailscale can push DNS configuration to clients. Pi-hole usually arrives via router DHCP. Whichever setting is more specific or more recently applied often wins—and it can win differently on iOS versus Android versus a Linux server.

Symptoms of a fight:

• Ad blocking works on the smart TV (no Tailscale) but not on your phone (Tailscale up)
• something.ts.net works while nas.lan fails—or the reverse
• Split results depending on whether the Tailscale app is connected
• Browsers with Secure DNS bypass both and confuse your debugging

When Pi-hole should win

Keep Pi-hole as the primary resolver for home when:

• Ad blocking and query logs for the household matter more than mesh names
• Most clients are not on Tailscale (TVs, IoT, guests)
• You already maintain local DNS records for LAN services
• You want one place to read “what looked up what”

In that world, Tailscale clients should be configured so they still use Pi-hole for general queries—or you accept that Tailscale devices are a separate DNS island and stop expecting identical filtering.

Use MagicDNS for node names without making MagicDNS the global resolver if your client settings allow that split. The exact toggles change over time; the principle does not: mesh naming can be additive instead of totalitarian.

When MagicDNS should win

Let Tailscale DNS lead when:

• You live on the road and the “LAN” is the tailnet
• Pi-hole is unreachable unless the mesh is already up (chicken and egg)
• You care more about finding nodes than filtering ads on that device
• Travel laptops should not depend on a home Pi-hole path for basic resolution

Travel routers and exit-node laptops often want Tailscale DNS so names work before any home subnet route is healthy. Forcing those clients through a home Pi-hole can strand them when the house path is down—or send hotel queries on a hairpin you did not intend.

Design patterns that stop the fight

1. Pi-hole for LAN DHCP; Tailscale override only for mesh names. Ideal when settings allow MagicDNS without replacing global DNS. Test after every OS update.

2. Pi-hole as Tailscale’s global DNS. Point Tailscale’s DNS config at the Pi-hole’s tailnet IP so mesh clients still filter. Requires Pi-hole reachable over Tailscale (advertise correctly, ACL carefully). Now Pi-hole must accept queries from 100.x sources.

3. Split horizons. Home SSID clients → Pi-hole. Travel devices → MagicDNS. Stop insisting on identical behavior.

4. Local records in both places carefully. Duplicating nas in Pi-hole and relying on MagicDNS for nas-1 is fine if names differ. Identical short names with different answers is how you earn support tickets from yourself.

5. Disable browser DoH while debugging. Otherwise you are not testing your stack.

Pi-hole over Tailscale: the gotchas

If remote clients use home Pi-hole via Tailscale, you inherit new failure modes: mesh down means DNS down unless fallbacks exist. Some clients handle multiple resolvers poorly. Put a sensible fallback upstream in the client OS only if you understand that fallbacks also bypass your blocklists.

Also watch ACLs: a Pi-hole open to the whole tailnet is a DNS oracle for every invited device. Limit which tags may query it if your household is not flat-trust.

Conditional forwarding and reverse DNS for LAN subnets get more interesting when queries arrive from Tailscale IPs. Expect to tune Pi-hole’s interface settings and network awareness.

MagicDNS and short names

Short names feel great until they collide with LAN short names. Prefer FQDNs in muscle memory for serious services: backup.home.arpa via Pi-hole, backup-host.<tailnet>.ts.net via MagicDNS. Teach family the media URL; keep admin names long and boring.

A practical decision rule

Ask per device class: is this device primarily a household browser or primarily a remote admin endpoint?

• Household browsers → Pi-hole wins
• Remote admin endpoints → MagicDNS wins
• Both → Pi-hole via Tailscale IP, with tested fallbacks and ACLs

Do not pick a winner for the entire apartment with one slogan. Pick winners per path.

Verification checklist

1. From a phone with Tailscale connected: nslookup / DNS debug for a blocked ad domain, a LAN name, and a tailnet node name.
2. Disconnect Tailscale; repeat.
3. From a TV without Tailscale: confirm Pi-hole still sees queries.
4. From a travel laptop on hotel Wi-Fi: confirm you can resolve what you need without hairpinning everything through a dead home path.
5. Document the intended resolver per device class in a note next to your ACL note.

If any step surprises you, the fight is still on.

Decision guide

Pi-hole wins for LAN policy, ads, and household query visibility.

MagicDNS wins for naming mesh peers, especially when off-LAN.

They coexist when Tailscale does not blindly replace LAN DNS—or when Tailscale deliberately uses Pi-hole as its resolver with reachability and ACLs designed for that.

The resolver that wins should be the one you chose, not the one the last OS toggle chose while you were fixing something else. When both claim your LAN, write the claim down—and test the phone that always lies.

IoT, TVs, and the devices that never run Tailscale

Smart TVs, game consoles, and cheap IoT will keep using DHCP DNS forever. That is an argument for keeping Pi-hole healthy on the LAN even if your personal devices go MagicDNS-first. When you change router DNS to experiment with Tailscale-only thinking, you can break the living room while your laptop still looks fine.

Segment experiments: test resolver changes on a single DHCP reservation or Wi-Fi SSID before flipping the whole apartment. Family members are excellent integration tests with low patience.

Unbound, upstreams, and double filtering

If Pi-hole already recurses with Unbound, and Tailscale also applies DNS filtering features, you can double-filter or double-fail. Prefer one policy engine. Extra layers sound safer and usually mean harder outage diagnosis. Pick Pi-hole as the filter or Tailscale as the filter for a given client class—not both with overlapping block philosophies.

Upstream choice still matters when Pi-hole is the winner: a flaky upstream looks like “DNS is broken” even when MagicDNS is innocent. Keep a known-good secondary upstream configured in Pi-hole, not a surprise OS fallback that bypasses logs.

A weekend migration without breaking breakfast

Saturday morning: write down current DHCP DNS, Tailscale DNS toggles on one phone, and a list of names you must resolve (NAS, Home Assistant, one ts.net node, one blocked ad test domain). Change only the phone’s Tailscale DNS behavior first. Run the verification checklist. Only then consider pointing Tailscale’s global DNS at Pi-hole’s tailnet address.

Sunday: fix ACLs so only family/admin tags can query Pi-hole remotely. Confirm IoT SSID still uses LAN Pi-hole without Tailscale in the path. If anything fails, roll back the phone before you touch the router. Router-wide DNS experiments are how “quick DNS fixes” become afternoon outages.

Keep a paper note of the last known-good settings. Screenshots go stale; a three-line card in the rack does not.

When the answer is “both, deliberately”

Many stable homes end here: Pi-hole owns the living room. MagicDNS owns node names for admin devices. Phones either use Pi-hole through Tailscale or accept different filtering while away from home. The explicit acceptance of different behavior is the mature state. The immature state is demanding identical DNS personality from a TV and a travel laptop.

Write that acceptance into your network notes so the next troubleshooting session does not start from the fantasy that one resolver must rule them all. When both claim your LAN, the adult move is to assign claims—not to install another DNS container and hope the conflict develops Stockholm syndrome.

Assign the claims, test the phone, spare the TV, and move on to a problem that is not DNS cosplay.