> Can you help me understand the motivation underlying the requirement? The motivation is that if the current dns server goes down, we don't have to wait for the request to timeout and make another request to the next server. Before resolved this was more of a problem since libc would always try to use the first server if it was down and didn't have any memory, so we would add the timeout for the dns lookup to each dns query. But I understand that resolved does remember if a server is down and continues to use that one, but afaict it never switches back, and that is a problem, as I'll explain below.
> Do you have DNS servers in your configuration which are always farther / slower? If so, why do you have them in your configuration at all? Yes. We have one DNS server in each availability zone (AWS). We would prefer to use the DNS server in the same availability zone as the host, but want to fall back to one of the others if that one becomes unavailable. > Do you have a particular application requirement for low-latency DNS resolution - and if so, wouldn't the use of a caching local resolver (a configuration which resolved supports, and which we enable by default) have more of an impact on satisfying that requirement? The less time it takes for our application servers to receive an answer the better. Bandwidth for DNS traffic is very cheap and the overhead for DNS CPU is also very inexpensive. We want to have the ability to use the fastest answer from an upstream DNS server as possible. We are also want redundancy so that we can remain unimpacted by planned and unplanned maintenance / issues. A local DNS cache helps with the fast response, but it does not help with an upstream servers availability. -- 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
