On Mon, Feb 09, 2009, Rainer Duffner wrote:
Ray Van Dolson schrieb:
On Mon, Feb 09, 2009 at 07:58:38AM -0800, centos@911networks.com wrote:
The problem is that it is not very modular.
You must decided on which features (=patches) you want to incorporate and then build the RPM accordingly.
We use tinydns+dnscache almost exclusively (it's not good if you need to play 2ndary for a true BIND) and are very happy with it.
We have been using djbdns for years with excellent results, and user very few non-standard patches (mainly a hack to dnscache to allow it to respond to the world on one of our servers that we allowed customers to use in the mid '90s, and can't change).
We are secondaries for a few hundred BIND domains, and have no problems with that using djb tcpclient axfr-get to pull the data from these under control of a cron job.
We are also provide secondary DNS for many of our customer's sites which run djbdns, and they simply use rsync to copy their zone files to our primary server.
We use the rbldns daemon extensively to handle DNSRBLs.
The data formats for djbdns are quite simple, particularly compared to the ugly kludge of BIND. Setting up forward and reverse DNS for a host for which one is authoritative for the in-addr address requires a single line, at a minimum:
=fqdn:ipaddress:
The startup times are essentially zero, as are updates to remote servers using rsync to copy the tinydns and rbldns data files to our secondary servers.
The version we run on all our Linux systems has been hacked into SRPMS for the OpenPKG portable package management system, and we run it on various Linux distributions, FreeBSD, and OS X.
I don't remember exactly when we started using djbdns, but it was at least 8 years ago. Other than a simple hack I did years ago to have dnscache ignore CVS and RCS directories, it has been dead solid with zero problems.
Bill