9 Pro
2025
9 Pro
'25
12:59
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
9 Pro
9 Pro
13:38
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
--
13:55
On 9 Dec 2025, at 12:38, Libor Peltan
<libor.peltan(a)nic.cz> wrote:
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?
I agree that zone-ksk-submitted should behave more like the automated ksk submission
mechanism, so with additional parameters for parent ds ttl etc.
It’s not a big problem to wait before running zone-ksk-submitted, but it was unclear
from the docs for me whether knot would delay or remove the key immediately.
On 9 Dec 2025, at 12:38, Anand Buddhdev
<anandb(a)ripe.net> wrote:
You can configure a "submission" section in knot.conf, and provide trusted
resolvers there. Then Knot DNS will watch for DS record updates at the parent, and
consider the TTL before starting the DNSKEY retire process.
I will probably test that on our subdomains and in the future for .is.
The good news is that we’re almost done doing an algorithm rollover for .is.
The new DS record was published last night and we’ll trigger knot to finish
the rollover tomorrow. I’ve been very impressed with how well knot handled
the rollovers :)
.einar
13:38
On 09/12/2025 12:59, Einar Bjarni Halldórsson via knot-dns-users wrote:
Hi Einar,
One thing I’m not sure about is exactly what happens
when we run `knotc zone-ksk-submitted`?
If you use this command, Knot DNS assumes that you know what you are
doing, and are aware of the TTLs, etc.
Should I wait before running zone-ksk-submitted, or is
there a config option I’m missing to tell knot
the ds ttl?
You can configure a "submission" section in knot.conf, and provide
trusted resolvers there. Then Knot DNS will watch for DS record updates
at the parent, and consider the TTL before starting the DNSKEY retire
process.
Regards,
Anand Buddhdev
10 Pro
10 Pro
14:40
FYI https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1836/diffs
On 12/9/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
--
1
days inactive
2
days old
4 comments
4 participants
participants (4)
-
Anand Buddhdev -
Daniel Salzman -
Einar Bjarni Halldórsson -
Libor Peltan