Reliable supermaster setup - howto?

[Przemyslaw Wegrzyn-2]

Hi!

I'm quite new to PDNS, I'm considering switching from bind9 to pdns,
mostly for its easy integration with database backend (at the moment our
system uses custom scripts that generate bind config files after each
change). I'm just evaluating simple PDNS setup.

1. I can see that any time serial is updated in the SOA record of the
domain, pdns server discovers the change and reloads the zone. That's
great, however - this is obviously a kind of polling, which
configuration parameter controls the interval of database queries?

2. I'd like to automatically propagate new domains to slave DNS server,
the idea of 'supermaster' looks exactly like what I need. My current
setup sends notifications about zone changes to slave, and my slave
happily configures new zones. However, I'm concerned about situation
when particular notification is lost.  How should the system recover
from that situation?

Cheers,
Przemek
_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Dmitry Banshchikov]

On Fri, 23 Oct 2009 12:54:14 +0200
Przemyslaw Wegrzyn <czajnik@...> wrote:

> Hi!
>
> I'm quite new to PDNS, I'm considering switching from bind9 to pdns,
> mostly for its easy integration with database backend (at the moment
> our system uses custom scripts that generate bind config files after
> each change). I'm just evaluating simple PDNS setup.
>
> 1. I can see that any time serial is updated in the SOA record of the
> domain, pdns server discovers the change and reloads the zone. That's
> great, however - this is obviously a kind of polling, which
> configuration parameter controls the interval of database queries?

Variables packetcache-size and  query-cache-ttl.


>
> 2. I'd like to automatically propagate new domains to slave DNS
> server, the idea of 'supermaster' looks exactly like what I need. My
> current setup sends notifications about zone changes to slave, and my
> slave happily configures new zones. However, I'm concerned about
> situation when particular notification is lost.  How should the
> system recover from that situation?
>

Master-slave DNS synchronization in PDNS is based on database
replication.

--

Dmitry Banshchikov
_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Angel Bosch Mora]

> >
> > 2. I'd like to automatically propagate new domains to slave DNS
> > server, the idea of 'supermaster' looks exactly like what I need.
> My
> > current setup sends notifications about zone changes to slave, and
> my
> > slave happily configures new zones.

forget about all this master-propagates-slaves stuff.

just choose a proper backend and thinkg of pdns as a client that retrieves data.

i use ldap backend and i have lot of 389 Directory Servers replicated. to fire up a new DNS server i just have to copy the confs and start the daemon.

you can do that with mysql, oracle or even create your own replicated backend.

just unBIND your point of view ;)


muzzol

--
Abans d'imprimir aquest missatge, pensau si és realment necessari. El medi ambient és cosa de tothom.

Aquest missatge es dirigeix exclusivament a la persona que n'és destinatària. Pot incloure dades confidencials i/o de caràcter personal, la difusió de les quals es regula mitjançant la Llei orgànica de protecció de dades i la Llei de serveis de la societat de la informació. Si no sou la persona destinatària que s'hi indica (o la responsable de lliurar-l'hi), en cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones. Si heu rebut aquest missatge per error o l'heu aconseguit per altres mitjans, us demanam que ens ho comuniqueu immediatament per aquesta mateixa via i que l'elimineu de manera permanent.


_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Przemyslaw Wegrzyn-2]

Dmitry Banshchikov wrote:
>> 1. I can see that any time serial is updated in the SOA record of the
>> domain, pdns server discovers the change and reloads the zone. That's
>> great, however - this is obviously a kind of polling, which
>> configuration parameter controls the interval of database queries?
>>    
>
> Variables packetcache-size and  query-cache-ttl.
>  
Ah, so the idea is that SOA record is reloaded to the cache whenever it
expires, right?

