-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://software.newsforge.com/article.pl?sid=05/04/06/197203&from=rss
Just wondering how many have transitioned to djbdns from bind and if so
any feedback.
regards,
/vicky
vickyr@socal.rr.com (Vicky Rode) writes:
http://software.newsforge.com/article.pl?sid=05/04/06/197203&from=rss
i'm struck by the persistent rumours repeated by this text:
Those who have been concerned with the number of security
vulnerabilities found in the BIND server through the years,
...
BIND9, being a different code base from the ones DJB has complained
about, has already dealt with the "security vulnerabilities in BIND
through the years". some day DJB and his followers should switch to
the current decade when looking for things to complain about, maybe.
Just wondering how many have transitioned to djbdns from bind and if so
any feedback.
if "transition" were a verb, i could point you at:
http://www.isc.org/ops/ds/reports/2005-01/dist-servsoft.php
(sorry about the frames, we're removing them, really), wherein it is writ:
Count Server Software
77929 BIND
16000 Microsoft
2193 TinyDNS
564 PowerDNS
556 simple DNS
1038 others
Count Server Software Version
36299 BIND 9.2.0rc7 -- 9.2.2-P3
20202 BIND 9.2.3rc1 -- 9.4.0a0
15396 BIND 8.3.0-RC1 -- 8.4.4
10069 Microsoft Windows 2000
3860 Microsoft Windows 2003
2673 BIND 4.9.3 -- 4.9.11
2163 TinyDNS 1.05
2053 Microsoft Windows NT4
1606 BIND 9.1.0 -- 9.1.3
1009 BIND 8.2.2-P3 -- 8.3.0-T2A
...
note, that's just the servers found in this survey, and might not be
representative of the full set (if there were such a thing as "full"
in light of known horizion variability.)
(attribution removed due to my freeform quoting to make a point)
...from the ones DJB has complained about...
And there we have the reason alot of us don't use DJB softwares. 
I used to use djbdns on my laptop for testing things, and then I took
an afternoon, learned to write BIND zone files, and decided I should
just use the BIND that comes with so many modern unixen and that
powers so much of the internet anyway...
Since then, I've always preferred deploying bind over djbdns. Even if
it was easier to configure, the installation process for DJBDNS always
really annoyed me. So that's a djbdns *to* bind transition story.
CK
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
thanks for the insight to all who responded.
regards,
/vicky
[snip some list]
One could also put together a list based on:
- Security holes.
- Amount of code
- Bloatness
- Seperation of functionality
- # of seconds it takes to load huge amounts of zones
In the end, it all comes down to religion:
Bind people don't ack djb points and vice versa.
Niek Baakman
<fnord>maradns</fnord>
niek@asbak.coding-slaves.com (Niek) writes:
One could also put together a list based on:
- Security holes.
in BIND9-- zero so far.
- Amount of code
in BIND9--
% find . -name '*.[chyl]' -print | xargs wc -l | awk '{X+=$1} END {print X}'
687674
- Bloatness
in BIND9-- none.
- Seperation of functionality
in BIND9-- you got me on this one, we have one daemon that does everything.
- # of seconds it takes to load huge amounts of zones
in BIND9-- you got me on this one.
in BIND9.3.1-- better but not good enough, BIND9.4 will be better still.
In the end, it all comes down to religion:
no.
Bind people don't ack djb points and vice versa.
i don't ack djb's existence, not merely his "points."
i'm happy to ack your points, and debate them, though.
Vicky - "Thou shalt not post about DJB software to a mailing list Vixie reads regularly". I take it you didn't listen in bible study class..
I had a play with DJBDNS after using BIND for years. Here's why I switched back:
- No AXFR support
- No TCP support
- I was forced to use DJBs naming conventions for zones
- Licensing
- Installation
Now, it looks like some of this has changed in the past few years, but at the time I was unable to provide a bunch of services that I wanted to because of these "missing features".
One of the reasons I see people quoting for their transition from BIND to DJBDNS is "BIND is hard to configure".
Really.
If you've got a good understanding of DNS (which, IMO, is required to run DJBDNS effectively), and you're finding BIND hard to configure, you'd best unsubscribe now and start looking for work elsewhere.
The other one is "BIND is a bigger binary than DJBDNS".
So?
It's the 00's kids, RAM and disk are cheaper than a hooker scraping for a fix.
My licensing and installation points above are common to all DJB software. I'm a lazy bastard. I want to click a button or tap some keys and have stuff happen in a way I understand and trust. I don't want to have my hosts littered with weird arcane trash that isn't looked after by my packaging system. If DJB were to allow people to provide binary packages of his software, this point wouldn't exist.
Anyway, in closing - Run BIND9. Save yourself.
I had a play with DJBDNS after using BIND for years. Here's why I switched back:
- No AXFR support
It supports this.
- No TCP support
It supports this.
- I was forced to use DJBs naming conventions for zones
If you administer 2-3 domains, sure it's an hassle, if not, put code-monkeys
to work. Most script people I know love the tinydns zone structure in comparison
to bind's one.
- Licensing
I agree here.
- Installation
A no-brainer.
Niek Baakman
No IXFR, no automatic notification of bind slaves (you get to run a
separate notify script) ...
But yes, it is far easier to use, consumes very low amounts of memory
and makes an excellent local resolver cache e&oe no roundrobin DNS
without a patch (as in it returns all the A records in the same order
every time, whereas bind does this in a different order ...)
No v6 support without a patch either
Oh yes, patch, patch ... welcome to patching hell if you run qmail or
any other djb ware
--srs
No IXFR, no automatic notification of bind slaves (you get to run a
separate notify script) ...
No RFC requires a specfic system of notification.
Seperate notify scripts are ok, rsync is even better!
Oh wait, does bind support rsync ?
But yes, it is far easier to use, consumes very low amounts of memory
and makes an excellent local resolver cache e&oe no roundrobin DNS
without a patch (as in it returns all the A records in the same order
every time, whereas bind does this in a different order ...)
Bind should patent this.
No v6 support without a patch either
Oh yes, patch, patch ... welcome to patching hell if you run qmail or
any other djb ware
Yeah we tech folk hate patching.
As I mentioned earlier, djb - non-djb is a religion thing:
rfc-wise, feature-wise (bind supports something, tinydns should too).
Niek Baakman
I like it - as long as I dont have to spend all my time on it.
Take qmail for instance - or at least netqmail that adds a set of
patches to make qmail borderline modern and usable (e&oe the
"comparison table" that rates it against sendmail 8.8, exim 2.x etc)
Add a couple more patches for tls, smtp auth etc, then try patching
for (say) mysql or ldap support.
Too many patches, none of which are guaranteed to play well with each
other without some re-patching
If djb would just have done what most other mta authors (especially
Wietse Venema and Philip Hazel) do, and be more open to rolling
contributed patches into qmail, or into other software he's written,
well it'd be more usable
But right now, if you are running anything other than a barebones mta,
or barebones dns, if you want to spend your time doing other things
than being a coding slave .. have fun running djbware
--srs (who needs a barebones dns server and resolver, so installed tinydns)
neither has ever had bugs or security problems, they were stopped
by the flying pigs. the same pigs who made them both completely
rfc-of-the-week compliant. the same pigs who made them both so
easy to set up and use. as a rare truthful router vendor hack
once said "we suck less." what a contenst.
do you prefer emacs or vi? me? i'll take coconut.
randy
because instead of MX you have . or + or - or : or something so helpfully
meaningful... same for NS and A and CNAME... Yes, 1 more level of
indirection is not always a good thing.
-chris
(not that I dislike djbdns, i just don't understand why things have to be
'different' so very much... and if bind works, why use djbdns?)
>
> > - I was forced to use DJBs naming conventions for zones
> If you administer 2-3 domains, sure it's an hassle, if not, put code-monkeys
> to work. Most script people I know love the tinydns zone structure in comparison
> to bind's one.because instead of MX you have . or + or - or : or something so helpfully
meaningful... same for NS and A and CNAME... Yes, 1 more level of
indirection is not always a good thing.
Try writing a script to parse BIND zone files. Now, try writing a script to
parse djbdns's zone file. It's far easier to do the latter. Notice the
similarity between djb's format and the format of some other commonly parsed
UNIX files.
(not that I dislike djbdns, i just don't understand why things have to be
'different' so very much... and if bind works, why use djbdns?)
A Honda Civic will get you to work and back, so why buy an M3?
As with many other things in the IT world, this decision boils down to
several factors. Who wrote it, or how popular it is, if you are a true
techie, should be close to the bottom of that list.
--Adam
woody wrote "and the usual kids-ranting-at-each-other" and so i'm back again:
> No IXFR, no automatic notification of bind slaves (you get to run a
> separate notify script) ...No RFC requires a specfic system of notification.
true enough, RFC1996 (thanks again randy!) isn't actually required -- it's
just convenient to speak the same protocol between all authority servers
for a given zone. i guess sometimes that's rsync.
Seperate notify scripts are ok, rsync is even better!
Oh wait, does bind support rsync ?
back before rsync, there was rdist. and because BIND4.8 was horrid at AXFR,
i admit that i used rdist to move zones around. rsync is quite a bit better,
and i know of people who use it to move zones around between BIND9 authority
servers because the access control and secrecy features can use the same
configuration infrastructure as their other sysadmin-related file sharing.
i myself am quite comfortable with DNS I-N-D (IXFR, NOTIFY, DYNUPD) and so
i move zones using IETF protocols rather than rdist/rsync/etc. but there's
nothing that prevents multiple BIND servers from all thinking of themselves
as "masters" and having their "zone files" managed by external programs such
as rdist or rsync.
> ... (as in it returns all the A records in the same order
> every time, whereas bind does this in a different order ...)Bind should patent this.
BIND's publisher is a public benefit corporation, so our only reason for
filing a patent would be for defense, and we consider the prior art strong
enough in the case of round-robin DNS that no defensive patent is needed.
> No v6 support without a patch either
>
> Oh yes, patch, patch ... welcome to patching hell if you run qmail or
> any other djb wareYeah we tech folk hate patching.
people with a lot of servers to run have to use configuration control on
their operating systems and utilities and config files. if a vendor will
offer patched binaries through "rpm" or "/usr/ports" or whatever then
everything gets easier. djb's license precludes this kind of repackaging,
is what i'm hearing. ISC uses a BSD-style license, and i personally think
that anything more restrictive, even GPL or LGPL, is suboptimal. apparently
DJB's license is even more restrictive than GPL, which is hard to fathom.
As I mentioned earlier, djb - non-djb is a religion thing:
perhaps to you it is. perhaps to DJB it is. perhaps to many, DJB is.
but the arguments i'm seeing tonight for/against djbware are engineering
arguments, not religious arguments.
rfc-wise, feature-wise (bind supports something, tinydns should too).
the people who are happy with djbware are VERY happy with it. no argument
from me on that point. in <http://www.circleid.com/article/774_0_1_0_C/>,
i wrote:
...
Those are good articles. But Jacco's site at
<http://www.bind9.net/> is also very good, and includes all kinds
of useful links. Education is good.
Administrators can also look at alternatives to BIND such as DJBDNS
located at djbdns: Domain Name System tools.
OK, so some of you were wondering why I bothered to respond to this
obvious "hit piece" written by someone without much background in
the field -- maybe the same yet-to-be-fired marketing wizard who
came up with the name "Internet Storm Center" when the term ISC had
another, much stronger, much older, meaning. I was going to Just
Hit Delete -- something you should never do with spam, by the way!
Until I saw the DJBDNS reference. Mr. Bernstein has what could
politely be called a grudge against... well, almost everybody. His
software seems to work, and it has a loyal and committed user
base. But if you're going to look at alternatives to BIND, you need
more options, and you need a better reason.
For more options, check out Nominum's ANS and CNS products, and
NLNetLabs' "NSD", and Cisco's DNS/DHCP Manager, and Microsoft's
Advanced Server product. (I'm sorry if I'm leaving somebody out,
that's off the top of my head.)
For a better reason, discard "I don't want to have to learn about
patches and apply them every year or two" since no vendor will ever
be able to guaranty this. If you want help staying patched, talk to
ISC about BIND support, or talk to your operating system vendor, or
talk to your ISP. Help is out there.
...
oddly enough, i still consider this on-topic, even though it has more to
do with sysadmin than netops.
adam@flounder.net (Adam McKenna) writes:
Try writing a script to parse BIND zone files.
why on earth would i want to do that? BIND might be storing it in SQL or
BerkeleyDB or some other DB/SDB/DBZ container. or the server might not be
BIND at all. the right way to do this is in Perl if you've got it:
our $zones = { };
$res->nameservers($ns);
my @zone = $res->axfr($mz);
foreach my $rr (@zone) {
next unless $rr->type eq 'TXT';
my ($name, @words) = ($rr->name, $rr->char_str_list());
my ($attr, $value) = @words;
$name =~ s/$mzp//;
$zones->{$name}->{$attr} = $value;
}
as operators we should all strive to make our tools as robust and as
independent as possible. i'm very glad that nothing i've written depends
on the format of zone files.
if you don't have perl, just use "dig", pipe it to awk or sed or cut or
whatever, and once again you'll have a server-independent format. AXFR
is your friend, don't ignore it.
> (not that I dislike djbdns, i just don't understand why things have to be
> 'different' so very much... and if bind works, why use djbdns?)A Honda Civic will get you to work and back, so why buy an M3?
because there might be a hill.
As with many other things in the IT world, this decision boils down to
several factors. Who wrote it, or how popular it is, if you are a true
techie, should be close to the bottom of that list.
amen.
OK. So one of them is a Honda Civic, and one is an M3. And I really don't
care which is which, because:
Count Server Software Version
2673 BIND 4.9.3 -- 4.9.11
Gaak.
Some of us are obviously still walking barefoot down unpaved muddy
streets in third world countries. It's time for *both* camps to send
in the missionaries to save the poor heathen zone file's immortal souls,
or at least provide safe drinking water or something.. 
djbdns has lower performance, both as an authoritative and recursive
resolver, than bind.
It's less flexible than bind9. But it's data files and log files are
easier to machine generate / parse.
dnscache seems marginally less prone to bloating memory usage than
bind. I've not compared it with recent binds.
tinydns isn't blindingly fast, but it doesn't nap while new zones are
loaded. With a decent DNS architecture that needn't be a problem with
bind, but it does need more hardware to work around.
I still wouldn't suggest tinydns for anything other than a small,
low-traffic requirement.
I quite like dnscache, and would consider it as one option for
recursive resolution (but if you're doing authoritative using bind
then you have bind clue onsite, and one of the stronger reasons for
using dnscache over bind goes away). In some unusual cases dnscache
can return data that is incorrect, but it's doing so as documented
and it's seldom a problem in practice.
djbdns has appallingly bad and often misleading, but entirely accurate
documentation. Bind does not.
The only unequivocally bad thing about the djbdns suite is the lack of
technical and social savvy in some of it's more vocal proponents.
I use both tinydns and dnscache, but I recommend bind to clients
I consult for.
Cheers,
Steve