DNS search domain not removed from resolv.conf on disconnect

[Anders Kaseorg]

When I connect to a wireless network that sets a DNS search domain name via DHCP, the line 'search <domain>' is added to /etc/resolv.conf as expected. But if I then disconnect and connect to a different network, it is not removed from resolv.conf. If the second network also sets a search domain name, that one gets appended to resolv.conf along with the first one, and so on. Depending on the network, this can cause DNS leaks, name resolution failures, or other misbehavior.

To be sure this wasn't some kind of user configuration issue, I reproduced this on the artful daily live image (artful-desktop-amd64.iso, 2017-08-27), from which I'm writing this report.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: network-manager 1.8.2-1ubuntu3
ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5
Uname: Linux 4.12.0-11-generic x86_64
ApportVersion: 2.20.6-0ubuntu7
Architecture: amd64
CasperVersion: 1.384
CurrentDesktop: ubuntu:GNOME
Date: Mon Aug 28 10:34:22 2017
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
IpRoute:
 default via 172.20.20.1 dev wlp3s0 proto static metric 600
 169.254.0.0/16 dev wlp3s0 scope link metric 1000
 172.20.20.0/24 dev wlp3s0 proto kernel scope link src 172.20.20.20 metric 600
LiveMediaBuild: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170827)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH
 wlp3s0 wifi connected /org/freedesktop/NetworkManager/Devices/3 xfinitywifi 39ffbbfc-1c1e-41c9-b3eb-c513065c3ea6 /org/freedesktop/NetworkManager/ActiveConnection/2
 enp0s31f6 ethernet unavailable /org/freedesktop/NetworkManager/Devices/2 -- -- --
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- -- --
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.8.2 connected started full enabled enabled enabled enabled enabled

[Laurent Bigonville (bigon)]

Hi,

I can confirm this bug.

This is really annoying as it breaks VPN connection here

[Launchpad Janitor (janitor)]

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

[Laurent Bigonville (bigon)]

@andersk Is resolvconf installed on your machine?

[Laurent Bigonville (bigon)]

OK I can confirm that uninstalling resolvconf is fixing that behavior here

[Paul Natsuo Kishimoto (khaeru)]

Is this reported upstream?

Could be one of:
https://bugzilla.gnome.org/show_bug.cgi?id=712818
https://bugzilla.gnome.org/show_bug.cgi?id=778004
https://bugzilla.gnome.org/show_bug.cgi?id=782469

I notice per the first one that "nmcli dev show" (not "… list", the report is old and I guess the semantics of nmcli have changed) will show me the search domain when I'm connected to a network that sets it:

=====
$ nmcli -f IP4.ADDRESS,IP4.DOMAIN dev show
IP4.ADDRESS[1]: 18.142.15.92/16
IP4.DOMAIN[1]: mit.edu

IP4.ADDRESS[1]: 18.189.91.11/19
IP4.DOMAIN[1]: mit.edu

IP4.ADDRESS[1]: 127.0.0.1/8
=====

So I guess if I try this the next time this bug crops up and nmcli disagrees with the contents of resolv.conf, I will mark the first URL as the upstream bug.

Or if someone who understands this better wants to open a new upstream bug, please go ahead.

[Laurent Bigonville (bigon)]

I cannot reproduce this on debian.

It seems that one of the difference is that resolvconf support is disabled in the ubuntu package. I feel that the problem comes from here. resovconf support should probably (not tested) be enabled in case it's pulled on the system by a dependency

[Paul Natsuo Kishimoto (khaeru)]

So this has occurred again:

=====

~$ nmcli -f IP4.ADDRESS,IP4.DOMAIN dev show
IP4.ADDRESS[1]: 10.0.0.156/24
IP4.DOMAIN[1]: hsd1.ma.comcast.net

IP4.ADDRESS[1]: 127.0.0.1/8

~$ cat /run/resolvconf/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 hsd1.ma.comcast.net utopia.net mit.edu

=====

Note the extra entries in the 'search' line of resolv.conf—these were from networks I was recently connected to.

[Bert Wesarg (bert-wesarg)]

Please, is there there any known work around?

[Bram Geron (bgeron)]

Try removing the resolvconf package. It is only one mechanism of managing /etc/resolv.conf, and it seems to conflict with the (new) systemd-resolved daemon.

My question on AskUbuntu: https://askubuntu.com/questions/973336/after-changing-networks-dns-lookup-fails-to-domains-that-were-local .

Perhaps we should mark resolvconf as conflicts-with systemd.

[Bert Wesarg (bert-wesarg)]

Thanks. That works.