>> 2. I'd like to automatically propagate new domains to slave DNS
>> server, the idea of 'supermaster' looks exactly like what I need. My
>> current setup sends notifications about zone changes to slave, and my
>> slave happily configures new zones. However, I'm concerned about
>> situation when particular notification is lost.  How should the
>> system recover from that situation
>
> Master-slave DNS synchronization in PDNS is based on database
> replication.
>
>  

I know this is one of the options, but according to the manual using
'supermaster' config and regular DNS zone AXFRs would do the trick. My
idea was to avoid database replication to the slave DNS server, that's
an extra maintenance effort for me.

Cheers,
Przemek


_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Przemyslaw Wegrzyn-2]

Angel Bosch Mora wrote:
>
> forget about all this master-propagates-slaves stuff.
>  
It's behaving so badly, or is unreliable, or not supported by
developers, or... ?
> i use ldap backend and i have lot of 389 Directory Servers replicated. to fire up a new DNS server i just have to copy the confs and start the daemon.
>
> you can do that with mysql, oracle or even create your own replicated backend.
>  
PostgreSQL is our database of choice. I'd need to evaluate existing
replication possibilities or   go with something custom.

Well, actually, propagating the list of domains would do, I expect PDNS
slave to handle zone transfers properly after all.
> just unBIND your point of view ;)
>
>  
Definitely :)

Regards,
Przemek
_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Kenneth Marshall-3]

On Fri, Oct 23, 2009 at 01:47:54PM +0200, Przemyslaw Wegrzyn wrote:

> Angel Bosch Mora wrote:
>>
>> forget about all this master-propagates-slaves stuff.
>>  
> It's behaving so badly, or is unreliable, or not supported by developers,
> or... ?
>> i use ldap backend and i have lot of 389 Directory Servers replicated. to
>> fire up a new DNS server i just have to copy the confs and start the
>> daemon.
>>
>> you can do that with mysql, oracle or even create your own replicated
>> backend.
>>  
> PostgreSQL is our database of choice. I'd need to evaluate existing
> replication possibilities or   go with something custom.
>
> Well, actually, propagating the list of domains would do, I expect PDNS
> slave to handle zone transfers properly after all.
>> just unBIND your point of view ;)
>>
>>  
> Definitely :)
>
> Regards,
> Przemek

The supermaster functionality works well for this. If you are using
PostgreSQL as the DB backend, you may want to consider using the
patch I posted to PDNS giving you the option to configure the zone
commit command. This allows you to use temporary tables to optimize
zone updates on the slaves. There are several samples included with
the patch.

Regards,
Ken
_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Przemyslaw Wegrzyn-2]

Kenneth Marshall wrote:
> The supermaster functionality works well for this. If you are using
> PostgreSQL as the DB backend, you may want to consider using the
> patch I posted to PDNS giving you the option to configure the zone
> commit command. This allows you to use temporary tables to optimize
> zone updates on the slaves. There are several samples included with
> the patch.
>
>  
This leaves my initial  question unanswered - how does such setup
recover from lost notifications from supermaster to slave?

As of PostgreSQL - my idea was to use PostgreSQL on master, and SQLite
on slave, for simplicity, but that would render your patch useless,
unfortunately. Where can I find the patch?

Cheers,
Przemek

_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Kenneth Marshall-3]

On Fri, Oct 23, 2009 at 03:00:08PM +0200, Przemyslaw Wegrzyn wrote:

> Kenneth Marshall wrote:
>> The supermaster functionality works well for this. If you are using
>> PostgreSQL as the DB backend, you may want to consider using the
>> patch I posted to PDNS giving you the option to configure the zone
>> commit command. This allows you to use temporary tables to optimize
>> zone updates on the slaves. There are several samples included with
>> the patch.
>>
>>  
> This leaves my initial  question unanswered - how does such setup recover
> from lost notifications from supermaster to slave?
>
> As of PostgreSQL - my idea was to use PostgreSQL on master, and SQLite on
> slave, for simplicity, but that would render your patch useless,
> unfortunately. Where can I find the patch?
>
> Cheers,
> Przemek
>

