On Mon, 2005-07-11 at 20:52 +0200, Thomas Hood wrote: > Here is a good reason, then, to use dnsmasq rather than bind. > When dnsmasq is run with the --strict-order option it always > consults nameservers in the specified order. But again, this would only help most (i.e. not all) of the time. The network setup where David is is just broken. > (Its default > behavior is to try to be smart: Start with no current server, > in this state queries are sent in parallel to all servers. The > first one to reply becomes the current server. Subsequent > queries are sent to that server alone. If a query to the > current server times out without a reply, revert to the > initial state and retransmit to all in parallel, select a ne > current server based on who wins the race.) Actually this looks to me like it would make things worse; in David's case, suppose that one of the external servers happens to win the race. It will give back a negative reply for an internal name. If that's then cached, then one loses. > Another reason: the dnsmasq package in Debian is one third the size of > the bind9 package. > > Another reason: dnsmasq is designed from the ground up as a caching > nameserver. Ok, but these reasons aren't very convincing on their own. > Another reason: dnsmasq does not need to be restarted or > even signalled when the list of nameservers chagnes. dnsmasq > can be configured to poll a file which lists the nameservers it > should use. Sending SIGHUP or whatever it is is a pretty trivial amount of code. > Another reason: If dnsmasq is used then there is no need for it > to be run as NM's private instance. dnsmasq naturally coexists > with bind running as an authoritative nameserver. When NetworkManager handles servers too we can be concerned about the possibility of running an authoritative nameserver alongside it, but for now I'm just not too worried about it. > There may be reasons for preferring bind but if they were > mentioned then that was before I joined the list. Hopefully > someone will clue me in if that is the case. Basically just that it was there and worked. I had a lot of code already written in eggcups for managing cupsd (writing out a conf file, etc), it was easy enough to port to named. If you really really care it shouldn't be too difficult to implement nm-named-manager-dnsmasq.c and do conditional compilation. Not sure if Dan would take the patch, but it's probably not too much of a maintenance burden. Personally though I don't really see the value of spending developer time on replacing bits of NetworkManager's internals (which is essentially what bind is now); better to spend time on the user-visible issues and features like VPN support, reliability, etc.
Attachment:
signature.asc
Description: This is a digitally signed message part