[Pdns-users] Small site backend recommendations

Charles Sprickman spork at bway.net
Sat May 21 04:27:31 UTC 2011


On Thu, 12 May 2011, ktm at rice.edu wrote:

> On Thu, May 12, 2011 at 03:37:24AM -0400, Charles Sprickman wrote:
>> Hello,
>>
>> We've been using the PDNS recursor for some time now and have been quite
>> happy with it.  It replaced dnscache and has proven to perform much better.
>>
>> We're now looking at moving away from tinydns, mainly to get IPv6
>> support without patching and to get started with DNSSEC.  I don't see us
>> with more than a few thousand zones anytime soon, and we aren't looking
>> at anything above 1000 qps (across three servers) anytime soon.
>>
>> I'm not sure I completely understand the PowerDNS philosophy quite yet,
>> but it looks like BCP is to run a db server on each name server
>> (postgres or mysql).  This feels a little too heavyweight for us.  What
>> might be some interesting options?  Would something like one master with
>> a "real" db backend (in our case PostgreSQL) and then two slaves running
>> SQLite work well?  Is there anything "lighter" than SQLite that we could
>> stick on the slaves?  Is the SQLite backend well-supported?
>>
>> Any pointers greatly appreciated.  We are committed to a database-backed
>> DNS server (we currently have a script that dumps db data to a tinydns
>> data file), and there do not seem to be that many actively-developed
>> options out there...
>>
>> Thanks,
>>
>> Charles
>
> Hi Charles,
>
> The advantages to having a db for each server is redundancy. A single
> server can easily serve 10X you expected load on a single box. I addition
> using db replication to move the updates around provides for a much more
> real-time process across all of your systems.

I do understand the general concept, but going from scp'ing a tiny .cdb 
file around to running a full-blown PostgreSQL instance on each nameserver 
just feels a little bit too "heavy" for us.  SQLite is certainly a little 
simpler and less resource-intensive.

I've been running through the docs again, and I'm finding there's a bit of 
a lack of "best common practices" sort of information.  So what I'd really 
like to get some feedback on is whether the following should work 
properly, especially given the (comparatively) small number of queries 
we'll be serving:

-One server as master/supermaster that is backed with gpgsql backend that 
will be where all records are added/deleted/changed.  This may also be a 
"hidden" master at some point as we change our general provisioning setup.
-Two servers as slaves using the gsqlite3 backend.

If I've understood the documentation correctly this should (at least in 
theory) work.  We add a zone on the supermaster and the slaves, even 
though they are running a different backend, will be notified of the new 
zone and fetch it via axfr.  Changes in existing zones are also fetched 
via axfr.

My only concerns after looking at the docs is whether the gsqlite3 backend 
is thoroughly tested and whether using traditional master/slave and axfr 
will lead to any issues with the servers being out of sync with each other 
(since it seems most pdns installations are larger and have gone with a 
full-blown db w/replication for each server).

Thanks,

Charles

> Cheers,
> Ken
>



More information about the Pdns-users mailing list