resolv.conf for resolved stub server should have a comment how to see the actual servers

[Martin Pitt]

resolv.conf currently just has

  nameserver 127.0.0.53

with resolved (its local stub resolver). We should have an extra comment on top of that that says

  # systemd-resolved stub resolver; run "systemd-resolve --status" to see the actual name servers

[Martin Pitt (pitti)]

Turns out that resolvconf always filters out comments, so the only way to get a comment in there is via /etc/resolvconf/resolv.conf.d/head. So moving package.

[Thomas Hood (jdthood)]

If such a comment were to be added then in order not to mislead it would have to take into account the configurability of various components. So you'd have to say something like:

«If the line "nameserver 127.0.0.53" is present then it probably refers to the systemd resolver listening on the loopback address. By default the systemd resolver is also configured to handle name queries via the Name Service Switch whose configuration file is nsswitch.conf. The name servers to which the systemd resolver forwards queries can be discovered by running "systemd-resolve --status".»

What would be far better, though, is to include a text file or manpage explaining how name service currently works in Ubuntu. (Actually we should have done this long ago.) The file could include the previous paragraph but would also talk about resolvconf and NetworkManager and its plugins. The name of this file could then be mentioned in the header that resolvconf writes into resolv.conf. /etc/resolvconf/resolv.conf.d/head would then be:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# For more info see /usr/share/doc/resolvconf/name-service-in-Ubuntu.txt
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

[Martin Pitt (pitti)]

Right, the comment would need to be conditional. My original naïve approach was to add the comment together with the nameserver, such as

printf "# Run systemd-resolve --status blabla\nnameserver 127.0.0.53\n" | /sbin/resolvconf -a systemd-resolved

so that the comment would only be there when appropriate and would also be at the appropriate line.

manpage> Not sure if that really helps -- this would also have to contain a lot of "if"s, like "if you have resolved/unbound/NM's dnsmasq/etc." and document all of these cases, which is both confusing and also prone to get out of sync with their respective upstreams.

(FTR, there is nothing Ubuntu specific here, it's the same in Debian and any other Linux)

[Thomas Hood (jdthood)]

Right, I think the file should only document the Ubuntu-specific things such as the facts that by default resolvconf and the systemd resolver are used, NetworkManager is used by default on Desktop and ifup on Server, and so on. There have been hundreds of questions about these basic things on AskUbuntu and the forums over the years. I have often referred people to Stephane Graber's blog post (https://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/) for background info but this is as of 16.11 no longer adequate.

[Steve Langasek (vorlon)]

On Fri, Nov 04, 2016 at 11:53:11AM -0000, Thomas Hood wrote:
> What would be far better, though, is to include a text file or manpage
> explaining how name service currently works in Ubuntu.

That doesn't help the problem that /etc/resolv.conf is the file that the
experienced admin expects to contain the nameservers' addresses.

> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
> # For more info see /usr/share/doc/resolvconf/name-service-in-Ubuntu.txt
> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

The admin is not going to follow documentation links for the thing that
"should" be working the way it always worked and that Ubuntu has broken.
Documentation is what you look for when you're looking to understand
something new, not to understand why Ubuntu has become buggy and annoying.

This text should go directly in /etc/resolv.conf.

[Steve Langasek (vorlon)]

I have a fix for resolvconf here, but it's inaccurate for the desktop because Network Manager is still doing dnsmasq by default. Opening a task for NM.

[Martin Pitt (pitti)]

https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver has the two outstanding issues to switch NM over to resolved too. These are unblocked now: the new resolved DNS plugin is in upstream master since around September, and NM 1.4 landed in zesty-proposed yesterday. Let's land that first, then backport the DNS plugin and switch it over, then we'll consistently use resolved everywhere and that comment will be much easier to write.

This is also the reason why I didn't do this comment change yet, I think it's better to wait for the above.

[Launchpad Janitor (janitor)]

This bug was fixed in the package resolvconf - 1.79ubuntu2

---------------
resolvconf (1.79ubuntu2) zesty; urgency=medium

  * etc/resolvconf/resolv.conf.d/head: add comment about
    'systemd-resolve --status', since systemd-resolved is now in use in all
    but the most unusual configurations, and expert users should be given
    guidance where to find the actual nameservers for debugging purposes.
    LP: #1638836.

 -- Steve Langasek <email address hidden> Mon, 28 Nov 2016 15:39:18 -0800

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager - 1.4.2-2ubuntu4

---------------
network-manager (1.4.2-2ubuntu4) zesty; urgency=medium

  [ Martin Pitt ]
  * Add resolved DNS plugin (backported from upstream master).
  * Disable resolvconf support.
    This is broken with DNS plugins other than "dnsmasq" -- it still writes
    127.0.1.1 into resolvconf as a nameserver, but this does not exist any more and
    will also shadow resolved's stub server on 127.0.0.53.
    This ought to be fixed more properly in the future.

  [ Steve Langasek ]
  * Re-drop dnsmasq in zesty, in favor of systemd-resolved.
    This unifies DNS lookups between Ubuntu desktop and server.
    But don't Recommend libnss-resolve, because the local resolver + libnss_dns.so
    should suffice for all uses and the resolved nss module is unnecessary added
    complexity.
    We need to specify "dns=systemd-resolved" as for the time being our
    /etc/resolv.conf points to resolvconf's generated file instead of
    systemd-resolved's, so the auto-detection does not work. Do that in a
    separate conf.d file in /usr to avoid unnecessary conffile prompts in the
    future. The user can still override it in /etc. (LP: #1638836)

 -- Martin Pitt <email address hidden> Fri, 02 Dec 2016 09:36:02 +0100

[Harry (harry33)]

Martin,

Please note, that in my setup, the network is lost immediately after rebooting with the new network-manager (1.4.2-2ubuntu4). Then, downgrading back to version 1.4.2.-2ubuntu3, and rebooting, I get network back.

In both of these versions, the network-manager creates the same kind of file /etc/resol.vconf.

I only use a cable network. I do not have the package resolvconf installed, as no other package depends on it (isc-dhcp-client merely suggests it).

[Martin Pitt (pitti)]

Hello Harry,

Harry [2016-12-03 15:02 -0000]:
> Please note, that in my setup, the network is lost immediately after
> rebooting with the new network-manager (1.4.2-2ubuntu4).

Thanks for filing bug 1647133, tracking that issue there.