Learn Tailscale - MagicDNS & DNS Management

#Introduction

In episode 5 you already used MagicDNS to call nodes by name. But MagicDNS has a depth you haven't seen yet: automatic resolution, DNS search domains, TLS certificates for internal services, and integration with the DNS your organization already has.

Episode 10 dissects MagicDNS in depth and the other DNS management within a tailnet: how hostnames are resolved, why .ts.net becomes the search domain, how internal HTTPS works, plus custom DNS nameserver and split DNS configuration for company internal domains.

#MagicDNS in Depth

#Automatic Hostname Resolution

MagicDNS works as a resolver embedded in every device. When you type ping nas-home, the device queries the local resolver, and MagicDNS answers with that node's tailnet IP — no need to add lines to /etc/hosts.

tailscale dns
ping nas-home
ssh devnull@nas-home

The output of tailscale dns shows the active DNS configuration: tailnet name, MagicDNS status, and the nameservers in use.

#The .ts.net DNS Search Domain

Because a node's full hostname is <name>.<tailnet-name>.ts.net, Tailscale adds <tailnet-name>.ts.net as a DNS search domain. As a result, typing nas-home is automatically treated as nas-home.<tailnet-name>.ts.net. That's why short hostnames work without any extra configuration.

#Internal HTTPS via MagicDNS

MagicDNS also integrates with Tailscale's certificate system. Every node that enables HTTPS gets a TLS certificate from Let's Encrypt or generated by Tailscale:

sudo tailscale cert nas-home

The sudo tailscale cert nas-home command issues a certificate for that MagicDNS hostname. As a result, services on the node can be accessed at https://nas-home.<tailnet-name>.ts.net without certificate warnings — the foundation for Tailscale Serve in episode 15.

#Custom DNS and Split DNS

#Configuring Custom DNS Nameservers

Besides MagicDNS, a tailnet can use custom nameservers — for example a corporate DNS or a home Pi-hole. Custom nameservers are configured in the admin console, and the result is propagated to all devices:

{
  "dns": {
    "nameservers": [
      "192.168.1.100",
      "1.1.1.1"
    ]
  }
}

The dns block in the ACL file determines the nameservers used by the whole tailnet. Devices will query 192.168.1.100 and 1.1.1.1 for DNS resolution outside MagicDNS.

#Split DNS for Internal Domains

Split DNS (DNS routing) directs queries for a specific domain to a specific nameserver, while other queries are processed normally:

{
  "dns": {
    "nameservers": ["10.0.0.53"],
    "splitDNS": {
      "internal.example.com": ["10.0.0.53"]
    },
    "searchDomains": ["internal.example.com"]
  }
}

The splitDNS configuration above ensures all queries to internal.example.com are answered by the internal DNS 10.0.0.53, while other domains use the default DNS. This is the best way to combine a tailnet with existing corporate DNS infrastructure.

#Integration with Corporate DNS Servers

For large organizations, a tailnet can sit on top of Active Directory DNS or an external consultant. Corporate nameservers are registered as primary, and internal search domains are added, so internal and tailnet name resolution work together without conflicts.

#DNS Best Practices

#Avoiding Name Conflicts

Avoid hostnames that match internal domains to prevent resolution confusion. Clear naming conventions (episode 5) become even more important when MagicDNS meets corporate DNS.

#Disabling MagicDNS When Needed

If you prefer full local DNS, MagicDNS can be turned off per device:

sudo tailscale set --accept-dns=false

The sudo tailscale set --accept-dns=false command makes the device use its regular system resolver and not follow tailnet DNS. Use this only if you know the consequences — .ts.net hostnames will no longer resolve.

#Summary

MagicDNS is a hidden layer of convenience: automatic resolution, the .ts.net search domain, and TLS certificates for internal services. Meanwhile custom nameservers and split DNS connect the tailnet to the DNS infrastructure you already have.

#Closing

Episode 10 finished the DNS discussion in the tailnet: you understand how MagicDNS works, the benefits of the search domain and internal HTTPS, and how to combine custom nameservers and split DNS for corporate environments.

Key takeaways:

• MagicDNS resolves node hostnames automatically.
• <tailnet-name>.ts.net is the built-in DNS search domain.
• tailscale cert provides TLS certificates for internal services.
• Custom nameservers are propagated to the whole tailnet via the dns configuration.
• Split DNS routes specific domain queries to specific nameservers.
• tailscale set --accept-dns=false disables MagicDNS per device.

In the next episode, episode 11, we'll cover Taildrop and file transfer — sharing files between devices in the tailnet directly and encrypted with tailscale file send, fast synchronization without cloud storage, plus Taildrop limitations and configuration.