DNS in Tailscale
Tailscale provides each device on your network with a unique IP address that stays the same no matter where your devices are. However, IP addresses aren’t very memorable, and can be unwieldy to work with. You can map Tailscale IPs to human readable names using DNS.
You can manage DNS for your Tailscale network in at least three ways:
- Using MagicDNS, our automatic DNS feature
- Using the DNS settings page in the admin console
- Using public DNS records
Tailscale can automatically assign DNS names for devices in your network. This feature, called “MagicDNS”, is in beta.
MagicDNS determines whether your network will use the MagicDNS beta to automatically assign DNS names to devices in your network. MagicDNS is optional, and not required to use other DNS settings.
Nameservers are the IPv4 or IPv6 addresses of DNS servers you want your Tailscale nodes to use for lookups, when connected to your network. Many companies have internal private DNS servers with the names of their private machines. If so, you can add those DNS servers here.
There are two types of nameservers:
Restricted Nameservers (also known as split DNS) only apply to DNS queries matching a certain search domain. If you configure 18.104.22.168 as a nameserver for example.com, only DNS queries like “foo.example.com” and “bar.example.com” will be handled by 22.214.171.124.
These nameservers also configure search domains for your devices, which expand single-label queries like “foo” into “foo.example.com” or “bar” into “bar.example.com”.
You can use a public DNS nameserver, or run your own. Some public global DNS nameservers include:
2620:fe::9, provided by Quad9
2001:4860:4860::8844, provided by Google
2606:4700:4700::1001, provided by Cloudflare
Tailscale considers each global DNS nameserver’s list of addresses as one entity. For example, if you add
126.96.36.199, the other three Google nameserver addresses are also added—you wouldn’t be able to add
188.8.131.52or the other Google addresses. This is true whether you add the addresses manually or through the dropdown in the DNS page of the admin console.
These nameservers are available in a dropdown when you add a nameserver using the DNS page of the admin console.
For redundancy, use more than one global nameserver (which can be from the same provider).
By default, clients of your network will use their local DNS settings for all queries. To force clients to always use nameservers you define, you can enable the “Override local DNS” toggle.
If you’d prefer not to manage DNS settings via the admin console, you can instead publish records on your public-facing DNS server, assuming you have one. The DNS names can be looked up (converted to a private IP address) by anyone on the Internet, but because Tailscale IP addresses are only accessible to users of your network, this is relatively harmless.
Almost every organization already has a public DNS server (so that they can route email, publish a web site, etc), so this is easier than setting up an internal private DNS server.
Tailscale does not offer a DNS server, so you will need to use one that you run yourself, or one offered by your cloud or domain host, or by some other DNS provider. Note that public DNS names may take a while to propagate once you add them.
The short answer is… DNS is complicated. On some platforms in some situations, Tailscale needs a trustworthy public resolver to use for DNS. We hope to remove this restriction in the near future.
Previous versions of the DNS settings page allowed defining search domains separately from nameservers. However, due to cross-platform compatibility reasons, this is no longer possible. To define a search domain, you’ll need to add at least one nameserver along with it.
If you don’t have a preference, we recommend using well-trusted public DNS nameservers alongside your search domain.
Adding arbitrary records isn’t possible right now, but we’re considering adding this ability in the future. Subscribe to or comment on this GitHub issue for updates.
Traditionally, network admins will use a tool like
nslookup to review DNS responses for various domains. However, on some platforms
nslookup doesn’t use DNS information provided by the OS, and returns incorrect results. You’ll likely notice this issue when using split DNS or MagicDNS, which rely on advanced DNS features.
To test DNS settings on different platforms, we recommend the following approaches:
Use the native
dscacheutil -q host -a name <domain-or-magic-dns-hostname>
For example, searching up the IP address for a MagicDNS hostname will return:
$ dscacheutil -q host -a name my-server name: my-server.example.com.beta.tailscale.net ip_address: 184.108.40.206
Use the Windows Powershell
Resolve-DnsName -Name <domain-or-magic-dns-hostname>
For example, searching up a MagicDNS hostname will return:
PS C:\> Resolve-DnsName -Name my-server Name Type TTL Section IPAddress ---- ---- --- ------- --------- my-server.example.com.beta.tailscale.net AAAA 600 Answer fd7a:115c:a1e0:ab12:4843:cd96:6251:c348 my-server.example.com.beta.tailscale.net A 600 Answer 220.127.116.11
Linux implements its DNS support using a DNS server listening on 127.0.0.x, so
nslookup returns correct results in spite of its naive approach. Use
nslookup to debug DNS responses on Linux.