NM "dns=dnsmasq" breaks resolution of private domain names

[Wolf Rogner]

Network Manager does not use the DHCP information delivered by a DHCP server.
Name servers and other information are not utilised.

The dhclient.leases file, resolv.conf and nm-dhclient-eth1.conf (I use a WLAN wlan0) show different information about name servers and domain names.

Thus settings that rely on any internal server names do not work.

Related bugs:
 * bug 1003842: Upgrading to Precise NM with "dns=dnsmasq" breaks systems with non-equivalent upstream nameservers
 * bug 993794: Precise can't connect to a network guarded by an authentication webserver whose address can only be looked up with one of the nameservers whose address is provided by DHCP

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.4.0-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
NonfreeKernelModules: nvidia wl
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Date: Wed May 9 14:15:01 2012
ExecutablePath: /usr/sbin/NetworkManager
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64+mac (20111012)
IpRoute:
 default via 10.1.0.254 dev eth1 proto static
 10.0.0.0/8 dev eth1 proto kernel scope link src 10.1.0.123 metric 2
 169.254.0.0/16 dev eth1 scope link metric 1000
 172.16.164.0/24 dev vmnet8 proto kernel scope link src 172.16.164.1
 192.168.179.0/24 dev vmnet1 proto kernel scope link src 192.168.179.1
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 LANG=en_US.UTF-8
SourcePackage: network-manager
UpgradeStatus: Upgraded to precise on 2012-04-29 (9 days ago)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth1 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/1
 eth0 802-3-ethernet unavailable /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.4.0 connected enabled enabled enabled enabled disabled

[Mathieu Trudel-Lapierre (cyphermox)]

Please attach the contents of /run/nm-dns-dnsmasq.conf. That file should contain exactly the information received from DHCP, and /etc/resolv.conf should contain just "127.0.0.1" (thus pointing to dnsmasq); on a standard vanilla Ubuntu install.

[Wolf Rogner (war-rsb)]

Would love to but currently things work as required. I have to wait till problems emerge again.

My /etc/resolv.conf contains:

# 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
nameserver 10.1.0.4
nameserver 10.1.0.254
nameserver 195.202.128.3
search rsb.intern rsb.at

Even on a fresh install it looks like this.

It looks like you suggested only when connection is not possible.

[Wolf Rogner (war-rsb)]

Just had the error on another machine. /etc/resolv.conf contained:

# 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
nameserver 127.0.0.1
search rsb.intern rsb.at

[Wolf Rogner (war-rsb)]

/run/nm-dns-dns-masq.conf

nameserver 10.1.0.4
nameserver 10.1.0.254
nameserver 195.202.128.3

[Mathieu Trudel-Lapierre (cyphermox)]

This is expected behavior, as long as the DNS entries in /run/nm-dns-dnsmasq.conf are correct. When that happens, please make sure dnsmasq is indeed running (as otherwise you won't have anything listening on 127.0.0.1 to forward requests)

[Wolf Rogner (war-rsb)]

Sorry Mathieu,

this behaviour might be correct from the dnsmask point of view. It does not work from the system or users point of view.

Thunderbird and ssh do not resolv correctly (to name but two that my users regularly use)

ping does not resolve correctly either. I have not even tried to find more applications and tools that do not work but there are a lot.

Network manager starts dnsmask with --no-resolv to ignore /etc/resolv.conf

That can be changed immediately to resolve this issue. If the resolv.conf file is left in order, things would work.

I am slightly disappointed that changes (that might be useful and required) are not communicated in advance to all parties that rely on the basic foundations. DNS resolution is basic.

Just to give you an insight into the consequences:

I have a client with 20000+ PCs. They have issues every day since 12.04. If they had rolled out 12.04, they would have had 40000 calls per day on their help desk (currently 300 - 500). My client tells me, my recommending Ubuntu was incorrect (basically boils down to I'm not worth my money) and the situation proves that Ubuntu / Linux is a playground for freaks.

So thanks for ruining another chance to establish open source by giving me and others a broken solution, a broken excuse and a broken design.

</personal frustration>

[Thomas Hood (jdthood)]

Does it make any difference if you comment out "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf?

[Wolf Rogner (war-rsb)]

commenting dns=dnsmasq out in the NetworkManager.conf leaves the /etc/resolv.conf file intact.

I will test this on my other machines.

Unfortunately, the upgrade changed this setting to use dnsmasq.
It also is set in the default installation.

It solves my problem, thanks.
It creates another problem: Changing this setting in 20000+ PCs.

We'll see

[Thomas Hood (jdthood)]

Wolf, you wrote:
> settings that rely on any internal server names do not work.

You said that your (working) resolv.conf contains:
> nameserver 10.1.0.4
> nameserver 10.1.0.254
> nameserver 195.202.128.3

Is it the case that the nameserver at 10.1.0.4 can resolve more names than the nameserver at 195.202.128.3?

[Thomas Hood (jdthood)]

Regarding this:
>Network manager starts dnsmask with --no-resolv to ignore /etc/resolv.conf
> That can be changed immediately to resolve this issue.

That is certainly not the right solution.

[Wolf Rogner (war-rsb)]

The 10.xx resolves internal names and external domain
the 192.xxx is a proxy and resolves external names

[Thomas Hood (jdthood)]

Thanks for the additional info, which confirms that this is the same case as #1003842. Please read the description of #1003842 for more information.