DNS name resolution doesn't work on Artful

Bug #1725680 reported by Jan Rathmann on 2017-10-21
This bug affects 3 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)

Bug Description

If I boot my laptop with a live image or an installation of Ubuntu 17.10, DNS name resolution doesn't work (which means I can't access any website).

Steps to reproduce:
- Boot laptop with Ubuntu 17.10 live image
- Connect to my wireless network
- Try to ping any website, e.g. ping ubuntu.com. This immediately fails with the error message "Name or service not known"
- Try to ping an IP-adress, e.g. ping : this works.

As a workaround, I can get a temporarily working DNS resolution by manually editing /etc/resolv.conf (symlink to /run/systemd/resolve/stub-resolve.conf) and setting the "nameserver" entry to or some other known DNS server.

On Ubuntu 17.04 this bug is not present.

The original address in /run/systemd/resolve/stub-resolve.conf is . I get immediate replies if I ping this address, but nevertheless DNS resolution doesn't work.

It seems that the service systemd-networkd isn't active by default:
$ sudo systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendo
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)

Manually starting it doesn't seem to help for this bug.

systemd-resolved is active:

$ sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor
   Active: active (running) since Sat 2017-10-21 12:13:12 UTC; 44min ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 1095 (systemd-resolve)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/systemd-resolved.service
           └─1095 /lib/systemd/systemd-resolved

Okt 21 12:13:12 ubuntu systemd[1]: Starting Network Name Resolution...
Okt 21 12:13:12 ubuntu systemd-resolved[1095]: Positive Trust Anchors:
Okt 21 12:13:12 ubuntu systemd-resolved[1095]: . IN DS 19036 8 2 49aac11d7b6f644
Okt 21 12:13:12 ubuntu systemd-resolved[1095]: . IN DS 20326 8 2 e06d44b80b8f1d3
Okt 21 12:13:12 ubuntu systemd-resolved[1095]: Negative trust anchors: 10.in-add
Okt 21 12:13:12 ubuntu systemd-resolved[1095]: Using system hostname 'ubuntu'.
Okt 21 12:13:12 ubuntu systemd[1]: Started Network Name Resolution.

Kind regards,

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: systemd 234-2ubuntu12
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3
Architecture: amd64
CasperVersion: 1.387
Date: Sat Oct 21 12:26:00 2017
ExecutablePath: /lib/systemd/systemd-resolved
LiveMediaBuild: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
MachineType: Acer Extensa 5635Z
 PATH=(custom, no user)
ProcKernelCmdLine: file=/cdrom/preseed/hostname.seed boot=casper initrd=/casper/initrd.lz quiet splash --- maybe-ubiquity
SourcePackage: systemd
 [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf
 [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/14/2009
dmi.bios.vendor: Phoenix
dmi.bios.version: V0.3305
dmi.board.name: BA50-MV
dmi.board.vendor: Acer
dmi.board.version: Not Applicable
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnPhoenix:bvrV0.3305:bd08/14/2009:svnAcer:pnExtensa5635Z:pvrNotApplicable:rvnAcer:rnBA50-MV:rvrNotApplicable:cvnAcer:ct10:cvrN/A:
dmi.product.name: Extensa 5635Z
dmi.product.version: Not Applicable
dmi.sys.vendor: Acer

Jan Rathmann (kaiserclaudius) wrote :
Jan Rathmann (kaiserclaudius) wrote :

I just tested that disabling systemd-resolved seems to be a good permanent workaround for me (according to the description under https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu )

Dimitri John Ledkov (xnox) wrote :

When you boot livecd and connect with network-manager to your wifi, what is the output of:

$ systemd-resolve --status

$ sudo NetworkManager --print-config

Does your wifi provide DNS nameservers?

Jan Rathmann (kaiserclaudius) wrote :

Yes, my wifi provides a DNS nameserver. It's adress is, and it is shown when I open System Settings --> WLAN and click on the properties of the connected network. When I manually add this DNS server to resolv.conf, DNS resolution will start working.

What I'm currently using is some sort of a "public facility wifi", where anyone can connect freely to without any authentification (and without encryption). Unfortunately, this is the only network I can test ATM, so I don't know if if would be different on e.g. a WPA2-encrypted private wifi.

Here is the output of the two commands:

$ systemd-resolve --status
          DNSSEC NTA: 10.in-addr.arpa

Link 3 (wlp7s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers:
          DNS Domain: lan

Link 2 (enp9s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no


$ sudo NetworkManager --print-config
# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: 10-dns-resolved.conf, 20-connectivity-ubuntu.conf) (run: 10-globally-managed-devices.conf) (etc: default-wifi-powersave-on.conf)

# rc-manager=symlink
# auth-polkit=true
# dhcp=dhclient



# backend=journal
# audit=true



Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
patpat (masottaus) wrote :

I'm PXE booting 17.10 live with Serva.
I also found that the booting image DNS is broken.

I traced the problem to Casper within the booting initrd.lz, the file
does not populate
therefore the DNS daemon does not work.

I've added to 23networking

    if [ -f /root/etc/systemd/resolved.conf ]; then

            cat > $resolv <<EOF
# resolv=/root/etc/systemd/resolved.conf
# Autogenerated by casper-Serva
 echo "[Resolve]" >> $resolv
        [ -n "$rc_server0" ] && [ "$rc_server0" != "" ] && echo "DNS=$rc_server0" >> $resolv
        [ -n "$rc_server1" ] && [ "$rc_server1" != "" ] && echo "FallbackDNS=$rc_server1" >> $resolv
        [ -n "$rc_server1" ] && [ "$rc_server1" = "" ] && [ "$rc_server0" != "" ] && echo "FallbackDNS=$rc_server0" >> $resolv
        [ -n "$rc_domain" ] && echo "Domains=${rc_domain}" >> $resolv

 echo "#LLMNR=yes" >> $resolv
 echo "#MulticastDNS=yes" >> $resolv
 echo "#DNSSEC=no" >> $resolv
 echo "#Cache=yes" >> $resolv
 echo "#DNSStubListener=udp" >> $resolv


and now 17.10 live PXE boots correctly with a healthy DNS


Jan Rathmann (kaiserclaudius) wrote :

I was finally able to test, if I could reproduce the bug on a WPA2 encrypted private wifi network. And interestingly I couldn't - DNS resolution worked fine when booting a live session and connecting to the private network.

So it is possible that the behaviour I described in this report may be some sort of corner case related to the wifi network I was using 1,5 months ago.

patpat (masottaus) wrote :

It seems Casper does not update /etc/systemd/resolved.conf
then I do not really know how you get this working if booting
from an untouched live 17.10 Ubuntu

Sebastien Bacher (seb128) wrote :

@Jan, were you maybe using a wifi behind a captive portal at the time? could be bug #1727237 maybe?

Jan Rathmann (kaiserclaudius) wrote :

Well, hmmm, it is possible that #1727237 is the same bug. The wifi I was using at that time was a bit weird in regards of having a captive portal: It seemed to me that it was implemented to show a captive portal in principle when connecting to it. But while some other people around were directed to that captive portal everytime they connected to the wifi, I saw it on my devices (Android phone and the laptop where I send this report from) only at the first connection - then I regularily connected to this wifi for months(!) and the captive portal was never shown again to me! And that's the reason why I even forgot to metion it at all in this bug report.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers