> I do not use NetworkManager as I use fixed ip, so the ip, etc. and dns is/was
> specified in /etc/network/interfaces

ah, ok, so you are not using systemd-networkd then, ok that makes sense
since you upgraded from pre-bionic where ifupdown/resolvconf are the
default.  In bionic they have been replaced with just systemd-networkd
(and netplan for configuration) but upgrades keep ifupdown/resolvconf.

> So it seems to that the issue is really that systemd-resolve is adding the 
> options
> to resolv.conf when it shouldn't interfere

no - systemd-resolved does not add anything to the /etc/resolv.conf
file, it *only* sets up its privately-managed files, under
/run/systemd/resolve/.  If /etc/resolv.conf is symlinked to either the
stub or normal systemd-resolved file, then it will pick up all systemd-
resolved's config (since it's just a symlink, of course) but systemd
won't edit an existing /etc/resolv.conf.

> systemd-resolve isn't checking /etc/network/interfaces for dns-
nameservers....

it never does.  e/n/i is 100% ifupdown, completely separate from
systemd-networkd.


What's happening here is resolvconf has a systemd service that pulls
"original" config from systemd-resolved:

$ cat /lib/systemd/system/resolvconf-pull-resolved.service 
[Unit]
ConditionPathExists=/run/resolvconf/enable-updates
ConditionFileIsExecutable=/sbin/resolvconf

[Service]
Type=oneshot
ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | 
/sbin/resolvconf -a systemd-resolved'


This service is triggered whenever the systemd-resolved stub conf file changes:

$ cat /lib/systemd/system/resolvconf-pull-resolved.path 
[Path]
PathChanged=/run/systemd/resolve/stub-resolv.conf
PathExists=/run/systemd/resolve/stub-resolv.conf

[Install]
WantedBy=systemd-resolved.service


This service is just wrong; the stub-resolv.conf file is *strictly* for use as 
a /etc/resolv.conf symlink when systemd-resolved is managing the system's dns.  
There is another file, /run/systemd/resolve/resolv.conf, that is intended for 
use by other local applications that control the system's dns but also want to 
know about any dns info that systemd-resolved might know about; this file 
leaves out the local stub resolver's address (127.0.0.53) and the edns0 option.


As a temporary workaround until resolvconf can be fixed, can you try 
reinstalling resolvconf, and then disable it from pulling in the 
systemd-resolved stub configuration:

$ sudo apt install resolvconf
$ sudo systemctl disable resolvconf-pull-resolved.path
$ sudo systemctl disable resolvconf-pull-resolved.service
$ sudo reboot


After reboot, you should then have a /etc/resolv.conf that does not contain the 
127.0.0.53 local stub resolver nor the edns0 option.

Let me know if that works.  Thanks!


** Tags added: regression-update sts sts-sponsors

** Changed in: systemd (Ubuntu)
   Importance: Undecided => Critical

** Changed in: systemd (Ubuntu)
     Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: systemd (Ubuntu)
       Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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

Bug 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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to