Back to guides
How-to

Accept DNS Configuration: Why Tailscale Replaced Your Resolver

You set up encrypted DNS, it worked, and then at some point it stopped being used. No error, no prompt, nothing in a log. The only notice you were given is a comment written into a file you had no reason to open.

26 August 2026

One option, and its default

The phrase people search for is the option's own help text. It is not an error message, which is part of why it is hard to track down:

tailscale set --help

  --accept-dns, --accept-dns=false
      accept DNS configuration from the admin panel (default true)

The default is true. Joining a tailnet therefore hands DNS on that device to the tailnet's configuration, and nothing asks you first. If you had configured an encrypted resolver at the operating-system level, it is no longer the thing answering your lookups. It has not been removed, disabled, or reported as failing. It is simply no longer consulted.

This is a defensible default. MagicDNS - resolving other machines on your tailnet by name - only works if Tailscale handles DNS, and that feature is most of why people enable it. The problem is not the choice, it is that a system-wide setting changed and the notification budget for that change was one comment in a file.

How to tell it happened

Three checks, in increasing order of usefulness. On Linux the first is the giveaway, and it is the notice mentioned above:

head -5 /etc/resolv.conf
# resolv.conf(5) file generated by tailscale
# For more info, see https://tailscale.com/s/resolvconf-overwrite
# DO NOT EDIT THIS FILE BY HAND -- CHANGES WILL BE OVERWRITTEN

nameserver 100.100.100.100

That address is Tailscale's internal DNS forwarder, running on the device itself. Every lookup now goes to it first, and it decides what happens next. If you had a resolver line here before, it is gone, and editing this file back will not hold.

The second check is the one worth remembering, because it explains itself and prints the fix:

tailscale dns status
=== 'Use Tailscale DNS' status ===

Tailscale DNS: enabled.

Tailscale is configured to handle DNS queries on this device.
Run 'tailscale set --accept-dns=false' to revert to your system
default DNS resolver.

=== MagicDNS configuration ===

MagicDNS: enabled tailnet-wide (suffix = your-tailnet.ts.net)

Resolvers (in preference order):
  - 100.x.y.z

Split DNS Routes:
  - ts.net.  -> <tailscale's own servers>

Search Domains:
  - your-tailnet.ts.net

Four things worth reading there. Resolvers in preference order is where your queries actually go - if that is not the encrypted resolver you configured, it is not being used. Split DNS Routes lists domains handled separately from everything else. Search Domains is why bare hostnames start resolving to tailnet machines. And a fourth section further down, System DNS configuration, shows what Tailscale believes your operating system was using before it took over - useful for recovering a setting you have forgotten.

The third check answers the question directly, one query at a time:

tailscale dns query example.com A
DNS query for "example.com" (A) using internal resolver:

Forwarding to resolver: 100.x.y.z

Response code: RCodeSuccess

Forwarding to resolver is the whole answer. Whatever address appears on that line is what handles your DNS, regardless of what any settings screen still shows.

Before Your device system resolver setting DoH / DoT Your encrypted resolver the one you configured After joining a tailnet, accept-dns left at true Your device resolv.conf rewritten Tailscale forwarder 100.100.100.100 tailnet resolver Your encrypted resolver still configured, never asked Nothing failed and nothing was reported.

The setting you made is still there. It is just not in the path any more.

Keeping both

There are three ways out, and they are not equivalent. Pick by what you actually want.

1. Turn the takeover off on this device. The command tailscale dns status prints for you:

tailscale set --accept-dns=false

Your own resolver comes back and your encrypted DNS is in the path again. The cost is real: this device stops getting the tailnet's DNS configuration, so resolving other machines by their MagicDNS names goes with it. If you reach your other machines by tailnet IP, or you only joined the tailnet for one service, that is a fine trade. If you rely on names, it is not.

2. Make your resolver the tailnet's resolver. Set your encrypted DoH or DoT endpoint as the global nameserver in the Tailscale admin console. Then Tailscale's takeover is harmless, because the thing it hands your queries to is the resolver you wanted in the first place. This is the option that keeps MagicDNS and encrypted DNS at the same time, and it is the right answer for most people who hit this.

3. Split DNS. Route only specific domains to specific resolvers and leave everything else alone. This is the surgical option and it is what the Split DNS Routes section in the status output is showing you. It is worth knowing about, and it is more configuration than most cases need.

Editing resolv.conf is not one of the three. The file says so itself. Tailscale rewrites it whenever it reconfigures, so a hand-edit survives until the next reconnect, network change, or restart - long enough to look like it worked and short enough to break later, when you have stopped associating the two events.

Why this is worth checking even if nothing looks wrong

Because the failure is silent in both directions. Your lookups still resolve, pages still load, and no test you are likely to run reports a problem. A DNS leak test will name whatever resolver the tailnet forwards to and call that fine - which it may well be, and which is not the same question as whether the hop was encrypted or whether it was the resolver you chose.

The specific thing to check is the one line above: Forwarding to resolver. If the address on it is not yours, then whatever you configured on this device - a DoH template, a Private DNS hostname, a systemd-resolved setting - is currently decorative.

This is also not an argument against running Tailscale. It is a good way to keep an admin plane off the public internet, which is exactly how we use it ourselves. It is an argument for knowing that joining a tailnet is a DNS change as well as a network one.

The general lesson

A default that takes over a system-wide setting should be judged by how loudly it says so, not by whether it is the right default. Here the default is defensible and the announcement is a comment in a file the user did not open, in a directory they had no reason to look at, phrased as an instruction not to edit it.

The useful habit that falls out of this: when something you configured stops taking effect and nothing reports an error, stop checking the setting and start checking what is actually in the path. Settings screens describe intent. Only a query describes behaviour.

Back to all guides