[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
scheme?
> > 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