[Opendnssec-develop] Policy configuration checker

Roy Arends roy at nominet.org.uk
Tue Aug 18 11:23:09 UTC 2009

Rickard Bondesson wrote on 08/18/2009 01:10:51 PM:

> > Do you mean to say here that a zone with very static data 
> > never needs to be resigned, like f.e. a key rollover ?
> > I think a static zone needs regular resigning as well, and 
> > there are simply 3 situations:
> > -Zone changes occur faster than resigning, and faster than 
> > publishing -Zone changes occur faster than resigning, but 
> > slower than publishing -Resigning occurs faster than zone changes
> > 
> > There are situations where changes to a zone are accepted, 
> > but not resigned because it's not publishing time yet.
> > I think that's the parameter to play with. Signing only needs 
> > to be done when it's publishing time, or when a rollover is sceduled.
> > 
> > Antoin Verschuren
> What I mean is that a zone should not be published if we have not 
> received a new serial (since the last signing) when we are in the 
> "SOA keep"-mode. Refreshed signatures may be created but not 
> published in this case.

The SOA serial number has one purpose, and one purpose only... to indicate 
to secondary (or slave) servers that a newer version of the zone is 
available. That means it is only of value if your primary to secondary 
replication mechanism is using AXFR or IXFR. That might not always be the 
case. Several implementations exist where the source of data is a 
database, or where the replication of data between servers occur via 

So far the theory.

In practise, I would not require a re-sign to be a re-publish. Note that 
re-publish might be far more costly than a re-sign, if you have to pay 
secondary services for transit. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20090818/ef523f49/attachment.htm>

More information about the Opendnssec-develop mailing list