search

tailscale / tailscale

The easiest, most secure way to use WireGuard and 2FA.
https://tailscale.com
BSD 3-Clause "New" or "Revised" License
19.06k stars 1.49k forks source link

FR: DNS Fallback should not use Tailscale DERP servers if OmitDefaultRegions is set in Custom Derp Map #8257

Open daramos opened 1 year ago

daramos commented 1 year ago

What is the issue?

When using a custom DERP map with the OmitDefaultRegions flag set to true, the DNS Fallback functionality still utilizes the baked in DERP map containing the Tailscale DERP servers. https://github.com/tailscale/tailscale/blob/ab797f0abd067750d474668ed615d7dc9d258cec/net/dnsfallback/dnsfallback.go#L153

In our case - we utilize a custom login server and DERP relay. We are consistently running into an issue with DNS on Windows clients possibly related to this golang bug https://go-review.googlesource.com/c/go/+/442375 but I have not been able to conclusively find the root cause of.

Because the DNS Fallback functionality always merges the custom DERP map and the baked in Tailscale DERP map together - our reconnection attempts take an abnormal amount of time to resolve the DNS entries via the fallback mechanism and also spam the Tailscale DERP servers with DNS requests that it cannot resolve. This took a much longer time prior to #8008 being merged in.

I believe the OmitDefaultRegions field being true in the custom DERP map should skip the baked-in DERP map from being utilized for DNS Fallback. Alternatively - a new field such as OmitDefaultRegionsForDnsFallback should be introduced to prevent the Tailscale servers from being spammed with requests it cannot resolve as well as ensure only custom DERP servers are queried.

Another option would be to ensure that Custom DERP servers are always used first for DNS querying and then fallback to the baked-in DERP servers if those fail.

Steps to reproduce

  1. Set a custom DERP map containing custom DERP relays and the OmitDefaultRegions flag set to True.
  2. Disable local client DNS functionality
  3. Attempt to login to Tailscale

You should find in the tailscaled logs that the Fallback DNS functionality is attempting to utilize Tailscale's DERP servers for DNS querying.

Are there any recent changes that introduced the issue?

No response

OS

Linux, Windows

OS version

Windows 10, assorted Linux distros

Tailscale version

1.42

Other software

No response

Bug report

No response

bradfitz commented 1 year ago

The fact that our default set of DNS fallback servers happen to have "derp" in their hostnames is the real distraction here. There's no connection between DERP and DNS fallback.

So any DERP-related settings shouldn't affect DNS fallback.

The two things I think we should actually do are:

1) fix the Windows issues making DNS fallback even necessary at all, 2) switch to @andrew-d's recursive DNS resolver and mostly eliminate our HTTP-based dnsfallback servers,

Okay, and maybe:

3) move our HTTP-based DNS fallback servers to their own hostnames rather than have "derp" in their names which confuses people.

What I don't want to do is add more configuration knobs.

daramos commented 1 year ago

Thanks for looking at all that Brad.

As an alternative to adding more knobs or messing with the current behavior too much, what would you think of a pull request that just prioritizes the custom servers over the baked-in servers during fallback lookups? I can certainly try to work on that if you think it would be worthwhile?

DentonGentry commented 1 year ago

I think we'd rather focus on finishing https://github.com/tailscale/tailscale/pull/8115