Different systemd-resolved integration for ifupdown/isc-dhcp/resolvconf in Ubuntu

Dimitri John Ledkov xnox at ubuntu.com
Thu Aug 6 11:12:11 BST 2020


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.



More information about the Pkg-systemd-maintainers mailing list