Re: Use of dnsmasq for caching nameserver

[Gene Czarcinski <gene czarc net>]

On 08/27/2012 12:19 PM, Mathieu Trudel-Lapierre wrote:
> On Sat, Aug 25, 2012 at 5:05 PM, Gene Czarcinski <gene czarc net> wrote:
> [...]
> > 1.  Is it already in use?  I am running "current" Fedora 17 and a "ps ax"
> > shows no "extra" dnsmasq ... just all the ones for my virtual networks.
> It's not in use in Fedora yet.

OK ... 18?
> > 2.  I also noticed that the NetworkManager dnsmasq is listening on
> > 127.0.0.1.  This could be a problem if the user (such as myself) wants to
> > run a dnsmasq listening on 127.0.0.1.
> Yes. I have a patch ready to be sent to the mailing list to change
> that to 127.0.1.1 (could be anything else really), as what we use in
> Ubuntu.
On further thought, this change to 127.0.1.1 may not be necessary.

If I am running a system which is using NetworkManager to manage the 
networks but also is the DNS and dhcp services provider for the local 
network through dnsmasq, then I suspect that turning off the caching 
nameserver is going to be the best approach.

I assume the NetworkManager will change /etc/resolv.conf to point to the 
caching nameserver and the real info for will be passed from 
NetworkManager or from the dhclient info to the dnsmasq(caching).

All this sounds like it will work fine with the dnsmasq instantiations 
used by libvirtd ... they will pick up the info from /etc/resolv.conf 
and go through the caching name server.

My interest in dnsmasq started because I wanted to run my own 
instantiation of dnsmasq so that I could access libvirtd's dnsmasqs.  My 
objective is to use ssh and scp to access virtual guests by name from 
the host system.  I can do it by IP address but DNS services exist for a 
reason.  Because dnsmasq was forwarding more than it should, there was 
an excellent chance that i could create dns query loops ... not 
something I wanted to deal with.

> > 3.  Will use of dnsmasq be optional and configurable?
> It already is, you can enable or disable it via "dns=dnsmasq" in
> /etc/NetworkManager/NetworkManager.conf; and since recently, you can
> tweak the configuration using files in /etc/NetworkManager/dnsmasq.d.
>
> > 4. I noticed that you have all the paramters specified in the software.
> > Based on my experience with libvirt, this makes it difficult to test any
> > needed parameter changes.  Suggention:  have you considered having your own
> > conf file and then specifying "--conf-file=<wherever>" in the software?
> See above; I think just the absolutely required parameters should be
> on the command line, I think that's largely the case right now.

Indeed.  It looks like your approach is better than that of libvirtd ... 
but, they have other considerations that might have driven their 
approach ... one of those dnsmasq process for each virtual network ... I 
currently have 7 virtual networks defined and running on a single host.
> > 5.  Let me add that I believe choosing dnsmasq for the caching nameserver is
> > a good choice.  On the whole it works well and is not all that complicated.
> Depends if you run into those really obscure bugs. I think we've found
> quite a few already, so things should be looking good for the most
> part.

Yes, indeed.  While I believe that dnsmasq is doing a good job and, in 
some cases, a better one that bind (named), it still has some problems.  
Specifically, I have found that it forwards a lot of queries that, to 
me, make no sense for being forwarded.  I was able to correct some of 
this with a patch to libvirt so that --local=/<something>/ was always 
specified.  <something> can either be a domain name or a null string so 
that only plain-names are handled.  I am looking at the dnsmasq code to 
correct the other condition where it forwards almost any plain-name [no 
domain] query.  When "domain-needed" is specified, I believe that no 
plain-name queries should be forwarded.

Gene