On Wed, Oct 12, 2022 at 09:05:34AM -0400, PGNet Dev wrote: > 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]
The most recent RFC (slightly dated) guidance on DNSSEC algorithms can be found at: https://www.rfc-editor.org/rfc/rfc8624#section-3 Real world deployment numbers at: https://stats.dnssec-tools.org > 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 The TLDs are generally not early adopters, but already 86 of them have algorithm 13 (ECDSA P256) keys (a few still mid-rollover also still have algorithm 8 RSA keys). > none are currently signing with ECDSA algo 13. IIRC the .org TLD had plans in that direction, the pandemic threw off their plannig schedule. > the overall usage of 13 is still low, though incrementally better than > a couple of years ago. It is much better than that once you look at signed zones broadly, rather than just TLDs. https://stats.dnssec-tools.org/ KSK Algorithm Zone Count 8 9899431 13 8998563 10 247205 14 158150 7 134183 5 21089 > 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 should perhaps have said "adopt", rather than "support". Support for algorithm 13 is by now essentially universal. All the validating resolvers you might care about support both 8 and 13. > what's currently recommended/required? https://blog.apnic.net/2022/03/24/dnssec-algorithms-for-tlds-and-everyone-else/ At this point 13 is best practice, because of smaller signatures and a better security margin. Algorithm 8 is acceptable, but with NSEC3 to avoid unwanted UDP fragmentation you're limited to 1280-bit ZSKs, with NSEC you can use 1536-bit ZSKs. > *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? No. For example, the root zone is signed with algorithm 8, and yet some TLDs delegated from the root are signed with algorithm 13. -- Viktor.
