Regarding #3, I've filed a wish in upstream's bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=14242
#2 is easy to implement and does solve the problem of standalone dnsmasq
not starting on installation in the presence of NM+dnsmasq. What I am
now wondering is how useful the resulting nameserver cascade is.
resolver ---[127.0.0.1]dnsmasq ---[127.0.0.2]nm-dnsmasq ---[8.8.8.8
or whatever]nameserver
It offers caching and service on ports other than lo, which nm-dnsmasq
alone does not, but would this be better implemented by making nm-
dnsmasq more configurable?
** Bug watch added: Sourceware.org Bugzilla #14242
http://sourceware.org/bugzilla/show_bug.cgi?id=14242
--
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 starting
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