[CentOS] new CentOS 5 as DNS server

Feizhou feizhou at graffiti.net
Fri Aug 3 23:20:04 UTC 2007


Ken Price wrote:
> 
>>> I'm coming in late to this thread.  We too are a hosting provider  
>>> (small time), hosting approximately 1600 live domains.
>>>
>>> Not to say tinydns is a bad alternative, as it has it's strengths,  
>>> but we moved away from [outgrew] it 2 years ago.
>>
>> I used to work for a messaging service provider and they had two
>> systems. The first system was the service provider offering its
>> messaging platform for its own domains and a hundred or so domains for
>> quite a lot of clients and these were managed with BIND by hand.
> 
> eek.  i can imagine that was a pain.

In the beginning it sure was.

Good thing BIND has this $INCLUDE thing. That reduced the amount of work 
after I cleaned up the mess from the previous configuration maintainer.

> 
>>
>> So I do not know how you 'outgrew' tinydns. After all the only part
>> that involves tinydns is 'generate the cdb file from a database for
>> tinydns to chew' or in other words, generating the cdb file for tinydns
>> is the least of your problems to tackle.
> 
> Look, in no way was i bashing TinyDNS or starting a flamewar.  This is 
> why i prefaced my comment with "Not to say tinydns is a bad alternative, 
> as it has it's strengths".  By "outgrew" i mean we required more of our 
> DNS server.  We weren't a top level domain provider.  Our clients 
> required authoritative and sometimes secondary service.  As a result, we 
> required better RFC compliance and a broader range of features then 
> TinyDNS provided.  That's all.  Our business simply required greater 
> flexibility.

You should have come out with this in the first place. Stating 1600 
domains as a hosting provider and then not clearly stating the technical 
reasons on why you had to switch away from tinydns looks like a veiled 
snipe at djbdns.

If anybody dares insinuate ease of use, performance or security reasons 
for not using djbdns, I am going to grill them because 'I' have tried to 
find something to replace dnscache, which has this knack of not caching 
CNAME records and hammering the authoritative servers of a zone when it 
receives multiple new requests for records in that zone before it gets 
an answer, and I have yet to find anything that is as scalable as 
dnscache despite its annoying shortcomings.

> 
> Generally, your business needs should determine the solution.  Not the 
> other way around.

Agreed.



More information about the CentOS mailing list