[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages

[Thomas Hood]

Alkis wrote:
> If nm + resolvconf managed to properly chain the 2 dnsmasq instances so that the NM-spawned dnsmasq was contacted first

I think that this configuration should be supported, whether or not it's
the best solution to the present problem (#959037).

Resolvconf can handle this with a little tweaking.  The "general" local
nameserver registers its listen-address, 127.0.0.1, with resolvconf
under a name like "lo.dnsmasq" which has a high priority according to
interface-order(5).  NM currently registers its slave nameserver's
address under the name "NetworkManager" which has a very low priority.
To implement Alkis's idea, the ordering would have to be adjusted so
that the NM address has a higher priority than the other addresses.  If
we decide to implement Alkis's idea then I'll change the Debian package
to add something like "lo.nm-dnsmasq" before the other lo.* patterns in
the default interface-order.  Then network-manager should be changed so
that it registers its slave's address under that name.

But, second, there is a problem connecting the resolver to the NM-
controlled dnsmasq such that the latter stays out of the way of the
general local nameserver which currently wants to listen on the IPv4
wildcard address.  Using address ::1 for nm-dnsmasq is a quick hack
which might work without further ado

But even if it works it clearly isn't a permanent solution.  More
satisfactory would be to use an another port than 53 for the special
purpose of connecting the resolver with nm-dnsmasq.

Currently the GNU C Library resolver doesn't support using another port.

Interestingly, OpenBSD does support it.  Here's an extract from the
OpenBSD resolv.conf man page.

     nameserver  IPv4 address (in dot notation) or IPv6 address (in hex-and-
                 colon notation) of a name server that the resolver should
                 query.  Scoped IPv6 address notation is accepted as well (see
                 inet6(4) for details).  A non-standard port may be specified
                 using [host]:port syntax.

Mac OS X has a similar feature.

That doesn't immediately help us, of course, but it does set a precedent
for a similar enhancement of the GNU C Library.  Perhaps we could
implement ::1 for now and also start work on getting the aforementioned
enhancement into glibc.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037

Title:
  NM-controlled dnsmasq prevents other DNS servers from running, yet
  network-manager doesn't Conflict with their packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions