Why MagicDNS alone can't name your home services on Tailscale

Published Nov 7, 2026, 10:01 AM EST Maker, meme-r, and unabashed geek, Joe has been writing about technology since starting his career in 2018 at KnowTechie. He's covered everything from Apple to apps and crowdfunding and loves getting to the bottom of complicated topics. In that time, he's also written for SlashGear and numerous corporate clients before finding his home at XDA in the spring of 2023. He was the kid who took apart every toy to see how it worked, even if it didn't exactly go back together afterward. That's given him a solid background for explaining how complex systems work together, and he promises he's gotten better at the putting things back together stage since then. Tailscale has a party trick I still find a little magical: install it on a box, and ten seconds later I can type pve from a coffee shop and land on my Proxmox host. No port forwards, no DNS records, no router IP range sabotaging your WireGuard VPN because a hotel used the same subnet. That's MagicDNS, and it's the reason most people never bother learning how Tailscale's DNS actually works. That's until the day they type jellyfin.lab.example.com from a hotel and get nothing. The tunnel is up. The subnet router is advertising the whole LAN. The name just dies. The thing is, MagicDNS isn't broken when that happens. It's doing exactly what it was built to do, and what it was built to do is narrower than the name suggests. Here's why, and what you bolt on to fix it. MagicDNS is a device list with a DNS front end One name per node, and you don't get to invent more Tailscale's own description is "automatically registers DNS names for devices in your network," and the word doing the work there is devices. Every node that joins your tailnet gets a single fully qualified name: the machine name, plus your tailnet's DNS name, so something like pve.yak-bebop.ts.net. The machine name comes from the OS hostname, cleaned up, and forced to be unique. If a second box called pve shows up, it becomes pve-1 forever, even after you rename the first one. That's the whole feature. There's no zone to edit. The docs say it in a single sentence: "It's not possible to add arbitrary records to MagicDNS," and link to a GitHub issue asking for exactly that, which has been open since March 2021. No records means no aliases, no CNAMEs, and no wildcards, because there's nowhere to put them. The most recent Tailscale-side reply keeps the issue open "as we may still move to support custom MagicDNS names," which is the politest possible way of saying no. So if you put Tailscale on one box that runs Jellyfin, a search frontend, and an LLM server, MagicDNS gives all three of them the same name. Jellyfin becomes box:8096, the LLM becomes box:13305, and so on down the port list. That's not a naming scheme, that's a phone book with one entry and a list of extensions on a sticky note. And in my lab, it's one step worse, because each of those services is an LXC with its own LAN address, which brings us to the next problem. Your subnet router does less than you think it does It carries the addresses home, but leaves the names behind The obvious next step is a subnet router, and I've got one advertising 192.168.4.0/22 into my tailnet. It works, which is part of the problem. From anywhere in the world I can hit 192.168.4.110:8096 and Jellyfin answers, so it feels like my LAN is on the tailnet. It isn't. A subnet router advertises a route, and that's all it advertises. The NAS, the Jellyfin container, and the Caddy proxy behind it aren't Tailscale nodes, so MagicDNS has never heard of them. Their names live in my Technitium DNS cluster, in a zone called lab.example.com, with a wildcard pointing at Caddy. Tailscale doesn't know that zone exists, and nothing about adding a subnet router tells it. Tailscale is upfront about this, if you read far enough: "Unless your nameservers are public, or using Tailscale IP addresses, you probably need to configure subnet routing to allow your devices to reach the private DNS servers." Translation: bring your own DNS server. We'll route to it. We won't be it. The names aren't yours, and neither are the certificates Everything lives under .ts.net, including the public ledger Even if you could stuff custom records into MagicDNS, they'd land under Tailscale's domain, not yours. Your tailnet DNS name is either the tail.ts.net default or a randomly generated pair like yak-bebop.ts.net, and you can flip between those two. That's it, and once you've issued certificates against the random one, you can't even re-roll it. You can't make MagicDNS answer for lab.example.com. The HTTPS feature follows the same rule. Run tailscale cert and you get a real Let's Encrypt certificate, but only for machine.tailnet.ts.net, because Tailscale completes the DNS-01 challenge with a TXT record under *.ts.net that it controls. Every machine name you certify is also written to the public Certificate Transparency ledger, which the docs warn about in bold. And you can't get a cert for a bare https://pve at all. My wildcard certificate for *.lab.example.com lives on Caddy, which replaced the reverse proxy config I dreaded, and has nothing to do with any of this. Two separate HTTPS worlds, and MagicDNS only lives in one of them. What really happens when you type the name on hotel Wi-Fi 100.100.100.100 shrugs and hands it to the hotel router Here's the mechanism, because once you see it the fix is obvious. Every Tailscale client runs a small stub resolver at 100.100.100.100 (Tailscale calls it Quad100), and when MagicDNS is on, Tailscale points the OS at it and adds your tailnet name as the first search domain. That part isn't configurable. Type pve, the resolver tries pve.yak-bebop.ts.net, finds it in the device list, done. Type jellyfin.lab.example.com and the resolver has no idea. It hasn't got a record, and it hasn't been told who to ask. So the query falls through to whatever DNS the device would use anyway. At home, that's a resolver that knows about your zone (Technitium, in my case), so everything works, which is exactly why this bug hides until you leave the house. On hotel Wi-Fi, the fallback is the hotel router, which has never heard of my domain and says so. The route to 192.168.4.0/22 is up the whole time. Reachability and name resolution are different layers, and only one of them came along for the trip. One warning before you go test this: on Windows, nslookup talks to a single server directly and ignores the policy table Tailscale uses, so it'll happily tell you split DNS is broken when it isn't. Use Resolve-DnsName instead. On a Mac, host and nslookup skip the system resolver the same way, and dscacheutil is the one that tells the truth. The best solution is split DNS Split DNS is what Tailscale actually expects you to do. In the admin console, you add a nameserver, tick "Restrict to domain," and tell it that queries for lab.example.com go to my Technitium VIP at 192.168.4.61. Everything else stays with local DNS. The subnet router makes .61 reachable, Technitium answers with the wildcard, Caddy serves the cert, and jellyfin.lab.example.com works from the hotel. Two gotchas: the docs say an exit node takes over all DNS unless you enable "Use with exit node" on that nameserver, and Tailscale's own engineers have closed GitHub reports as expected behavior when Firefox's Secure DNS bypassed the system resolver and MagicDNS with it. Tailscale Services became generally available in February 2026 on every plan, and it's the closest thing to custom MagicDNS names you'll get. Define svc:jellyfin, have a tagged host advertise it, and the tailnet hands out a stable virtual IP plus jellyfin.yak-bebop.ts.net. Since GA it can point at things behind a subnet router, which makes it useful for a homelab. But it's capped at 10 services per user; it's TCP only unless you drop to a layer-3 endpoint and do your own iptables, and the name is still Tailscale's, not yours. Nice, not a DNS replacement.