Hi all, In Ubuntu, by default the local caching per-interface / split-dns DNS resolver is systemd-resolved. Although by default all new installations are managed with netplan.io using either systemd-networked or NetworkManager backends with native support for resolved, we still have installations that use ifupdown / isc-dhcp / resolvconf stack.
I'm trying to improve the support for systemd-resolved, hopefully without regressing existing installations. Although resolvctl has resolvconf emulation mode, it is not suitable for Debian/Ubuntu, as it doesn't handle "$iface.$subtype" naming convention used to group&sort nameservers within an interface, and it also does not handle `lo.$subtype` system overrides of DNS nameservers to use by default. What I have envisioned is, when systemd-resolved is enabled, make ifupdown/isc-dhcp push DNS information directly to systemd-resolved via dhcp-exit-hook / ifup.d hooks that those packages ship directly. Supporting the wide syntax of dns nameserver resolution as was historically possible only when resolvconf was installed. And at the same time, when systemd-resolved is enabled, skip pulling those same DNS configurations into resolvconf. ..... for non-lo interfaces. Once all of the pieces of above work land, in Ubuntu, for the majority of cases, resolved will have correct per-interface DNS knowledge irrespective of whether or not it manages /etc/resolv.conf or not. And for most installation types, even with ifupdown / isc-dhcp / resolvconf they will receive the same experience as the netplan.io based install. I took care to ensure that ifupdown settings are prefered over the isc-dhcp ones, such that one can override whatever is coming from dhcp using manual configuration. And I also added support for DEFAULT_ROUTE setting via ifupdown, which resolved specific setting to fine-tune control, which interfaces / nameservers may or may not be used to resolve DNS names for an unmatched dns domain. (i.e. if there are two interfaces, one with search domain company.com and another with home.net, one can choose and mark of them as default_route false to explicitely disable said interface from resolving socialnetwork.com to specifically choose which interfaces should be used for the rest of the internet outside of the search domains). And if one disables systemd-resolved things should operate more or less as they have always done. The above mentioned integrations are currently still landing in groovy, and have not yet migrated, but should be available soon. -- Regards, Dimitri.
