[Pdns-users] Supermaster and superslave automatic provisioning

a b tripivceta at hotmail.com
Thu May 24 21:34:59 UTC 2012


> One reason is that this supports setups of the following type:
> - ns01 is a powerdns machine in slave mode, slaving domains from other machines.
> - ns01 stores all slaved zones in a database (MySQL, Oracle, etc.) which is replicated to one or more database slaves
> - ns02/ns03 use these database slaves in readonly mode.
> 
> In this case, all three name servers see 'type=SLAVE' on many domains in the domains table, but only one of them should actually be slaving.

Understood, but the decision whether any given DNS server is a master or a slave is data driven, via the SOA and NS records, as well as the "supermasters" table.

With that in mind, could the logic in pdns_server not have been:

"if I am listed in the NS record,"
AND
"I am not in the supermasters table,"

"I must be a slave DNS server".

There is enough information in the schema to deduce correct behavior, no?

Is the following possible:

Server1 runs a database.  Server1 is configured as a  supermaster
stricly  via  INSERT  statements in the database, via SOA, NS and
"supermaster" records.   Server1  contains  NS  records  for  the
(super)slaves.   Server1  contains  SLAVE  type  records  in  the
"zones" table.

Server2 runs a database.  Server2  has  a  completely  empty  yet
correct schema.

Upon doing a COMMIT on Server1, will it send AXFR to Server2,  or
is there a way to accomplish that 

a)  without  configuring  "master=yes"   on   the   master,   and
   "slave=yes" on the slaves
and
b) without using native database replication?

If that is not currently possible, how does  one  programatically
determine what the server is going to become at database / schema
creation time? Our goal is to never have  the  database  creation
and configuration nor the configuration file modified by a human,
ever, for any reason.

It is unclear to us from the documentation whether this is possible.
 		 	   		  


More information about the Pdns-users mailing list