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

Bug #1817903 reported by Steve Roberts
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
resolvconf (Ubuntu)
Fix Released
Critical
Dan Streetman
Bionic
Fix Released
Critical
Dan Streetman
Cosmic
Fix Released
Critical
Dan Streetman
Disco
Fix Released
Critical
Dan Streetman

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]

== upgrade from pre-bionic (e.g. xenial) to bionic or later ==

1) create a xenial system with ifupdown/resolvconf. The ifupdown config needs to include an upstream name server (must be static). At this point, once the network is configured and up, the resolvconf should have put the upstream name server(s) and search domain into the /etc/resolv.conf. As is usual for pre-systemd releases, there should be no local dns resolver in /etc/resolv.conf (i.e. 127.0.0.53 should not be included) at this point.

2) upgrade the system to bionic (alternately it should be possible to install bionic, then remove netplan and install/configure ifupdown and resolvconf, but I have not specifically tested this). The upgrade will retain the ifupdown/resolvconf configuration, and will not change to netplan/systemd-networkd. After upgrade is finished, the /etc/resolv.conf will contain:
  a) the upstream name server(s)
  b) options edns0
  c) the local stub resolver (127.0.0.53)
  d) search domain

the fixed resolvconf will remove (b).

As mentioned, this case also should cover the situation of a native Bionic install, where netplan is removed and ifupdown/resolvconf is manually installed.

== bionic or later install ==

with a bionic install, ifupdown is not installed, instead netplan/systemd-networkd handle networking. In this case, systemd-networkd manages the /etc/resolv.conf, and symlinks it to networkd's stub-resolv.conf which always contains only the local stub resolver (127.0.0.53) and (recently) options edns0, and local search domain.

If resolvconf is installed while systemd-networkd is managing the network, then currently the resolv.conf contents will remain completely unchanged, still pointing to the local stub resolver.

This resolvconf change will alter that, to remove 'options edns0'. No other changes will be made from the stub-resolv.conf.

[regression potential]

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

This will cause systems with resolvconf installed to lose the fix from bug 1811471, and again experience that bug.

[other info]

This affects only Bionic and later; in Xenial and earlier, systemd does not handle dns, and the 'edns0' option was not added to that systemd-resolved anyway.

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, did you try to downgrading the system packages to see if that resolves the issue?
The previous update has change in dns queries
https://bugs.launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.12

Would be interesting to know if that version already had the problem?

Revision history for this message
Steve Roberts (drgrumpy) wrote :

My update was from 237-3ubuntu10.11, which didn't have the problem (12 was never installed)

It seems I cannot easily downgrade via apt or synaptic, as the previous versions do not seem to be in the repos, can you advise how to do so?

