DNSSEC specification recommends not signing with DNSSEC algorithm 7 (RSASHA1NSEC3SHA1) #1953
Comments
|
Each TLD and registrar support a different subset of the algorithms and it's a moving target --- at least, this was true when I added DNSSEC to Mail-in-a-Box originally. RSASHA1-NSEC3-SHA1 appeared to be the most supported algorithm at the time. I would be happy to target a newer algorithm. But we also have to be careful about not breaking anyone's existing DNSSEC configuration. |
|
I'll see if I can find more information on what is supported where. I did some searching in the Cloudflare GitHub to see if they publish a resolution to this issue and I came up short, but I barely can read anything in code. However, I did find they have an old fork of this (maintained) repo: Don't know if there is something there that may be used to resolve the issue here, but there are several files starting with Also found RFC 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC which has the following chart: Though I'm not sure if there is an update some place that supersedes this. The RFC is dated June 2019. For implementation, perhaps something like new installs get the newer algorithm. For current installs... some CLI |
|
I've gone about as far on researching this as I am able. Cloudflare DNSSEC is now exclusively algorithm 13. Their page Understanding and configuring DNSSEC in Cloudflare DNS includes an overview and discussion on their service as well as what to do when a registrar does not support DNSSEC or algorithm 13, and they even go so far as to recommend reporting the registrar to ICANN with a link to the ICANN complaint page, as registrars are required to support DNSSEC. (I find this at least somewhat hypocritical, as ICANN also states that algorithm 8 is The above linked page also includes a list of registrars and instructions on how to enable DNSSEC with those registrars. It is the best list like this I have discovered, though it is obviously very incomplete. There is also a post in the Cloudflare community forums that includes a discussion on algorithm 8 and a response from a team member: DNSSEC Algorithm 8. It seems noteworthy that dropping algorithm 8 generated only one post to the Cloudflare community forums that I can find. The Root Canary project links to the NLnet Labs' DNSthought platform, which includes reports on resolver support for DNSSEC algorithms. According to the reports, algorithm 7 supported by 11,050 resolvers, algorithm 8 by 14,522 resolvers, and algorithm 13 by 13,977 resolvers. >75% of the algorithm 8 and 13 resolvers support algorithm 7; >98% of algorithm 7 resolvers support 8 and 13; >95% of algorithm 8 resolvers support 13; and >99% of algorithm 13 resolvers support 8. It seems like if there is a disparity where resolvers are not supporting an algorithm, then the registrar support may not be the only factor in deciding on an algorithm. My best guess at this point is that using algorithm 8 may be only slightly more available than 13, and 7 seems to actually be on its way out. However, given that Cloudflare recently (March 2021) began supporting algorithm 13 exclusively, this will likely put more pressure on registrars to support algorithm 13, if they don't already. This with the resolver data, and it may be that algorithm 13 is a better option than algorithm 8 since support appears similar and algorithm 13 will likely be supported longer by the RFC. |
|
That's really helpful. I've worked on this issue today and I'll push a commit tomorrow that hopefully addresses this by encouraging users to migrate to algorithm 13 by 1) signing zones with algorithms 7 (for existing MiaB boxes), 8, and 13 simultaneously, and 2) providing a warning in the status checks for users not using algorithm 13 (which would be everyone that has DNSSEC activated). |
* Stop generating RSASHA1-NSEC3-SHA1 keys on new installs since it is no longer recommended, but preserve the key on existing installs so that we continue to sign zones with existing keys to retain the chain of trust with existing DS records. * Start generating ECDSAP256SHA256 keys during setup, the current best practice (in addition to RSASHA256 which is also ok). See https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 and https://www.cloudflare.com/dns/dnssec/ecdsa-and-dnssec/. * Sign zones using all available keys rather than choosing just one based on the TLD to enable rotation/migration to the new key and to give the user some options since not every registrar/TLD supports every algorithm. * Allow a user to drop a key from signing specific domains using DOMAINS= in our key configuration file. Signing the zones with extraneous keys may increase the size of DNS responses, which isn't ideal, although I don't know if this is a problem in practice. (Although a user can delete the RSASHA1-NSEC3-SHA1 key file, the other keys will be re-generated on upgrade.) * When generating zonefiles, add a hash of all of the DNSSEC signing keys so that when the keys change the zone is definitely regenerated and re-signed. * In status checks, if DNSSEC is not active (or not valid), offer to use all of the keys that have been generated (for RSASHA1-NSEC3-SHA1 on existing installs, RSASHA256, and now ECDSAP256SHA256) with all digest types, since not all registers support everything, but list them in an order that guides users to the best practice. * In status checks, if the deployed DS record doesn't use a ECDSAP256SHA256 key, prompt the user to update their DS record. * In status checks, if multiple DS records are set, only fail if none are valid. If some use ECDSAP256SHA256 and some don't, remind the user to delete the DS records that don't. * Don't fail if the DS record uses the SHA384 digest (by pre-generating a DS record with that digest type) but don't recommend it because it is not in the IANA mandatory list yet (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml). See #1953
|
Pushed, see 178c587. I hope this works! I've updated a few of my domains to ECDSAP256SHA256 and hopefully everything is valid. I tested with (Also note that I have just renamed the master branch to |
|
Wow, awesome. I can test with a test domain in a week or so, but not at this moment. |
|
Updated my box with a newer DNSSEC key, added "DOMAINS=none" to cat /home/user-data/dns/dnssec/RSASHA1-NSEC3-SHA1.conf, dnsvis is happy. |
|
Great! |
When looking at some DNSSEC records at dnsviz.net, I noticed the following warning with MiaB servers:
I'm a little outside my comfort zone for proposing a config, but I do see that algorithm 13 is used by Cloudflare and Namecheap.
Here is the IANA list of of Algorithm numbers [1]:
* There has been no determination of standardization of the use of this algorithm with Transaction Security.
[1] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
The text was updated successfully, but these errors were encountered: