[Opendnssec-develop] Re: [OpenDNSSEC] #13: "engine: no new signatures, keeping zone" when changing zone parameters

[Stephen.Morris at nominet.org.uk]

Matthijs Mekking <matthijs at NLnetLabs.nl> wrote on 01/09/2009 13:08:47:

> > Hi,
> > 
> > Picking op this ticket. Not sure what to do.
> > 
> > The report is two-fold.
> > 
> > 1.
> > What to do if the signer engine is presented a new SignerConfiguration
> > but no new signatures need to be created. Should we keep the old zone 
or
> > should we force a new output zone?
> > 
> > In my point of view, we should only output a new zone if new 
signatures
> > where created. So, for example an increased signature refresh value 
does
> > not necessarily result in a new output zone.
> 
> Currently, it forces new signatures when a new SignerConfiguration is
> detected.

I would have thought that would be OK.  How often is the signer 
configuration likely to change once the system is in operation?



> > 2.
> > What to do when signer_engine_cli sign <zone> is called. Should we 
force
> > a new output zone or only if new signatures are created?
> > 
> > In my point of view, again, we should only output a new zone if new
> > signatures are created. If the SOA serial changed, we should only 
output
> > a new zone if the SOA/Serial is equal to "keep".
> 
> Currently, the old zone is kept if only the SOA serial changes
> (regardless of the SOA/Serial value).

I think we should force a new output zone: the user has requested that a 
signing operation be performed and so we should do it.  We could always 
add a flag to the command (or add a new command) that will only output the 
zone if new signatures are created.

However, bear in mind one special case: the OpenDNSSEC data flow is:

   Unsigned zone -> Signer -> Signed zone -> Auditor -> Nameserver

What happens if an insecure delegation is added to the unsigned zone and 
the zone is signed using NSEC3?  No new signatures (other than that for 
the updated SOA) have to be created, but signer needs to propagate the new 
information through to the nameserver.

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