Hi,
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.
Sorry, but that is not correct.
NetworkManager can handle split-dns just fine, by using dnsmasq and
reconfiguring it via dbus when vpn connections come and go. I can
easily add more servers + zones by dropping a config file snippet into
the /etc/NetworkManager/dnsmasq.d/ directory, for example to resolve the
hostnames for my kvm guests on the libvirt network.
That works for ages on my RHEL-7 workstation where systemd-resolved
doesn't even exist ...
So sending the requests to all available DNS servers in absence of
better routing info is a great enabler:
I fail to see why sending queries to all servers is a good plan. The
redhat vpn dns servers surely can't resolve the hostnames for my local
lan, and frankly they shouldn't even know which hosts I try to access.
Likewise my ISP shouldn't know which non-public RH servers I try to
access.
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, if auto-detect doesn't work we should (a) fix the vpn
protocols/implementations and (b) fallback to manually configuring
things until this is done.
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".
At the expense of leaking information, which I don't consider a good
trade-off.
take care,
Gerd