| 2019-02-27 12:44:07 |
Steve Roberts |
bug |
|
|
added bug |
| 2019-02-27 14:04:04 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2019-02-27 16:44:20 |
Bryan Quigley |
bug |
|
|
added subscriber Bryan Quigley |
| 2019-02-27 19:03:11 |
Dan Streetman |
tags |
|
regression-update sts sts-sponsors |
|
| 2019-02-27 19:03:19 |
Dan Streetman |
systemd (Ubuntu): importance |
Undecided |
Critical |
|
| 2019-02-27 19:03:22 |
Dan Streetman |
systemd (Ubuntu): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-02-27 19:03:25 |
Dan Streetman |
systemd (Ubuntu): status |
New |
In Progress |
|
| 2019-02-27 21:54:22 |
Dan Streetman |
merge proposal linked |
|
https://code.launchpad.net/~ddstreet/ubuntu/+source/resolvconf/+git/resolvconf/+merge/363748 |
|
| 2019-02-27 22:36:07 |
Dan Streetman |
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 |
[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]
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 |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Xenial) |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Bionic) |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
nominated for series |
|
Ubuntu Disco |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Disco) |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
nominated for series |
|
Ubuntu Trusty |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Trusty) |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
nominated for series |
|
Ubuntu Cosmic |
|
| 2019-02-27 22:45:53 |
Dan Streetman |
bug task added |
|
systemd (Ubuntu Cosmic) |
|
| 2019-02-27 22:46:04 |
Dan Streetman |
systemd (Ubuntu Trusty): status |
New |
Invalid |
|
| 2019-02-27 22:46:07 |
Dan Streetman |
systemd (Ubuntu Xenial): status |
New |
Invalid |
|
| 2019-02-27 22:46:10 |
Dan Streetman |
systemd (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-02-27 22:46:12 |
Dan Streetman |
systemd (Ubuntu Cosmic): status |
New |
In Progress |
|
| 2019-02-27 22:46:14 |
Dan Streetman |
systemd (Ubuntu Cosmic): importance |
Undecided |
Critical |
|
| 2019-02-27 22:46:16 |
Dan Streetman |
systemd (Ubuntu Bionic): importance |
Undecided |
Critical |
|
| 2019-02-27 22:46:20 |
Dan Streetman |
systemd (Ubuntu Cosmic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-02-27 22:46:22 |
Dan Streetman |
systemd (Ubuntu Bionic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-02-27 22:55:22 |
Dan Streetman |
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]
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 |
[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 |
|
| 2019-02-27 23:08:10 |
Dan Streetman |
bug |
|
|
added subscriber Brian Murray |
| 2019-02-27 23:10:22 |
Dan Streetman |
bug |
|
|
added subscriber Dimitri John Ledkov |
| 2019-02-28 13:07:13 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2019-02-28 13:19:52 |
Eric Desrochers |
bug task added |
|
resolvconf (Ubuntu) |
|
| 2019-02-28 13:20:16 |
Eric Desrochers |
resolvconf (Ubuntu Disco): importance |
Undecided |
High |
|
| 2019-02-28 13:20:16 |
Eric Desrochers |
resolvconf (Ubuntu Disco): status |
New |
In Progress |
|
| 2019-02-28 13:20:16 |
Eric Desrochers |
resolvconf (Ubuntu Disco): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-02-28 13:20:30 |
Eric Desrochers |
resolvconf (Ubuntu Disco): importance |
High |
Critical |
|
| 2019-02-28 14:18:21 |
Launchpad Janitor |
resolvconf (Ubuntu Disco): status |
In Progress |
Fix Released |
|
| 2019-02-28 15:01:04 |
Dan Streetman |
systemd (Ubuntu Bionic): status |
In Progress |
Invalid |
|
| 2019-02-28 15:01:13 |
Dan Streetman |
systemd (Ubuntu Cosmic): status |
In Progress |
Invalid |
|
| 2019-02-28 15:01:22 |
Dan Streetman |
systemd (Ubuntu Disco): status |
In Progress |
Invalid |
|
| 2019-02-28 15:01:33 |
Dan Streetman |
systemd (Ubuntu Bionic): importance |
Critical |
Undecided |
|
| 2019-02-28 15:01:33 |
Dan Streetman |
systemd (Ubuntu Bionic): assignee |
Dan Streetman (ddstreet) |
|
|
| 2019-02-28 15:01:42 |
Dan Streetman |
systemd (Ubuntu Cosmic): importance |
Critical |
Undecided |
|
| 2019-02-28 15:01:42 |
Dan Streetman |
systemd (Ubuntu Cosmic): assignee |
Dan Streetman (ddstreet) |
|
|
| 2019-02-28 15:01:51 |
Dan Streetman |
systemd (Ubuntu Disco): importance |
Critical |
Undecided |
|
| 2019-02-28 15:01:51 |
Dan Streetman |
systemd (Ubuntu Disco): assignee |
Dan Streetman (ddstreet) |
|
|
| 2019-02-28 15:02:03 |
Dan Streetman |
resolvconf (Ubuntu Cosmic): importance |
Undecided |
Critical |
|
| 2019-02-28 15:02:03 |
Dan Streetman |
resolvconf (Ubuntu Cosmic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-02-28 15:02:10 |
Dan Streetman |
resolvconf (Ubuntu Cosmic): status |
New |
In Progress |
|
| 2019-02-28 15:02:23 |
Dan Streetman |
resolvconf (Ubuntu Bionic): importance |
Undecided |
Critical |
|
| 2019-02-28 15:02:23 |
Dan Streetman |
resolvconf (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-02-28 15:02:23 |
Dan Streetman |
resolvconf (Ubuntu Bionic): assignee |
|
Dan Streetman (ddstreet) |
|
| 2019-02-28 15:02:31 |
Dan Streetman |
resolvconf (Ubuntu Xenial): status |
New |
Invalid |
|
| 2019-02-28 15:02:40 |
Dan Streetman |
resolvconf (Ubuntu Trusty): status |
New |
Invalid |
|
| 2019-02-28 15:03:41 |
Dan Streetman |
removed subscriber Brian Murray |
|
|
|
| 2019-02-28 15:03:58 |
Dan Streetman |
removed subscriber Dimitri John Ledkov |
|
|
|
| 2019-03-01 01:10:10 |
Dan Streetman |
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 |
[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 (either static or dynamic). 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) and (c), and restore /etc/resolv.conf to what it contained in Xenial release, before the upgrade to Bionic.
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 revert the /etc/resolv.conf to Xenial's contents; specifically, the upstream name server(s) and search domain. It will no longer include the local stub resolver nor edns0.
[regression potential]
Regressions due to this change would likely be seen in dns query failures with other system configurations.
Additionally, for the case where systemd-networkd is actually managing the network, this change will stop sending dns traffic to the local stub resolver, and instead send it to the upstream name server(s). This will increase outgoing dns traffic (since it's no longer cached locally), but will matches the behavior from Xenial. Additionally, resolvconf should not be needed when systemd-networkd is managing the network (and thus systemd-resolved is managing dns), and resolvconf can simply be uninstalled from the system to move back to normal use of the local stub resolver.
[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 |
|
| 2019-03-01 02:46:14 |
Eric Desrochers |
removed subscriber STS Sponsors |
|
|
|
| 2019-03-01 02:46:19 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2019-03-01 09:47:25 |
Łukasz Zemczak |
resolvconf (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2019-03-01 09:47:27 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-03-01 09:47:29 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2019-03-01 09:47:32 |
Łukasz Zemczak |
tags |
regression-update sts sts-sponsors |
regression-update sts sts-sponsors verification-needed verification-needed-cosmic |
|
| 2019-03-01 09:48:23 |
Łukasz Zemczak |
resolvconf (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-03-01 09:48:28 |
Łukasz Zemczak |
tags |
regression-update sts sts-sponsors verification-needed verification-needed-cosmic |
regression-update sts sts-sponsors verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2019-03-05 10:03:27 |
Dan Streetman |
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 (either static or dynamic). 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) and (c), and restore /etc/resolv.conf to what it contained in Xenial release, before the upgrade to Bionic.
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 revert the /etc/resolv.conf to Xenial's contents; specifically, the upstream name server(s) and search domain. It will no longer include the local stub resolver nor edns0.
[regression potential]
Regressions due to this change would likely be seen in dns query failures with other system configurations.
Additionally, for the case where systemd-networkd is actually managing the network, this change will stop sending dns traffic to the local stub resolver, and instead send it to the upstream name server(s). This will increase outgoing dns traffic (since it's no longer cached locally), but will matches the behavior from Xenial. Additionally, resolvconf should not be needed when systemd-networkd is managing the network (and thus systemd-resolved is managing dns), and resolvconf can simply be uninstalled from the system to move back to normal use of the local stub resolver.
[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 |
[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) and (c), and restore /etc/resolv.conf to what it contained in Xenial release, before the upgrade to Bionic.
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 revert the /etc/resolv.conf to Xenial's contents; specifically, the upstream name server(s) and search domain. It will no longer include the local stub resolver nor edns0.
[regression potential]
Regressions due to this change would likely be seen in dns query failures with other system configurations.
Additionally, for the case where systemd-networkd is actually managing the network, this change will stop sending dns traffic to the local stub resolver, and instead send it to the upstream name server(s). This will increase outgoing dns traffic (since it's no longer cached locally), but will matches the behavior from Xenial. Additionally, resolvconf should not be needed when systemd-networkd is managing the network (and thus systemd-resolved is managing dns), and resolvconf can simply be uninstalled from the system to move back to normal use of the local stub resolver.
[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 |
|
| 2019-03-05 10:09:22 |
Dan Streetman |
tags |
regression-update sts sts-sponsors verification-needed verification-needed-bionic verification-needed-cosmic |
regression-update sts sts-sponsors verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2019-03-05 10:27:49 |
Dan Streetman |
tags |
regression-update sts sts-sponsors verification-done-bionic verification-needed verification-needed-cosmic |
regression-update sts verification-done verification-done-bionic verification-done-cosmic |
|
| 2019-03-08 12:20:42 |
Sven Luzar |
bug |
|
|
added subscriber Sven Luzar |
| 2019-03-11 15:38:44 |
Launchpad Janitor |
resolvconf (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-03-11 15:38:48 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-03-11 18:24:49 |
Launchpad Janitor |
resolvconf (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-03-13 21:41:06 |
Steve Langasek |
resolvconf (Ubuntu Bionic): status |
Fix Released |
Triaged |
|
| 2019-03-13 21:41:24 |
Steve Langasek |
resolvconf (Ubuntu Cosmic): status |
Fix Released |
Triaged |
|
| 2019-03-14 21:13:41 |
Dan Streetman |
resolvconf (Ubuntu Cosmic): status |
Triaged |
In Progress |
|
| 2019-03-14 21:13:55 |
Dan Streetman |
resolvconf (Ubuntu Bionic): status |
Triaged |
In Progress |
|
| 2019-03-14 21:14:07 |
Dan Streetman |
resolvconf (Ubuntu Disco): status |
Fix Released |
In Progress |
|
| 2019-03-15 12:00:27 |
Dan Streetman |
attachment added |
|
lp1817903-disco.debdiff https://bugs.launchpad.net/ubuntu/disco/+source/resolvconf/+bug/1817903/+attachment/5246425/+files/lp1817903-disco.debdiff |
|
| 2019-03-15 12:24:01 |
Ubuntu Foundations Team Bug Bot |
tags |
regression-update sts verification-done verification-done-bionic verification-done-cosmic |
patch regression-update sts verification-done verification-done-bionic verification-done-cosmic |
|
| 2019-03-15 12:55:51 |
Eric Desrochers |
bug |
|
|
added subscriber STS Sponsors |
| 2019-03-15 13:43:09 |
Eric Desrochers |
resolvconf (Ubuntu Disco): status |
In Progress |
Fix Committed |
|
| 2019-03-15 13:54:20 |
Dan Streetman |
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) and (c), and restore /etc/resolv.conf to what it contained in Xenial release, before the upgrade to Bionic.
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 revert the /etc/resolv.conf to Xenial's contents; specifically, the upstream name server(s) and search domain. It will no longer include the local stub resolver nor edns0.
[regression potential]
Regressions due to this change would likely be seen in dns query failures with other system configurations.
Additionally, for the case where systemd-networkd is actually managing the network, this change will stop sending dns traffic to the local stub resolver, and instead send it to the upstream name server(s). This will increase outgoing dns traffic (since it's no longer cached locally), but will matches the behavior from Xenial. Additionally, resolvconf should not be needed when systemd-networkd is managing the network (and thus systemd-resolved is managing dns), and resolvconf can simply be uninstalled from the system to move back to normal use of the local stub resolver.
[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 |
[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 |
|
| 2019-03-15 13:54:46 |
Dan Streetman |
tags |
patch regression-update sts verification-done verification-done-bionic verification-done-cosmic |
patch regression-update sts |
|
| 2019-03-15 15:22:55 |
Dan Streetman |
resolvconf (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-03-20 19:33:17 |
Brian Murray |
resolvconf (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2019-03-20 19:33:23 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-03-20 19:33:30 |
Brian Murray |
tags |
patch regression-update sts |
patch regression-update sts verification-needed verification-needed-cosmic |
|
| 2019-03-20 19:35:49 |
Brian Murray |
resolvconf (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-03-20 19:35:58 |
Brian Murray |
tags |
patch regression-update sts verification-needed verification-needed-cosmic |
patch regression-update sts verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2019-03-21 09:50:48 |
Steve Roberts |
tags |
patch regression-update sts verification-needed verification-needed-bionic verification-needed-cosmic |
patch regression-update sts verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2019-03-22 05:14:09 |
Mathew Hodson |
bug |
|
|
added subscriber Mathew Hodson |
| 2019-03-29 21:29:29 |
Dan Streetman |
tags |
patch regression-update sts verification-done-bionic verification-needed verification-needed-cosmic |
patch regression-update sts verification-done verification-done-bionic verification-done-cosmic |
|
| 2019-04-01 11:38:42 |
Launchpad Janitor |
resolvconf (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-04-01 12:55:23 |
Launchpad Janitor |
resolvconf (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-04-03 04:46:21 |
Mathew Hodson |
bug task deleted |
resolvconf (Ubuntu Trusty) |
|
|
| 2019-04-03 04:46:29 |
Mathew Hodson |
bug task deleted |
resolvconf (Ubuntu Xenial) |
|
|
| 2019-04-03 04:46:40 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Trusty) |
|
|
| 2019-04-03 04:46:49 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Xenial) |
|
|
| 2019-04-03 04:46:56 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu) |
|
|
| 2019-04-03 04:47:09 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Cosmic) |
|
|
| 2019-04-03 04:47:15 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Bionic) |
|
|
| 2019-04-03 04:47:23 |
Mathew Hodson |
bug task deleted |
systemd (Ubuntu Disco) |
|
|
| 2019-04-03 04:47:50 |
Mathew Hodson |
removed subscriber Mathew Hodson |
|
|
|
