[Pdns-users] Small site backend recommendations

Leen Besselink leen at consolejunkie.net
Sat May 21 12:34:52 UTC 2011


On 05/21/2011 06:27 AM, Charles Sprickman wrote:
> 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).
>

I find it is usually better to test for ourselfs how it works in our
setup than rely on others. ;-)

Personally I've never seen the gpgsql open a lot of connections which is
where the overhead might be in PostgreSQL (in PowerDNS 3 it is more on
purpose though). PowerDNS has 2 caches if I understand it correctly. One
where the queries are cached and one where packets are cached, both for
a short time. So many clients asking the same question will never go to
the database more than ones.

With your intended setup as long as you test everything and make sure
the SOA-serial is updated when changes are made and a notify is sent to
the slaves that should be fine.

DNSSEC adds key material to the mix and would also need to change those
keys every few weeks or months (depends on your preference) and you have
to make sure the serial gets updated again as well.

> Thanks,
>
> Charles
>
>> Cheers,
>> Ken
>>
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users




More information about the Pdns-users mailing list