On 11 Aug 2019, at 12:59, Mark Elkins <[email protected]> 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
[email protected] 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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
