Hi Michael, On 6/12/07, Michael Mealling <[EMAIL PROTECTED]> wrote:
Alex, I know that in my situation I needed a DNS server that I could easily modify and that didn't come with a lot of extras. What I was building was a custom synthesizing DNS server for VOIP applications which means I was creating NAPTR records based on business rules. I modeled much of what I did directly on the provider in the Directory project but much of what I needed wasn't there (SNMP agent, query statistics, custom business rules, etc). (BTW, personal opinion: SNMP must die a quick and painful death)
Hehe I'm there right with you! Ready to shoot it :). I think people who are looking at something like this fall into three
camps: 1) People who want a DNS server to replace BIND or some other instance to do what DNS servers do.
Aye! Also I think with ADS we can do some slick things with dynamic DNS and triggers. 2) A well done and maintained set of async DNS libraries for DNS queries Yes this is something that would be nice to have. 3) A DNS server that is capable of high query througput but can easily
modified to handle non-standard DNS applications (synthesized zones, synthesized records, smart caching, etc)
Yes this is something my employer has expressed interest in. They are pretty excited in the possibilities with LDAP virtualization and what this would mean for DNS in terms of synthesized zones and records. They host a lot of sites and which require some interesting fail over scenarios. Triggers, stored procedures and views in LDAP will nicely facilitate these needs when the DNS server backs it's records in a read optimized and search-able directory. IMHO, the PP in Directory handles #1 but includes a lot of things that
most enterprises will have other components to handle. For example, where I'm working now the people who run DNS and the people who run LDAP are in completely different departments, with different standards and different data centers. Having LDAP and DNS in the same app does them no good.
The LDAP protocol can be turned of and just the store can be used. Really this just gives you a bigger advantage over dealing with flat files or some kind of XML. You get the indices and fast search/lookup capabilities with minimal overhead. Basically the default store is backed by JDBM (B+Tree) files. Also if you don't want that we can make it so a store interface can be used and you can use flat files. We can separate LDAP from DNS easily with the proper store interface abstraction. Just some thoughts from having done it already... Aye. My concern is to try to build community around DNS in general and I understand our Light weight [DAP] may not be LW enough. In which case I think it's worth considering how we can make the store more pluggable or even lighter :). Sometimes it's just a matter of not needing the search capabilities and wanting to step away from the LDAP DN syntax and definitely can appreciate that. However if people want to just start over that's their right it would just be a waste IMHO if we cannot work out the issues. Regardless tho there is nothing that says two projects on the same protocol cannot co-exist at Apache. It might even be better in the end. Hope the community picks the best solution for everyone. Regards, Alex
