Hi Einar,
thank you for your point!
Your observation is correct: unlike the automated KSK submission
feature, which queries the parent zone for the DS and than schedules the
old KSK removal according to both the DS TTL and the configured
parent-delay[1],
the knotc zone-ksk-submitted command accounts for none of those and
causes an immediate old KSK removal.
I think this is an error in Knot DNS's design. Maybe we should modify
the behavior so that the knotc zone-ksk-submitted command has an
(optional) additional parameter where the user could specify the parent
DS's TTL, and also adds the (possibly) configured parent-delay.
What do you think?
Libor
[1]
https://www.knot-dns.cz/docs/3.5/singlehtml/#parent-delay
On 09. 12. 25 12:59, Einar Bjarni Halldórsson via knot-dns-users wrote:
Greetings,
One thing I’m not sure about is exactly what happens when we run `knotc
zone-ksk-submitted`?
Our parent zones don’t support CDS/CDNSKEY, so we manually update DS records and then
run `knotc zone-ksk-submitted`. It seems to me that as soon as we run it, the retiring of
the outgoing
KSK key starts and it’s removed from the DNSKEY RRset. Is that correct?
I’d like to be sure, because as it is, I wait at least the TTL of the DS record before
running zone-ksk-submitted,
if I run it right away and knot removes the key immediately from the DNSKEY RRset, then
caching resolvers
will invalidate the zone.
The docs for knotc say:
Use when the zone's KSK rollover is in submission phase. By calling this command the
user confirms manually that the parent zone contains DS record for the new KSK in
submission phase and the old KSK can be retired. (#)
Reading the docs, I would think I should run zone-ksk-submitted as soon as the new DS
record has been
published in the parent, but then knot would need to know to wait for the TTL of the DS
record before
removing the key.
Should I wait before running zone-ksk-submitted, or is there a config option I’m missing
to tell knot
the ds ttl?
.einar
--