In this systemd github issue https://github.com/systemd/systemd/issues/5755 in particular is problematic darkstar states "the DNS servers are supposed to be exactly equivalent". But as far as I can tell systemd doesn't have any provision for temporarily falling back to a different nameserver if the main one is unavailable and reverting back when it becomes available again. Besides the scenario I listed in my previous comments, this also prevents using a local nameserver as the main nameserver but falling back to an external nameserver if the local one becomes unavailable, with recovery. In that case the two nameservers may not even return the same responses, but having a working nameserver that returns public records is better than no nameserver at all. Again, if there is a way to accomplish failovers with recovery with resolved, I'd love to know how to do it.
Maybe systemd-resolved will get functionality that supports these use cases, but right now ifaict it doesn't. And even when it does, will it get backported to LTS versions of ubuntu such as 18.04? ** Bug watch added: github.com/systemd/systemd/issues #5755 https://github.com/systemd/systemd/issues/5755 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1745463 Title: Disabling systemd-resolved breaks dhclient resolvconf integration Status in resolvconf package in Ubuntu: Expired Status in systemd package in Ubuntu: Confirmed Bug description: To reproduce, mask resolved: sudo systemctl mask systemd-resolved.service ...then disable network-manager for ifupdown interfaces: $cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile dns=default rc-manager=resolvconf [ifupdown] managed=false [device] wifi.scan-rand-mac-address=no ...and reboot. You'll note that resolvconf integration with dhclient is now broken. Interfaces listed in /etc/network/interfaces or /etc/network/interfaces.d/* will not provide DNS configuration in /etc/resolv.conf and /run/resolvconf/interfaces/. This is because /etc/dhcp/dhclient-enter-hooks.d/resolvconf defines "make_resolv_conf()" as a valid function for the BOUND case, but /etc/dhcp/dhclient-enter-hooks.d/resolved undefines it (who's nasty now, eh?) even though resolved is masked. The file existence check in the beginning of /etc/dhcp/dhclient-enter- hooks.d/resolved should be more thorough, i.e. it should ensure that resolved is enabled, rather than simply look for the existence of /lib/systemd/systemd-resolved. This works for me: -if [ -x /lib/systemd/systemd-resolved ] ; then +if [ -x /lib/systemd/systemd-resolved ] && systemctl -q is-enabled systemd-resolved ; then Arguably, /etc/dhcp/dhclient-enter-hooks.d/resolvconf should implement a similar check, looking for /run/resolvconf/enable-updates as a condition for meddling with DNS settings. If desired, I'll file a separate bug for that package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1745463/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
