How to get the same domain name working on my internal LAN and also externally via tailscale?

by

Summary

This postmortem analyzes why a single domain name failed to resolve consistently on both a local LAN and over Tailscale. The core issue stemmed from DNS split‑horizon behavior and the assumption that a public DNS record could simultaneously serve internal and Tailscale clients without additional configuration.

Root Cause

The failure occurred because public DNS always resolves the hostname to the LAN IP, which is only reachable inside the home network.
When the same hostname is used over Tailscale, devices outside the LAN attempt to reach 192.168.x.x, which is not routable through Tailscale.

Key contributing factors:

  • Public DNS cannot return different answers based on network context
  • Tailscale does not automatically override public DNS for arbitrary domains
  • LAN-only IPs are unreachable from Tailscale unless explicitly routed
  • No MagicDNS or split DNS configuration was in place

Why This Happens in Real Systems

Real networks commonly run into this because:

  • DNS is global, but private networks are not
  • Split-horizon DNS requires explicit configuration, not automatic behavior
  • Tailscale clients trust public DNS unless told otherwise
  • Private IPs cannot be reached unless advertised as routes or replaced with Tailscale IPs

Real-World Impact

This type of misconfiguration leads to:

  • Inconsistent access depending on where the client is located
  • Confusing failures where the same URL works at home but not remotely
  • Unnecessary debugging of web servers, proxies, or certificates
  • Broken mobile workflows, especially on iOS where DNS caching is aggressive

Example or Code (if necessary and relevant)

A typical failing setup looks like this:

# Public DNS record
myserver.example.com -> 192.168.0.10

# Caddy reverse proxy
reverse_proxy 192.168.0.10

This works only on the LAN, not over Tailscale.

How Senior Engineers Fix It

Experienced engineers solve this using split DNS or MagicDNS overrides, ensuring Tailscale clients resolve the hostname to the server’s Tailscale IP, not its LAN IP.

Common solutions:

  • Use Tailscale MagicDNS + DNS Search Domains
    • Create a Tailscale DNS override:
      • myserver.example.com → 100.x.y.z (server’s Tailscale IP)
  • Run a lightweight internal DNS server and advertise it via Tailscale
    • Tailscale clients use it only when on the Tailscale network
  • Advertise the LAN subnet through Tailscale
    • Allows Tailscale clients to reach 192.168.0.10 directly
  • Avoid public DNS for private services
    • Use a private domain like myserver.tailnet-name.ts.net

The key principle: Tailscale clients must receive a different DNS answer than public internet clients.

Why Juniors Miss It

Less experienced engineers often overlook this because:

  • They assume DNS is location-aware, but it is not
  • They expect Tailscale to automatically override public DNS, which it does not
  • They misunderstand the difference between:
    • Routing (moving packets)
    • DNS resolution (finding IPs)
  • They rely on public DNS for private services, which rarely works cleanly
  • They underestimate how often split-horizon DNS is required in hybrid networks

Juniors typically focus on the web server or proxy, while seniors recognize that DNS is the real failure point.

Leave a Comment