BIND Is Most Popular DNS Server
bleachboy writes "Last week I completed a new DNS server survey, since D. J. Bernstein's hasn't been updated for years. Not surprisingly, BIND wins. Why is it so hard for alternate DNS servers to gain favor, especially when BIND can be so frustrating sometimes? And yes, I'm shilling."
No matter which DNS server is the default in any distro. All of the DNS admins I know will compile or reinstall the server anyway.
It maybe true that some of the home users running a "server" in the closet may be using the default server of distro, but I think there aren't that many to make a difference.
-- Reality checks don't bounce.
Sigh. Y'know, I really should get used to sendmail FUD on Slashdot, but here I am feeding the trolls anyway. I use sendmail because it's better than the alternatives, and it's far from an abomination. I'm not going to claim the syntax looks good at first glance, but then most perl programs look like line noise too, yet the Slashdot crowd doesn't seem to have a problem with that. When other MTAs can match Sendmail's flexibility, then maybe I'll consider switching. But not before.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Ratio of BIND domains serviced to installs: 24,335,752 / 340,345 = 71.5 domains/server.
Ration of MS DNS domains to installs: 2,165,143 / 101,781 = 21.27 domains/server.
Ratio of TinyDNS domains to installs: 5,405,266 / 12,130 = 445.6 domains/server!
Despite only having 2% of the installs, TinyDNS serves 15% of all domains on the internet. Obviousy it is very capable, and has few to no exploits available for it. Why don't more people use TinyDNS if it's so capable?
Because they haven't read how easy it is to setup!
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
...since D. J. Bernstein's hasn't been updated for years...
Maybe because it hasn't needed updating.
http://cr.yp.to/djbdns/guarantee.html
Please tell me something Sendmail does that Postfix doesn't.
I'd argue Postfix is more modular, more simple to configure, more respectful of system resources, more secure and more flexible than Sendmail.
BIND just wouldn't work. It worked at first, until I dumped a bunch of hosts into my zone (only a couple thousand, which isn't much in the grand scheme of things). After it stopped working I happened to get in touch with some of the developers. They just kept telling me to upgrade to the next release.
Some of the problems? Sometimes the CPU would peg at 100% like the program was in a loop, the server would quit resolving after about ten minutes, and the server wouldn't replicate.
My zone files were standard and by the book. The particular developer I was talking to the most (generally) tried to blame the A records I had added (without knowing which ones). I quadruple-checked the entries, all of which followed the RFC. I reinstalled the program, tried it on totally different servers, etc. The problem persisted.
After screwing around with BIND for two weeks I gave up. I switched over to MSDNS. Guess what? The EXACT same file that wouldn't work with BIND worked with MSDNS. This was BIND 9.2. We've been running MSDNS for a few years now with hardly any issues. We ran into some cache pollution once, but once I checked the stupid box to prevent it the problem went away.
Its a pain having to mess with the registry for simple tasks, but I guess its worth it for a working product. We're building everything programatically just like we were for BIND. Microsoft did good when it decided to use flat zone files. If only they would make everything so simple...
"Never tell me the odds"
Like the subject says, I USED to use djbdns for my home DNS server. After a while, when I upgraded the OS on said home DNS server, I got rid of djbdns and moved to BIND. Why, you may ask?
1) I didn't like the fact that I had to use two separate IP addresses for caching and domain hosting. Maybe there was a workaround for it, but at the time I didn't know what it was and it frustrated me to high heaven that I needed two IP addresses on a box that I would have liked to have only used one.
2) The log files didn't print out timestamps in any kind of human-readable format. If I want to see what my system's doing, I don't have time to run the timestamps through some kind of translator.
3) Due to a directory existing where axfrdns didn't expect one in the log directory (and it was a name that it didn't even use), axfrdns did not work at all. I didn't find that out until a power issue brought the DNS server down and the secondary servers didn't have the correct DNS information. Once I removed the directory, axfrdns started working again.
4) Believe it or not, I find BIND zone files to be a bit more readable than tinydns's zone files. It also helps when I'm not forced to name my domain name servers a.something-or-other in the zone file. (Why add a CNAME or A for the one you want to use in the first place?)
5) daemontools.... ugh. Let's not even go there.
Go ahead and mark me as flamebait or what you will. If djbdns works for you, great. But for me, I found djbdns to be much more frustrating than BIND, and since I've migrated over to BIND I haven't had a bit of problem.
Just my $.02...
As another testimonial, I use djbdns for over 900 domains and over 100,000 RRs. We receive about 300 queries/sec with tinydns using about 2% CPU and about 800K of memory. I love the rsync method of syncing dns data, it works especially well for Dynamic DNS (which is something I provide).
As an aside, long ago, ODS (the service I run) ran BIND. At the time BIND used 90+% CPU consistently. Mainly because of the constant dynamic updates being sent to BIND via the update daemon. It also used about 50MB of memory or so (back in 1999 or therabouts). The switch to djbdns came shortly thereafter and I haven't looked back. Granted, djbdns cannot provide immediate dynamic updates because of its use of CDB. However, I find that every 30 seconds proves to be sufficient, especially when the 'secondaries' get updated immediately as well (thanks to rsync). Building the cdb is also remarkably fast, with it taking 0.55 seconds to hash the cdb with over 100k records.
Overall, I'm quite happy.