[Opendnssec-user] What's difference between usage of ODS2x DelegationSignerSubmitCommand & DelegationSignerRetractCommand ?

[PGNet Dev]

The ODS 2x docs @

https://wiki.opendnssec.org/display/DOCS20/conf.xml#conf.xml-DelegationSignerSubmitCommandandDelegationSignerRetractCommand

state for both of these commands the exact same functional decscription,

"<DelegationSignerSubmitCommand> Configure the
<DelegationSignerSubmitCommand> if you want to have a program/script
receiving the new KSK during a key rollover.

and

<DelegationSignerRetractCommand> Configure the
<DelegationSignerRetractCommand> if you want to have a program/script
receiving the new KSK during a key rollover."

and provide NO further clarification of the differences in usage &
timing of these commands.

What are the trigger conditions / different usage for

<DelegationSignerRetractCommand>

vs

<DelegationSignerRetractCommand>

?

Are they both triggered automatically based on internal key state?
Which, specifically? And what's relative timing?

Or do they fire only on a manually executed cmd line trigger?

[Yuri Schaeffer]

Post by PGNet Dev
What are the trigger conditions / different usage for
<DelegationSignerRetractCommand>
vs
<DelegationSignerRetractCommand>
Are they both triggered automatically based on internal key state?
Which, specifically? And what's relative timing?

These are fired automatically. Based in the internal state. specifically:

When a new key is introduced and the enforcer deems it ready for
inclusion in the DS RRset at the parent the
DelegationSignerSubmitCommand will fire.

Each KSK has a DS state which is one of

typedef enum key_data_ds_at_parent {
KEY_DATA_DS_AT_PARENT_INVALID = -1,
KEY_DATA_DS_AT_PARENT_UNSUBMITTED = 0,
KEY_DATA_DS_AT_PARENT_SUBMIT = 1,
KEY_DATA_DS_AT_PARENT_SUBMITTED = 2,
KEY_DATA_DS_AT_PARENT_SEEN = 3,
KEY_DATA_DS_AT_PARENT_RETRACT = 4,
KEY_DATA_DS_AT_PARENT_RETRACTED = 5
} key_data_ds_at_parent_t;

A new KSK will start at KEY_DATA_DS_AT_PARENT_UNSUBMITTED. Then at some
point it is ready to be submitted and will move to
KEY_DATA_DS_AT_PARENT_SUBMIT. If no DelegationSignerSubmitCommand is
specified in the conf it will stay there until the user issues a 'key
ds-submit'. If it is specified the script will fire. Either way the
state will then go to KEY_DATA_DS_AT_PARENT_SUBMITTED and stay there.
You should see a 'waiting for ds-seen' in your keylist. The user is
supposed to issue a 'key ds-seen' when the DS record of this particular
key is visible to the world.
Then, at some point this key is to be removed. The process is similar
and the key will transition to KEY_DATA_DS_AT_PARENT_RETRACT. Then after
a manual 'key ds-retract' or an automatic DelegationSignerRetractCommand
the state will be KEY_DATA_DS_AT_PARENT_RETRACTED. Now you should see
'waiting for ds-gone' until the user does a 'key ds-gone', at which
point the state will be KEY_DATA_DS_AT_PARENT_UNSUBMITTED again.

Post by PGNet Dev
And what's relative timing?

This depends on the rollover strategy, kasp parameters, TLLs on
different records (including negative), signer parameters, whether it is
an algorithm rollover and how fast the user interacts. I can't give you
a straight answer to this. It is a hard problem for which the enforcer
is designed to solve.

Regards,
Yuri

[PGNet Dev]

Post by Yuri Schaeffer

Post by PGNet Dev
What are the trigger conditions / different usage for
<DelegationSignerRetractCommand>
vs
<DelegationSignerRetractCommand>
Are they both triggered automatically based on internal key state?
Which, specifically? And what's relative timing?

When a new key is introduced and the enforcer deems it ready for

...

This is an immensely helpful write up.

https://tools.ietf.org/html/rfc7583 is too, but obviously doesn't
address the ODS_specific bits.

It'd be quite useful to include it, or some similar variant, in the ODS
2 online docs.

Post by Yuri Schaeffer
You should see a 'waiting for ds-seen' in your keylist. The user is
supposed to issue a 'key ds-seen' when the DS record of this particular
key is visible to the world.

IIUC there is no current "wait for ds-seen" mechanism or script hook in
ODS 2.1.x, is there? I.e., needs to be done externally (cron job, etc)?

Post by Yuri Schaeffer
Then, at some point this key is to be removed.

Ok. So, kasp-schedule driven ...

Post by Yuri Schaeffer

Post by PGNet Dev
And what's relative timing?

This depends on the rollover strategy, kasp parameters, TLLs on
different records (including negative), signer parameters, whether it is
an algorithm rollover and how fast the user interacts. I can't give you
a straight answer to this. It is a hard problem for which the enforcer
is designed to solve.

Similar to rfc7583,

3. Key Rollover Timelines ..........................................8
3.1. Key States .................................................8
3.2. ZSK Rollover Timelines ....................................10
3.2.1. Pre-Publication Method .............................10
3.2.2. Double-Signature Method ............................12
3.3. KSK Rollover Timelines ....................................14
3.3.1. Double-KSK Method ..................................14
3.3.2. Double-DS Method ...................................17
3.3.3. Double-RRset Method ................................20
3.3.4. Interaction with Configured Trust Anchors ..........22
3.3.5. Introduction of First Keys .........................24

it'd be useful to evolve the ODS docs to descriptively parallel some
subset of those strategies, identifying recommendations/best-practices
best suited for ODS2's enforcerd design.

Thanks!

[Yuri Schaeffer]

Post by PGNet Dev
IIUC there is no current "wait for ds-seen" mechanism or script hook in
ODS 2.1.x, is there? I.e., needs to be done externally (cron job, etc)?

Yes. So a possible solution would be to have the
DelegationSignerSubmitCommand upload the DS and then initiate a cron job
that polls the parent on some interval. If the DS is visible it would
'ds-seen' the enforcer and remove itself from cron.

//Yuri

[Merijn van den Kroonenberg]

Post by Yuri Schaeffer

Post by PGNet Dev
IIUC there is no current "wait for ds-seen" mechanism or script hook in
ODS 2.1.x, is there? I.e., needs to be done externally (cron job, etc)?

Yes. So a possible solution would be to have the
DelegationSignerSubmitCommand upload the DS and then initiate a cron job
that polls the parent on some interval. If the DS is visible it would
'ds-seen' the enforcer and remove itself from cron.

Possible useful tooling for this (ods-dsseen script):

https://github.com/CAPSLOCK2000/ods-scripts

But I do not know if they are 2.0 compatible (as I believe tooling and
output changed a bit).

Post by Yuri Schaeffer
//Yuri