> On 08/27/2012 12:19 PM, Mathieu Trudel-Lapierre wrote: > > On Sat, Aug 25, 2012 at 5:05 PM, Gene Czarcinski <[email protected]> > > 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 > >> 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. If the user wants to run dnsmasq on 127.0.0.1 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 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). Yep. > 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. OK. > >> 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. Pavel > 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/networkmanager-list > _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
