Hacker News new | ask | show | jobs
by diegs 1335 days ago
Is this still incompatible with split horizon DNS? Whenever I'm connected to my corporate tailnet I can no longer resolve hostnames that are registered on my personal, DHCP-assigned DNS server, breaking access to my home network. This also leads me to believe that all my DNS requests are being routed through the magic DNS server which is not cool IMO.
2 comments

It sounds like your corporate tailnet checked the "override local DNS" setting and provided their own default nameservers, so those are the ones that get used. They could also not do that, at which point your LAN resolver would get consulted, but I presume there's a policy reason in play?

You say "the MagicDNS server" like it's a quad-8 thing out on the internet. That server lives in the tailscale process on localhost. In some configurations on some OSes, we do have to route requests through that in order to polyfill missing OS features (usually, implementing split-DNS policies that the OS cannot represent natively, or transparently upgrading to DoH for upstreams that support it). You can inspect the logic that decides how to implement DNS policy depending on the policy and OS in https://github.com/tailscale/tailscale/tree/main/net/dns, as well as inspect what the in-process DNS forwarder does (extremely boring: match query suffix in configuration, forward packet to appropriate upstreams).

Weird, I asked our TS admin to disable "override local DNS" and he claimed the option was disabled out, seemingly due to magic DNS being enabled or something. I'll see if I can get access myself to try and change it. Thank you for the reply!
If things still aren't behaving, write in to support@tailscale.com and we'll sort you out. It sounds like the corporate setup wants to just push some custom DNS routes for specific suffixes and leave everything else alone, which is definitely a supported configuration.
Most of the Split DNS issues should be fixed now.

If you're on Linux, you want systemd-resolved, as it's the only Linux DNS resolver that's really any good, regardless of your opinions on systemd overall (See https://tailscale.com/blog/sisyphean-dns-client-linux/)

In any case, file a bug with details and we'll fix it up if there are still issues.

You're right for most setups, but when Docker also comes into play, systemd-resolved+Tailscale+Docker interacts really badly and containers cannot resolve anything anymore. This caused some serious hair-pulling at work a few months ago.
How did you solve it?

I want to be prepared if it happens, spent too much time figuring out weird Docker - DNS/network interactions on hotel wifis and the like...

The only proper solution I could find is disabling systemd-resolved entirely. There doesn't seem to be any way to make it use something other than 127.0.0.1 as its listen address (it's actually hardcoded in systemd-resolved) which means that Docker containers which inherit /etc/resolv.conf rules can't resolve DNS anymore.