[Bug 1817903] Re: systemd-resolve appends "options edns0" to resolv.conf

[Steve Roberts]

Testing fix:
I added the ppa (same system) and updated resolvconf

then did:
$ sudo systemctl enable resolvconf-pull-resolved.path
OK
and
$ sudo systemctl enable resolvconf-pull-resolved.service
this gives: The unit files have no installation config....
(not sure if this is expected ?), but it does seem to have operated (see below).

Then reboot, and all seems to work as expected, ok

cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 192.168.2.1

and the pull service has operated:
$ systemctl status resolvconf-pull-resolved.service
● resolvconf-pull-resolved.service
   Loaded: loaded (/lib/systemd/system/resolvconf-pull-resolved.service; static;
   Active: inactive (dead) since Thu 2019-02-28 10:26:50 GMT; 10min ago
  Process: 3359 ExecStart=/bin/sh -c cat /run/systemd/resolve/resolv.conf | /sbi
 Main PID: 3359 (code=exited, status=0/SUCCESS)

Feb 28 10:26:50 phs08 systemd[1]: Starting resolvconf-pull-resolved.service...
Feb 28 10:26:50 phs08 systemd[1]: Started resolvconf-pull-resolved.service

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

Title:
  systemd-resolve appends "options edns0" to resolv.conf

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

  systems upgraded from pre-Bionic releases to Bionic or later will
  continue to use ifupdown/resolvconf for network conf and management,
  but resolvconf has a new systemd service in Bionic and later that
  pulls systemd-resolved stub-resolv.conf into its local configuration.
  With the recent addition of edns0 option to the stub resolver conf in
  systemd to fix bug 1811471, this means resolvconf now sets up the
  /etc/resolv.conf file to include upstream servers but also use edns.
  For any systems where the upstream resolver(s) don't support edns, dns
  lookups will break.

  [test case]

  create a xenial system with ifupdown/resolvconf, then upgrade to
  bionic (alternately it should be possible to install bionic, then
  remove netplan and install/configure ifupdown and resolvconf).  The
  system ifupdown config should include an upstream name server.

  After upgrade, the /etc/resolv.conf will contain both the upstream
  name server as well as options edns0.

  [regression potential]

  this changes how resolvconf handles system dns on bionic and later:

  1) networking is managed by ifupdown

  resolvconf is currently adding the local stub resolver to
  /etc/resolv.conf, even though in this case it doesn't know about any
  upstream name servers.  This change will remove the local stub
  resolver from /etc/resolv.conf; it should not be there.

  2) networking is managed by systemd-networkd

  resolvconf is currently setting up /etc/resolv.conf to direct all
  local dns queries to the local stub resolver, similar to how systemd-
  resolved itself configures /etc/resolv.conf.  This change will instead
  set up /etc/resolv.conf to bypass the local stub resolver, and send
  all dns queries to the upstream name server(s).

  In case #1, this change has little chance for regression; in case #2
  however, this change will bypass the local stub resolver and thus
  create more network dns traffic (since dns queries will not be cached
  locally).  However, this is how pre-Bionic releases worked, and simply
  removing resolvconf will restore systemd-resolved control of
  /etc/resolv.conf, causing the system to again use the local stub
  resolver.

  Additional regressions due to this change would likely be seen in dns
  query failures with other system configurations.

  [other info]

  This affects only Bionic and later; in Xenial and earlier, resolvconf
  does not include the 'resolvconf-pull-resolved' service to pull in the
  systemd-resolved stub config, which is what causes this problem.

  This also does not affect Debian, as it does not include the
  'resolvconf-pull-resolved' service either.

  original description:

  --

  Mint 19 (Ubuntu 18.04)

  Following latest mint update done on 24/02/2019, DNS is broken....

  nslookup and dig of certain domain names work as expected, ping does
  not (ip works but not domain name)

  After a day of trial and error, testing I found that the problem lies
  with the presence of

  "options edns0"

  in /run/resolvconf/resolv.conf (link to by /etc/resolv.conf)

  With option present many dns lookups fail with both FF and chrome browswers and thunderbird...
  This is on a home network, with router set as dns proxy for external wan, not using NetworkManager

  Deleting the option on live system results in the issue immediately
  disappearing, but on reboot it is added back in (by systemd-resolve ?)

  I cannot find any option to prevent this being added, so presumably it
  is hard-coded in systemd following the update?

  systemd:
    Installed: 237-3ubuntu10.13

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1817903/+subscriptions