nplan and libnss-resolve should be in same dependency

[Stefan Bader]

I am filing this under nplan because I don't know what better anchor to use. I discovered for systems which I bring up by using debootstrap and then extend that installation to be bootable, I end up with nplan installed but not libnss-resolve. This results in broken DNS resolution when starting to use nplan.

It looks like nplan is a dependency of ubuntu-minimal but libnss-resolve is only in ubuntu-standard. But it is also required when using networkd as renderer for netplan.

[Mathieu Trudel-Lapierre (cyphermox)]

I don't think it is; you should be able to use things just as well with /etc/resolv.conf, and having systemd-networkd (or systemd-resolved) update it, depending on whether this is automatic via DHCP or for a static IP.

Regardless, in general I tend to agree libnss-resolve probably should be included at the same level as nplan; this will need some more testing.

In any case, not a bug in nplan, possibly a bug for libnss-resolve (systemd); so reassigning.

[Stefan Bader (smb)]

That would be the sane thing, however... Practically, without libnss-resolve installed "systemd-resolve --status" returns an error about some DBUS element and whether it is because of that or something else not properly checked, you end up with nothing in /etc/resolv.conf and thus without any DNS resolution at all.

Also a bit weird in that case is that "networkctl" shows the interface as routable/configured while clearly configuration did not go well. Meh!

[Dimitri John Ledkov (xnox)]

Which release is this for?

The expected behaviour is for:
1) /etc/resolv.conf to point at resolved stub resolver 127.0.0.53
2) systemd-resolved.service enabled by default and started on boot
3) systemd-resolve --status connecting over dbus and displaying resolved status
4) libnss-resolve module not installed, nor enabled.

What is your content of /etc/resolv.conf and what is the output of $ systemctl status systemd-resolved ?

[Stefan Bader (smb)]

Release: Artful/17.10

Manually removed libnss-resolve to simulate the result of only having installed ubuntu-minimal (netplan configured with networkd as renderer).

1) Actual result is that /etc/resolv.conf is empty (except for comments).

2) systemctl status systemd-resolved
* systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-resolved.service.d
        └─resolvconf.conf
Active: inactive (dead)

3) systemd-resolve --status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

journalctl |grep resolve
Jul 13 17:14:12 bar-artful6402 kernel: Key type dns_resolver registered
Jul 13 17:28:58 bar-artful6402 dbus[765]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service'
Jul 13 17:28:58 bar-artful6402 dbus[765]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.
Jul 13 17:43:57 bar-artful6402 dbus[765]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service'
Jul 13 17:43:57 bar-artful6402 dbus[765]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.

networkctl status eth0
* 2: eth0
       Link File: /lib/systemd/network/99-default.link
    Network File: /etc/systemd/network/05-eth0.network
            Type: ether
           State: routable (configured)
            Path: xen-vif-0
          Driver: vif
      HW Address: 00:16:3e:46:16:e2 (Xensource, Inc.)
         Address: 192.168.2.196
                  fe80::216:3eff:fe46:16e2
         Gateway: 192.168.2.1 (PC Engines GmbH)
             DNS: 192.168.2.1

[Stefan Bader (smb)]

Network file was still the override I had from when RA was causing problems. Same results after removal and re-applying netplan.

[Dimitri John Ledkov (xnox)]

about nplan/libnss-resolve dependency. This issue has been resolved in systemd, it appears that resolved has not been started from systemd package at all, when it should have been since yakkety.

systemd (234-1ubuntu2) artful; urgency=medium

  * Set UseDomains to true, by default, on Ubuntu.
    On Ubuntu, fallback DNS servers are disabled, therefore we do not leak queries
    to a preset 3rd party by default. In resolved, dnssec is also disabled by
    default, as too much of the internet is broken and using Ubuntu users to debug
    the internet is not very productive - most of the time the end-user cannot fix
    or know how to notify the site owners about the dnssec mistakes. Inherintally
    the DHCP acquired DNS servers are therefore trusted, and are free to spoof
    records. Not trusting DNS search domains, in such scenario, provides limited
    security or privacy benefits. From user point of view, this also appears to be
    a regression from previous Ubuntu releases which do trust DHCP acquired search
    domains by default.
    Therefore we are enabling UseDomains by default on Ubuntu.
    Users may override this setting in the .network files by specifying
    [DHCP|IPv6AcceptRA] UseDomains=no|route options.
  * resolved: create private stub resolve file for integration with resolvconf.
    The stub-resolve.conf file points at resolved stub resolver, but also lists the
    available search domains. This is required to correctly resolve domains without
    using resolve nss module.
  * Enable systemd-resolved by default
  * Create /etc/resolv.conf at postinst, pointing at the stub resolver.
    The stub resolver file is dynamically managed by systemd-resolved. It points at
    the stub resolver as the nameserver, however it also dynamically updates the
    search stanza, thus non-nss dns tools work correctly with unqualified names and
    correctly use the DHCP acquired search domains.
  * libnss-resolve: do not disable and stop systemd-resolved
    resolved is always used by default on ubuntu via stub resolver, therefore it
    should continue to operate without libnss-resolve module installed.

 -- Dimitri John Ledkov <email address hidden> Fri, 21 Jul 2017 17:07:17 +0100

[Dimitri John Ledkov (xnox)]

This has now migrated, please retest.