Key expiration does not trigger automatically a rollover?

[bortzmeyer]

After a few days (zsk.validity = "604800") without a change:

% cascade zone  status --detailed internautique.fr 
Status report for zone 'internautique.fr' using policy 'default'
✔ Waited for a new version of the internautique.fr zone
✔ Loaded <serial number not yet known>
  Loaded at 2025-11-01T16:29:59+00:00 (4days 22h 47m 20s ago)
  Loaded 333 B and 7 records from the filesystem in 0 seconds
✔ Waited for approval to sign <serial number not yet known>
• Approval received to sign <serial number not yet known>, signing requested
DNSSEC keys:
  ZSK tagged 30906:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key
    Actively used for signing
  KSK tagged 35690:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+35690.key
    Actively used for signing
  Details:
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key has expired.
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+35690.key expires at 2026-01-01T16:28:15Z

OK, the ZSK expired but I hoped that a rollover would replace it automatically and I'(m surprised it was not the case.

(And, as usual - see #291 - , when I start manually the rollover, no notify is sent to the name server, until I cascade zone reload)

[Philip-NLnetLabs]

Please check the key manager config file (in the keys directory) and see if automation is enabled for ZSK rolls and that the lifetime got propagated?

[bortzmeyer]

Please check the key manager config file (in the keys directory) and see if automation is enabled for ZSK rolls and that the lifetime got propagated?

% cat /var/db/cascade/keys/internautique.fr.cfg 
{
  "state_file": "/var/db/cascade/keys/internautique.fr.state",
  "keys_dir": "/var/db/cascade/keys",
  "use_csk": false,
  "algorithm": "Ed25519",
  "ksk_validity": {
    "secs": 5270400,
    "nanos": 0
  },
  "zsk_validity": {
    "secs": 604800,
    "nanos": 0
  },
  "csk_validity": {
    "secs": 31536000,
    "nanos": 0
  },
  "auto_ksk": {
    "start": false,
    "report": true,
    "expire": true,
    "done": true
  },
  "auto_zsk": {
    "start": true,
    "report": true,
    "expire": true,
    "done": true
  },
  "auto_csk": {
    "start": true,
    "report": true,
    "expire": true,
    "done": true
  },
  "auto_algorithm": {
    "start": true,
    "report": true,
    "expire": true,
    "done": true
  },
  "dnskey_inception_offset": {
    "secs": 86400,
    "nanos": 0
  },
  "dnskey_signature_lifetime": {
    "secs": 1209600,
    "nanos": 0
  },
  "dnskey_remain_time": {
    "secs": 604800,
    "nanos": 0
  },
  "cds_inception_offset": {
    "secs": 86400,
    "nanos": 0
  },
  "cds_signature_lifetime": {
    "secs": 1209600,
    "nanos": 0
  },
  "cds_remain_time": {
    "secs": 604800,
    "nanos": 0
  },
  "ds_algorithm": "Sha256",
  "default_ttl": 3600,
  "autoremove": true,
  "update_ds_command": []
}

[Philip-NLnetLabs]

This is weird. If it happens again, could you leave it in that state then we can look at the keyset state file and see if that gives a clue.

[bortzmeyer]

This is weird. If it happens again, could you leave it in that state then we can look at the keyset state file and see if that gives a clue.

Note that cascade zone history offers zero information about key expiration:

2025-11-01T21:30:36+00:00 2025110108 Signing succeeded (triggered by keyset cron modified keyset state)
2025-11-01T21:30:36+00:00 2025110108 Signed zone review pending
2025-11-01T21:30:36+00:00 2025110108 Signed zone review approved
2025-11-06T15:20:13+00:00 -          Keyset command '/home/cascade/.cargo/bin/dnst keyset -c /var/db/cascade/keys/internautique.fr.cfg zsk start-roll' succeeded in 0s
2025-11-06T15:21:47+00:00 2025101721 New version received