<tt><font size=2>Rickard Bondesson wrote on 08/18/2009 01:10:51 PM:<br>
<br>
> > Do you mean to say here that a zone with very static data <br>
> > never needs to be resigned, like f.e. a key rollover ?<br>
> > I think a static zone needs regular resigning as well, and <br>
> > there are simply 3 situations:<br>
> > -Zone changes occur faster than resigning, and faster than <br>
> > publishing -Zone changes occur faster than resigning, but <br>
> > slower than publishing -Resigning occurs faster than zone changes<br>
> > <br>
> > There are situations where changes to a zone are accepted, <br>
> > but not resigned because it's not publishing time yet.<br>
> > I think that's the parameter to play with. Signing only needs
<br>
> > to be done when it's publishing time, or when a rollover is sceduled.<br>
> > <br>
> > Antoin Verschuren<br>
> <br>
> What I mean is that a zone should not be published if we have not
<br>
> received a new serial (since the last signing) when we are in the
<br>
> "SOA keep"-mode. Refreshed signatures may be created but
not <br>
> published in this case.<br>
</font></tt>
<br><tt><font size=2>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
filetransfer.</font></tt>
<br>
<br><tt><font size=2>So far the theory.</font></tt>
<br>
<br><tt><font size=2>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. </font></tt>
<br>
<br><tt><font size=2>Roy</font></tt>