(Executive summary of the following: I think we should fix this by
making nm-dnsmasq listen at ::1.)
Thanks for your much-needed help, Simon.
It is good to know that the "except-interface" avenue is available. We
want, however, to be able to enjoy the advantages of non-bind-interfaces
mode ("unbound mode"??) in standalone dnsmasq insofar as we can.
Certainly standalone dnsmasq should continue to run in unbound mode when
n-m is not installed or when nm-dnsmasq is not in use; so ideally we
would ensure that /etc/NetworkManager/NetworkManager.conf contains
dns=dnsmasq if and only if /etc/dnsmasq.d/nm-dnsmasq contains "bind-
interfaces except-interface=lo". I don't see a very easy way to ensure
this.
In any case it would be better if we never had to force dnsmasq into
bind-interfaces mode.
So instead of switching the nm-dnsmasq listen address from 127.0.0.1 to
127.0.1.1 it seems better to switch that address to ::1: no more
difficult, yet in the latter case standalone dnsmasq can continue to run
in unbound mode as it has traditionally done (unless forced into bind-
interfaces mode by something like libvirt-bin, of course).
Implementing the change to ::1 shouldn't be too hard.
* It's a one-line change to network-manager where it starts dnsmasq and another
one-line change where it register's the latter's address with resolvconf.
On a system with n-m and no standalone dnsmasq this will result in
/etc/resolv.conf containing "nameserver ::1" and the resolver will connect to
nm-dnsmasq. On a system with standalone dnsmasq and no n-m this will be no
different from the traditional state of affairs, with /etc/resolv.conf
containing "nameserver 127.0.0.1" and the resolver connecting to standalone
dnsmasq.
On a system with both n-m and standalone dnsmasq this will *also* result in
/etc/resolv.conf containing "nameserver 127.0.0.1" and the resolver connecting
to standalone dnsmasq. This is probably unwanted, but is easily fixed by
* changing network-manager so that it registers the ::1 address under the name
"nm-dnsmasq" (name open to discussion) instead of under the name
"NetworkManager" (which can still be used for registering external nameserver
information in the dns!=dnsmasq case);
* changing resolvconf so that it includes the pattern "nm-dns" at the top of
/etc/resolvconf/interface-order.
Then on a system with both n-m and dnsmasq, /etc/resolv.conf will contain
"nameserver ::1" and the resolver will use nm-dnsmasq.
The remaining challenge then is to see to it that NM sends the address
127.0.0.1 to nm-dnsmasq via /var/run/nm-dns-dnsmasq.conf when there is a
local nameserver running that provides general name service. This would
probably have to be configurable via the GUI since it's hard to tell
whether or not a locally running nameserver provides general name
service.
--
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 : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
