[Opendnssec-develop] DelegationSignerSubmitCommand

Sion Lloyd sion at nominet.org.uk
Wed Dec 8 15:16:00 UTC 2010

On Tuesday 07 Dec 2010 5:38:10 pm Rickard Bellgrim wrote:
> On 7 dec 2010, at 06.49, Sion Lloyd wrote:
> > The problem with not passing the old key is that if the "--no-retire"
> > flag is issued to the ds-seen command then the key will be left in the
> > zone but the DS will get removed... But when the
> > DelegationSignerSubmitCommand is called we do not know if this flag will
> > be used or not...
> I think we still have an confusion on what we have the --no-retire for. See
> discussion from 4 March 2010.
> You mention that --no-retire is for those who have overlapping KSKs. But is
> that even possible to do in OpenDNSSEC without hacking in the database?

If you never retire the old key it will always be used... I am not saying that 
this is a good idea, but it is possible.

> So the --no-retire will only delay the current rollover until the
> ksk-retire is given. And since we can only have one flow of keys within
> the zone, then we know that the new key is what we are going to rollover
> to.

If the user doesn't issue the ksk-retire command, either because they forget 
or because they don't want to, then they could just accumulate keys... again I 
am not saying that this is a good idea, just that it is possible.

Should we disable this option if it is not compatible with our rollover 

> > So the question is, what shoud we do?
> > 
> > 1) Pass all records and let the user remove the ones they don't want?
> > 2) Pass just the new record and if the user wants the old one also they
> > have to dig it out themselves?
> > 3) Call DelegationSignerSubmitCommand again when ds-seen is run?
> > 4) Something else?
> > 
> > My first feeling was for (1) as it is easier to drop a record than to
> > produce it. Then I thought (2) as it is consistent with the rollover
> > scheme that we are using... Any ideas?
> I think OpenDNSSEC should know what keys (DS RR) that should be in the
> parent. And that is those who should be sent.
> // Rickard

More information about the Opendnssec-develop mailing list