Hi Marco,
On 24-10-16 17:47, Marcos Sanz wrote:
Hi all,
my attention has been brought to the KSK rollover double-signature style
described in 6781 and what I think is a mistake/oblivion there. Section
4.1.2 states
initial: Initial version of the zone. The parental DS points to
DNSKEY_K_1. Before the rollover starts, the child will have to
verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
it is needed during the rollover, and we refer to the value as
TTL_DS.
new DNSKEY: During the "new DNSKEY" phase, the zone administrator
generates a second KSK, DNSKEY_K_2. The key is provided to the
parent, and the child will have to wait until a new DS RR has been
generated that points to DNSKEY_K_2. After that DS RR has been
published on all servers authoritative for the parent's zone, the
zone administrator has to wait at least TTL_DS to make sure that
the old DS RR has expired from caches.
DS change: The parent replaces DS_K_1 with DS_K_2.
In that description it looks as if the only relevant TTL during the
rollover is that of the old DS RR. In my eyes though, the replacement of
the DS at the parent shouldn't happen before having waited at least the
TTL of DNSKEY_K_1 itself. Otherwise validation errors might occur
(mismatch between a cached DNSKEY_K_1 and the DS_K_2 at the parent).
You are right: DS_K_2 may only be provided to the parent *after* the TTL
of DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for
rollovers. The corresponding timeline is described in section 3.3.1.
Best regards,
Matthijs
I've seen TLDs doing their KSK rollover the way I describe (so it looks as
it is standard operational practice), but the RFC doesn't reflect that.
There are no errata filed for the RFC so far either.
Any thoughts on that?
Best,
Marcos
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
