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
