[Bug 1817903] Re: systemd-resolve appends "options edns0" to resolv.conf
Dan Streetman
dan.streetman at canonical.com
Wed Feb 27 19:01:44 UTC 2019
> 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
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
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
More information about the foundations-bugs
mailing list