[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
I would if I considered it a bug. (I didn't fully describe the current
state of samba4, because I figured it was irrelevant: You can alter the
interfaces it binds to, but not for *only* the dns resolver -- so
currently, if you want samba4 listening on the wildcard address you'll
need the dns resolver listening there too.) It would be a nice feature,
sure. But, it's nm-dnsmasq is the one breaking away from standards in
ways that will break other packages, so I'm reporting the conflict here.
Btw, named immediately notices because of the
/etc/network/if-{up,down}.d/bind9 scripts that trigger rndc reconfig
when an interface goes up or down.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
In response to #131 and #134 by Thomas: I would argue that will it conflict with anything that exists? is the wrong question, here. Certainly it will conflict in the future, and removing the users ability to run a DNS service on the wildcard address is suboptimal at best, even if they don't *need* to. To directly answer the question about something that conflicts: the internal resolver of the samba4 packages. They're beta right now, but the scheduled release date is December, and there's no parameter (yet) for altering the port or interfaces. This is actually the one that bit me originally. To answer what does it give us?, currently NM invokes a single dnsmasq instance that must be shared between all users. This isn't ideal, because NM connections can be per-user, and this could lead information disclosure at worst and oddly-rearranged DNS resolve orders at best. With an NSS module, you could spin up one dnsmasq instance for the system on a possibly priviliged port (but not 53) and one per user (above 1024), and link them together as forwarders so that only the user owning the connection will use the resolution they've specified in the GUI. It would require som tracking of which user's instance is on which port,and auto-invoking them when necessary, and shutting it down when the user logs out, but would allow for much more flexible and clean separation of user settings. For the record, I am happy to write the NSS plugin myself, but it would require some changes in NM core itself, so I would have to work with someone on the NM team to implement it. If you're interested, and know who that would be, please do let me know. I will also create a new bug report as requested. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
You've got the basic idea. The nsswitch.conf file is where Name Service services are configured, and hosts is one of them. DNS is *one* way to look up hosts, but so is files (/etc/hosts) and mdns4 (avahi). Anything that extends how names are translated to addresses should, imnho, be done through NSS. This is because *everything* supports NSS. For instance, NIS and NIS+ hosts are done through NSS, and this is supported by essentially everything, because it's the standard. All of the enterprise directory services I've come across use an NSS plugin (usually the nis one). It's just simply the right way to do it. I wouldn't worry about resolver libraries that don't use glibc. They're typically DNS-specific, and are typically configured by their own files anyway. Dig, for instance, will use whatever server you tell it to, and ignore resolv.conf (though it uses it as a default). Same goes for the host tool -- they're used for querying specific DNS servers. However, those resolvers *also* ignore /etc/hosts, because that's referenced by the files NSS plugin. Any service that uses gethostbyname(3) is using glibc, and that's going to be everything except edge cases that are intentionally doing their own thing anyway. Things that try to emulate glibc behavior by first checking /etc/hosts and then /etc/resolv.conf are simply doing it wrong, and will miss (for instance) avahi, NIS, and any other directory service that may be installed. I'm surprised at the idea that it will be less work to modify glibc. Even if it's technically easier to make a change in the glibc code than to create your own NSS plugin, you have a myriad of problems: NM functionality would now have a dependency on a nonstandard patch of glibc, the documentation for /etc/resolv.conf will be inconsistent for only this distribution, there could (will) be resistance by the glibc folks, who knows what you'll break when you alter how glibc behaves, etc. However, with an NSS module, we have a huge number of advantages: * It's the standard way of achieving this type of thing and is hence supported by most everything * It's the standard way of achieving this type of thing so it's very well documented * It's the standard way of achieving this type of thing so it's very modularized and isolated, and if NM stops working it will continue along the chain without screwing up plugins further up like (unlike when dnsmasq dies with the proposed glibc change) * It's the standard way of achieving this type of things so the things that don't support it are, in general, doing it wrong and that's a bug on their end * It's the standard way of achieving this type of thing so there's already a package (libnss-mdns) that adds a hosts NSS module, meaning both that we know it works and that it is officially supported by ubuntu * It could be owned by the NM project instead of creating a dependency on a glibc patch that would not be taken up by distributions very quickly * You could make it do other interesting things like have static /etc/hosts-like entries per connection. You get the idea. If you want to see an example of an NSS hosts plugin packaged for ubuntu, that hooks into /etc/nsswitch.conf, look at the nss-mdns source package. The debian/libnss-mdns.postinst script that runs upon installation is what handles inserting it into /etc/nsswitch.conf, and can easily be adapted to handle inserting a NM plugin. If you want another example of an ubuntu package dealing with NSS plugins look at the auth-client-config package, though this one only handles the passwd, group, and shadow services. In short: An NSS plugin has vastly less risk of breaking software because Ubuntu already uses it and things aren't breaking (and it's also the standard, anyway), could actually be part of the NM project as opposed to owned by glibc, and will likely be easier than modifying glibc anyway due to fewer dependencies. This seems like win-win-win to me. To be clear, I'm advocating that we make a small NSS plugin wrapper around calls to a dnsmasq (or other) mini name server controlled by NM, that runs on a non-privileged port and can be spawned per-user. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
Are you sure? I am only aware of named.conf's listen-on { IP_ADDRESS;
}. If there is a feature such as you describe then presumably named
binds ALL:53 and then filters according to the addresses on the
specified interfaces.
Nope, I just verified, you're quite correct. I hadn't heard of it
either, but upon (mis)reading comments above I presumed without
verifying. Bad on me.
A question about the NSS plugin idea. Will this work only for software
that uses glibc? What about alternative resolver libraries?
Anything that uses the gethostbyname(3) call uses the NSS chain. That
means essentially everything that isn't a resolver itself uses
nsswitch.conf. DNS resolver libraries won't use NSS by design, because
they are the resolvers themselves that are *used* by NSS. This is why
there are no names in their respective configuration files, save for
what they're serving (remote addresses are specified by address). If
any DNS resolver itself reads nsswitch.conf, it's doing somethign Very
Wrong.
The idea of NSS is that the DNS resolvers aren't *supposed* to use it.
They are the exporters of NSS services, not the consumers. I don't know
of any of them that use NSS for their own resolution; they are just one
link in the NSS chain that is used by the (libc) name resolver
libraries. When you hit the DNS service itself, you really *don't* want
it to start the NSS chain over, because that would just lead to a loop.
My proposal for using NSS in place of NetworkManager's dnsmasq is to
create a new NSS plugin and place it earlier in the NSS chain than the
standard DNS resolver. For instance, a line like so:
hosts: files mdns4_minimal [NOTFOUND=return] network_manager
[NOTFOUND=return] dns mdns4
This is straight from my Precise install, with the addition of the
network_manager [NOTFOUND=return] stanza. It says that first you
check /etc/hosts (that's files), then a subset of avahi
(mdns4_minimal [NOTFOUND=return]), then your NM plugin
network_manager [NOTFOUND=return], plain old DNS (dns), then avahi
again (mdns4).
It would not conflict with any other NSS plugin, because they are all
tried in turn until a match is found. If you place it directly in front
of the DNS resolver plugin in nsswitch.conf, it will be used before the
standard DNS lookup, allowing you to do all the fancy connection-
specific magic you need to do, while returning Try Next for anything
non-connection specific, thus allowing the normal DNS resolver plugin
(which reads resolv.conf) to do things as normal. This is *instead* of
hooking in at resolv.conf, as you do now. People can install any
resolver they want, and it works as designed. This lets you listen on
high-numbered ports as well, *and* lets you have per-user dnsmasq
instances (per user vpns?), while still running Bind or a normal dnsmasq
instance on *:53.
Right now, the dnsmasq for NM basically hijacks resolv.conf, which means
it's hooking into the DNS NSS plugin's resolution (it's the plugin that
reads resolv.conf, not the applications, using code in libc). This is
causing conflicts, because in order to use resolv.conf, you need to be
running on port 53 -- and it would take re-writing parts of the DNS NSS
plugin (or libc!) to change this. But, you don't need to do that at
all. Just insert the NM NSS plugin *before* the DNS NSS plugin, and you
can do all the fancy things you want, without ever breaking any DNS
resolution at all. If you don't have anything special to do, return
notfound and DNS will do its thing. Alternatively, you can *replace*
the DNS NSS library with your own (add yours to nsswitch and remove the
dns one), and do all processing in there, which will likely involve
querying the local dnsmasq instance directly without even bothering with
resolv.conf.
Really, the Name Service Switch subsystem is the system designed to
handle Switching between multiple Name Service providers. That's where
such things need to be. See documentation:
http://www.gnu.org/software/libc/manual/html_node/Name-Service-
Switch.html
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
Another drawback is that you still need to manually configure bind (and others) to only listen on particular addresses. If you're using dhcp this presents a problem, because you don't actually know the address. With bind, this is okay, mostly, because you can say to listen on everything for a particular interface (but then you can't listen on 127.0.0.1, because it's the same interface as 127.0.1.1), but other servers only have per-address configurations. The NSS plugin idea is *exactly* what NSS was designed for, and literally doesn't conflict with any name resolver in any way. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
I just read this entire chain, and I'm surprised not to see mention of using an NSS plugin, like Avahi (and ldap and NIS and /etc/hosts and DNS itself). I expect it would be simple enough to write a small NSS plugin that merely calls the NM-dnsmasq (running on localhost on a port other than 53) and placing it in front of (or instead of) dns on the hosts line in /etc/nsswitch.conf. This would not conflict at *all* with any local DNS servers, and would work for anything that used the libc resolver. It's also vastly cleaner than the let's change multiple upstream packages options I see listed above. For extra points, it's probably past time to make a dbus nss plugin, which could be configured to talk to NM, which in turn would ask its personal dnsmasq instance running on any available port, or however it decided to track such things in the future. This would be a clean interface, with all resolving going through libc, with a well-defined API chain (libc --NSS-- dbusplugin --DBUS-- NetworkManager --DNS-- dnsmasq), and allow for NetworkManager to change the last step (DNS protocol to dnsmasq) to whatever in the future without re-architecting anything underneath. Or have the NSS plugin directly access dnsmasq and have NetworkManager manage its configuration, to follow dnsmasq port changes or what have you. It's not as future-proof, but it still gets the job done without conflicting with any resolvers. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
