On Wed, Sep 30, 2020 at 10:05 am, Gerd Hoffmann kraxel@redhat.com wrote:
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 ...
We actually considered dnsmasq, but NetworkManager developers recommended systemd-resolved. See: https://pagure.io/fedora-workstation/issue/123#comment-621603
I agree dnsmasq would have been a lot better than the status quo prior to F33. We would probably have used that if systemd-resolved didn't exist. If we could have a do-over, we should have started using it long ago.
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.
I've tried to stop this line of discussion a bit earlier, since it's based on a misunderstanding of how NetworkManager uses systemd-resolved. I agree we should prioritize avoiding DNS leaks, and that's actually the primary motivating factor for the switch to systemd-resolved (you can see how much more attention I devote to this topic in the change proposal compared to the other benefits of systemd-resolved). NetworkManager will not configure systmed-resolved to send queries all over the place. We need a local resolver (systemd-resolved, dnsmasq, etc.) to ensure DNS queries go where users expect; it's not something we can do with traditional resolv.conf managed by NetworkManager.
Michael