You may be right that developing a new "nm-dns" module would be easier
than trying to enhance the existing dns module to support nonstandard
ports.

But the more immediately relevant comparison is the comparison between
the current solution and any solution involving a new or an enhanced NSS
module. The current solution is to run nm-dnsmasq at 127.0.1.1:53. This
solution has already been rolled out and seems to be working well. (To
my own surprise I haven't seen any complaints related to the switch from
127.0.0.1 to 127.0.1.1, even though I have been following AskUbuntu and
ubuntuforums.) Any alternative has to offer significant benefits if it's
going to be considered for adoption, considering the amount of work and
the risk involved. What benefits would the nm-dns module or the enhanced
dns module give us relative to what we have now? One is: the ability to
run nm-dnsmasq on another port, freeing up port 53 for BIND named
listening on ALL:53. What else?  Would the NSS-module approach make it
easier to implement per-user caches, for example? (I see that Solaris
provides per-user instances of nscd for this purpose.)

Robin, please submit a version of your comment #129 as a new bug report
against network-manager, requesting that the connection to nm-dnsmasq be
implemented by means of a new NSS module. Give your arguments in favor.
Then we can continue the discussion in an open bug report rather than in
this fix-released one.

-- 
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:
  Confirmed
Status in “dnsmasq” package in Ubuntu:
  Fix Released
Status in “network-manager” package in Ubuntu:
  Fix Released
Status in “pdns-recursor” package in Ubuntu:
  Invalid
Status in “pdnsd” package in Ubuntu:
  Invalid
Status in “djbdns” source package in Precise:
  Confirmed
Status in “dnsmasq” source package in Precise:
  Triaged
Status in “network-manager” source package in Precise:
  Triaged
Status in “pdns-recursor” source package in Precise:
  Invalid
Status in “pdnsd” source package in Precise:
  Invalid

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

Reply via email to