DNS name resolution doesn't work on Artful

Bug #1725680 reported by Jan Rathmann
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Confirmed
Undecided
Unassigned

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 8.8.8.8 : 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 8.8.8.8 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 127.0.0.53 . 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)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-con
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-cl
 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,
Jan

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
ProcEnviron:
 LANG=C.UTF-8
 PATH=(custom, no user)
ProcKernelCmdLine: file=/cdrom/preseed/hostname.seed boot=casper initrd=/casper/initrd.lz quiet splash --- maybe-ubiquity
SourcePackage: systemd
SystemdDelta:
 [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

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :
Revision history for this message
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 )

Revision history for this message
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?

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

Yes, my wifi provides a DNS nameserver. It's adress is 192.168.44.1, 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
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 3 (wlp7s0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.44.1
          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)

[main]
# rc-manager=symlink
# auth-polkit=true
# dhcp=dhclient
dns=systemd-resolved
plugins=ifupdown,keyfile

[connectivity]
uri=http://connectivity-check.ubuntu.com/

[ifupdown]
managed=false

[logging]
# backend=journal
# audit=true

[device]
wifi.scan-rand-mac-address=no

[connection]
wifi.powersave=3

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

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
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
/script/casper-bottom/23networking
does not populate
/etc/systemd/resolved.conf
therefore the DNS daemon does not work.

I've added to 23networking

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

            cat > $resolv <<EOF
# resolv=/root/etc/systemd/resolved.conf
# Autogenerated by casper-Serva
EOF
 echo "[Resolve]" >> $resolv
        [ -n "$rc_server0" ] && [ "$rc_server0" != "0.0.0.0" ] && echo "DNS=$rc_server0" >> $resolv
        [ -n "$rc_server1" ] && [ "$rc_server1" != "0.0.0.0" ] && echo "FallbackDNS=$rc_server1" >> $resolv
        [ -n "$rc_server1" ] && [ "$rc_server1" = "0.0.0.0" ] && [ "$rc_server0" != "0.0.0.0" ] && 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

    fi

and now 17.10 live PXE boots correctly with a healthy DNS

Best,
Patrick

Revision history for this message
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.

Revision history for this message
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

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

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

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

@Sebastien
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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