DNS search domain not removed from resolv.conf on disconnect

Bug #1713457 reported by Anders Kaseorg on 2017-08-28
84
This bug affects 14 people
Affects Status Importance Assigned to Milestone
NetworkManager
Unknown
Unknown
network-manager (Ubuntu)
High
Unassigned
resolvconf (Ubuntu)
Undecided
Unassigned

Bug Description

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

Anders Kaseorg (andersk) wrote :
description: updated
description: updated
Laurent Bigonville (bigon) wrote :

Hi,

I can confirm this bug.

This is really annoying as it breaks VPN connection here

Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
Changed in resolvconf (Ubuntu):
status: New → Confirmed
Laurent Bigonville (bigon) wrote :

@andersk Is resolvconf installed on your machine?

Laurent Bigonville (bigon) wrote :

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

Paul Natsuo Kishimoto (khaeru) wrote :

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

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

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.

BertWesarg (bert-wesarg) wrote :

Please, is there there any known work around?

Bram Geron (bgeron) wrote :

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.

BertWesarg (bert-wesarg) wrote :

Thanks. That works.

Changed in network-manager (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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