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?

You can easily turn it on yourself, it's been supported for a long time.
I don't think dnsmasq will be the default DNS server of choice in future
Fedora releases as it doesn't support DNSSEC.

> >> 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

If the user wants to run dnsmasq on and use NetworkManager at
the same time, he should just let NetworkManager start it.

> > 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
> > Ubuntu.
> 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
> > 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.

Did you consider unbound? We will probably use it anyway to provide
DNSSEC validation.


> 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
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org

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