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