Date: Tue, 20 Feb 2001 02:37:03 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: roam@orbitel.bg (Peter Pentchev) Cc: tlambert@primenet.com (Terry Lambert), josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <200102200237.TAA05931@usr05.primenet.com> In-Reply-To: <20010219123015.D2946@ringworld.oblivion.bg> from "Peter Pentchev" at Feb 19, 2001 12:30:15 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Now hold it, just a second! Restarting?! > > I'll not go into detail as to synchronizing djbdns data files via > rsync (yet it *is* easily doable, esp. with ssh permitting passwordless > authentication for executing a single command - in this case, sending over > the new database and executing the rebuild command), but one of the djbdns > features that I've found I like best over BIND is just that - > > tinydns does NOT need restarting when its data file changes! > (if you meant you need to restart dnscache, see below.) > > (For those who haven't looked into djbdns, tinydns is the authoritative > 'content' server, there's a separate program, 'dnscache', that does > the recursive resolving thing.) > > tinydns never loads its datafile into memory, it mmap's it and does > one-pass lookups on each and every query. The tinydns-data program, > which is used to rebuild the database, works on a temporary file, > and only atomically replaces the real database when finished. > Thus, there's NO downtime updating the content server's DB. You still need to unmap the old file and remap the new file. It is my experience that the amount of time to turn around a change in data introduces an unacceptable propagation delay. This is compounded by having to do the changes to multiple DNS servers. With in excess of 50,000 lines of configuration data for 10,000 domains, the delay was very noticible. Further, the "synchronization is left as an exercise for the student" approach of having every server be primary, is incompatible with current network technology. In particular, a good DNS service provider will put DNS servers, minimally, at two colocation facilities, generally within spitting distance of MAE West and East, and better, five (add Chicago, France, and somewhere along the Pacific Rim). You are aware that with a West coast facility only, adding another DNS server on the East coast will increase your web site traffic by 30%, right? That's all accounted for by failures to reach your DNS server on the West coast; these are hit you are missing due to the users on the other end getting a lookup failure. I really did not want to deal with synchronization between S.F., Rochester NY, and Chicago, given the DJBDNS philosophy. Among other things, IBM will not open up SSH holes in its firewalls. With BIND and standard zone transfers, if I have a link lost between two DNS servers, then at least I am assured of NOTIFY synchronizing them at the first possible opportunity; if I had to roll my own, then I have to build all the retry logic into my code. Worse, it's probably written in a write-once language like Perl, since I'd give the job to someone else while I was tackling the things I really needed to worry about. It's just not worth it. > If your problem was with dnscache giving out stale information after > a dynamic hostname has changed, may I ask why not use low TTL's, > possibly of the order of half an hour or less? I generally use a TTL of 1 for transient records; this doesn't stop stupid programs from caching them (many people run caches which refuse to cache for anything less than 5 minutes to cut their DNS traffic). I'm safe on a redial, since the new record will replace the old record after authentication. Internally, I don't use cached data, since I have 100Mbit link between the mail and DNS servers. This means that as long as I get my updates to all my DNS servers _in a timely fashion_, I don't have the risk of using a stale DNS record, and shoving all my customer's mail down to some idiot's Linux box or Microsoft Exchange server, just because they have an open relay, and get the IP address that my customer used to have. > To reiterate, there is NO downtime associated with rebuilding > a djbdns database, which is more than can be said for BIND. There is propagation delay, which is effectively downtime, since I end up with the same latency, either way. Since BIND implements DNSUPDAT and DNSNOT, I have _no_ downtime (or latency, if you want to word-weasel) with BIND, because I don't have to rebuild the database at all to make the changes I need to make. The changes can be made without needing to do a rebuild at all. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102200237.TAA05931>