Given the recent advances in SHA-1 collision attacks,
https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html https://sha-mbles.github.io/
it is time to deprecate the remaining DNSSEC SHA-1 based DNSKEY algorithms.
If you've deployed inbound DANE by publishing signed TLSA records for your MX hosts, but your underlying DNSSEC deployment uses DNSKEY algorithms other than 13 (recommended), 8 (popular) or 10 (fine, though not widely used), then you should migrate your domains to algorithm 13 (preferred) or 8.
This should be done while the attacks are still costly, and have somewhat limited applicability. Algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) may not be quite dead, but they are significantly wounded.
If/when you do decide to switch algorithms, please perform the migration with care. Algorithm rollovers can be tricky. The basic process is:
1. Publish and activate a ZSK for the new algorithm. Your zone should now be double-signed, which each record having two RRSIGs. Don't forget to bump the SOA.
2. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone.
3. Publish and activate a KSK for the new algorithm. This KSK adds a second signature to your zone apex DNSKEY RRset. Don't forget to bump the SOA.
4. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone.
5. Arrange for the parent zone to publish DS records matching the new KSK in addition to DS RRs matching the KSKs for the previous algorithm.
6. Wait for at least 2 parent zone TTLs after all nameservers for the parent zone have started serving the new DS RRset.
7. Request deletion of the DS RRs for the old algorithm.
8. Wait for at least 2 parent zone TTLs after all nameservers for the parent zone have starting serving the new DS RRset.
9. Remove the old KSKs from your DNSKEY RRset after checking that the DS RRset with just the new algorithm matches your new KSK.
10. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone.
11. Deactivate the old ZSKs leaving the zone signed only under the new ZSKs.
12. Wait for at least 2 maximum TTLs after the primary and all secondary nameservers have started serving the updated zone.
13. Remove the old ZSKs from your DNSKEY RRset.
The reason for all this is to maintain the followin invariants:
A. Each algorithm mentioned in the parent zone DS RRset must have a matching KSK in the zone's DNSKEY RRset.
B. Each KSK algorithm appearing in the zone's DNSKEY RRset must have a corresponding ZSK signature for each record in the zone.
Therefore, new algorithms are introduced from the ZSK up, while old algorithms are removed from the DS RRset down. The various "wait" steps are needed to ensure that resolvers using cached data are able to validate your changing zone at all times.
Presently, the DANE survey database shows ~230 thousand domains using algorithms 5 and 7. It would be great to see this number substantially reduced over the coming months.