Get rid of DNSConfig.FallbackResolvers

[danderson]

As a workaround for some limitations of our new DNS implementation, we've had to add fallback resolvers, which are like the old CorpDNS resolvers but only get used when we're in a case where the OS would do the wrong thing if given only a split DNS configuration.

This bug is to track removing FallbackResolvers once we've implemented fixes for the cases that require it:

• macOS/iOS clients using an exit node: unless we provide a default resolver through the NetworkExtension API, the machine ends up with no primary DNS resolver. The fix for this is exit node DNS forwarding, Forward DNS traffic to exit node #1713.
• android doesn't yet understand split-DNS at all, and we need to research how to make it work. Support split DNS in android #1695

Once those two are fixed, we should be able to pull out FallbackResolvers from the client.

[rosszurowski]

Adding a note that if we remove FallbackResolvers from the client, the admin panel should change shortly afterwards to remove the restrictions we have in place there.

[DentonGentry]

I think we can eventually not need FallbackResolvers, #2116 provides a way to extract a sufficiently accurate DNS config from an Android device. We could then allow Magic DNS to be enabled without requiring a global DNS server to be provided.

[DentonGentry]

Android build 1.19.116-t878a20df2-gb2665ab2ff5 in the Open Testing track implements the mechanism described in #2116 to extract the current DNS config from Android, no longer requiring fallback resolvers.

Work on #1713 is underway, to forward DNS queries to exit nodes. Once that is done, we shouldn't need FallbackResolvers any more.

[DentonGentry]

Forwarding DNS queries to exit nodes is present in 1.19.x builds in https://pkgs.tailscale.com/unstable/ and will be in the 1.20 release build.

[mayakacz]

This will break users with <1.20 on tailnets (specific concern for Android) when they enable MagicDNS.

[DentonGentry]

Android added handling to retrieve platform DNS servers in 1.20. At this point only 1.4% of the Android fleet is running 1.18 or earlier, 98.6% of the fleet is using a version which no longer needs FallbackResolvers. In particular, I think we can be confident that new tailnets where we might have MagicDNS be on by default are unlikely to have an older Android Tailscale app amongst their devices.

[DentonGentry]

1.20 also fixed the other case at the top of this bug, of macOS/iOS clients using an exit node. As of 1.20 we have the client forward its DNS queries to the exit node for resolution.

• 2.5% of macOS devices are running a release 1.18 or before.
• 0.1% of iOS devices are running a release 1.18 or before.

[bradfitz]

Unlike our general policy of assuming nothing, on Android (at least Google Android) we can assume Google public DNS as the fallback even on old versions.

[mihaip]

/admin/dns has requires that "To enable MagicDNS, add a global nameserver first." requirement, we should not have that if "Override local DNS" is off.

(capturing out of band discussion)

[maisem]

Not complete yet.