Tailscale MagicDNS Not Resolving Private Hostnames? Configure Split DNS and Test on Windows

The scenario below comes from an XDA Developers write-up by Joe Rice-Jones about his own homelab. His addresses, Technitium DNS server, Caddy proxy and Jellyfin setup are one author's environment. The mechanics behind them are documented by Tailscale and apply to any tailnet.

Three separate jobs that get blurred together​

The failure is easier to reason about if you split it into three layers:

• Name registration is MagicDNS. It maps Tailscale devices to names.
• IP routing is the subnet router. It carries packets to LAN addresses.
• DNS forwarding is split DNS. It sends questions about your private zone to a server that can answer them.

MagicDNS covers only the first layer. The subnet router covers only the second. If you never configure the third, a name inside your private zone has nobody to ask once you leave home.

What MagicDNS actually gives you​

Each device gets one fully qualified name. Tailscale's docs describe it as a machine name plus your tailnet DNS name, for example monitoring.yak-bebop.ts.net. The machine name comes from the device's hostname when it joins. Tailscale's tailnet-name documentation says it is generated from the OS hostname and can be changed from the admin console or the CLI. If you rename the machine, the MagicDNS entry follows.

Search domains make the short form work. With MagicDNS on, typing monitoring is equivalent to typing the full name.

The limit is stated plainly in Tailscale's DNS reference: it's not possible to add arbitrary records to MagicDNS. That rules out several things:

• aliases
• CNAMEs
• wildcards
• separate names for different apps on one host

If one machine runs a media server, a search front end and an LLM server, all three share the machine's name. You tell them apart by port, for example box:8096. The XDA piece notes that a GitHub feature request for custom MagicDNS records has been open since March 2021. An open issue is not a roadmap commitment, so treat custom records as unsupported for now.

Why the subnet router doesn't fix it​

A subnet router lets tailnet devices reach machines that can't run Tailscale. Tailscale describes it as a gateway that advertises routes. A route is an IP range, not a list of hostnames. In the author's setup, a router advertising 192.168.4.0/22 lets him reach 192.168.4.110:8096 from anywhere. That proves IP reachability and nothing about naming.

The NAS, the container and the reverse proxy behind the router are not Tailscale nodes, so MagicDNS has no entries for them. Tailscale's DNS reference says this directly: unless your nameservers are public or use Tailscale IPs, you probably need subnet routing so devices can reach private DNS servers. The router makes your DNS server reachable. It does not make that server part of any lookup.

Tailscale also says it does not offer a DNS server. You supply the resolver that holds your records, whether that is Technitium, Pi-hole, Windows Server DNS or something else.

Why it works at home and fails away​

The XDA author describes the Tailscale client running a local stub resolver at 100.100.100.100. When MagicDNS is on, the tailnet name goes first in the search list, and that placement isn't configurable. Tailscale's docs confirm that MagicDNS is always the first domain in the search domain list.

A name MagicDNS doesn't know about gets handled by whatever DNS the device would otherwise use. At home, that is likely your own resolver, so everything works. Away from home, it is whatever the local network provides. The author's hotel router is the example in his piece. Exactly what happens depends on client settings, Tailscale settings and resolver behavior, so a hotel router is only one possible outcome. That is why this bug tends to appear only when you leave the house.

The fix: split DNS​

Tailscale calls this a restricted nameserver. The docs define it this way: a restricted nameserver only applies to DNS queries matching a specific search domain, and using one is also known as split DNS. Tailscale's example sends only *.example.com lookups to 1.1.1.1.

For a home lab, the pattern looks like this:

1. Run a DNS server that holds your private records.
2. Make it reachable from the tailnet, typically through a subnet route that covers its address.
3. In the admin console's DNS page, add it as a nameserver and restrict it to your domain, such as lab.example.com.
4. Check that your access rules let clients reach the DNS server's address.

The author's version uses a Technitium virtual IP at 192.168.4.61 with a wildcard record pointing at Caddy. Those details are his, not requirements.

Don't reach for Override DNS servers​

Tailscale also has an "Override DNS servers" toggle. It is a different, broader tool. The docs say that by default tailnet devices use their local DNS settings for all queries, and the override forces them onto your global nameservers. It isn't needed for split DNS. Tailscale also warns that if an ACL or grant blocks access to the global nameserver, the device won't be able to resolve DNS queries.

Testing DNS on Windows without fooling yourself​

This is the most useful practical point for Windows admins. Tailscale's documentation warns that on Windows, nslookup queries a single DNS server directly and doesn't honor NRPT rules or other DNS policies Tailscale uses for split DNS. It can report failure while browsers, curl and ping resolve fine.

Tailscale's recommended check is PowerShell:

Resolve-DnsName -Name <domain-or-magic-dns-hostname>

On macOS, the recommended tool is dscacheutil -q host -a name <name>. Tailscale's MagicDNS page adds that some macOS CLI tools such as host or nslookup circumvent system DNS resolution.

A sensible troubleshooting order, which is my inference from Tailscale's routing/DNS split rather than a Tailscale procedure:

1. Run Resolve-DnsName on the private name.
2. If it returns the right IP, test the IP and port directly.
3. If the name fails but the IP works, the problem is DNS configuration, not routing.
4. If both fail, check route approval and access rules.

Common gotchas​

• Exit nodes. The docs say a device using an exit node also uses the exit node as its DNS resolver for all domains, regardless of your nameserver setup. To override that, open the DNS page, find the nameserver, open its three-dot menu, enable Use with exit node and save.
• Client version. Only devices on Tailscale v1.34 or later can use search domains.
• Browser DNS. A browser's built-in encrypted DNS can bypass operating system DNS policy, which would skip split DNS. The XDA author cites Firefox Secure DNS. I couldn't find a primary source for that specific support report, so treat it as a general thing to check, not a confirmed case.

HTTPS and certificates are a separate world​

Even when names resolve, certificates follow different rules. Tailscale's HTTPS documentation says tailscale cert requests a Let's Encrypt certificate for the machine's tailnet name. It also says Tailscale creates a *.ts.net DNS TXT record to complete the DNS-01 challenge. Several consequences follow:

• Certified machine names are published to the public Certificate Transparency ledger. Tailscale warns you not to enable HTTPS if machine names contain sensitive information.
• Per the docs, you cannot obtain an HTTPS URL for a bare hostname such as.
• The tailnet DNS name can be switched between the default and a randomized name. After a randomized name has been used for HTTPS certificates, it cannot be re-generated, and switching can break existing links.
• None of this issues certificates for your own domain. A wildcard certificate for *.lab.example.com on a reverse proxy belongs to your own DNS and TLS setup.

Tailscale Services: closest to custom names, with limits​

The XDA piece mentions Tailscale Services as the nearest thing to per-app names. Tailscale's docs say each Service consists of a MagicDNS name, a TailVIP, a resource definition and one or more back-end hosts. Heise reports the feature launched as beta in October 2025 and has been generally available since February 2026.

Tailscale's GA announcement says every user, including Personal users, can create up to 10 services. The docs list a limitation: services currently only support TCP, with UDP only through layer 3 endpoints on Linux that need extra OS-level configuration.

A Service is still named under your tailnet domain. It doesn't let you use lab.example.com. It helps with the "one machine, many apps" problem, but it doesn't replace split DNS for your own zone.

Which approach fits​

Bottom line​

Treat MagicDNS as a device directory, not a DNS zone. If you want your own names to work away from home, you need three things: a route to your DNS server, a DNS server that holds the records, and a restricted nameserver entry for your domain. Test with Resolve-DnsName on Windows. A failing nslookup may just be the tool ignoring Tailscale's policy rules.