Diagnosing DNS Configuration Conflicts on a Linux Homelab Host

Problem and context

While experimenting with Tailscale private networking and subnet routing, resolver configuration on an Ubuntu host became confusing. Tailscale-managed settings and the intended local DNS settings were not aligned.

Investigation and correction

I inspected /etc/resolv.conf and identified management by systemd-resolved or Tailscale at different stages. In the documented sequence, disabling acceptance of Tailscale DNS settings and restarting systemd-resolved restored the expected local resolver list.

Resolver ownership and tradeoffs

/etc/resolv.conf is often generated or a symlink. Editing it directly is not a durable fix. First identify the controlling component—NetworkManager, systemd-resolved, DHCP or a VPN client—and change its supported configuration source.

DNS changes can affect private-name resolution as well as ordinary lookups. Validate the applications and names relevant to the intended configuration; do not infer success solely from one file.

Outcome and evidence boundary

The notes show the intended local nameservers in the resolver file after correction. This is evidence of that configuration state, not a comprehensive or long-term DNS reliability test. Real addresses, tailnet identifiers and device names are omitted.

Lessons learned

Find the owner of generated configuration before editing it. Confirm behavior with resolver tools and application checks as well as inspecting the file.

Next verification

• Use resolvectl, dig and relevant application tests to validate the desired resolution behavior.
• Document persistence across a reconnect or reboot before claiming a durable correction.