Re: Use of dnsmasq for caching nameserver

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  This could be a problem if the user (such as myself) wants to
run a dnsmasq listening on
Yes. I have a patch ready to be sent to the mailing list to change
that to (could be anything else really), as what we use in
On further thought, this change to 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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]