On a different machine on the same network I still have 237-3ubuntu10.11 and it is working as expected (and I don't want to update!)

Revision history for this message
Brian Murray (brian-murray) wrote :

Could you give some examples of DNS lookups that fail for you so we can try and recreate the issue? Additionally, do you know what DNS servers you are using?

Revision history for this message
Dan Streetman (ddstreet) wrote :

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

in Bionic, resolv.conf links (by default) to /run/systemd/resolve/stub-resolv.conf; is that what you meant?

Can you paste the contents of your /etc/resolv.conf file here?

Revision history for this message
Sebastien Bacher (seb128) wrote :

@downgrade, basically

$ dpkg -l | grep 237-3ubuntu10
-> that should give you the list of systemd debs installed

download those from https://bugs.launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/16258134

and use 'sudo dpkg -i *.deb'

Revision history for this message
Dan Streetman (ddstreet) wrote :

Ok I have found what the problem is, I think; I suspect that you have resolvconf installed on your system, which is taking over the /etc/resolv.conf file, and I think that resolvconf is pulling the edns0 option, but also including external nameserver(s), which is an incorrect configuration, since the edns0 option should only be used when talking to the local stub resolver, because we don't know if external dns server(s) support edns.

The resolvconf package is not installed by default for Bionic (though I am not sure if Mint installs it by default for some reason). Is this system upgraded from a previous release, or did you install resolvconf manually? Unless you specifically need it, can you try unistalling resolvconf and rebooting to see if that fixes the problem for you?

$ sudo apt remove resolvconf
$ sudo reboot

And also please do paste the contents of /etc/resolv.conf here, especially if removing resolvconf doesn't help.

Revision history for this message
Steve Roberts (drgrumpy) wrote :

Thanks for the attention to this:

DNS servers: 208.67.220.220 (opend dns) and 212.159.6.10 (recommended by isp)

typical sites: planthealth.co.uk, plus random others...
nslookup and dig ok
ping domain_name gives "Name or service not known"
ping ip ok
FF: Hmmm problem etc...

So this is my resolv.conf which is def linked to /run/resolvconf/resolv.conf rather than the systemd stub-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
nameserver 127.0.0.53
options edns0

I do have resolvconf installed (think I upgreded to Mint 19 from 18.3 so that explains it...)...
will remove and report back...

Revision history for this message
Steve Roberts (drgrumpy) wrote :

Thanks again for the help....

Removed resolvconf:
sudo apt remove resolvconf

reboot

as expected now /etc/resolv.conf is linked to run/systemd/sub-resolv.conf
and contains only:

nameserver 127.0.0.53
options edns0

BUT now I cannot connect to anything, nslookup, ping fails, etc.
$ ping google.com
ping: google.com: Temporary failure in name resolution

and
$ systemd-resolve --status
does not list any dns

So I made a guess and added DNS=192.168.2.1
to /etc/systemd/resolved.conf

$ sudo systemctl restart systemd-resolved

now
$ systemd-resolve --status
lists dns as 192.168.2.1

and all is good...

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

Seems resolvconf was detecting this and adding the dns to resolv.conf, but systemd-resolve is not looking or detecting ?

So it seems to that the issue is really that systemd-resolve is adding the options to resolv.conf when it shouldn't interfere because resolvconf is in charge of it OR that systemd-resolve isn't checking /etc/network/interfaces for dns-nameservers....

Revision history for this message
Dan Streetman (ddstreet) wrote :

> 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
assignee: nobody → Dan Streetman (ddstreet)
status: New → In Progress
Revision history for this message
Steve Roberts (drgrumpy) wrote :

Yes that works, and many thanks for the explanation.

/etc/resolv.conf is now linked to /run/resolvconf/resolv.conf
and contains only the local proxy dns:

$ 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 all works as expected

But in the long term I guess I should move to systemd-networkd as the preferred way to set static ip?

Revision history for this message
Dan Streetman (ddstreet) wrote :

> But in the long term I guess I should move to systemd-networkd as the
> preferred way to set static ip?

that is entirely up to your preferences; ifupdown and resolvconf are still supported, and included, and you can continue to use them. They are still the default way to configure the network in Debian, as far as I know. However, Ubuntu starting at Bionic has switched to default to using either systemd-networkd (and system-resolved), or NetworkManager, or both; with configuration of both/either done by netplan. However, as you have seen, anyone who upgrades to Bionic or later from a pre-Bionic release will continue to use ifupdown/resolvconf.

If you're asking for what the recommended way is, then I would recommend switching to using systemd for network management, and using netplan for network configuration (or if you prefer, just creating systemd-networkd conf files directly).

Dan Streetman (ddstreet)
description: updated
Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Trusty):
status: New → Invalid
Changed in systemd (Ubuntu Xenial):
status: New → Invalid
Changed in systemd (Ubuntu Bionic):
status: New → In Progress
Changed in systemd (Ubuntu Cosmic):
status: New → In Progress
importance: Undecided → Critical
Changed in systemd (Ubuntu Bionic):
importance: Undecided → Critical
Changed in systemd (Ubuntu Cosmic):
assignee: nobody → Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Bionic):
assignee: nobody → Dan Streetman (ddstreet)
Revision history for this message
Dan Streetman (ddstreet) wrote :

