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

2019-04-02 Thread Mathew Hodson
** 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)

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in resolvconf source package in Bionic:
  Fix Released
Status in resolvconf source package in Cosmic:
  Fix Released
Status in resolvconf source package in Disco:
  Fix Released

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

To manage notifications about this bug go to:

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

2019-04-01 Thread Launchpad Bug Tracker
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   Thu, 14 Mar 2019 17:35:23
-0400

** Changed in: resolvconf (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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...
  

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

2019-04-01 Thread Launchpad Bug Tracker
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   Thu, 14 Mar 2019 17:33:24
-0400

** Changed in: resolvconf (Ubuntu Cosmic)
   Status: Fix Committed => Fix Released

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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...
  

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

2019-03-29 Thread Dan Streetman
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 removed: verification-needed verification-needed-cosmic
** Tags added: verification-done verification-done-cosmic

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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'.  

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

2019-03-21 Thread Steve Roberts
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 systemd-resolve --status 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 removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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

  

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

2019-03-20 Thread Brian Murray
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

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 

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

2019-03-15 Thread Dan Streetman
** Changed in: resolvconf (Ubuntu Disco)
   Status: Fix Committed => Fix Released

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  In Progress
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  In Progress
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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?

  

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

2019-03-15 Thread Dan Streetman
** Description changed:

  [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.
+ 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 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.
+ 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.
  
- 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.
+ 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, resolvconf
- does not include the 'resolvconf-pull-resolved' service to pull in the
- systemd-resolved stub config, which is what causes this problem.
+ 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 

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

2019-03-15 Thread Eric Desrochers
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

-- 
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 resolvconf package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  In Progress
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  In Progress
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Committed
Status in systemd source package in Disco:
  Invalid

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 

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

2019-03-15 Thread Ubuntu Foundations Team Bug Bot
** Tags added: patch

-- 
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 resolvconf package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  In Progress
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  In Progress
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  In Progress
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-15 Thread Dan Streetman
** Patch added: "lp1817903-disco.debdiff"
   
https://bugs.launchpad.net/ubuntu/disco/+source/resolvconf/+bug/1817903/+attachment/5246425/+files/lp1817903-disco.debdiff

-- 
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 resolvconf package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  In Progress
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  In Progress
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  In Progress
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-14 Thread Dan Streetman
** 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

-- 
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 resolvconf package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  In Progress
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  In Progress
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  In Progress
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-13 Thread Steve Langasek
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

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Triaged
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Triaged
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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) 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
  

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

2019-03-12 Thread Foo Bar
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.

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-12 Thread Dan Streetman
> 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.

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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) 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
  

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

2019-03-12 Thread Foo Bar
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.

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-11 Thread Launchpad Bug Tracker
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   Wed, 27 Feb 2019 17:03:57
-0500

** Changed in: resolvconf (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Released
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-11 Thread Launchpad Bug Tracker
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   Wed, 27 Feb 2019 17:01:03
-0500

** Changed in: resolvconf (Ubuntu Cosmic)
   Status: Fix Committed => Fix Released

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Released
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-05 Thread Dan Streetman
cosmic:

ubuntu@lp1817903-x-b-c:~$ dpkg -l |grep resolvconf
ii  resolvconf1.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  resolvconf1.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 removed: sts-sponsors verification-needed verification-needed-cosmic
** Tags added: verification-done verification-done-cosmic

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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) 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 

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

2019-03-05 Thread Dan Streetman
bionic:

ubuntu@lp1817903-x-b:~$ dpkg -l | grep resolvconf
ii  resolvconf1.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  resolvconf1.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


** Description changed:

  [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
+ 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
+   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]
  

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

2019-03-04 Thread pythonmeister
I can confirm that the update from proposed solves the problem.

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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 

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

2019-03-04 Thread Steve Roberts
Installed resolvconf from bionic-proposed, all seems to working as it
should.

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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 

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

2019-03-03 Thread Steve Roberts
Sorry, my bad, it seems I miss read the first part of the wiki! Now
installed, will report back.

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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

  

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

2019-03-02 Thread Steve Langasek
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.

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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)

  

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

2019-03-02 Thread Steve Roberts
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?

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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
  

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

2019-03-02 Thread Steve Langasek
On Sat, Mar 02, 2019 at 11:33:13AM -, 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?

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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 

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

2019-03-02 Thread Steve Roberts
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

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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 

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

2019-03-01 Thread Łukasz Zemczak
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

-- 
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 resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in resolvconf source package in Trusty:
  Invalid
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in resolvconf source package in Cosmic:
  Fix Committed
Status in systemd source package in Cosmic:
  Invalid
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  Invalid

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 (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 

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

2019-02-28 Thread Dan Streetman
** Description changed:

  [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.
+ == upgrade from pre-bionic (e.g. xenial) to bionic or later ==
  
- After upgrade, the /etc/resolv.conf will contain both the upstream name
- server as well as options edns0.
+ 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]
  
- this changes how resolvconf handles system dns on bionic and later:
+ Regressions due to this change would likely be seen in dns query
+ failures with other system configurations.
  
- 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.
+ 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, 

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

2019-02-28 Thread Dan Streetman
** 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)
   Importance: Critical => Undecided

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

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

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

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

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

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

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

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

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

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

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

