On Wed, Sep 30, 2020 at 10:05 am, Gerd Hoffmann <kraxel@xxxxxxxxxx>
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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