@drgrumpy can you test the resolvconf package from this ppa to see if it correctly fixes the problem for you (on a system where you haven't worked around this by disabling the 'resolvconf-pull-resolved' service/path, of course):

https://launchpad.net/~ddstreet/+archive/ubuntu/lp1817903

description: updated
Revision history for this message
Dan Streetman (ddstreet) wrote :

@brian-murray since you commented in comment 3 and thus are familiar with this bug, and I don't have disco upload rights, please give my MP a look and merge into disco if you have a chance. I'll SRU to B/C once it's in D. Thanks.

Revision history for this message
Dan Streetman (ddstreet) wrote :

@xnox adding you to this bug fyi.

Revision history for this message
Steve Roberts (drgrumpy) wrote :

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

Revision history for this message
Dan Streetman (ddstreet) wrote :

> $ sudo systemctl enable resolvconf-pull-resolved.service
> this gives: The unit files have no installation config....

yes that's fine, sorry - this .service can't be enabled/disabled, it's just triggered by the .path service. I should have left out the 'disable' of it in my first instructions (as enable or disable for it does nothing, really).

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

excellent. thanks!

Eric Desrochers (slashd)
Changed in resolvconf (Ubuntu Disco):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → High
status: New → In Progress
importance: High → Critical
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package resolvconf - 1.79ubuntu11

---------------
resolvconf (1.79ubuntu11) disco; urgency=medium

  * Pull systemd-resolved conf from non-stub file; the stub file should
    not be used unless all dns traffic goes to the local stub resolver.
    Specifically, now that stub-resolv.conf includes edns0 option,
    using the stub conf with non-local dns servers can break dns
    resolution. (LP: #1817903)

 -- Dan Streetman <email address hidden> Thu, 28 Feb 2019 13:20:48 +0000

Changed in resolvconf (Ubuntu Disco):
status: In Progress → Fix Released
Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Bionic):
status: In Progress → Invalid
Changed in systemd (Ubuntu Cosmic):
status: In Progress → Invalid
Changed in systemd (Ubuntu Disco):
status: In Progress → Invalid
Changed in systemd (Ubuntu Bionic):
assignee: Dan Streetman (ddstreet) → nobody
importance: Critical → Undecided
Changed in systemd (Ubuntu Cosmic):
assignee: Dan Streetman (ddstreet) → nobody
importance: Critical → Undecided
Changed in systemd (Ubuntu Disco):
assignee: Dan Streetman (ddstreet) → nobody
importance: Critical → Undecided
Changed in resolvconf (Ubuntu Cosmic):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Critical
status: New → In Progress
Changed in resolvconf (Ubuntu Bionic):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Critical
status: New → In Progress
Changed in resolvconf (Ubuntu Xenial):
status: New → Invalid
Changed in resolvconf (Ubuntu Trusty):
status: New → Invalid
Dan Streetman (ddstreet)
description: updated
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Steve, or anyone else affected,

Accepted resolvconf into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resolvconf/1.79ubuntu10.18.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in resolvconf (Ubuntu Cosmic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-cosmic
Changed in resolvconf (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Hello Steve, or anyone else affected,

Accepted resolvconf into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resolvconf/1.79ubuntu10.18.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Steve Roberts (drgrumpy) wrote :

I followed the instructions at https://wiki.ubuntu.com/Testing/EnableProposed

but after repeated updates, it keeps telling me the it is not found:

 $ sudo apt-get install resolvconf/bionic-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Release ‘bionic-proposed’ for ‘resolvconf’ was not found

drgrumpy@phs08 ~ $ sudo apt-get install resolvconf=1.79ubuntu10.18.04.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version ‘1.79ubuntu10.18.04.1’ for ‘resolvconf’ was not found

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1817903] Re: systemd-resolve appends "options edns0" to resolv.conf

On Sat, Mar 02, 2019 at 11:33:13AM -0000, Steve Roberts wrote:
> I followed the instructions at
> https://wiki.ubuntu.com/Testing/EnableProposed

> but after repeated updates, it keeps telling me the it is not found:

> $ sudo apt-get install resolvconf/bionic-proposed
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Release ‘bionic-proposed’ for ‘resolvconf’ was not found

It works here. Are you perhaps using a mirror that's out of date?

Revision history for this message
Steve Roberts (drgrumpy) wrote :

On checking it seems that is the case. Tried a dozen different mirrors all give:
 Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/bionic-proposed/main/binary-amd64/Packages 404 Not Found [IP: 91.189.88.150 80]

Which mirror do you recommend?

Revision history for this message
Steve Langasek (vorlon) wrote :

ports.ubuntu.com is NOT a mirror of the main archive, it's a separate distribution channel for less-common architectures.

If in doubt, use archive.ubuntu.com.

Revision history for this message
Steve Roberts (drgrumpy) wrote :

Sorry, my bad, it seems I miss read the first part of the wiki! Now installed, will report back.

Revision history for this message
Steve Roberts (drgrumpy) wrote :

Installed resolvconf from bionic-proposed, all seems to working as it should.

Revision history for this message
pythonmeister (stefan-sonnenberg-pythonmeister) wrote :

I can confirm that the update from proposed solves the problem.

Dan Streetman (ddstreet)
description: updated
Revision history for this message
Dan Streetman (ddstreet) wrote :

bionic:

ubuntu@lp1817903-x-b:~$ dpkg -l | grep resolvconf
ii resolvconf 1.79ubuntu10 all name server information handler
ubuntu@lp1817903-x-b:~$ 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.122.1
nameserver 127.0.0.53
options edns0

ubuntu@lp1817903-x-b:~$ dpkg -l | grep resolvconf
ii resolvconf 1.79ubuntu10.18.04.1 all name server information handler
ubuntu@lp1817903-x-b:~$ 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.122.1

tags: added: verification-done-bionic
removed: verification-needed-bionic
Revision history for this message
Dan Streetman (ddstreet) wrote :

cosmic:

ubuntu@lp1817903-x-b-c:~$ dpkg -l |grep resolvconf
ii resolvconf 1.79ubuntu10 all name server information handler
ubuntu@lp1817903-x-b-c:~$ 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.122.1
nameserver 127.0.0.53
options edns0

ubuntu@lp1817903-x-b-c:~$ dpkg -l |grep resolvconf
ii resolvconf 1.79ubuntu10.18.10.1 all name server information handler
ubuntu@lp1817903-x-b-c:~$ 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.122.1

tags: added: verification-done verification-done-cosmic
removed: sts-sponsors verification-needed verification-needed-cosmic
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package resolvconf - 1.79ubuntu10.18.10.1

---------------
resolvconf (1.79ubuntu10.18.10.1) cosmic; urgency=medium

  * Pull systemd-resolved conf from non-stub file; the stub file should
    not be used unless all dns traffic goes to the local stub resolver.
    Specifically, now that stub-resolv.conf includes edns0 option,
    using the stub conf with non-local dns servers can break dns
    resolution. (LP: #1817903)

 -- Dan Streetman <email address hidden> Wed, 27 Feb 2019 17:01:03 -0500

Changed in resolvconf (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for resolvconf has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package resolvconf - 1.79ubuntu10.18.04.1

---------------
resolvconf (1.79ubuntu10.18.04.1) bionic; urgency=medium

  * Pull systemd-resolved conf from non-stub file; the stub file should
    not be used unless all dns traffic goes to the local stub resolver.
    Specifically, now that stub-resolv.conf includes edns0 option,
    using the stub conf with non-local dns servers can break dns
    resolution. (LP: #1817903)

 -- Dan Streetman <email address hidden> Wed, 27 Feb 2019 17:03:57 -0500

Changed in resolvconf (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Foo Bar (foobar123456) wrote :

I just got this update on Ubuntu 18.10 and it broke resolving of localhost subdomains. localhost can be resolved to 127.0.0.1, but any *.localhost can not.

man systemd-resolved has the following line:

  The hostnames "localhost" and "localhost.localdomain" (as well as any hostname ending in
  ".localhost" or ".localhost.localdomain") are resolved to the IP addresses 127.0.0.1 and ::1.

So this well-defined behaviour just broke with this patch.

Revision history for this message
Dan Streetman (ddstreet) wrote :

> man systemd-resolved has the following line:

If this update had any effect on you, then you're not using systemd-resolved; you're using resolvconf. If you don't want that, then uninstall resolvconf, and your dns resolution will revert to using systemd-resolved.

Revision history for this message
Foo Bar (foobar123456) wrote :

Thanks, that solved it. Not sure why I had both at all, never fiddled on this low level stuff. Must be a left-over from some Ubuntu upgrade in the past that was now triggered by this patch.

Revision history for this message
Steve Langasek (vorlon) wrote :

The resolvconf SRU also introduces regressions (LP: #1819625) and is in the process of being reverted.

Changed in resolvconf (Ubuntu Bionic):
status: Fix Released → Triaged
Changed in resolvconf (Ubuntu Cosmic):
status: Fix Released → Triaged
Dan Streetman (ddstreet)
Changed in resolvconf (Ubuntu Cosmic):
status: Triaged → In Progress
Changed in resolvconf (Ubuntu Bionic):
status: Triaged → In Progress
Changed in resolvconf (Ubuntu Disco):
status: Fix Released → In Progress
Revision history for this message
Dan Streetman (ddstreet) wrote :
tags: added: patch
Revision history for this message
Eric Desrochers (slashd) wrote :

Previous change reverted and new fix uploaded (after ddstreet discussion with xnox) in Disco.

- Eric

Changed in resolvconf (Ubuntu Disco):
status: In Progress → Fix Committed
Dan Streetman (ddstreet)
description: updated
tags: removed: verification-done verification-done-bionic verification-done-cosmic
Dan Streetman (ddstreet)
Changed in resolvconf (Ubuntu Disco):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Steve, or anyone else affected,

Accepted resolvconf into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resolvconf/1.79ubuntu10.18.10.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in resolvconf (Ubuntu Cosmic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-cosmic
Changed in resolvconf (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Steve, or anyone else affected,

Accepted resolvconf into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/resolvconf/1.79ubuntu10.18.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Steve Roberts (drgrumpy) wrote :

I have installed 1.79ubunbtu10.18.04.3 from the bionic-proposed and rebooted...

The result is different from before

$ 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 &quot;systemd-resolve --status&quot; to see details about the actual nameservers.

nameserver 192.168.2.1
nameserver 127.0.0.53

In previous fix 127.0.0.53 was not present

$ systemd-resolve --status
Global
         DNS Servers: 192.168.2.1
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
...

All seems to be working as expected.

tags: added: verification-done-bionic
removed: verification-needed-bionic
Revision history for this message
Dan Streetman (ddstreet) wrote :

ubuntu@lp1817903-c:~$ dpkg -l |grep resolvconf
ii resolvconf 1.79ubuntu10.18.10.2 all name server information handler
ubuntu@lp1817903-c:~$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0
search lxd

ubuntu@lp1817903-c:~$ dpkg -l |grep resolvconf
ii resolvconf 1.79ubuntu10.18.10.3 all name server information handler
ubuntu@lp1817903-c:~$ 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 127.0.0.53
search lxd

tags: added: verification-done verification-done-cosmic
removed: verification-needed verification-needed-cosmic
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package resolvconf - 1.79ubuntu10.18.10.3

---------------
resolvconf (1.79ubuntu10.18.10.3) cosmic; urgency=medium

  * d/resolvconf.resolvconf-pull-resolved.service
    Hack out the 'edns0' option that systemd-resolved has
    recently added to its stub-resolv.conf. (LP: #1817903)

 -- Dan Streetman <email address hidden> Thu, 14 Mar 2019 17:33:24 -0400

Changed in resolvconf (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package resolvconf - 1.79ubuntu10.18.04.3

---------------
resolvconf (1.79ubuntu10.18.04.3) bionic; urgency=medium

  * d/resolvconf.resolvconf-pull-resolved.service
    Hack out the 'edns0' option that systemd-resolved has
    recently added to its stub-resolv.conf. (LP: #1817903)

 -- Dan Streetman <email address hidden> Thu, 14 Mar 2019 17:35:23 -0400

Changed in resolvconf (Ubuntu Bionic):
status: Fix Committed → Fix Released
Mathew Hodson (mhodson)
no longer affects: resolvconf (Ubuntu Trusty)
no longer affects: resolvconf (Ubuntu Xenial)
no longer affects: systemd (Ubuntu Trusty)
no longer affects: systemd (Ubuntu Xenial)
no longer affects: systemd (Ubuntu)
no longer affects: systemd (Ubuntu Cosmic)
no longer affects: systemd (Ubuntu Bionic)
no longer affects: systemd (Ubuntu Disco)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.