** Changed in: resolvconf (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: resolvconf (Ubuntu Trusty)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1817903

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

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

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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


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

2019-02-28 Thread Launchpad Bug Tracker
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   Thu, 28 Feb 2019 13:20:48
+

** Changed in: resolvconf (Ubuntu Disco)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1817903

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

Status in resolvconf package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in resolvconf source package in Trusty:
  New
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  New
Status in systemd source package in Bionic:
  In Progress
Status in resolvconf source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  In Progress
Status in resolvconf source package in Disco:
  Fix Released
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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

  original description:

  --

  Mint 19 (Ubuntu 18.04)

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

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

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

  "options edns0"

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

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

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

  I cannot find any option to prevent this being added, so presumably it
  is 

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

2019-02-28 Thread Eric Desrochers
** Also affects: resolvconf (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: resolvconf (Ubuntu Disco)
   Importance: Undecided => High

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

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

** Changed in: resolvconf (Ubuntu Disco)
   Importance: High => Critical

-- 
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 resolvconf package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in resolvconf source package in Trusty:
  New
Status in systemd source package in Trusty:
  Invalid
Status in resolvconf source package in Xenial:
  New
Status in systemd source package in Xenial:
  Invalid
Status in resolvconf source package in Bionic:
  New
Status in systemd source package in Bionic:
  In Progress
Status in resolvconf source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  In Progress
Status in resolvconf source package in Disco:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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

  original description:

  --

  Mint 19 (Ubuntu 18.04)

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

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

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

  "options edns0"

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

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

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

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

  systemd:
    Installed: 237-3ubuntu10.13

To manage notifications about this bug go to:

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

2019-02-28 Thread Dan Streetman
> $ 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!

-- 
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
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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

  original description:

  --

  Mint 19 (Ubuntu 18.04)

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

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

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

  "options edns0"

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

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

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

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

  systemd:
    Installed: 237-3ubuntu10.13

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

-- 
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


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

2019-02-28 Thread Steve Roberts
Testing fix:
I added the ppa (same system) and updated resolvconf

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

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

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

nameserver 192.168.2.1

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

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

-- 
You received this bug notification because you are a member of Ubuntu
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
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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

  original description:

  --

  Mint 19 (Ubuntu 18.04)

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

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

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

  "options edns0"

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

  With option present many dns lookups fail with both FF 

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

2019-02-27 Thread Dan Streetman
@xnox adding you to this bug fyi.

-- 
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
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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

  original description:

  --

  Mint 19 (Ubuntu 18.04)

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

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

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

  "options edns0"

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

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

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

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

  systemd:
    Installed: 237-3ubuntu10.13

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

-- 
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


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

2019-02-27 Thread Dan Streetman
@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.

-- 
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
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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

  original description:

  --

  Mint 19 (Ubuntu 18.04)

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

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

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

  "options edns0"

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

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

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

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

  systemd:
    Installed: 237-3ubuntu10.13

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

-- 
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


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

2019-02-27 Thread Dan Streetman
@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 changed:

  [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

-- 
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
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

  systems upgraded from pre-Bionic releases to Bionic or later will
  continue to use ifupdown/resolvconf for network conf and management,
  but resolvconf has a new systemd service in Bionic and later that
  pulls systemd-resolved stub-resolv.conf into its local configuration.
  With the recent addition of edns0 option to the stub resolver conf in
  systemd to fix bug 1811471, this means resolvconf now sets up the
  /etc/resolv.conf 

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

2019-02-27 Thread Dan Streetman
** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Disco)
   Importance: Critical
 Assignee: Dan Streetman (ddstreet)
   Status: In Progress

** Also affects: systemd (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** 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

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

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

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

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

-- 
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
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

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

  1) networking is managed by ifupdown

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

  2) networking is managed by systemd-networkd

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

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

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

  [other info]

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

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

  original description:

  --

  Mint 19 (Ubuntu 18.04)

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

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

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

  "options edns0"

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

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

  Deleting the 

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

2019-02-27 Thread Dan Streetman
** Description changed:

+ [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
+   Installed: 237-3ubuntu10.13

-- 
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
Status in systemd source package in Trusty:
  Invalid
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress

Bug description:
  [impact]

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

  [test case]

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

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

  [regression potential]

  this changes 

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

2019-02-27 Thread Dan Streetman
> 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).

-- 
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


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

2019-02-27 Thread Dan Streetman
** Merge proposal linked:
   
https://code.launchpad.net/~ddstreet/ubuntu/+source/resolvconf/+git/resolvconf/+merge/363748

-- 
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


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

2019-02-27 Thread Steve Roberts
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?

-- 
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


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

2019-02-27 Thread Dan Streetman
> 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


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

2019-02-27 Thread Steve Roberts
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

-- 
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:
  New

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


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

2019-02-27 Thread Steve Roberts
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...

-- 
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:
  New

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


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

2019-02-27 Thread Dan Streetman
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.

-- 
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:
  New

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


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

2019-02-27 Thread Sebastien Bacher
@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'

-- 
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:
  New

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


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

2019-02-27 Thread Dan Streetman
> 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?

-- 
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:
  New

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


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

2019-02-27 Thread Brian Murray
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?

-- 
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:
  New

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


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

2019-02-27 Thread Steve Roberts
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!)

-- 
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:
  New

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


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

2019-02-27 Thread Sebastien Bacher
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?

-- 
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:
  New

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