Comment 46 for bug 959037

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.