> 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
Bugs, which is subscribed to 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-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to