Cannot resolve DNS in artful daily

Confirmed with Ubuntu same build number.

manifests diff between 20 and 21. resolvconf is gone from 20170821.

Status changed to 'Confirmed' because the bug affects multiple users.

I can confirm that for me removing /etc/resolv.conf and replacing it with a link to stub-resolv.conf using

sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

and rebooting (probably I could just have restarted the appropriate service) restores DNS functionality.

This bug was fixed in the package systemd - 234-2ubuntu9

---------------
systemd (234-2ubuntu9) artful; urgency=medium

  * boot-and-services: skip gdm3 tests when absent, as it is on s390x.

 -- Dimitri John Ledkov <email address hidden> Wed, 23 Aug 2017 11:58:57 +0100

update to systemd (234-2ubuntu9) doesn't help, after reboot I still need manually add nameserver to /etc/resolve.conf

On Mon, Aug 28, 2017 at 01:47:23AM -0000, Jarod wrote:
> update to systemd (234-2ubuntu9) doesn't help, after reboot I still need
> manually add nameserver to /etc/resolve.conf

After your update, is /etc/resolv.conf a symlink to
/run/systemd/resolve/stub-resolv.conf ?

Please show the output of 'systemctl status systemd-resolved'.

jarod@ubuntu-pc:~$ ll /etc/resolv.conf
-rw-r--r-- 1 root root 78 Aug 28 09:38 /etc/resolv.conf

jarod@ubuntu-pc:~$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 114.114.114.114 # this entry is manually add by me
nameserver 127.0.1.1

jarod@ubuntu-pc:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-08-28 09:44:24 CST; 1 day 3h ago
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
 Main PID: 3137 (systemd-resolve)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/systemd-resolved.service
           └─3137 /lib/systemd/systemd-resolved

Aug 28 09:44:24 ubuntu-pc systemd[1]: Starting Network Name Resolution...
Aug 28 09:44:24 ubuntu-pc systemd-resolved[3137]: Positive Trust Anchors:
Aug 28 09:44:24 ubuntu-pc systemd-resolved[3137]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Aug 28 09:44:24 ubuntu-pc systemd-resolved[3137]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Aug 28 09:44:24 ubuntu-pc systemd-resolved[3137]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.i
Aug 28 09:44:24 ubuntu-pc systemd-resolved[3137]: Using system hostname 'ubuntu-pc'.
Aug 28 09:44:24 ubuntu-pc systemd[1]: Started Network Name Resolution.

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2017-08-29 22:12:30 CEST; 36s ago
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
  Process: 3497 ExecStartPre=/bin/sh -c [ ! -s /etc/resolv.conf ] && ln -snf ../run/systemd/resolve/stub-resolv.conf (code=exited, status=1/FAILURE)
 Main PID: 3498 (systemd-resolve)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/systemd-resolved.service
           └─3498 /lib/systemd/systemd-resolved

Aug 29 22:12:30 laptop systemd[1]: Starting Network Name Resolution...
Aug 29 22:12:30 laptop systemd-resolved[3498]: Positive Trust Anchors:
Aug 29 22:12:30 laptop systemd-resolved[3498]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Aug 29 22:12:30 laptop systemd-resolved[3498]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Aug 29 22:12:30 laptop systemd-resolved[3498]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19
Aug 29 22:12:30 laptop systemd-resolved[3498]: Using system hostname 'laptop'.
Aug 29 22:12:30 laptop systemd[1]: Started Network Name Resolution.

Started working for me about yesterday, but then dropped again.
I use .domain vpn and no .domain get resolved by the system.
It was ok about a week ago, then not working, working for a day, then again - none.

Today, I also ran into this issue. Wifi was working and I could successfully ping Google's DNS 8.8.8.8.

However, pinging google.com didn't work: "Name or service not known"

The workaround in comment #6 does the trick for me:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Forgot to mention, I have a fresh install from the daily artful image on 21st of September 2017.

I have the same issue. A couple of month ago we had a similar issue, which could be fixed by "downgrading" the resolver setup for systemd. However, the issue returned a couple of days ago.
In general networking works after start up, but stops after a random time period. When I "turn off" the connection and then turn it on again, it works again for some time before it breaks down again.

This only affects DNS, as media streams and running connections are not affected. The time interval range from 1-2 minutes up to an hour.

