[dns-operations] PowerDns Recursive Daemon

[Michael Sinatra]

Paul Vixie wrote:
>>> switching hats for a moment, is there anything isc could do to make bind9
>>> more useful or attractive to you?  granted that we make no money from the
>>> software itself (only development and support contracts), i'm nevertheless
>>> concerned about any reasons you'd have for switching away from it.
>> The ability to answer directly from a transactional database that spoke SQL
>> was why PowerDNS was selected to replace BIND at the client where I built
>> out a service around it.
> 
> sure, but that's on the authority side.  (and, BIND9 can do it, using DBZ,
> which was no doubt inspired by PowerDNS.)  what we're talking about here on
> this thread is a "PowerDns Recursive Daemon" (according to the Subject:).
> 
>> Now, the whole SQL thing makes it hard to push huge amounts of queries per
>> second, but makes it easy to scale horizontally without worrying about
>> coherency.
> 
> as far as i know, both PowerDNS and BIND9+DBZ use a hot spot cache to avoid
> hitting the SQL overly often.  but i don't use either myself, so i could be
> way out to lunch on that.
> 
>> I'll let someone else address the benefits of using some other more
>> lightweight form of db instead of zonefiles.
> 
> if someone wants to open a separate thread on authority data from SQL, i'd be
> keenly interested in reading and participating.  but the question here is not
> that question.

I can't speak to the original poster's motivations, but I think one 
motivation would be code diversity.  I don't know how big an issue this 
is on the recursive side, as much as it is on the authoritative site. 
But I can imagine that for big enterprises and ISPs, you would want to 
have your recursors be as reliable as possible, and code diversity plays 
to that (assuming you can deal with the added complexity of supporting 
two applications that do the same thing).  On the authoritative side we 
have nsd as a very viable open-source alternative, and I know people 
have asked in the past about code diversity on the caching side.

michael