[Bug 1745463] Re: Disabling systemd-resolved breaks dhclient resolvconf integration

[Steve Langasek]

On Thu, Jan 25, 2018 at 11:02:35PM -0000, GeekSmith wrote:
> Is the use of resolvconf and ifupdown without resolved an unsupported
> configuration in 17.10?

resolvconf is in universe as of 17.10.  In effect, yes, this is
unsupported.

> Is resolved the only supported DNS configuration management system in
> Ubuntu 17.10?

Yes.

> There are many users who value the control and flexibility of
> pre-resolved systems and do not want a local caching nameserver.

Flexibility for flexibility's sake is not a goal of Ubuntu.

resolved is not configured as a caching nameserver; it is a stub resolver,
configured for the purpose of ensuring a stable DNS endpoint.

> The inadequacy is that systemd breaks resolvconf.

I'm sorry, but this is a circular argument which does not explain why you
are trying to use resolvconf in the first place.

> There are too many systems, mainly servers, that cannot or should not
> run a nameserver, not even a local one. resolved is not ready to service
> these systems.

What determines that a server "cannot or should not" run a local
resolver?

Enabling a local resolver on servers in addition to desktops (where we have
already enabled dnsmasq for years) has been a common request.

If there are scenarios where it is not appropriate to run resolved, then we
should absolutely evaluate those and determine how they should be supported
in Ubuntu.  However, they must be evaluated on their own merits, which means
that the technical details must be presented for consideration.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1745463

Title:
  Disabling systemd-resolved breaks dhclient resolvconf integration

Status in resolvconf package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

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