@prefec2 that sounds like a different bug. This one is not intermittent. If the workaround in comment #6 does not fix it for you then I suggest filing a new bug.

I just upgraded from 17.04 to release version of 17.10, then I encounter this problem, too. comment #6's method fixed this issue for me.

So how was /etc/resolv.conf configured before you removed it? To my understanding, there should be no problems after upgrade from any of the default configurations in 17.04.

livecd-rootfs fixed in version 2.468:

livecd-rootfs (2.468) artful; urgency=medium

  [ Dimitri John Ledkov ]
  * Drop obsolete fix-ups of resolv.conf, debootstrap should now result in
    correct symlink to resolved without any further fixes.

  [ Michael Hudson-Doyle ]
  * Have subiquity.service order after on a service defined by the subiquity
    snap, which in turn will order after the job that mounts the subiquity
    snap. (LP: #1721414)

network-manager is also fixed:

network-manager (1.8.2-1ubuntu6) artful; urgency=medium

  * src/dns/nm-dns-manager.c:
    - Fix resolved detection, the symlink target is usually relative to
    the root, such that in chroots the file points to a file inside the
    chroot. But keep absolute targets too, as these may have been in use
    with older version of systemd.
    - Add support for stub-resolv.conf detection.

netcfg is also fixed.

netcfg (1.142ubuntu4) artful; urgency=medium

  * Add resolved support. LP: #1714167

 -- Dimitri John Ledkov <email address hidden> Wed, 20 Sep 2017 09:52:03 +0100

@vorlon

It just contained:

# Generated by NetworkManager
nameserver 127.0.1.1

Were you not using resolvconf on this system prior to upgrade? NetworkManager should only have managed /etc/resolv.conf contents if it did not detect that another system was managing it (resolvconf or resolved).

No, I wasn't using resolvconf.

On Sat, Oct 21, 2017 at 08:54:03AM -0000, diabloneo wrote:
> No, I wasn't using resolvconf.

Ok, is there any particular reason for that? The resolvconf package is part
of ubuntu-minimal in Ubuntu 17.04. Removal of ubuntu-minimal leaves you
with an unsupported configuration.

On 21 October 2017 at 21:51, Steve Langasek
<email address hidden> wrote:
> On Sat, Oct 21, 2017 at 08:54:03AM -0000, diabloneo wrote:
>> No, I wasn't using resolvconf.
>
> Ok, is there any particular reason for that? The resolvconf package is part
> of ubuntu-minimal in Ubuntu 17.04. Removal of ubuntu-minimal leaves you
> with an unsupported configuration.

If you want to switch to the new default configuration you can do this:

$ sudo ln -fs ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

And reboot. both ifupdown and network-manager, in 17.10 feed
nameservers to resolved and this is what default configuration should
look like.

Otherwise you need to specify nameserver in either /etc/resolv.conf
direct, or by supplying them to network-manager and asking it to
manage the /etc/resolv.conf.

--
Regards,

Dimitri.

@vorlon

The resolvconf package is installed. I meaned it's not running when I check with 'systemctl status' or 'ps -ef'

@diabloneo

resolvconf doesn't leave a process running on the system; it is only triggered when there are changes to the network or to the available local resolvers, and coordinates updates to /etc/resolv.conf.

But if /etc/resolv.conf is not a symlink to /run/resolvconf/resolv.conf, this has no effect.

And if NetworkManager had written its own contents to /etc/resolv.conf, that means either it was not a symlink to /run/resolvconf/resolv.conf, or you were using a buggy version of NetworkManager. (The Ubuntu package of NetworkManager detects when resolvconf is in use, and avoids overwriting /etc/resolv.conf.)

The question is how your system got into that state in 17.04. But this may not be a question we are able to answer after the fact.

If you have any further insight into how your system got into this state, we would be interested to know. Otherwise, I recommend you follow Dimitri's guidance from comment #27 to return your system into a supported configuration.

Actually, since you have already used the method from comment #6 to point /etc/resolv.conf directly at resolved instead of at resolvconf, this is also fine.

@vorlon thank you for your well explaination. My system was upgraded from 16.04 -> 16.10 -> 17.04 -> 17.10, I'm not sure how it became that in 17.04.