Algorithm roll-over, unexpected content in dsset-file

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Algorithm roll-over, unexpected content in dsset-file

Mark Elkins
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
[hidden email]       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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm roll-over, unexpected content in dsset-file

Ondřej Surý
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 <[hidden email]> 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
[hidden email]       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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Algorithm roll-over, unexpected content in dsset-file

Mark Elkins
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 <[hidden email]> 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
>> [hidden email]       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
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark James ELKINS  -  Posix Systems - (South) Africa
[hidden email]       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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users