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. Perhaps you could point out which specific features you miss?
I don't know if zone transfers are supported currently, some time ago you had to fiddle around with rsync or such things.
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. DJB argues against zone transfers and urges people to use rsync (preferrably over SSH) instead, for several reasons outlined on his web page. However, tinydns (the DNS server) in combination with axfrdns (the TCP request and AXFR responder) servers zone 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. DJB favours a push approach (which BIND8, I believe, has introduced with NOTIFY as well) via rsync/ssh. You could also use SSH with automatic command execution (command='cd /etc/tinydns/root && tcpclient 1.2.3.4 53 axfr.get zone data data.tmp && && make') to achieve the same effect.
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, which therefore means that you'll find HowTos, etc. geared towards it, or a couple of small, highly secure tools that work differently than the former and may require some scripting around them to achieve the same features, however usually implemented with higher quality.
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, BTW (this is meant merely as an explanation, my opinion doesn't necessarily converge with DJB here or elsewhere). It can be configured to support FreeS/WAN's opportunistic encryption by handing out KEY records, and the FreeS/WAN docs speak of SecDNS... so maybe djbdns does actually support 'cryptography'. I don't know enough about the so-called Secure DNS to be able to say. Cheers Tobias
* 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.
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, which therefore means that you'll find HowTos, etc. geared towards it, or a couple of small, highly secure tools that work differently than the former and may require some scripting around them to achieve the same features, however usually implemented with higher quality.
This is a lot like Sendmail, older versions sucked, so they did a rewrite/audit and secured it reasonably well. Things change. http://www.isc.org/products/BIND/bind-security.html So far (knock on wood) Bind 9.x hasn't had any serious security bugs. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://www.seifried.org/security/
[ Let's see how long this thread will continue and if this time some new points are made or simply all the well known(?) facts are repeated. I mostly participate with this message since I feel many "spectators" / lurkers simply don't _know_ much else but BIND -- if at all they know any alternative. That's why I urge everyone with serious interest in the topic to actually have a look at them before repeating the ubiquitous "all the world is BIND" and "if others _say_ it's good it must be, I don't need to check myself" mumble. ] On Mon, Jan 21, 2002 at 04:14 -0700, Kurt Seifried wrote:
This is a lot like Sendmail, older versions sucked, so they did a rewrite/audit and secured it reasonably well. Things change.
http://www.isc.org/products/BIND/bind-security.html
So far (knock on wood) Bind 9.x hasn't had any serious security bugs.
Well, I'm not positive if there haven't been such bugs or if they simply haven't been discussed in public. I remember the recent bugtraq mini thread which started with the MaraDNS announcement (see <20020109123631.A24072@artemas.reachin.com> and <20020110040505.24874.qmail@cr.yp.to>). Especially the message by DJB which wasn't accepted by the moderator (http://cr.yp.to/djbdns/bugtraq/20010201072942-22539-qmail@cr-yp-to) and the links therein caught my interest: As much as some of us might dislike his wording or doggedness(id?) in some respects, he often (always?) has a valid point to make. As long as those urging questions are still left unanswered (are the new BIND developers really different from those drunken monkeys who wrote previous versions? is the code really a new rewrite or just added bloat on top of previous acked crap? has none of the many severe acked bugs been security relevant? who else besides DJB actually *guarantees* the software's functionality and robustness? etc) I somewhat doubt ISC's announcements and put them into the same drawer where I put Bill Gates' latest "we're heading for secure products and put features behind" blurb. Once I can see that things improve, I might change my mind. But until then I'm sceptic when looking at the recent history. In contrast I have yet to see djbdns die on me when it's pushed by the outside world with all the [snip] in it. And frankly speaking setting up djbdns I never had to watch its logs too closely. It simply runs. Reliably and without hogging resources. Plus once you get the concept it's way much easier to handle than "the standard" in any day-to-day scenario, see the "ease of use" comparison on the cr.yp.to site. Admittedly I don't need any of the "missing" features (SecDNS, dynamic updates). But I assume neither do most of the people still running BIND. I can only explain people use BIND because they're too lazy to change or just don't know there's something else out there. Very few will be prevented from changing since the alternative lacks features. And it's still left to further discussion if missing features are better handled by a separate tool (and to return to the most asked for: djbdns *does* support AXFR -- as a server as well as a client, it's just not done in the process which holds the authoritative data and serves record requests). Regarding the license which keeps distributors from providing packages I don't have any problems here. Most people only understand "I don't get a binary, so I stick with what comes with the CD". They don't see the point behind where DJB actually states "employ the software in the way it was designed by me and I will guarantee that it *will* work as designed and announced". To repeat the above point: Who else does this? Plus I'm always free to get the source and modify (patch) it should I wish for a different behaviour. What else could I want? To conclude: djbdns _definitely_ is worth a look. And if it only was to see that things can be done differently. :) But those who don't _need_ BIND probably will stick with djbdns once they get over the "being different" (BTW: what's the point in running any kind of UNIX on a PC when they always come with Windows preinstalled? If "what's usually preinstalled MUST be good for me" is not a valid excuse then why should be "most others run BIND, so do I"?). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Hi, On 21 Jan 2002 at 20:06, Gerhard Sittig wrote:
assume neither do most of the people still running BIND. I can only explain people use BIND because they're too lazy to change or just don't know there's something else out there. Very few
you forgot one reason to use bind, and this one is important and security relevant: The number of others using it and the resulting amount of documentation and help available! The same is true für MS products. Customers use bind because if they have problems help is available. There are books they can buy. The DNS technicians of their ISP can help. This is an important reason to use bind. mike
On Mon, Jan 21, 2002 at 08:43:17PM +0100, Thomas Michael Wanka wrote:
Customers use bind because if they have problems help is available. There are books they can buy. The DNS technicians of their ISP can help. This is an important reason to use bind.
Great, that's settled then. So when do we dump Linux? After all, Windows is used much more and there's more help available for Windows. -- Jurjen Oskam * http://www.stupendous.org/ for PGP key * Q265230 9:35am up 19 days, 14:41, 1 user, load average: 0.00, 0.00, 0.00
participants (6)
-
Gerhard Sittig -
Jurjen Oskam -
Kurt Seifried -
Reckhard, Tobias -
Steffen Dettmer -
Thomas Michael Wanka