* Reckhard, Tobias wrote on Mon, Jan 21, 2002 at 10:04 +0100:
We had a discussion about djbdns on a local maillinglist in Berlin. It's not offering all features that bind offers.
While this may well be true, many people probably don't need certain features at all. And there are workarounds or patches for quite a few of the 'problems' that a certain number of people have with the pure djbdns.
I know from qmail, that most of the patches are "inofficial" and not security-checked sometimes, so a patched djbdns may not secure at all, who knows.
Perhaps you could point out which specific features you miss?
Well, I have some hundert zones on currently a few primary and a few secondaries, but not any zone is on any secondary. Secondaries keep track what to transfer when, and this is controlled by serial number which is not bad. I don't now how much work it is to set up a secondary for djbdns, i.e. adding new zones. With bind, it's only a thing of adding them to configuration, they get the new zone automatically. Well, and the logging is nice, I see it when something fails, without watching if zone files are up to date or not, it's in the logs when a zone transfer failed. This are details but for me they are important.
Zone transfers are supported in the current version (djbdns 1.05), but you need the separate ucspi-tcp package to provide TCP client and server.
I think that ucspi-tcp is a nice package, but I think it's a little more efford setting it up than having "native" TCP support. On the other hand, you have a stable, tested TCP implementation.
DJB argues against zone transfers and urges people to use rsync (preferrably over SSH) instead, for several reasons outlined on his web page.
I read it a long time ago IIRC. Rsync+ssh is more secure and so on, but it's more efford to set up and to watch if it fails I think.
transfers just fine. tinydns does not pull zones per zone transfer automatically, so you need to use cron jobs to pull from the clients on a regular basis to emulate AXFR behaviour.
Well, with bind I don't need to do anything, it works out of the box. This is comfortable and cheap.
For non-trivial setups (i.e. some hunderds zones and a handful secondaries) I would not recommend such approach but use bind8 instead.
IMHO, that depends on what you favour: a relatively bloated piece of software with a pretty poor security track that most organisations and documents expect,
This is really a pitty, and I don't like to quality of bind, really. But on the other hand, I don't have time to do so much details by hand for so much servers and zones.
than the former and may require some scripting around them to achieve the same features, however usually implemented with higher quality.
I feel that scripting solutions often seem not as stable as "real servers", often it's not trivial to do the right error checking and so on. On rsync cron jobs, I had to take care that error messages get into syslog, and if I forget somethink, I may not notice some errors and such.
If you need cryptography, I think there is no way around bind9 currently. For a small private caching only server djbdns may be a nice solution.
Hmm, what do you mean with 'cryptography'? You may be right, if you mean that djbdns doesn't support 'SecDNS', which DJB doesn't believe in,
:) Well, but this statement cannot last forever I think. At least inside companies it may be usable; well, I don't think that this will be used globally and by root servers next future.
configured to support FreeS/WAN's opportunistic encryption by handing out KEY records, and the FreeS/WAN docs speak of SecDNS...
KEY records without SecDNS (signed records and zones) makes not much sense. I think djbdns can work with KEY records but they are unsigned, so you cannot use them, since you cannot trust them.
so maybe djbdns does actually support 'cryptography'. I don't know enough about the so-called Secure DNS to be able to say.
Ohh, and one thing I forgot: does djbdns support dynamic zone update? Well, usually I don't like it, and I have the dynamic names in own zones, but I won't live without it. Well, it's not really secure (and I use it with a bad script via SSH :(), but needed for dynamic IP accounts. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.