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 hadany 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 Paulus JakePaulus at gmail.com
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 at 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 this1. 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. -- Thanks http://www.911networks.com When the network has to work
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. :-) -- Florin Andrei http://florin.myip.org/
Message-ID: <4991E3B7.6090503 at andrei.myip.org> On: Tue, 10 Feb 2009 12:29:43 -0800, Florin Andrei <florin at andrei.myip.org> wrote:>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. > > 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.With one very large caveat. Be aware that updating bind via yum can result in your existing bind configuration files being renamed to something.rmpsave and your name server left in a dysfunctional state. I suggest that you consider excluding bind from normal updates and only update it when you are ready and able to check for possible configuration issues. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
James B. Byrne wrote:> > Be aware that updating bind via yum can result in your existing bind > configuration files being renamed to something.rmpsave and your name > server left in a dysfunctional state. I suggest that you consider > excluding bind from normal updates and only update it when you are > ready and able to check for possible configuration issues.Or put those files under Cfengine or Puppet and have auto-yum work with the config management system. But yeah, I agree, if the number of systems is small (so config management is not justified), avoid doing auto-updates to the critical components. -- Florin Andrei http://florin.myip.org/
Message-ID: <VA.000036bd.05799d0c at news.conactive.com> On: Thu, 12 Feb 2009 10:31:23 +0100, Kai Schaetzl <maillists at conactive.com> wrote:> > Ian Forde wrote on Wed, 11 Feb 2009 20:01:21 -0800: > >> locate rpmsave >> locate rpmnew > > rpmsave is left from *un*installations, rpmnew is the *new* file, > there is no file overwritten. rpm usually doesn't overwrite files > if they got changed. And I haven't seen any overwrites with all > the bind updates in the past months. So, I cannot back James' > claim. > > KaiI cannot answer whether this situation is still the case, and I know that it was not always the case, but on the last but one update to bind my configuration files were all renamed to .rpmsave and there were no .rpmnew files created, only the default config files left in place of the old ones. I also believe, be cannot be sure, that this particular revision was a "minor" (9.X.y) as opposed to "tiny" (9.x.Y) update. I also believe that the same thing happened on the last update as well but, as I now do bind updates far more circumspectly, I may simply be confusing the present remedy with the original problem. In any case, the problem was not expected and it caused considerable grief until the problem was identified and the cause determined. It is just something that anyone hosting their own DNS should consider. The consequences of a dysfunction name server can be quite severe and can initially evidence itself in places that one would not immediately associate with DNS issues. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3