4

I am in the process of setting up DNSSEC for my domains. Initially I was going to go with algorithm 13 (ECDSA-P256-SHA256), but it seems that dyn.com doesn't allow me to add a DS record with an algorithm value of 13. (Would love some insight as to why they prevent this)

I figured, hey, no matter, there are two keys, right? I could have the KSK be algorithm 8 (RSASHA256) and keep the ZSK as algorithm 13. The ZSK is the one making most of the signatures anyway, so that is where the big win would be.

But it seems like dnssec-signzone was giving me a lot of grief. I eventually got it to seem like it worked, but dnssec-verify seems to consistently give me the following error:

$ dnssec-verify -o example.com example.com.db.signed 
Loading zone 'example.com' from file 'example.com.db.signed'
Verifying the zone using the following algorithms: RSASHA256.
Missing ZSK for algorithm RSASHA256
Missing self-signed KSK for algorithm ECDSAP256SHA256
No correct RSASHA256 signature for example.com SOA
No correct RSASHA256 signature for example.com NSEC
The zone is not fully signed for the following algorithms: RSASHA256 ECDSAP256SHA256.
dnssec-verify: fatal: DNSSEC completeness test failed.

So, my question is:

Is it legal with DNSSEC to have differing algorithms for the ZSK and KSK? If so, how can I sign verify the zone using the standard bind DNSSEC tools with such a configuration?

darco
  • 205
  • 1
  • 10
  • Well, as much as the tools complain about it, it does appear to work: `dig voria.net +dnssec +multi` isn't giving me any errors. – darco Jan 31 '15 at 04:00

2 Answers2

4

It is not legal. The rules for zone signing were clarified in RFC 6840 because the original RFC was quite terse:

The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset.

Since both the KSK and the ZSK are included in the zone's RRset, in practice this requires that the ZSK and KSK use the same algorithm (or rather, that there is a matching ZSK for every KSK algorithm).

Note that the following paragraph explains that these requirements apply to DNS servers only; resolvers (validators) are instructed to accept any valid signing path.

Community
  • 1
Arno
  • 56
  • 2
1

It does seem to work in practice with most validating resolvers.

However, a strict interpretation of RFC 4035 Section 2.2 (specifically "There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.") could imply that if you have different KSK and ZSK algorithms, a validating resolver may require all RRsets to be signed by both algorithms (both KSK and ZSK are in the apex DNSKEY RRset). Since the KSK only signs the DNSKEY RRset, and the ZSK (only) signs everything else, all your data would have only one signature algorithm, and could therefore fail validation.

Alex Dupuy
  • 113
  • 6
  • Re-reading the last sentence it isn't entirely clear (and in fact different systems vary). The KSK is always used to sign the apex DNSKEY RRset. The ZSK (part of the apex DNSKEY RRset and thus signed by KSK) is always used to sign all the other RRsets in the zone. Although many systems sign the apex DNSKEY RRset with the KSK as well, this is not required and if not done, even the apex DNSKEY RRset will be signed only with one algorithm. – Alex Dupuy Jul 26 '16 at 12:27
  • "many systems sign the apex DNSKEY RRset with the KSK as well" > I assume you meant ZSK? – Etienne Dechamps Sep 19 '21 at 17:37
  • Yes, I should have written "many systems sign the apex DNSKEY RRset with the ZSK as well" in my comment. – Alex Dupuy Sep 22 '22 at 23:28
  • I should also have noted that for those systems, only the zone apex RRSet has two signatures (which may be of different algorithms). All the other RRSets are only signed by the ZSK and thus ( if the KSK and ZSK use different algorithms) could fail validation by a strict resolver (or a resolver that only implements the algorithm of the KSK and not the ZSK). – Alex Dupuy Sep 22 '22 at 23:37