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:
- 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