Date: 01 Oct 2002 09:22:40 -0400 From: Chris Shenton <chris@shenton.org> To: "Leigh V" <leighv@roq.com> Cc: "Dave [Hawk-Systems]" <dave@hawk-systems.com>, "Jan Knepper" <jan@digitaldaemon.com>, "FreeBSD ISP" <FreeBSD-ISP@FreeBSD.ORG> Subject: Re: DNS (bind or djbdns or ???) Message-ID: <87fzvqguov.fsf@thanatos.shenton.org> In-Reply-To: <006801c268f4$ec722e10$2d01a8c0@michael> References: <DBEIKNMKGOBGNDHAAKGNMEBGCBAB.dave@hawk-systems.com> <006801c268f4$ec722e10$2d01a8c0@michael>
next in thread | previous in thread | raw e-mail | index | archive | help
"Leigh V" <leighv@roq.com> writes: > but I found that DJBDNS is far worse because you have to recompile the whole > database file everytime you change something and with 1000 domains each > having there own stack of records, restarting bind is much faster result. I'm a long time BIND user but switched to DJBDNS a couple years back and prefer it. I hope to avoid a religious mire here and provide some useful hints. For BIND to read changes in the zone files, it requires a reload (ndc or kill -HUP) but it stops answering queries while it reads and parses the zone files. That downtime can be a drag with large zone datasets. When you change a record, DJBDNS requires you to rebuild the zones' CDB (a read-optimized, constant-time database) which the data is being served from, but the nameserver continues to answer queries while this is happening. This is an especially good thing when you have a lot of zone data like you do. You don't need to restart or reload the daemon itself, very nice. (Russ Nelson's "axfr" is handy for managing lots of zones: it pulls zones you secondary, aggregates other zones in individual files, then creates the CDB for you.) WRT the original question about daemontools: yes. You need this as well as the ucspi-tcp package; both are in ports and build trivially. Setup is a little confusing cuz it's different, but there's good advice on www.lifewithdjbdns.org. Daemontools allows you to stop, start, pause, reset, and query daemons -- quite nice. The ucspi-tcp stuff grabs the TCP connections, does resource limiting, then handles the file descriptor to the intended service so the service itself doesn't have to implement this -- it just reads/writes stdin/stdout -- making the service smaller and therefore less complicated (and presumably more secure). Getting your head around these meta-services takes some time but it's very nice once you get it going. As to others' posts about DJB being a difficult person, I agree. But it sure makes the lists more lively. :-) I do like his code though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87fzvqguov.fsf>