[Dnsmasq-discuss] Dnsmasq ready for corporate use?

[Simon Kelley]

Rory Campbell-Lange wrote:
> Apologies for the troll-like title of this email.

No problem, it's a good question.
> 
> Following the problems with crashes with the recent Debian testing
> version of Dnsmasq, I'd like to enquire if the software is ready for
> fairly intensive use in an office of around 150-200 machines.
> 
> I don't wish to sound in the least bit offensive. There is other fine
> software which has not yet completely stabilised which we are using on a
> day-to-day basis (Dovecot, for instance). I would, however, be grateful
> for an idea of the general stability and quality of the program to see
> if it matches up to the excellent documentation and the positive
> write-up in Linux magazine.
> 
> Cheers,
> Rory

I'm not the correct person to give an unbiased answer on this, but I'll 
shove my oar in anyway. I'm very happy to hear other people's opinions 
on this, good or bad.

Dnsmasq 2.x, which is the version which added DHCP, is now 11 months and 
18 releases old: Adding the DHCP support was my "escape from Christmas" 
project last year. Of those 18 releases, about 14 have been almost 
exclusively feature upgrades or fixed specific bugs with limited impact. 
One was to fix a bug caused by the non-POSIX compliance in the Linux 
kernel which was never seen in anger and also affected glibc, syslogd 
and inetd, at least. Three were to supercede flawed releases which 
crashed, in each case the crash bug was found and fixed in a few weeks.

In other words, if you follow the bleeding edge,there's a chance you 
might get burned, but otherwise the code is stable and usable.

I've been thinking for some time that I should make stable and 
development branches, but each time I've convinced myself that dnsmasq 
2.x is now finished, so I don't need a development branch. I think that 
this is probably a delusion.

Aside from the risk of Simon-induced problems in a latest release, I 
don't think there's much question that the code is ready for the sort of 
use you are proposing - the basic design has had much testing over 
several years, and the current code is in widespread enough use that all 
the common problems have been found.


What do others think?


Cheers,

Simon.