Good morning:
We're about to start moving our public DNS to in-house managed servers. My first thought was "Linux + BIND" and we're done. Someone in another business unit's IT dept. has suggested tinydns be used.
From what I could find, it looks like this software hasn't really had
any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this software? It seems to have some strong virtues but maybe not enough to justify using it over BIND just because any Linux admin we hire could be expected to know BIND.
Thanks for your time,
Jake schrieb:
Good morning:
We're about to start moving our public DNS to in-house managed servers. My first thought was "Linux + BIND" and we're done. Someone in another business unit's IT dept. has suggested tinydns be used.
From what I could find, it looks like this software hasn't really had
any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this software? It seems to have some strong virtues but maybe not enough to justify using it over BIND just because any Linux admin we hire could be expected to know BIND.
Thanks for your time,
djbdns is OK - if you have some frontend that prepares the data-files for it. Otherwise, don't bother. Well, the same is true in some way for BIND - if you have more than a dozen or so zones with frequent updates, you'll swear, too. Just different swear-words ;-)
How many zones do you manage, BTW?
Also, if you need IPV6 etc - djbdns is not really predestined for this....
Rainer
On Mon, 9 Feb 2009 10:22:42 -0500 Jake jakepaulus@gmail.com wrote:
From what I could find, it looks like this software hasn't really had
any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this
1. DJBDNS does not need to be maintained: IT'S PERFECT. Bugless, no security hole... and does NOT support IPv6. 2. It's great, works like a rock. 3. Everything you need to know, including winning the loto, is at: http://www.lifewithdjbdns.com/ with all the explanations and the installation is toward the end of the page.
On Mon, Feb 09, 2009 at 07:58:38AM -0800, centos@911networks.com wrote:
On Mon, 9 Feb 2009 10:22:42 -0500 Jake jakepaulus@gmail.com wrote:
From what I could find, it looks like this software hasn't really had
any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this
- DJBDNS does not need to be maintained: IT'S PERFECT. Bugless, no
security hole... and does NOT support IPv6. 2. It's great, works like a rock. 3. Everything you need to know, including winning the loto, is at: http://www.lifewithdjbdns.com/ with all the explanations and the installation is toward the end of the page.
Wasn't it released to public domain along with qmail? Surprised someone hasn't packaged this up for Fedora/EPEL yet if so.
Maybe there was some hesitancy based on questions around its public domain status?
I'm more familiar with BIND, but used djbdns at a previous job and it worked very well.
Ray
Ray Van Dolson schrieb:
On Mon, Feb 09, 2009 at 07:58:38AM -0800, centos@911networks.com wrote:
The problem is that it is not very modular.
You must decided on which features (=patches) you want to incorporate and then build the RPM accordingly.
We use tinydns+dnscache almost exclusively (it's not good if you need to play 2ndary for a true BIND) and are very happy with it.
Rainer
On Mon, Feb 09, 2009, Rainer Duffner wrote:
Ray Van Dolson schrieb:
On Mon, Feb 09, 2009 at 07:58:38AM -0800, centos@911networks.com wrote:
The problem is that it is not very modular.
You must decided on which features (=patches) you want to incorporate and then build the RPM accordingly.
We use tinydns+dnscache almost exclusively (it's not good if you need to play 2ndary for a true BIND) and are very happy with it.
We have been using djbdns for years with excellent results, and user very few non-standard patches (mainly a hack to dnscache to allow it to respond to the world on one of our servers that we allowed customers to use in the mid '90s, and can't change).
We are secondaries for a few hundred BIND domains, and have no problems with that using djb tcpclient axfr-get to pull the data from these under control of a cron job.
We are also provide secondary DNS for many of our customer's sites which run djbdns, and they simply use rsync to copy their zone files to our primary server.
We use the rbldns daemon extensively to handle DNSRBLs.
The data formats for djbdns are quite simple, particularly compared to the ugly kludge of BIND. Setting up forward and reverse DNS for a host for which one is authoritative for the in-addr address requires a single line, at a minimum:
=fqdn:ipaddress:
The startup times are essentially zero, as are updates to remote servers using rsync to copy the tinydns and rbldns data files to our secondary servers.
The version we run on all our Linux systems has been hacked into SRPMS for the OpenPKG portable package management system, and we run it on various Linux distributions, FreeBSD, and OS X.
I don't remember exactly when we started using djbdns, but it was at least 8 years ago. Other than a simple hack I did years ago to have dnscache ignore CVS and RCS directories, it has been dead solid with zero problems.
Bill
Thank you very much for all of your feedback. It really sounds like i got two general replies:
"eh, I wouldn't use it" (a minority) and "We do some complicated stuff to make it meet our needs and we love it." (majority)
For us, ease of management is really key to having success with our technical staff. I think we'll likely stick with BIND.
-Jake
On Mon, Feb 9, 2009 at 1:02 PM, Bill Campbell centos@celestial.com wrote:
On Mon, Feb 09, 2009, Rainer Duffner wrote:
Ray Van Dolson schrieb:
On Mon, Feb 09, 2009 at 07:58:38AM -0800, centos@911networks.com wrote:
The problem is that it is not very modular.
You must decided on which features (=patches) you want to incorporate and then build the RPM accordingly.
We use tinydns+dnscache almost exclusively (it's not good if you need to play 2ndary for a true BIND) and are very happy with it.
We have been using djbdns for years with excellent results, and user very few non-standard patches (mainly a hack to dnscache to allow it to respond to the world on one of our servers that we allowed customers to use in the mid '90s, and can't change).
We are secondaries for a few hundred BIND domains, and have no problems with that using djb tcpclient axfr-get to pull the data from these under control of a cron job.
We are also provide secondary DNS for many of our customer's sites which run djbdns, and they simply use rsync to copy their zone files to our primary server.
We use the rbldns daemon extensively to handle DNSRBLs.
The data formats for djbdns are quite simple, particularly compared to the ugly kludge of BIND. Setting up forward and reverse DNS for a host for which one is authoritative for the in-addr address requires a single line, at a minimum:
=fqdn:ipaddress:
The startup times are essentially zero, as are updates to remote servers using rsync to copy the tinydns and rbldns data files to our secondary servers.
The version we run on all our Linux systems has been hacked into SRPMS for the OpenPKG portable package management system, and we run it on various Linux distributions, FreeBSD, and OS X.
I don't remember exactly when we started using djbdns, but it was at least 8 years ago. Other than a simple hack I did years ago to have dnscache ignore CVS and RCS directories, it has been dead solid with zero problems.
Bill
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186
Those who cast the vote decide nothing. Those who count the vote decide everything. (Joseph Stalin) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, Feb 09, 2009 at 03:07:30PM -0500, Jake wrote:
Thank you very much for all of your feedback. It really sounds like i got two general replies:
"eh, I wouldn't use it" (a minority) and "We do some complicated stuff to make it meet our needs and we love it." (majority)
For us, ease of management is really key to having success with our technical staff. I think we'll likely stick with BIND.
-Jake
Yep. Honestly, both work well. Use whatever you have more expertise or experience in.
Ray
On Mon, 2009-02-09 at 15:07 -0500, Jake wrote:
Thank you very much for all of your feedback. It really sounds like i got two general replies:
"eh, I wouldn't use it" (a minority) and "We do some complicated stuff to make it meet our needs and we love it." (majority)
For us, ease of management is really key to having success with our technical staff. I think we'll likely stick with BIND.
-Jake
Jake,
We are a small company and started using BIND 3 years ago so that we could control local access within the network with local zones for 3 remote sites. Everything on the network works better with your own DNS service. Most of my sendmail problems were immediately solved as well as others. A local DNS is great and BIND was easy for us to use.
Good Luck!!
Greg
centos@911networks.com wrote:
From what I could find, it looks like this software hasn't really had
any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this
- DJBDNS does not need to be maintained: IT'S PERFECT. Bugless, no
security hole... and does NOT support IPv6. 2. It's great, works like a rock.
I've heard that story before about other djb code (qmail). Turned out to be horribly wrong and never fixed, so I'll never trust anything with those initials attached again.
- Everything you need to know, including winning the loto, is at:
http://www.lifewithdjbdns.com/ with all the explanations and the installation is toward the end of the page.
I'd advice planning out a strategy to migrate your zones back to bind if you do go this route. Tinydns does some implicit magic that, if you use, will make someone's life difficult later when they try to figure out how to rebuild bind zone files to do the same thing.
Jake wrote:
Good morning:
We're about to start moving our public DNS to in-house managed servers. My first thought was "Linux + BIND" and we're done. Someone in another business unit's IT dept. has suggested tinydns be used.
From what I could find, it looks like this software hasn't really had
any community drive behind it in a while. The latest RPMs on rpmforge are for red hat 6 and red hat 7. I very much dislike the idea of compiling my own because of all the overhead associated with making sure the system stays up-to-date and so on so this really puts me off already. Does anyone have an opinion on this software? It seems to have some strong virtues but maybe not enough to justify using it over BIND just because any Linux admin we hire could be expected to know BIND.
tinydns supports large zone/record updates on the fly...in comparison with bind which will stop answering while it is loading up zones. The caveat however is that you need GOOD disk i/o if you have a lot of records because tinydns achieves that due to use a cdb database whereas BIND will stick them all in memory. So if you are constantly updating zones, I would suggest tinydns as the entire process can be automated and the source for the cdb database stored in a nice sql database with a nice frontend, script plugin/api for whatever you imagine.
If you don't have very dynamic stuff and you do not need to constantly rebuild zones, BIND should be better I suppose especially if you are in an environment where a lot of zones share the same data (ns, mx,...) thanks to INCLUDE.
As for making sure the system stays up-to-date, you do not have to worry about djbdns and daemontools...they are pretty much set in stone now excpet for maybe some patches that you might want (it's public domain so just roll your own if you do need them patches). All you have to worry about is installing on new systems. It is literally compile once and forget. Zero overhead.
Oh, may I point out that there are no security issues with djbdns whereas BIND has a history of problems even until recently. 'slaves' can be updated with by rsyncing the cdb database over so there is no room for human error with respects to dns server configuration whether it is leaving recursive on or whatever.
Interesting that any Linux admin you can hire will know BIND. I find that not to be the case over here in Hong Kong. I guess there is a reason why Linux is not very popular over here notwithstanding the lack of people who know Linux.
Jake wrote:
We're about to start moving our public DNS to in-house managed servers. My first thought was "Linux + BIND" and we're done. Someone in another business unit's IT dept. has suggested tinydns be used.
Here's the straight dope:
There was a time (circa 2000) when tinydns had a reason to exist. Back then, years ago, Bind was so horribly buggy, you couldn't afford to put it online, unless you were willing to deal with all the trouble. So many people, myself included, used tinydns extensively. It was tiny, fast, easy and solid. Also weird and unlike anything else (except DJB's own software). But we were an ISP and we just couldn't afford to babysit Bind all day long - DNS just had to continue working flawlessly.
But things have changed. Nowadays Bind is solid enough. If you're still worried about security issues (you shouldn't, but I'm assuming the paranoid scenario) then CentOS has a good SELinux policy around it, so just install the latest CentOS, keep SELinux enabled, do a "yum update" every once in a while, and be at peace. By the way, this is also the most sweat-free solution from a sysadmining perspective.
If you're serving a fairly large number of domains, or for some reason a SQL backend seems useful in your case, the alternative you're looking for is PowerDNS, not tinydns.
The way tinydns became obsolete is nothing new. I remember using qmail back in the day - yes, I was a DJB fanboy. It was great, especially at a time when Sendmail had more holes in it than a metric ton of Swiss cheese. But then Postfix came along, and I had no reason to stick with qmail anymore.
Such is the computer industry - licentious and forgetful. :-)
-
Bill Campbell -
centos＠911networks.com -
Christopher Chan -
Florin Andrei -
Gregory P. Ennis -
Jake -
Les Mikesell -
Rainer Duffner -
Ray Van Dolson