Hi Marcos, For .nl we have rolled the KSK conform the double KSK method as described in RFC7583. We didn't notice a mistake or oblivion there :-0
Grtz, Marc -----Original Message----- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Matthijs Mekking Sent: dinsdag 25 oktober 2016 12:35 To: Marcos Sanz <s...@denic.de>; dnsop@ietf.org Subject: Re: [DNSOP] RFC 6781 and double signature KSK rollover 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
