Please enhance dnsmasq to talk directly to resolvconf and to register only its actual listening address(es)

[Pete Graner]

The standalone Dnsmasq (from the dnsmasq package) is preventing the NetworkManager-controlled dnsmasq from starting. By setting ENABLED=0 in /etc/default/dnsmasq instead of ENABLED=1, name service started working again.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: dnsmasq (not installed)
ProcVersionSignature: Ubuntu 3.5.0-12.12-generic 3.5.2
Uname: Linux 3.5.0-12-generic x86_64
ApportVersion: 2.5.1-0ubuntu2
Architecture: amd64
Date: Mon Aug 27 10:48:06 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.default.dnsmasq: 2012-08-27T10:43:43.717591
mtime.conffile..etc.dnsmasq.conf: 2012-05-26T23:51:39.391123

[Mathieu Trudel-Lapierre (cyphermox)]

The issue seems to be that with its current configuration (and including "bind-interfaces", and "except-interface=lo"), dnsmasq tries to update DNS via resolvconf which adds a file under /run/resolvconf/interface/lo.dnsmasq.

That file contains 'nameserver 127.0.0.1', which is absolutely incorrect given the configuration, at least because of except-interface.

This nameserver configuration in resolvconf appears to take precedence over the NetworkManager provided configuration (nameserver 127.0.1.1) also running dnsmasq.

[Thomas Hood (jdthood)]

The bug (in the network-manager package) is that /etc/dnsmasq.d/network-manager contains

    except-interface=lo

despite the fact that network-manager was changed not to listen on lo's IP address (127.0.0.1) any more. Here's the changelog entry announcing this change.

  network-manager (0.9.6.0-0ubuntu4) quantal; urgency=low
    * debian/patches/dns-dnsmasq-interface-and-dbus-path.patch: set the address
      dnsmasq (and bind) plugins should listen on for DNS resolution to 127.0.1.1,
      as opposed to 127.0.0.1 to avoid conflicts with other instances that might
      need to run on the system with that address.
      [...]
   -- Mathieu Trudel-Lapierre <email address hidden> Tue, 21 Aug 2012 11:45:46 -0400

If the aforementioned line is commented out

    #except-interface=lo

then name service works, with the standalone dnsmasq listening on 127.0.0.1 and forwarding to 127.0.1.1. @Submitter: please use this workaround for now. Assuming you want to use standalone dnsmasq, remember to set /etc/default/dnsmasq ENABLED back to 1.

Earlier discussion of the issues at hand here: bug #959037.

[Mathieu Trudel-Lapierre (cyphermox)]

Thomas: no, this is a dnsmasq bug. Even if nothing is set to listen on 127.0.0.1, if dnsmasq is configured to avoid lo and bind to interfaces (as it is per the network-manager provided configuration) it should still do so and not write out lo.dnsmasq.

[Thomas Hood (jdthood)]

Mathieu: True, if dnsmasq is configured not to listen on lo (using "except-interface=lo") then it shouldn't write lo.dnsmasq. That's one bug.

But do you agree that "except-interface=lo" should no longer be included in /etc/dnsmasq.d/network-manager, since network-manager now listens on 127.0.1.1 and there is no need to prevent standalone dnsmasq from binding lo's address, 127.0.0.1? If so, then that's a second bug for which another report can be opened.

[Thomas Hood (jdthood)]

I wrote in comment #5:
> If so, then that's a second bug for which another report can be opened.

I opened bug #1044388 about this.

[Mathieu Trudel-Lapierre (cyphermox)]

This remains a bug, but fixing bug 1044388 is going to make this a much more rare occurence.

Unassigning for now, the bug needs to be filed upstream and fixed by the upstream maintainer.

[Thomas Hood (jdthood)]

Currently it's the initscript that talks to resolvconf. If we want the initscript to implement the behavior requested here (i.e., "register 127.0.0.1 with resolvconf if and only if dnsmasq is listening on lo") then the initscript will have to understand dnsmasq's configuration files. That's asking too much from an initscript.

Dnsmasq should be enhanced so that the dnsmasq process talks to resolvconf. The process knows whether or not it's listening on the loopback address.

Furthermore, the process knows exactly which addresses it's binding; so if it's listening on 127.0.0.2 it can register 127.0.0.2 with resolvconf. Nice.

Furthermore, the process knows when it has been terminated, even if it's not the initscript that's sent the signal, so it can de-register its listen address with resolvconf. Nice.

[quequotion (quequotion)]

I would say either way is fine, reading a configuration file or directly communicating with resolvconf.

Directly communicating with resolvconf is the best solution.

[James E. Flemer (jflemer)]

A short term documentation only fix would be to describe the behavior of `DNSMASQ_EXCEPT` (in relation to resolvconf) in `/etc/default/dnsmasq` so that users don't have to RTFS of `/etc/init/dnsmasq` to figure out how to do this...

The changelog comment calling `DNSMASQ_EXCEPT` "obsolete" is wrong, since it is the only way to keep this package from adding `127.0.0.1` to resolvconf.