Date: Mon, 19 Feb 2001 12:30:15 +0200 From: Peter Pentchev <roam@orbitel.bg> To: Terry Lambert <tlambert@primenet.com> Cc: josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010219123015.D2946@ringworld.oblivion.bg> In-Reply-To: <200102191012.DAA17412@usr05.primenet.com>; from tlambert@primenet.com on Mon, Feb 19, 2001 at 10:12:05AM %2B0000 References: <20010218233916.J28286@lizzy.bugworks.com> <200102191012.DAA17412@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 19, 2001 at 10:12:05AM +0000, Terry Lambert wrote: > > I can't help getting the impression that people don't care to give djbdns a > > proper look because of the way they perceive its author. Who cares what kind > > of personality the author has, as long as the code works and is > > well-supported? > > I looked at DJBDNS in serious detail, for use on a datacenter > project within IBM. I found it wanting. > [snip] > Because all servers are "primary", and they have the same weight, > as far as being authoritative servers, this means that updates to > one server's data must be made to both servers. Worse, both must > then be restarted for the updates to take effect. Even if I could > ignore the problem with not being able to update a single server > and have the secondaries "just work" because of NOTIFY, the need > to shoot all my name servers in the head when I do an update is > simply unacceptable. I can't rely on one server being up while > another is reloading. With BIND, I only have to worry about this > on zone creation, and I can stagger the reload on zone creates, so > it's not really a problem. With DJBDNS, my hands are tied, and > the frequency of update events when you have 500 customers doing an > update each time they dial in, and dialing in once an hour or even > more frequently, with another update on teardown, means that my DNS > servers would be largely unavailable. No thank you. 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. 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? To reiterate, there is NO downtime associated with rebuilding a djbdns database, which is more than can be said for BIND. G'luck, Peter -- If I were you, who would be reading this sentence? 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?20010219123015.D2946>