Unexpected DNS behavior on my Windows computer after tailscale agent update

Windows
1

TL;DR After updating the tailscale agent on my windows pc, all of my nslookup requests using domains from local dns records created in my pihole instance, seem to be going through magicdns however I have magicdns disabled. Is this new or expected behavior?

I run tailscale across my home network and I use pi-hole for local dns resolution. I have the pi-hole tailscale ip set as the nameserver in tailscale and use “override local dns” to force all the computers and servers in my network to use it. This has worked mostly without issues for many months now. I recently updated tailscale on my main windows computer to 1.30.0 and thats when I started noticing “odd” behavior.

Previously, when I would do an nslookup I would get results similar to this:

powershell> nslookup vm300.tailscale.lan
Server:         pi-hole
Address:        100.82.122.19

Non-authoritative answer:
Name:   vm300.tailscale.lan
Address: 100.89.214.89

However, now when I run it, I get results like this where it indicates its using tailscales magicdns:

Server:  magicdns.localhost-tailscale-daemon
Address:  100.100.100.100

Name:    vm300.tailscale.lan
Address:  100.89.214.89

I have magicdns disabled within tailscale since I use pihole for my dns. As you can see it still returns the correct IP but the whole reason I noticed this is because I randomly had issues today resolving some domains created within pihole. When I ran nslookup at that time, it couldn’t find the domain (e.g. *** dns.opendns.com can't find vm300.tailscale.land: Non-existent domain). It references opendns since its not using pihole and instead using the nameserver set within my router.

I tried a bunch of things to fix this, ran commands like /flushdns and NETSH winsock reset catalog among others and then restarted the computer. I also reinstalled the agent. The only way to get it to not reference magicdns is to hardcode the pihole tailscale ip as the nameserver within windows network settings but shouldn’t I not need to do that since I’m using “override local dns”?

Ultimately, my question is, why is it using magicdns when I don’t have it enabled? Is this something new where it always uses it before forwarding the request on to pihole? And maybe I didn’t notice earlier? If I run nslookup from one of my linux servers then it doesn’t mention magicdns. Just feels like something odd has been happening since the agent updated but I can’t pinpoint what.

1 Like
2

After re-reading the docs it seems that it referencing magincdns is expected so this might not actually be an issue but if anyone has additional thoughts then please let me know.

3

I also noticed this after updating to 1.30. The same behavior also started happening on my android phones after updating to 1.30.

4

Where did you see that?

5

Hi,

I am having the same exact issue on Windows, macOS and iOS machines.

I have MagicDNS disabled, Override Local DNS enabled, and my list of DNS server comprises of 2 IPs of Pi-hole instances, and Quad9 resolver as last resort.

All my Tailscale clients are accepting DNS settings from Tailscale.

Previously, doing this would change my clients resolver to my Pi-hole IPs + Quad9 when Tailscale was running, exactly as shows on the Tailscale admin settings page.

After v1.30.0 and still now, it’s 100.100.100.100 that gets pushed to my clients instead. Trying to resolve a private domain name that would usually be handled by one of my Pi-hole fails, because it hits 100.100.100.100 instead and doesn’t get forwarded to any of my custom DNS IPs.

Don’t know if this is a new behaviour or an issue.
In any case, the right DNS settings need to be pushed to the clients (just like pre 1.30.0) or 100.100.100.100 needs to be able to forward requests in accordance to the list on the admin page.

Best,
Cilusse.

When Tailscale connected and accepting DNS settings:

% scutil --dns
DNS configuration

resolver #1
  nameserver[0] : 100.100.100.100
  if_index : 23 (utun3)
  flags    : Supplemental, Request A records, Request AAAA records
  reach    : 0x00000003 (Reachable,Transient Connection)
  order    : 101400

Previously it would have been:

% scutil --dns
DNS configuration

resolver #1
  nameserver[0] : 10.4.0.53 [Pi-hole 1]
  nameserver[1] : 10.6.0.53 [Pi-hole 2]
  nameserver[2] : 9.9.9.9
  nameserver[3] : 149.112.112.112
  if_index : 23 (utun3)
  flags    : Supplemental, Request A records, Request AAAA records
  reach    : 0x00000003 (Reachable,Transient Connection)
  order    : 101400
1 Like
6

After a bit more digging around, I think I have found the reason.

Tailscale has different ways of handling DNS across different systems. Sometimes it passes the DNS list to the OS to query itself, and sometimes it routes all the queries through 100.100.100.100 (even if MagicDNS is off, it’s just an arbitrary IP at this point). Good discussion about this here. And official guide here.

I suspect that they have changed that in v1.30.0. Windows may previously had been receiving your nameservers in the order displayed on the admin panel, and possibly querying them in order too.
Now, Windows gets given 100.100.100.100 only, and sends requests there. Tailscale’s 100.100.100.100 forwards the query to all specified nameservers at once, and takes the quickest reply, and usually, a good public resolver will reply quicker than a Pi-hole instance.

To fix my setup, I have simply removed all the public resolvers from my nameservers list, forcing any request to be answered by my own resolvers.

Hope this helps!

2 Likes
7

Great follow-up! The official guide you linked was one of the docs I read that made me think this might not actually be an “issue”. I ended up doing the same thing you did, removed Quad 9 from my list of nameservers in Tailscale and left only my pihole listed.

8

This has been happening to me as well for a few months. It is only the Windows client that does this. The only temp fix I found was to restart the tailscale service from the services app. It is a temp fix and happens often during the day.