[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