© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
> 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=
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://