[Pdns-users] Regarding secondary zones

[Lorens Kockum]

On Mon, Apr 25, 2005 at 02:00:10PM -0400, David Taylor wrote:
> I'm not sure I fully understand and would like some clarification on how
> I expect secondary zones to work.  We are going to be using PDNS with a
> native replication configuration.  The backend will be the generic-mysql
> backend.  So all of our primary zones will be loaded as NATIVE by
> default.  But the secondary zones will need to be loaded as SLAVE with
> their primary NS listed under the master field.  Correct so far?

No :-) You say you are going to use native replication, then you
describe the DNS AXFR replication.

In native replication, the databases are identical on all
servers, the type is "NATIVE" everywhere, and somebody other
than PDNS makes sure the databases are synced. That somebody is
presumably native database replication.

In traditional bind-style DNS AXFR replication (there may be
another name for that), the master server has NATIVE zones, and
the slaves have slave zones. In this style you can mix pdns
servers with bind servers and other types of compatible servers.

Discussion on DNS AXFR replication follows.

> In this configuration, will PDNS automatically try to perform a zone
> transfer for the zone file of any secondary zone we enter into the DB?

Yes.

> Or would we either need to do this manually or tell PDNS to do this?

If you configure the master as supermaster (enter the master's
IP in the supermaster table on the slaves, see supermaster doc),
then when you configure a zone on the master, the master will
tell the slaves about it using DNS NOTIFY, and the slaves will
say "hey my supermaster is telling me about a zone I don't have
yet, but since he's my supermaster I'll set up the zone".

I suppose the supermaster could be a bind server, but I'm fairly
sure bind hasn't implemented superslave capability as described.

You never have to touch the superslave configuration again
except if you want to remove old zones (this could be made
automatic too... hint, hint ;-)

Caveat: sometimes the dns notify gets lost. It is, after all, a
single UDP packet (I hate the way MPLS drops the first packet
in a conversation, which is what I attribute most of this to,
but I also have the problem when there are say a thousand
notifications to send out at once). If it gets lost on an
initial notify, there is no record on the slave that makes sure
that the slave checks every so often to make sure that the zone
is fresh. I've been thinking that if the master logged transfers
(or rather SOA serial checks) from slaves to the database
instead of just to syslog, then it could check that notifies to
slaves were followed by transfer requests inside a reasonable
amount of time, and maybe log it at a higher level if the slave
continues to play dumb.

HTH