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