I'm going to say something that'll make network engineers wince. Some people are running three DNS overlays on one laptop and assuming it'll sort itself out. Daniel's one of them — well, not assuming. He's asking the question precisely because he knows it won't.
Three overlays. Commercial VPN, Tailscale, Cloudflare WARP. All on one machine. I'm already tense.
Here's what he wrote in. The concrete use case: a single laptop where Tailscale and Cloudflare Zero Trust exist purely to reach authenticated private resources — tailnet hosts by MagicDNS name, internal apps behind Access — while a commercial VPN carries all general internet traffic. Nothing ever egresses raw on the local ISP link. DNS is the hard part. All three want to install their own resolver, and the failure mode is silent — things keep working while queries leak to the wrong place.
That's the scary part. Silent failure. Your browser loads, everything feels fine — and your DNS queries are spraying out to three different resolvers, one of which is your ISP's, completely unencrypted.
He's asking the full stack. How do you run all three without any of them hijacking the others' DNS, and without ever falling back to raw unprotected resolution? What are the common interference points, the per-client configuration to prevent overrides, the best way to guarantee no unencrypted fallback, and the tools to monitor and verify DNS handling across all three?
That's a systems design question dressed up as a settings question. And the answer — spoiler — involves accepting that none of these clients were designed to share.
Today we're untangling the DNS knot. Where these clients collide, and how to make them coexist without leaking a single query.
So let's set the scene. A modern laptop has a DNS resolver configuration that is, by design, a single point of control. On Linux it's slash etc slash resolv dot conf, or systemd-resolved if you're on a modern distro. On macOS it's the network adapter's DNS settings, managed through the System Configuration framework. On Windows it's the adapter properties, or the DNS over HTTPS settings in the network stack.
One file, one list of servers. Very simple.
Very simple, and completely incapable of representing the idea that different applications might want different resolvers. The OS thinks there's one DNS configuration. Period. So when you install three tools that all believe they own the DNS stack, they all write to that same configuration. The last one to write wins.
And the first two don't know they lost.
They don't. That's the core of it. A commercial VPN connects, it pushes its own DNS servers into the system config — often as a leak prevention measure. If you didn't force all DNS through the VPN tunnel, a query could go out your local link and reveal what sites you're visiting. So the VPN client says, I'm taking over DNS, here are my servers.
Then Tailscale connects.
Tailscale brings MagicDNS, which maps your tailnet hostnames — server dot cat-pictures dot ts dot net — to their Tailscale IPs. To do that, it needs to intercept your DNS queries. On by default, it sets itself as the system resolver, or at least inserts itself into the resolution path. There's a toggle called Override Local DNS that, when enabled, makes Tailscale the authoritative resolver for everything, not just tailnet names.
And if you're using a Mullvad exit node through Tailscale, there's a documented case on the Pi-hole forum where MagicDNS overrode Mullvad's DNS settings entirely. The user had Tailscale with a Mullvad exit node for privacy, and Pi-hole for ad blocking. MagicDNS took over, queries bypassed Pi-hole, and suddenly they had DNS leaks to the local resolver. Everything still worked — pages loaded, ads appeared — but the DNS path was completely wrong.
Then Cloudflare WARP connects. WARP encrypts your DNS and routes it through Cloudflare's network. In its default mode, it rewrites the system resolver to one dot one dot one dot one. If you enable DNS over HTTPS mode, it goes further, setting up an encrypted tunnel specifically for DNS. And if you're using Zero Trust with Gateway policies, it needs to intercept DNS to enforce your organization's filtering rules.
So we've got three clients. VPN forces its servers. Tailscale forces MagicDNS. WARP forces one dot one dot one dot one. They all write to the same config file. The last one to connect wins, and the other two are silently defeated.
And here's where it gets worse. These clients create virtual network interfaces — utun interfaces on macOS, wintun on Windows. Each one is a tunnel. The OS has a routing table that decides which interface gets which traffic. If WARP creates a default route that says all traffic goes through WARP, but Tailscale's routes are more specific for the hundred dot sixty-four dot zero dot zero slash ten range, you've got a routing priority question.
Which the OS answers with a metric. Lowest metric wins for the default route. But DNS doesn't follow routes the same way — it follows the resolver configuration. So your traffic might go through the VPN tunnel while your DNS queries go to WARP's resolver.
Split tunneling makes this even more tangled. Tailscale's exit nodes route all your traffic through a specific node on your tailnet. WARP has split tunnel rules that let you exclude certain IP ranges or applications from its tunnel. A commercial VPN might have its own split tunneling, routing only specific apps through the encrypted connection.
So you configure WARP to exclude Tailscale's IP range. Smart. But did you also exclude Tailscale's DNS server IP? Because if WARP is still intercepting DNS, queries for internal tailnet names go to one dot one dot one dot one, which has no idea what server dot cat-pictures dot ts dot net is. Resolution fails.
And failure is where the real danger lives. When a DNS query fails — the resolver is unreachable, or it returns NXDOMAIN, or it times out — the OS doesn't just give up. It falls back. On most systems, if the primary resolver doesn't respond, the OS tries the secondary. If none of the configured resolvers work...
It goes raw. Plain UDP to whatever the DHCP server handed it. Your ISP's resolver, unencrypted, logging every domain you visit.
That's the fallback trap Daniel's worried about. You can configure DNS over HTTPS everywhere, set up encrypted resolvers for every client, and still leak queries the moment something times out. The fallback is silent. Your browser shows the page. You never know the query went out in the clear.
Let me make this concrete with how the interfaces actually collide. Tailscale uses a hundred dot one hundred dot one hundred dot one hundred as its MagicDNS resolver address. That's a virtual IP — it only exists inside Tailscale's network stack. When MagicDNS is active, your DNS queries go to that address, and Tailscale resolves them using its internal mapping.
WARP also uses a hundred dot one hundred dot one hundred dot one hundred in some configurations. Same address, different meaning. If both clients claim that IP, you've got a conflict at the interface level before you even get to DNS.
And the commercial VPN? It might push its own DNS server — say, ten dot eight dot eight dot eight — which is only reachable inside the VPN tunnel. If the tunnel drops for a split second, that resolver is unreachable. The OS falls back. Query leaks.
The fundamental problem is that each of these clients assumes it's the only thing managing DNS. They're not designed to cooperate. Tailscale's documentation is clear — the Override Local DNS option exists specifically to take control. WARP's Windows GA release from October twenty twenty-five explicitly notes changes to DNS handling that could override existing configurations. They're not hiding it. They're telling you this is how it works.
So what do you actually do? Daniel's asking for the configuration strategy, not just the diagnosis.
Step one is to stop letting them fight over the system resolver. The approach I'd recommend is a local DNS proxy — something like dnsmasq or stubby — listening on localhost, port fifty-three. This proxy is your choke point. It receives every DNS query from your machine and forwards them via DNS over HTTPS or DNS over TLS to a trusted upstream resolver. The key is that this proxy never falls back to plain DNS. It's configured to only speak encrypted protocols.
One choke point. One place where unencrypted fallback is impossible because the proxy doesn't know how to do it.
You configure dnsmasq to forward to a DoH endpoint — say, Cloudflare's one dot one dot one dot one over HTTPS — and you disable any plain UDP upstream. If the DoH connection fails, dnsmasq returns SERVFAIL. It does not fall back. Your applications see a failure, which is annoying but not a privacy leak.
Better a broken page than a leaked query.
That's the tradeoff. Now, you point every client at this proxy. Set your system resolver to one twenty-seven dot zero dot zero dot one. The commercial VPN, Tailscale, WARP — they all think they're talking to a local resolver, which they are. The proxy handles the actual upstream resolution.
But they'll still try to overwrite the system resolver.
They will. So step two is client-specific configuration to stop that. For Tailscale, you disable Override Local DNS. This is the big one. With that off, Tailscale won't touch your system resolver. You then use Tailscale's split DNS feature — under the DNS settings in the admin console — to specify that queries for your tailnet domain, like dot ts dot net, go to Tailscale's MagicDNS resolver at a hundred dot one hundred dot one hundred dot one hundred. Everything else goes to your local proxy.
And Accept DNS?
Accept DNS controls whether Tailscale accepts DNS configuration from the admin console at all. For this setup, you want it on, but with a very specific configuration — only the tailnet domain goes to MagicDNS. Nothing else.
So Tailscale handles internal names, and hands everything else off.
Right. Now WARP. WARP is the least forgiving of the three when it comes to sharing. Its whole security model assumes it controls DNS. But you can configure it. In the WARP client settings, under Split Tunnels, you create an exclude rule for Tailscale's DNS server — a hundred dot one hundred dot one hundred dot one hundred — and for your local proxy at one twenty-seven dot zero dot zero dot one. This tells WARP not to route those IPs through its tunnel.
You're carving out exceptions so WARP doesn't intercept the queries meant for Tailscale or for the local proxy.
Yes. And for the commercial VPN, the critical setting is usually called something like DNS Leak Protection or Force VPN DNS. You need a VPN that allows you to specify custom DNS servers, or that respects the system resolver when leak protection is configured properly. Some VPNs, when you enable leak protection, hardcode the system resolver to their servers and ignore everything else. That's exactly what we don't want.
Some VPNs let you set a custom DNS. You'd point it at the local proxy.
If the VPN supports it, yes. Set the VPN's DNS to one twenty-seven dot zero dot zero one. The query goes through the VPN tunnel — because the VPN client is routing all traffic — but the actual resolution happens at your local proxy, which forwards it encrypted to your upstream. The VPN sees the encrypted DoH connection, not the DNS query contents.
That's assuming the VPN's custom DNS setting actually sticks and doesn't get overridden by the client's own leak protection logic.
Yes. And that's platform-specific. On macOS, the network extension framework gives VPN clients a lot of power to intercept DNS. On Linux with systemd-resolved, you've got more control — you can configure resolved to use specific resolvers per interface, and set the VPN interface to use your local proxy. On Windows, the DNS over HTTPS support in the network stack adds another layer — you can set DoH at the adapter level, but WARP might override it.
The sane answer, and I think you're heading here, is that stacking three clients on one host might not be the sane answer.
It might not be. The cleaner architecture is to push the split onto a router or a dedicated box. Run Tailscale on your router, or on a Raspberry Pi that acts as a DNS proxy for your whole network. The commercial VPN runs on the router too, or on a separate VLAN. Your laptop connects to the router, gets its DNS from the proxy, and doesn't run any of these clients locally.
But Daniel's use case is a laptop. Mobile. Coffee shops, airports. The router solution doesn't travel.
No, it doesn't. So for the mobile case, you're stuck with the local proxy approach. And you need to verify it's actually working.
This is the part where most people stop. They configure everything, run a DNS leak test, see Cloudflare's IPs, and call it done.
And that's insufficient. A DNS leak test — dnsleaktest dot com, ipleak dot net — shows you which resolver answered the query. If you see only Cloudflare IPs, that's good. But it doesn't show you the path. It doesn't tell you whether the query went through the VPN tunnel, or through WARP, or directly to Cloudflare over your local link. It just shows the endpoint.
You need to watch resolution live.
You do. On macOS and Linux, dig with the plus trace flag shows you the full resolution path — which servers were queried, in what order. You can see if a query hit your local proxy, then went to Cloudflare, or if it somehow bypassed the proxy and went straight to your ISP.
tcpdump or Wireshark on port fifty-three. Filter for DNS traffic. You'll see plaintext queries instantly — they stick out. If you've configured everything for DoH, you should see zero plaintext DNS on the wire.
And on systems with systemd-resolved, resolvectl status gives you a clean view of the current DNS configuration per interface. You can see which resolver is set for which link, and whether any of them are using plain DNS.
I'd add one more. Query a tailnet hostname — something that only MagicDNS can resolve. If it resolves, Tailscale's split DNS is working. If it doesn't, something intercepted the query before it reached MagicDNS.
That's a good functional test. And query something that should be filtered by your VPN's DNS — if the VPN pushes a resolver that blocks malware domains, try resolving a known bad domain. If it resolves, the VPN's DNS isn't being used.
So the verification checklist: dig plus trace for the resolution path, tcpdump for plaintext leakage, resolvectl for interface configuration, and functional tests for each client's DNS features.
And you do this after every client update. That's the part people miss. WARP's Windows GA release in October twenty twenty-five changed DNS handling. Tailscale releases updates that tweak MagicDNS behavior. Commercial VPNs push updates that modify leak protection. Any one of these can silently break your carefully constructed hierarchy.
The setup is fragile by nature. You're working against the design intent of three different products.
That's the systemic insight. This isn't a configuration problem with a set-and-forget solution. It's a maintenance problem. You're the DNS policy manager for your machine, and none of the tools you're using acknowledge your authority. They all think they're in charge.
Which brings us to the question of kill switches. Daniel mentioned the fallback that appears when a tunnel drops, and whether kill switches actually cover DNS or only routing.
Most VPN kill switches are routing-level. They prevent traffic from leaving your machine on any interface except the VPN tunnel. If the tunnel drops, the kill switch blocks all packets. But DNS is sneaky. Some kill switches block IP traffic but don't block DNS queries — because DNS is often handled by a separate system service that the kill switch doesn't control. The query goes out on port fifty-three, the kill switch sees it as a DNS packet rather than a general IP packet, and...
It slips through.
It can. You need to test this. Drop the VPN tunnel intentionally — disconnect it — and immediately run a DNS query. Watch tcpdump. If you see a plaintext query leave your machine in that window before the kill switch engages, you've got a gap.
And WARP's kill switch equivalent? If WARP is your primary DNS path and it drops?
WARP has a similar mechanism — it can block traffic outside the tunnel. But if you've configured split tunnels that exclude Tailscale's DNS, and WARP drops, your queries might fall back to Tailscale's resolver, or to the system resolver, depending on what's configured. The fallback chain is complex and platform-specific.
So the local proxy approach handles this more cleanly. The proxy doesn't have a fallback. It either resolves via DoH or it fails. No plaintext path exists.
That's why I keep coming back to the local proxy as the foundation. Everything else is layered on top.
Let me ask you something. You've been doing this long enough — have you ever had a setup that survived more than six months without breaking?
Honestly? No. Something always changes. A macOS update reshuffles the network extension order. A WARP update decides it needs to be the primary resolver again. Tailscale adds a feature that subtly alters how split DNS works. I've had setups that worked beautifully for weeks and then broke overnight because of an automatic update I didn't even notice.
So the real advice is, pick the minimum set of clients you actually need.
If you can get away with Tailscale plus a commercial VPN and skip WARP, do it. If WARP's Gateway policies are essential for your organization, maybe the commercial VPN is the one to drop. Every client you add multiplies the failure pattern.
Daniel's use case needs all three. Tailscale for tailnet access, WARP for Zero Trust and Gateway, commercial VPN for general traffic privacy.
Then he's signing up for ongoing maintenance. The configuration we've described — local DNS proxy, Tailscale split DNS with Override Local DNS disabled, WARP split tunnels excluding Tailscale's resolver, VPN custom DNS pointing to the proxy — that'll work. Today. On most platforms. But he needs to verify it regularly.
There's also the question of what happens to MagicDNS names when a full-tunnel VPN takes over resolution. If the commercial VPN forces all DNS through its own servers, and those servers can't resolve tailnet names...
They can't. MagicDNS names only resolve through Tailscale's resolver. If the VPN intercepts a query for server dot cat-pictures dot ts dot net and sends it to the VPN's DNS server, that server will return NXDOMAIN. The name doesn't exist in public DNS. Your internal services become unreachable.
Even though Tailscale is still connected, even though the tailnet is healthy.
Yes. Because the DNS query never reached Tailscale. The VPN grabbed it first. This is why the order of operations matters — Tailscale's split DNS needs to be consulted before the VPN's resolver for tailnet domains. With the local proxy approach, you can configure the proxy to route dot ts dot net queries to MagicDNS and everything else to the VPN's resolver or to DoH.
The proxy becomes the traffic cop.
It does. And dnsmasq can do this. You add a line like server equals slash ts dot net slash a hundred dot one hundred dot one hundred dot one hundred. Queries for anything ending in dot ts dot net go to MagicDNS. Everything else follows the default upstream.
That's elegant. One config file, one decision point.
And it survives client updates, mostly, because the clients are all pointed at one twenty-seven dot zero dot zero one. They don't know about the routing logic happening behind the proxy. They just see a local resolver.
Until one of them decides one twenty-seven dot zero dot zero one isn't good enough and overwrites it.
Yes. That's the arms race. And that's why verification isn't optional.
Before we move on, I want to touch on something Daniel mentioned about the difference between a VPN that hijacks all DNS and one that respects split-DNS handoff. This is a real distinction in how VPN clients are built.
It is. Some VPNs — especially the privacy-focused ones — take an all-or-nothing approach. They set themselves as the default route and force all DNS through their servers. The reasoning is sound: if any DNS query goes outside the tunnel, it's a potential leak. But it breaks coexistence with other tools.
Others let you define split DNS — these domains go through the VPN, these don't. Or they let you specify custom DNS servers per connection.
Mullvad is interesting here because it integrates with Tailscale. You can use a Mullvad exit node through Tailscale, and Tailscale handles the DNS. But as that Pi-hole forum thread documented, MagicDNS can override Mullvad's DNS settings in ways that surprise users. The integration is real, but the DNS handoff isn't always clean.
So even when the tools are designed to work together, the DNS layer can break.
DNS is always the hardest part. Always. It's a protocol from nineteen eighty-three that's been stretched to do things its designers never imagined. Encrypted DNS, split horizons, internal namespaces — none of this was in the original spec. We're layering complexity on a foundation that assumes one resolver, one answer, one path.
And yet it all still mostly works.
It does. And when it breaks, it breaks silently. That's the part that keeps me up at night.
Hilbert, you've been quiet. You've got that look.
Hilbert: Hundred dot one hundred dot one hundred dot one hundred. You said Tailscale and WARP both use it. They do. What you didn't mention is that it's not a real IP. It's a CGNAT address — carrier-grade NAT space, RFC sixty-five ninety-eight. Reserved for internal use. Never routable on the public internet.
Right, it's from the shared address space.
Hilbert: Which means if either client binds it to a loopback interface, the other one can't. It's not like two DHCP servers on a LAN where you get a conflict warning. The second client just fails to bind. Silently. The interface comes up, the IP isn't there, and the client doesn't log anything useful. I spent three days on this in ninety-eight.
Ninety-eight?
Hilbert: I was running DNS for a small ISP in Connecticut. We had a customer who insisted on running two VPN clients on his Windows NT machine. Different vendors. Both tried to claim the same internal IP for their virtual adapters. Second one would install, the machine would bluescreen on reboot. Took me a weekend to figure out it was an IP conflict at the virtual adapter level, not a driver issue.
An IP conflict causing a bluescreen. That's very Windows NT.
Hilbert: The fix was to unplug the modem, force the stack to reset, then bring the interfaces up in a specific order. Modem first, then VPN one, then VPN two. If you got the order wrong, bluescreen. I wrote it on a Post-it note and stuck it to the customer's monitor. He called me every time it rained because the modem would reconnect and the order would be wrong.
The Post-it note was the documentation.
Hilbert: It was. I still have that Post-it. It's in a box somewhere. Anyway, the hundred dot one hundred dot one hundred dot one hundred thing — it's the same class of problem. Two clients, one address, no conflict resolution. The second one just loses.
And the user never knows unless they check.
Hilbert: They never check. I run a Pi now. Raspberry Pi four, sits in my hallway, runs dnsmasq. Every device on my network points to it. Tailscale is on the Pi, not on my laptop. WARP is on the Pi. The commercial VPN — I don't run one. I trust the Pi.
You moved the complexity off your machine entirely.
Hilbert: I learned. You can't trust a laptop to manage three DNS clients. It's not what the operating system was built for. The Pi is my choke point. One place, one config, one thing to break.
That's the router solution we were talking about.
Hilbert: It is. And I disabled MagicDNS on my laptop. Kept overriding my Pi-hole. I was getting ads again and it took me a week to notice. Tailscale's MagicDNS is useful but it doesn't play well with others. I've been meaning to write a blog post about it.
How long have you been meaning to write that?
Hilbert: Three years. Maybe four.
Sounds about right.
Hilbert: The DNS proxy approach you described — dnsmasq on localhost, all clients pointed at it, no fallback — that's the right answer for a mobile setup. But I'd add one thing. Log the queries. dnsmasq can log every DNS request to a file. If something breaks, you've got a record of what was being queried and where it went. Without logs, you're guessing.
Logging adds a privacy consideration — you're storing DNS query history locally.
Hilbert: Encrypt the log file. Rotate it daily. Or don't. Up to you. But when something leaks, you'll want to know what and when. I've been burned too many times by silent failures. The log is your insurance.
Hilbert, the Post-it note. Do you know which box?
Hilbert: Somewhere in the closet. With the token ring adapters and the copy of OS two Warp I can't bring myself to throw away.
OS two Warp. Now there's a DNS stack I haven't thought about in decades.
Hilbert: It had better DNS than Windows NT. Just saying.
I believe you.
So where does this leave us? The configuration strategy exists. Local DNS proxy, careful split DNS rules, per-client settings to stop the resolver hijacking, and a verification routine that you actually run. It works today. It might not work after the next automatic update.
The open question is whether we'll ever get a unified DNS management standard across these tools. Something like a DNS policy manager that all the clients respect — a single configuration point where you declare your intent, and the clients negotiate among themselves.
I'm skeptical. Each of these tools has a legitimate reason to want control of DNS. Tailscale needs it for MagicDNS. WARP needs it for Gateway filtering. VPNs need it for leak prevention. A unified standard would require them to give up some of that control, and I don't see the incentive.
The incentive is that power users — the kind of people running three overlays on one machine — are increasingly frustrated. They'll either build workarounds like the local proxy, or they'll abandon one of the tools.
Or they'll do what Hilbert did and push the complexity onto a dedicated box. That's probably the long-term trend. DNS management moves to the network layer, not the endpoint.
The real takeaway is that DNS is the silent backbone of privacy. You can encrypt all the traffic you want, but if your DNS queries are leaking, you've revealed the map of everywhere you go online. Managing it across multiple tools is a constant battle.
One worth fighting. But go in with your eyes open. Verify, don't assume.
Thanks to Hilbert Flumingtop for producing, and for the Post-it note we'll never see.
This has been My Weird Prompts. Find us at my weird prompts dot com, or email the show at show at my weird prompts dot com.
We'll be back soon. Check your resolvers.
