On Tuesday, September 29, 2020 6:41:12 AM MST Lennart Poettering wrote:
On Di, 29.09.20 04:03, John M. Harris Jr (johnmh(a)splentity.com)
wrote:
> > Search domains on VPNs are an indicator that these domains are handled
> > by the VPN, that's why we use them also as routing domains. But this
> > doesn't mean it's the *only* routing domains we use. We use the ones
> > you configure, primarily. But since the concept didn't previously exist
> > we make the best from what we have.
>
>
>
> If you really must send DNS queries to both (which defeats the purpose of
> 'Split DNS'), then it may be better to just use the DNS server of the VPN
> when connected to VPN, then only check the LAN interface when the
> response is NXDOMAIN.
As mentioned in this thread already: this policy makes sense for some
cases but not for others.
For example, if I have my laptop in my home wifi, connected to RH VPN,
then there are some names resolvable only via the local
DNS. Specifically: my router's, my printer's and my NAS' address. And
there are other names only resolvable via RH VPN. systemd-resolved for
the first time gives me a chance for this to just work: it will send
requests to both the RH DNS servers and the local ones, and uses the
first successful reply, or the last failed reply. And that's quite
frankly awesome, because that *never* worked before.
So sending the requests to all available DNS servers in absence of
better routing info is a great enabler: it makes DNS "just work" for
many cases, including my own, and I doubt it's a particularly exotic
one.
There seems to be some confusion in this thread as to how exactly that works.
It seems that the individual pushing this change is under the assumption that
this implements 'Split DNS', that only requests for VPN resources are queried
from the VPN's DNS server(s).
Key, take-away here:
1. Ideally we'd just route company DNS traffic to VPN, and everything
else to local LAN DNS. But that requires explicit routing info to
be configured, we cannot auto-detect this info (beyond some minor
inference from the search domains)
Well, we have the routing information, unless the VPN is one flat network.
However, routing has absolutely nothing to do with DNS. Routing is a layer
below, and is most likely required for your DNS queries to actually get to the
DNS server(s) inside the VPN.
2. In some cases hence routing all DNS traffic via VPN and nothing
via
local might be a workable option. In others this would be wrong.
3. In others routing all DNS traffic via local DNS and nothing via VPN
might be workable option. In others this would be wrong.
4. In all cases where we can't do #1 because we lack the info, and
don't know whether to do #2 or #3 because it depends on the type of
VPN use, then sending to everything in parallel and taking the
first positive reply and the last negative one is the best chance
to make things "just work".
This seems to be the part where the Change Owner is confused as to how this
works, which is concerning at best. We need to be very careful when changing
functionality that is so essential to the way Fedora systems use network
resources, this is a pretty big change in functionality, and doesn't provide
'Split DNS', the issue the Change was originally created to solve.
--
John M. Harris, Jr.