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)
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.
2) A well done and maintained set of async DNS libraries for DNS queries
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)
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.
Just some thoughts from having done it already...
-MM
Alex Karasulu wrote:
What about working on the DNS protocol provider we have in Directory?
Let's
grow community around this. The barrier of entry to existing ASF
committers
from
MINA should be minimal.
What's the benefit of starting yet another DNS server effort? Furthermore
are there
issues with the DNS PP in Directory?
--
Michael Mealling Refactored Networks, LLC
CEO & President 1645 Old Hwy 41
Office: +1-678-581-9656 Suite 112, Box 138
Cell: +1-678-640-6884 Kennesaw, GA 30152
http://refactored-networks.com/
