Tailscale subnet routers and exit nodes solve distinct networking problems by either routing specific private IP ranges or funneling all public traffic and DNS queries through a designated remote device, creating silent routing and resolution mismatches if configured incorrectly.
Why Subnet Routers Leave Local DNS Untouched
Deploying a Tailscale subnet router makes a private subnet like 192.168.1.0/24 reachable across your tailnet without requiring individual client nodes to join that local network. When configuring a subnet router on a Linux host, administrators must ensure IP forwarding is active by appending net.ipv4.ip_forward = 1 to system configuration files and verifying the local interface routes using standard routing commands. By default, enabling subnet routing has no effect on DNS resolution. Devices connected from remote locations continue utilizing whatever local DNS resolver is assigned by their current Wi-Fi network, such as a coffee shop or hotel router.
This design choice introduces immediate resolution failures when attempting to query local hostnames. Typing an address like ssh pi.home.lan from a remote terminal fails because the external public resolver has no knowledge of internal domain records. However, executing a direct command using the numeric IP address, such as ssh 192.168.1.30, succeeds because the packet falls directly inside the advertised subnet range. Tailscale’s built-in MagicDNS functions independently on the client side, but standard local hardware like network printers remain invisible unless explicitly addressed or integrated into a split DNS configuration.
How Exit Nodes Shift Entire DNS Queries to Remote Resolvers
Switching to a Tailscale exit node alters the mechanics entirely by forcing all internet traffic and DNS lookups through a single chosen remote device, such as a home server or an Android TV box. Using an exit node causes a device to abandon global and split DNS nameservers in favor of the exit node’s local resolver. If that remote machine relies on an ad-blocking sinkhole like a Pi-hole, the remote user gains network-wide ad blocking and local hostname resolution away from home. If the remote server defaults to an ISP resolver, that ISP handles every query.
This aggressive override creates its own configuration hurdles. Any custom public nameserver specified in the Tailscale admin console—such as Cloudflare or Quad9—gets bypassed automatically while an exit node is active, unless administrators manually check the option to use specific nameservers with exit nodes. Public Wi-Fi networks still observe encrypted traffic payloads passing through the tunnel, but the actual lookup resolution happens entirely at the exit node’s destination.
Resolving Naming Failures Through Split DNS and Admin Configurations
Diagnosing these misconfigurations requires testing which resolver actually answers network queries. Running an explicit query like nslookup nas.home.lan reveals whether home DNS infrastructure is processing the request. If the lookup fails, traffic is leaking to local network resolvers instead of traversing the secure tunnel.
To establish precise control over name resolution without tunneling all web traffic, administrators must utilize split DNS configurations within the Tailscale admin console. Adding a restricted nameserver for a specific search domain like home.lan and pointing it toward a local DNS server IP ensures that only those designated queries route through the subnet router while standard internet traffic utilizes local resolvers. Alternatively, enabling global DNS overrides forces every client device to ignore local network resolvers entirely and adhere strictly to centrally defined nameservers.
