Re: Algorithm roll-over, unexpected content in dsset-file
Hi Ondřej, Thanks for the info. I was happy to run an Algorithm roll-over the way I did previously (years ago) and was unaware of the combined signing key issue. Regardless, decided to create a new Algo-13 KSK when ever I create the first Algo-13 ZSK for any particular domain - which removes the problem. Algorithm roll-overs are way more fun than a normal KSK roll-over :-) Was trying to keep all my KSK roll-overs as spread out around the year as possible. I suspect what I want to do is keep ZSK's using the old algo until its time to create a new KSK (with Algo-13) then immediately roll-over a ZSK (created with Algo-13)... so the KSK's timetable does not change. Might do a presentation on this one day. On 2019/08/11 19:32, Ondřej Surý wrote: When there’s no DNSSEC KEY with SEP bit set, the Algo-13 “chain” has single entry point, e.g. Single-Type Signing Scheme (Combined Signing Key), see https://tools.ietf.org/html/rfc6781#section-3.1 and https://tools.ietf.org/html/rfc8499#section-10 I don’t know exactly know what are you trying achieve, but adding only ZSK with new algorithm serves no purpose. Ondřej -- Ondřej Surý — ISC On 11 Aug 2019, at 12:59, Mark Elkins wrote: Hi, Running BIND 9.14.4 on Gentoo. I've been running BIND and DNSSEC for a long time. Years ago - I changed from Algorithm 5 to 8 and am now changing from 8 to 13. My ZSK's have a lifetime of 34 days and my KSK a lifetime of 370 days. I've chosen to create a new ZSK every 17 days and KSK every 185 days - so usually have two of each per domain. I've 1532 domains in my system, 74 are NSEC and 54 are NSEC3 - the rest are unsigned. Currently - resigning happens randomly over the year - which keeps loads (and changes) scattered over the year. Some parents - I manage via EPP, others have various other methods of updating - so having the best part of six month to do a key-rollover has its advantages. I've just started allowing the system to add Algo-13 Keys... and this is what I see: 1 - Created a test zone file: contains enough to be legal. 2 - Created some old keys, one ZSK and one KSK - Signed the domain and looked inside the "dsset-" file # vi db.foo.com # dnssec-keygen -a RSASHA256 foo.com # dnssec-keygen -a RSASHA256 -f KSK foo.com # cat Kfoo.com.*.key >> db.foo.com # dnssec-signzone -a -o foo.com db.foo.com # cat dsset-foo.com. foo.com. IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 foo.com. IN DS 62014 8 2 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE (perfect!) 3 - created one additional ZSK - Algo 13, add that to the zone and resigned. # dnssec-keygen -a ECDSAP256SHA256 foo.com # cat Kfoo.com.+013+34805.key >> db.foo.com # dnssec-signzone -a -o foo.com db.foo.com Verifying the zone using the following algorithms: RSASHA256. Missing self-signed KSK for algorithm ECDSAP256SHA256 The zone is not fully signed for the following algorithms: ECDSAP256SHA256. DNSSEC completeness test failed. Zone verification failed (failure) I don't mind the failure - after all there is no complete Algo-13 chain - but the existing Algo-8 chain is complete. Interestingly, the signed zone contains no mention of the Algo-13 ZSK. No problem. However - WTF is a ZSK doing in the dsset file??? Is this a bug? # cat dsset-foo.com. foo.com. IN DS 34805 13 1 A040C7BC6C03778B20AD4A3AEE3BC0648CE8AC23 foo.com. IN DS 34805 13 2 340DC924A523CAD49E5C22357BBFECC07A2944D7723AD8F44DCE5332 FACD3AB2 foo.com. IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 foo.com. IN DS 62014 8 2 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE 4 - If I then add an algo-13 KSK, add it to the Zone and run signzone - everything looks good again... (New KSK) foo.com. IN DNSKEY 257 3 13 pD6yMHdPCKmLj0hY8oiLA1F2Vdb8a1LgpzU8XiO2c6eIh16n1Dv2Vogc 9WylTUjOLTZlhRXPDmAcIUTyBUuC2Q== # dnssec-signzone -a -o foo.com db.foo.com Verifying the zone using the following algorithms: RSASHA256 ECDSAP256SHA256. Zone fully signed: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked db.foo.com.signed # cat dsset-foo.com. foo.com. IN DS 23294 13 1 AADE5856B8EB3BB946DAAD2804A735816B3B3132 foo.com. IN DS 23294 13 2 7FD5F02A2E52A1C6E3DEBD54C05A9A974CE88FA78548E3644B36FA2D 27E0F910 foo.com. IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 foo.com. IN DS 62014 8 2 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE I really don't like the bad ZSK DS record in dsset because I currently use that info to build CDS records in to my Database - which is used to verify when the DS record is seen in the parent. Anyway - I think this is a bug in the code of dnssec-signzone. I'm trying to wait as
Re: Algorithm roll-over, unexpected content in dsset-file
When there’s no DNSSEC KEY with SEP bit set, the Algo-13 “chain” has single entry point, e.g. Single-Type Signing Scheme (Combined Signing Key), see https://tools.ietf.org/html/rfc6781#section-3.1 and https://tools.ietf.org/html/rfc8499#section-10 I don’t know exactly know what are you trying achieve, but adding only ZSK with new algorithm serves no purpose. Ondřej -- Ondřej Surý — ISC > On 11 Aug 2019, at 12:59, Mark Elkins wrote: > > Hi, Running BIND 9.14.4 on Gentoo. > > I've been running BIND and DNSSEC for a long time. Years ago - I changed from > Algorithm 5 to 8 and am now changing from 8 to 13. > > My ZSK's have a lifetime of 34 days and my KSK a lifetime of 370 days. I've > chosen to create a new ZSK every 17 days and KSK every 185 days - so usually > have two of each per domain. I've 1532 domains in my system, 74 are NSEC and > 54 are NSEC3 - the rest are unsigned. Currently - resigning happens randomly > over the year - which keeps loads (and changes) scattered over the year. Some > parents - I manage via EPP, others have various other methods of updating - > so having the best part of six month to do a key-rollover has its advantages. > > I've just started allowing the system to add Algo-13 Keys... and this is what > I see: > > 1 - Created a test zone file: contains enough to be legal. > > 2 - Created some old keys, one ZSK and one KSK - Signed the domain and looked > inside the "dsset-" file > # vi db.foo.com > # dnssec-keygen -a RSASHA256 foo.com > # dnssec-keygen -a RSASHA256 -f KSK foo.com > # cat Kfoo.com.*.key >> db.foo.com > # dnssec-signzone -a -o foo.com db.foo.com > # cat dsset-foo.com. > foo.com.IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 > foo.com.IN DS 62014 8 2 > 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE > (perfect!) > > 3 - created one additional ZSK - Algo 13, add that to the zone and resigned. > > # dnssec-keygen -a ECDSAP256SHA256 foo.com > # cat Kfoo.com.+013+34805.key >> db.foo.com > > # dnssec-signzone -a -o foo.com db.foo.com > Verifying the zone using the following algorithms: RSASHA256. > Missing self-signed KSK for algorithm ECDSAP256SHA256 > The zone is not fully signed for the following algorithms: ECDSAP256SHA256. > DNSSEC completeness test failed. > Zone verification failed (failure) > > I don't mind the failure - after all there is no complete Algo-13 chain - but > the existing Algo-8 chain is complete. Interestingly, the signed zone > contains no mention of the Algo-13 ZSK. No problem. > > However - WTF is a ZSK doing in the dsset file??? Is this a bug? > > # cat dsset-foo.com. > foo.com.IN DS 34805 13 1 A040C7BC6C03778B20AD4A3AEE3BC0648CE8AC23 > foo.com.IN DS 34805 13 2 > 340DC924A523CAD49E5C22357BBFECC07A2944D7723AD8F44DCE5332 FACD3AB2 > foo.com.IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 > foo.com.IN DS 62014 8 2 > 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE > > 4 - If I then add an algo-13 KSK, add it to the Zone and run signzone - > everything looks good again... > > (New KSK) foo.com. IN DNSKEY 257 3 13 > pD6yMHdPCKmLj0hY8oiLA1F2Vdb8a1LgpzU8XiO2c6eIh16n1Dv2Vogc > 9WylTUjOLTZlhRXPDmAcIUTyBUuC2Q== > # dnssec-signzone -a -o foo.com db.foo.com > Verifying the zone using the following algorithms: RSASHA256 ECDSAP256SHA256. > Zone fully signed: > Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked > ZSKs: 1 active, 0 stand-by, 0 revoked > Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked > ZSKs: 1 active, 0 stand-by, 0 revoked > db.foo.com.signed > # cat dsset-foo.com. > foo.com.IN DS 23294 13 1 AADE5856B8EB3BB946DAAD2804A735816B3B3132 > foo.com.IN DS 23294 13 2 > 7FD5F02A2E52A1C6E3DEBD54C05A9A974CE88FA78548E3644B36FA2D 27E0F910 > foo.com.IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 > foo.com.IN DS 62014 8 2 > 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE > > I really don't like the bad ZSK DS record in dsset because I currently use > that info to build CDS records in to my Database - which is used to verify > when the DS record is seen in the parent. Anyway - I think this is a bug in > the code of dnssec-signzone. > > I'm trying to wait as long as possible before forcibly creating Algo-13 KSK's > in the hope that they will be created according to the existing schedule. If > the Second Algo-13 ZSK is to be created in under 3 days - then I'll replace > the oldest KSK with an Algo-13 KSK. > > -- > Mark James ELKINS - Posix Systems - (South) Africa > m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > >
Algorithm roll-over, unexpected content in dsset-file
Hi, Running BIND 9.14.4 on Gentoo. I've been running BIND and DNSSEC for a long time. Years ago - I changed from Algorithm 5 to 8 and am now changing from 8 to 13. My ZSK's have a lifetime of 34 days and my KSK a lifetime of 370 days. I've chosen to create a new ZSK every 17 days and KSK every 185 days - so usually have two of each per domain. I've 1532 domains in my system, 74 are NSEC and 54 are NSEC3 - the rest are unsigned. Currently - resigning happens randomly over the year - which keeps loads (and changes) scattered over the year. Some parents - I manage via EPP, others have various other methods of updating - so having the best part of six month to do a key-rollover has its advantages. I've just started allowing the system to add Algo-13 Keys... and this is what I see: 1 - Created a test zone file: contains enough to be legal. 2 - Created some old keys, one ZSK and one KSK - Signed the domain and looked inside the "dsset-" file # vi db.foo.com # dnssec-keygen -a RSASHA256 foo.com # dnssec-keygen -a RSASHA256 -f KSK foo.com # cat Kfoo.com.*.key >> db.foo.com # dnssec-signzone -a -o foo.com db.foo.com # cat dsset-foo.com. foo.com. IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 foo.com. IN DS 62014 8 2 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE (perfect!) 3 - created one additional ZSK - Algo 13, add that to the zone and resigned. # dnssec-keygen -a ECDSAP256SHA256 foo.com # cat Kfoo.com.+013+34805.key >> db.foo.com # dnssec-signzone -a -o foo.com db.foo.com Verifying the zone using the following algorithms: RSASHA256. Missing self-signed KSK for algorithm ECDSAP256SHA256 The zone is not fully signed for the following algorithms: ECDSAP256SHA256. DNSSEC completeness test failed. Zone verification failed (failure) I don't mind the failure - after all there is no complete Algo-13 chain - but the existing Algo-8 chain is complete. Interestingly, the signed zone contains no mention of the Algo-13 ZSK. No problem. However - WTF is a ZSK doing in the dsset file??? Is this a bug? # cat dsset-foo.com. foo.com. IN DS 34805 13 1 A040C7BC6C03778B20AD4A3AEE3BC0648CE8AC23 foo.com. IN DS 34805 13 2 340DC924A523CAD49E5C22357BBFECC07A2944D7723AD8F44DCE5332 FACD3AB2 foo.com. IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 foo.com. IN DS 62014 8 2 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE 4 - If I then add an algo-13 KSK, add it to the Zone and run signzone - everything looks good again... (New KSK) foo.com. IN DNSKEY 257 3 13 pD6yMHdPCKmLj0hY8oiLA1F2Vdb8a1LgpzU8XiO2c6eIh16n1Dv2Vogc 9WylTUjOLTZlhRXPDmAcIUTyBUuC2Q== # dnssec-signzone -a -o foo.com db.foo.com Verifying the zone using the following algorithms: RSASHA256 ECDSAP256SHA256. Zone fully signed: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked db.foo.com.signed # cat dsset-foo.com. foo.com. IN DS 23294 13 1 AADE5856B8EB3BB946DAAD2804A735816B3B3132 foo.com. IN DS 23294 13 2 7FD5F02A2E52A1C6E3DEBD54C05A9A974CE88FA78548E3644B36FA2D 27E0F910 foo.com. IN DS 62014 8 1 6CFC9114C7D0954195C01B488C3B8D6E1BD0F220 foo.com. IN DS 62014 8 2 74112FE6AE6E9DFB5A00EB3C26397E92CAA27038FA176A9B4B67D9FE 4E0154FE I really don't like the bad ZSK DS record in dsset because I currently use that info to build CDS records in to my Database - which is used to verify when the DS record is seen in the parent. Anyway - I think this is a bug in the code of dnssec-signzone. I'm trying to wait as long as possible before forcibly creating Algo-13 KSK's in the hope that they will be created according to the existing schedule. If the Second Algo-13 ZSK is to be created in under 3 days - then I'll replace the oldest KSK with an Algo-13 KSK. -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