The slave will check after the cache period times out. You could
also run a tickle script to check that you do not have any stale
zones. If you are using SQLite on the slaves, you will not need
the patch. The way SQLite implements tables make the normal zone
AXFR transfer process reasonably performant. It was PostgreSQL's
multi-version concurrancy that killed the performance when using
a PostgreSQL backend.

Regards,
Ken
_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Przemyslaw Wegrzyn-2]

Kenneth Marshall wrote:

>> This leaves my initial  question unanswered - how does such setup recover
>> from lost notifications from supermaster to slave?
>>
>> As of PostgreSQL - my idea was to use PostgreSQL on master, and SQLite on
>> slave, for simplicity, but that would render your patch useless,
>> unfortunately. Where can I find the patch?
>>    
>
> The slave will check after the cache period times out. You could
> also run a tickle script to check that you do not have any stale
> zones.

I'm not sure if I understand things right - I'm talking about a
situation when I add a whole new zone to the master server, and I'd like
the slave server to add it automatically as well. The zone is not yet
configured on the slave, so it will not ask for that. It only asks when
notified by master. So the only way to make it reliable, I suppose, is
to repeat the notifications form master, until a successful AXFR to
slave occurs.
>  If you are using SQLite on the slaves, you will not need
> the patch. The way SQLite implements tables make the normal zone
> AXFR transfer process reasonably performant. It was PostgreSQL's
> multi-version concurrancy that killed the performance when using
> a PostgreSQL backend.
>  
Ah, clear now. Thanks. From the previous post I wasn't exactly sure what
this patch is supposed to do.

Cheers,
Przemek
_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users

[Frank Louwers]

On 23 Oct 2009 wk 43, at 15:17, Przemyslaw Wegrzyn wrote:

> Kenneth Marshall wrote:
>>> This leaves my initial  question unanswered - how does such setup  
>>> recover from lost notifications from supermaster to slave?
>>>
>>> As of PostgreSQL - my idea was to use PostgreSQL on master, and  
>>> SQLite on slave, for simplicity, but that would render your patch  
>>> useless, unfortunately. Where can I find the patch?
>>>
>>
>> The slave will check after the cache period times out. You could
>> also run a tickle script to check that you do not have any stale
>> zones.
> I'm not sure if I understand things right - I'm talking about a  
> situation when I add a whole new zone to the master server, and I'd  
> like the slave server to add it automatically as well. The zone is  
> not yet configured on the slave, so it will not ask for that. It  
> only asks when notified by master. So the only way to make it  
> reliable, I suppose, is to repeat the notifications form master,  
> until a successful AXFR to slave occurs.

AXFR's are so 20-th century :)

No really, try other schema's if you can. Let me explain you our pdns  
setup.

We have one master database that contains all profiles. From that db,  
a script generates the actual zones every 10 minutes. These are stored  
in the PDNS Master database on our primary nameserver, using the MySQL  
backend.

NS2 and NS3 use MySQL replication to replicate that master DB.

This means that if a new zone is added and committed to the NS1 PDNS  
Master MySQL db, it is automatically available on NS2 and NS3. No need  
to configure anything on ns2/ns3, no need for AXFR, etc.

For customers that run BIND, we use the "supermaster" functionality as  
follows.

Primary BIND of the customer (CUST-NS) configures the zone, and  
notifies our NS1. Our NS1 gets the NOTIFY, sees that it doesn't know  
anything about the zone, sees that CUST-NS is a configured  
supermaster, and it will AXFR the zone from CUST-NS and commit it to  
it's own master MySQL db. Again, MySQL replication takes care of  
distributing the zone to NS2 and NS3.


Regards,

Frank Louwers
Openminds bvba
_______________________________________________
Pdns-users mailing list
Pdns-users@...
http://mailman.powerdns.com/mailman/listinfo/pdns-users