Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 20:31, Thomas Hood wrote:
> (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).
I don't think that's true. In unbound mode, the standalone dnsmasq will
bind the IPv6 wildcard address, which will stop the nm-dnsmasq from
binding ::1 There's no escape in IPv6 land. Indeed the situation is
worse, because as far a I know, you can't use any address in the defined
subnet for loopback, it has to be ::1, so except-interface=lo is required.
I think the 127.0.1.1 (or whatever) answer is the best. Unfortunately
there's no way round having to set --bind-interfaces on the standalone
dnsmasq, but except-interface=lo is not required as long as the
127.0.0.0/8 address in use by nm-dnsmasq doesn't appear on the lo interface.
Simon.
--
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
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 13/06/12 11:07, Thomas Hood wrote: > OK, so the ::1 idea fails as a quick hack. The alternatives seem to be > as follows. > > 1. Either we accept that nm-dnsmasq is incompatible with every standalone > nameserver and enforce this in a better way; > 2. or we force every standalone nameserver into bind-interfaces mode and move > nm-dnsmasq's listen address to something other than 127.0.0.1; > 3. or we make nm-dnsmasq listen on another port number (using the --port > option) and enhance glibc to support accessing nameservers at ports other > than 53. > > Have I forgotten any? > > #3 is the most attractive option but requires the most work and won't > happen soon. In the short term the choice is between #1 and #2. > For completeness, there's a #4 which is to dump bind-interfaces except-interface=lo into /etc/dnsmasq.d, but that won't work for other nameservers (though something analogous would, I expect) If you can make #2 happen without breaking things, that would seem to be worth doing, I guess the main problem is that you need dnsmasq 2.61 or a backport of the relevant code to 2.59. Simon. -- 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
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 13/06/12 11:07, Thomas Hood wrote: > OK, so the ::1 idea fails as a quick hack. The alternatives seem to be > as follows. > > 1. Either we accept that nm-dnsmasq is incompatible with every standalone > nameserver and enforce this in a better way; > 2. or we force every standalone nameserver into bind-interfaces mode and move > nm-dnsmasq's listen address to something other than 127.0.0.1; > 3. or we make nm-dnsmasq listen on another port number (using the --port > option) and enhance glibc to support accessing nameservers at ports other > than 53. > > Have I forgotten any? > > #3 is the most attractive option but requires the most work and won't > happen soon. In the short term the choice is between #1 and #2. > Further to #2 and getting dnsmasq support. I found a bug last night that means that dnsmasq --listen-address= where is not on an interface, will listen on port 69 of even if tftp is not enabled. The fix is in git but not a release, but should be backported if you do #2. It's trivial: one line. Simon. -- 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
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 11/06/12 19:57, Thomas Hood wrote: > 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. > Another option is to use another address in 127.0.0.0/8, any will work. You'll need dnsmasq 2.61 or later for this to be a viable option. You could have the nm-dnsmasq run with --bind-interfaces --listen-address=127.0.100.1 and put 127.0.100.1 in /etc/resolv.conf. Another instance of dnsmasq will run without interfering with that, providing only that --bind-interfaces is set. Simon. -- 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
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 11/06/12 20:41, Thomas Hood wrote: > Aha, I had tried this and it didn't work... in version 2.57. But I see > that quantal already has 2.62. > >> Another instance of dnsmasq will run without interfering with that, > providing only that --bind-interfaces is set. > > Just to make sure I understand correctly: Do you mean here that --bind- > interfaces has to be set on both instances of dnsmasq? Or will one > instance (the NM-controlled one) with --bind-interfaces coexist nicely > with another (the standalone dnsmasq) which doesn't use that option and > listens on 0.0.0.0? It has to be set in both instances of dnsmasq. dnsmasq started as a system daemon reads config from /etc/dnsmasq.d/* so dropping a file there containing "bind-interfaces" and doing the relevant restart in postinst should make this automatic in most cases. > > NM already runs dnsmasq with --bind-interfaces and --listen-address > (specifically, --listen-address=127.0.0.1) so we would only be changing > the address. > > Mathieu mentioned earlier the possibility of using 127.0.1.1 which > happens to be the address assigned (in /etc/hosts) to the system > hostname on some (but not all) systems. Is there any advantage to using > 127.0.1.1 as opposed to another 127.* address? > I don't think so: they're all equivalent. Simon. -- 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
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 10:05, Alkis Georgopoulos wrote: > Note that while bind-interfaces can be specified multiple times, > defining except-interfaces more than once is a syntax error in my > dnsmasq 2.59-4. > Are you sure? That should be allowed. Simon. -- 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
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
On 12/06/12 11:24, Thomas Hood wrote: > Hmm, just tested this myself. You can't use "except-interface=lo"; it > seems you have to use "listen-address=10.1.2.3". Perhaps Simon knows a > better way. > If you want to listen on an address which doesn't appear on an interface (ie 127.0.1.1) then you have to use --listen-address. The rules for 127.0.0.1 are slightly arcane too: If you use -interface and --except-interface, then dnsmasq will assume that you want it to listen on the address of any loopback interfaces it finds as well. In practise that means 127.0.0.1 So dnsmasq --interface=eth0 will listen on the address(es) of eth0 and 127.0.0.1. If you use --listen-address, then dnsmasq assumes you want more control and only uses the addresses you actually give so dnsmasq --listen-address=127.0.1.1 will _not_ listen on 127.0.0.1 Given this, it makes sense to use 127.0.1.1 (or any address in 127.0.0.0/8 that doesn't appear on lo) for nm-dnsmasq. Because 127.0.1.1 doesn't appear on lo, another dnsmasq instance will not try and listen on it, and the only thing required to get the two dnsmasq instances to co-exist is --bind-interfaces. Cheers, Simon. -- 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
