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."
But what I really want is something like EasyDNS provides: Aliases. I want to be able to 'clone' whole domains, because they're all going to the same place anyways based on the hostname.
Maybe EasyDNS just wipes out all the duplicate hostnames, and writes new records for them between the web interface and the backend when a host is changed or added..
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
"air is most popular substance to breathe". :)
That being said, PowerDNS is pretty awesome as a master, very nice for front end interface building.
-- The unsig...
Personally, I use one called djbdns. It's extremely small and basically bug free! The author actually will pay $50,000 to whoever finds the first exploit in it or something. If you don't need all the extra power that bind offers, this is a much better way to go. Less memory and space required, meaning cheaper systems may run it better. Even the config file can't be simpler!! cat /etc/tinydns/root/data .pnet:10.0.3.33:a:259200 .10.in-addr.arpa::ns.pnet:
#Define hosts & aliases
=pollux.pnet:10.0.3.1
=altair.pnet:10.0.3.2
Unlike sendmail which can scare people away just with the configuration file, the BIND zone file layout and other stuff isn't hard to learn.
So people use what came with the box, what their book on "DNS & BIND" uses, and so on.
Also, everybody else uses it!
Why not?? He's replaced the other major ISC-associated software. Plus you know there must be security holes in dhcpd.
-russ
Don't piss off The Angry Economist
Is because it has been done forever. Instead of the exploit a year phenomenon you have with Bind, there haven't been any yet. When Bind can take 10,000 requests per second on a dual Xeon box (used for MAPS) and not melt into a smoky plastic dog treat, let me know. Don't get me wrong. Djb is slightly, well, he comes across as a bitter man with something to prove. And I can't stand qmail. But he hit the nail on the head with DjbDNS. I've got nearly 240 domains with a combined total of over 125,000 records hosted with no problem.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
When other MTAs can match Sendmail's flexibility, then maybe I'll consider switching.
I think you hit the nail on the head. These big, some would say bloated, systems end up getting used because they're flexible. Others are constantly writing 3rd party stuff that specifically use these systems.
Case in point: Microsoft ADS is very DNS dependant and the only DNS they support besides Microsoft DNS is BIND. BIND may, or may not be the best DNS out there, but because it's the standard people are building their systems to, it is almost certainly the most compatible and, by extension, the most flexible.
TW
He used fpdns which is a well-known and accurate tool. http://www.rfc.se/fpdns/
The question is whether the flexibility is worth the security cost imposed by the extra complexity required to get the flexibility. I say no, and run qmail. It's the only MTA that has never had a security lapse. (actually, Courier might not have had one either, but who runs Courier?)
-russ
Don't piss off The Angry Economist
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?
tinydns is unmaintained software. It does not compile out of the boxon modern systems. You don't have a license, so you can only do with it what your local copyright law permits (which may or may not be enough). The zone file format of tinydns is non-standard. The answers it generates are often excessively verbose (e.g. redundant NS records). Third-party documentation suggests a configuration that violates recommendations of TLD operators and most ISPs, which means that you have to redo parts of it once you receive your first delegation.
And so on. Go ahead and use BIND alternatives for authoritative name servers, but try to avoid tinydns.
Maybe because it hasn't needed updating.
He meant the *survey* hasn't been updated, not the software. Even if it wasn't obvious from the language (and I think it was!) it should have been obvios from the link.
Please explain how you managed to fingerprint DNS servers.
.com, .net, .org, .info, and .biz TLDs 37 million domains -> 1 million name server names -> 646,524 unique name server IPs.
The same way you fingerprint OS's via there ip stack. Unusual queries and how the server reacts to them.
http://cr.yp.to/surveys/dns1.html is one among several fingerprinting methodologies.
The accuracy of the sample set is extremely questionable.
If you RTFS, he didn't take a sample, he used all the name servers. There aren't that many (which in itself is a interesting commentary on the true size of the internet) - for the
The interesting part is is the 27 percent that can't be fingerprinted. My guess is that they would follow a similar pattern to the fingerprintable ones but their firewalls block some of the unusual queries.
The reason bind, not djbdns is includedi with every distro is because djbdns can not be distributed in modified/binary form . I don't really agree with it, but hey, thats how Dan J. Bernstein wants it.
Anyway, compiling djbdns is mad easy (unlike qmail) check this out
I use djbdns anywhere I need DNS server.
Exactly. What is so difficult about setting up BIND for an average site? I was able to set up BIND on Woody by installing the package, reading documentation for 15 minutes and then editing a few example zone files. And I have never ever set up a DNS server before (though I know quite a bit about how DNS protocol works).
7 .88:mail.panic.mil.:0h ostmaster.panic.mil::72 00:3600:604800:3600
...) AND learn what the common DNS terminology means. In the BIND case, I only need the common terminology.
Now, I clicked on one of the links in this story and found that to configure tinydns (as an example) you have to learn some strange sendmail-like syntax:
=www.panic.mil:1.8.7.99
@panic.mil:1.8.
Zpanic.mil:dns1.panic.mil:
Heh, WTF? I would have to learn this syntax and how it relates to common DNS terminology (A, CN, MX,
All for all, I'd say BIND is used not only because it's default. It's default and sufficiently easy to use so most people do not feel the need to replace it. As a bonus, if there is a security problem, it is likely to be fixed REALLY fast upon discovery, which is a bit less probable for the other servers (because they are not used as frequently).
Normally I don't like AOL! -messages, but I really want to echo what you say. I used to love qmail back in '98, and love the rest of djb's software too.
After working with his software for some years, I've come to senses. His software is excellent, but he don't maintain it. He maintains that you have to apply a host of third party patches. You cannot modify the sources and redistribute them.
In the long run, it sucks.
Postfix and Exim are my current favorite MTA's. BIND is just the standard dns server. I've considered looking into djbdns - but I'm afraid that I'll burn myself if I try it. I don't trust DJB and his software at all - after watching how qmail has detoriated through non-updates during the last 6 years.
"Rune Kristian Viken" - http://www.nwo.no - arca
Yes and now. Every chemical analysis is basicly guessing, because no substance presents itself: Hey, I am Carbonbihydroxide! There are several tests which can give you a quite conclusive set of clues, what substance you are looking at. "Quite conclusive" in this case means: Better than 0.999999... probability.
That's the same way server fingerprinting works. Run several tests, and each of them increases the probability for one and lowers the probability for others. It gets quite hard to modify a server in a way that it responds exactly like another one (error messages, timing, matchting between OS type and DNS server: You won't find WINS running on OpenVMS that easily.)
Of course it's not definitive. But it gets very close to several nines in probability.
milter, that is.
Um .... tinydns doesn't need to be maintained, because people aren't finding security holes or bugs in it on a weekly basis.
tinydns doesn't even compile on modern GNU/Linux systems. Surely this is a bug in tinydns, isn't it?
Which modern systems are those exactly? I've never had any trouble getting it to compile...
... surely that's just because there's been nothing to change about it? Are there outstanding bugs?
Systems with a recent version of GNU libc.
When you say unmaintained
It's not bugs, it's lack of features: IPv6 support, CIDR support for dnscache configuration, maybe even DNSSEC even you want to give it a try.
He's also terribly arrogant :-( He often has his reasons for rejecting proposals, but not always and he's very bad on communications.
RFC 1035 (STD 13) describes the format of zone files (which are called "master files" in this document).
Not a separate computer, just a separate service. If you're running a public DNS service, you really should allow only recursive or authoritative queries. If you must service both, have the authoritative service listen on a 127.0.0.x IP and have the recursive one query that for the domain in question. But unless you're an ISP, there's really not a good reason to have your public nameserver handle recursive queries.
:-)
Here's a bit more discussion of why it's a good idea to split your DNS. But like I said, it doesn't have to be a separate computer, just a different interface
.sig: file not found
While bind may not be "super simple moron proof", It's also not that frigging hard either. Add on top all the various GUI management tools for it that make it not hard at all. Looking at some of the zones managed by clueless Windows (and linux) administrators using Active Directory or other tools, it's clear that some people need to read the O'Reilly DNS and BIND book. There is more to DNS than the server software - you need to understand WHAT the records do, and HOW to use them correctly. You also need to know how to use tools like dig and nslookup. Bind is only one part of the equation, and it's just not that hard to learn. While there are a lot of options, most people won't need but a few. There are MANY MANY good examples and tutorials.
Bind is also rock solid. It doesn't die. I have servers that run bind that have been running for YEARS without a reboot, and bind has never needed to be restarted. The answer is quite simple. It's not THAT hard, and it works. Why change? Occasionally someone will find a security hole, so you patch and move on, just like everything else.
It does compile out of the box on modern systems. I use it for 5 different domains that I administer. The latest time I set it up, it was on a Gentoo Linux box, I just had to emerge the package and was good to go.
In this case, you don't use the official version of tinydns, but a modified one which contains random patches. Others have patched GNU libc to increase interoperability with broken applications such as tinydns, too.
It is maintained, but the author doesn't see a pressing need for any changes to its functionality. It's simple, secure, and does everything an authoritative dns server should do correctly.
The official version does not support IPv6, for example.
I don't know what third-party documentation you're referring to, but most people just read how to configure it from the djbdns official site at http://cr.yp.to, which suggests no bad configurations.
The way serial numbers for zones are automatically generated by tinydns is not universially accepted.
It depends on what you mean by lazy.
Ever see someone toss a coat on the floor rather than hang it up, and then go back later to hang it up anyway?
That's not laziness. That's called "time management".
Mandrake has shipped Postfix as the default MTA for years (since at least the 7.x days). I much prefer Postfix to Sendmail, which is one of the reasons why I mainly use Mandrake instead of Red Hat. I am lazy too... :-) I could install Postfix on Red Hat and tweak a lot of other things to be the way I like them (I've been using Linux since the kernel 0.99 days), but Mandrake out of the box is much closer to the way I like things.
what does sendmail offer you that exim doesn't
:-)
As someone who used to run sendmail (from the late 80's to 2002 before switching to exim) it gives you native support for UUCP!! It also gives you good brain excercises so you can do things like complex regular expressions, the US tax code, etc.
Seriously, if you really need to customize sendmail, you need to understand the rewrite rules in depth which are quite bizzare to someone not familiar. Adding additional functionality like sql DB lookups for virtual users with SMTP Auth, etc. can be a challenge for even the more seasoned sendmail admin. Once you get beyond the simple soho stuff, sendmail becomes quite awkward to work with. Sendmail Milter's is a horrible interface. Add on message archiving, spam / virus filters, special handling for certain addresses / domains, etc. and exim really starts to look good. Unless you are a full time mail administrator, you probably have better things to learn than sendmail syntax, and that's the bottom line.
Bind is no sendmail. Bind's syntax is actually quite clean - more like apache or exim than sendmail. There are no bizzare ruleset's to learn - it's more like defining a structure in C.
Umm, Florian, couple of questions here:
1) Unmaintained? Well, if it's feature complete (does what the author and its users need), and hasn't been shown to have any serious bugs or exploits, what's to maintain?
2) Doesn't compile out of the box on "modern" systems? Excuse me, but doesn't OpenBSD 3.4 count as modern? I sure didn't have to do anything special to get it working there. Got an example?
3) Non standard zone file format? Well, for me the tinydns format is a helluva lot more readable, and less error prone. No serial number incremeting, no missing closing braces, etc.
4) Can't really say anything about the length of the answers returned, so I have to defer to you on that. But can you show me which 3rd-party docs tell you to do something "that violates recommendations of TLD operators and most ISPs"? Are we talking about this site? Or someone else?
I'm not one of DJB acolytes here; I just was able to understand DJB's docs and examples a lot faster than any of the BIND howtos I saw, and it looked like there would be fewer pitfalls. And yes, on the license thing, I'd like to see him release it under something more permissive, but for now:
A) It does what I want, and
B) I can satisfy myself that the software's reasonably secure.
That's enough for me. I was just hoping you could clarify some of what you'd said... Thanks!
As it is, I read the "quick how-to" files on setting your system up to work with djbdns, and find them far more confusing than BIND zone files and configuration files ever were. You don't just have to worry about one program - unless you're ONLY running the caching server.
This doesn't mean I'm not looking at alternatives... I dislike having to restart all the servers every time I add a domain, and having to restart the master every time I modify a domain, with BIND.
Yeah, except for the fact that (a) it's then incredibly difficult to allow customers to manage DNS on their own - something that I've come to really appreciate (we have several customers who host their DNS with us, but want to manage their zone contents themselves), and (b) the way that software like cPanel does it is not a good solution (we have one customer who handles his own DNS on a box running cPanel, and I'm regularly having to fix that for him). Also, (c) the half-way solutions of making a database, and using a bunch of scripts to regenerate the zone files periodically is always a mess - if the scripts should break, updates don't get applied, but if they do, hand-editing the zone files isn't a viable option.
I use PowerDNS for our DNS servers at work, and I and our customers are very pleased with it. We have a frontend (that I wrote) that integrates with our billing system, so users can log in and make changes to their domains, and have them take effect immediately. They never have to worry about trailing dots, domain serial numbers, or getting the SOA format right, not to mention multiple CNAMEs assigned to a single name (which will cause BIND to throw the zone out) or other mistakes like that - our frontend prevents errors like that. It's made DNS provisioning and management so much easier - provisioning is error-free now. Why would anyone want to use BIND? Seriously?
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
> This was BIND 9.2
That was probably the problem! BIND 9.x is much(!) worse than BIND 8.x at reading config files. We converted 19,000 domains over to 9.x last summer, and it took us about 8 man-months to do it. We even bought a support contract from the ISC. Their (useless) reply was always to just attempt to start BIND then try to decode the error logged, rinse and repeat. That's unbelievably tedious when you have over 200,000 lines worth of config files, and the error messages usually are very vague or just plain wrong. They worked just fine with BIND 8.x! Some of the files hadn't needed changing since last 1995! This was an upgrade that should have taken an afternoon, but because of the regression in the parser in BIND 9.x, it took about 320 times that long. A big FU to the ISC for so horribly messing-up the config file parsing in BIND 9.x!
Did you RTFA?
Because there it says:
70.105% 24,335,752 BIND
15.571% 5,405,266 TinyDNS
That must account at least for some exposure...
the only real quirks are that postfix uses about a dozen different files for different purposes / subsystems in the herd of daemons that make it up, and that a few of 'em have to be "byte-compiled" into berkeleyDB format to improve access speed before the daemons proper will read 'em. getting used to these is no harder than getting used to djb's, shall we generously call it, unusual mindset on what makes a config file good.
and, frankly, several of djb's config files look a lot more like sendmail.cf to me than any of postfix's ones. it's the same machine-readability-über-alles principle in 'em both, if you ask me. postfix generally doesn't play that mindgame on you, certainly not nearly as much.
I know the problem, and i have a solution
A) the maintainer is a dink, and won't upgrade, plus the interested parties seem to like to whine and complain about weird craziness and misnamind of files (both problems non-existent IMHO) instead of upgrading. There's a bug about the compile problem, solaris only, as i remember. Why is it out of x86 then? Exactly. Gentoo was once great for being more current than anyone, but has been slipping, sometimes severely, as in this cae.
B) use the -U flag. like so "emerge -Upv world"
That -U is upgrade-only. I use it all the time, that way portage doesn't downgrade. Also, yes, 9.2.3 has been out for something like 8 months now, using 9.2.2 is starting to look downright silly.
You may use it at home.. That's it. I would not call powerful DNS server which does not have idea about zone-transfer requests, inverse queries, non-Internet-class queries (queries list from DJB's page).
As for qmail - it's pretty inconvenient to patch it every time I need any new functionality. Qmail is pretty simple and doing complex things is quite frustrating with it.