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 Desktop Packages, which is subscribed to network-manager 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 Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out "#dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp