when selecting DNSSEC signing algorithms for eventual use with DANE setup,
checking first @
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1
both algos 8 & 13 are listed as options:
Number Description Mnemonic Zone Signing
Trans.Sec. Reference
8 RSA/SHA-256 RSASHA256 Y *
[RFC5702][proposed standard]
13 ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256 Y *
[RFC6605][proposed standard]
checking for signing algos @ root zone for my most-common in-use domains,
_r="http://www.internic.net/domain/root.zone";
curl -s $_r | egrep "^com\.|^net\.|^org\.|^io\." | awk '$4 == "DS" { printf
"%-10s %s\n", $1, $6 }'
com. 8
io. 8
net. 8
org. 8
none are currently signing with ECDSA algo 13.
and for root signing algo usage across all TLDs
curl -s $_r | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
68 5
59 7
1368 8
33 10
75 13
1 14
the overall usage of 13 is still low, though incrementally better than a couple
of years ago.
I'm interested in real-world production use -- specifically, NOT breaking
postfix/DANE.
Given, e.g., Viktor's comment
https://blog.apnic.net/2021/11/10/rsa-vs-ecdsa-for-dnssec/#comment-65911
"Perhaps if we can coax more TLDs into moving to ECDSA P256,
the ISPs will be more strongly incentivised to support the algorithm.
I'm unclear on what 'support' here means.
what's currently recommended/required?
*must* I sign my DNSSEC keys for my domains with the same algo in-use by the
respective TLDs' roots in order to not fubar DANE usage specifically, or can I
(arbitrarily) use any algo listed @ the iana.org link above, regardless of the
root signing algo?
