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.