Virtualmin 支持 DNSSEC 的一系列算法：RSASHA1、RSASHA256、RSAMD5、DSA、DH、HMAC-MD5(???)、NSEC3RSASHA1、NSEC3DSA。
如果我理解正确，SHA1 的概念证明在与 DKIM 一起使用时很容易妥协，因为数据长度。所以这会让我相信这同样适用于 DNSSEC。
哪些关键算法最适合用于生产环境的 DNSSEC？
有哪些支持性的技术论文来证实算法选择的推理？
然而，这里有一个平衡点，即 INFOSEC 经常必须找到的平衡点，即在选择适当安全的算法而又不过度消耗生产环境中的资源时。
尽管如此，适用于重要网络系统（财务或敏感的个人信息）的算法可能与关键任务系统的算法有所不同。
或者，在全球网络灾难事件中，中间人攻击的威胁是否太大，以至于即使对于没有高度敏感信息的关键任务系统，也需要最强大的加密技术？
（是的，这个问题很老，但值得回答。）
现代加密货币的一些规则：
为 DNSSEC 使用 HMAC 没有任何意义，HMAC 要求双方都可以访问相同的密钥；在 DNSSEC 的上下文中，这意味着客户端可以欺骗服务器，使其无用。
您的列表中缺少很多算法，我不知道为什么 Virtualmin 会为您提供这些选项。ECDSA 选项在签名操作中为您提供更小的响应和更低的 CPU 使用率。
鉴于 DNSSEC 密钥和响应的生命周期相对较短，在考虑到上述所有因素后，我倾向于选择较短的选项。这意味着使用带有 2048 位 RSA 密钥的 RSASHA256 或 ECDSAP256SHA256（带有 SHA256 的 256 位 ECDSA）。
截至 2018 年 9 月，Viktor Dukhovni报告了在使用中观察到的算法，密钥长度为：
DNSKEY parameter frequency (1000 or more instances), by zone count:
kskalgs | flags | proto | alg
--------+-------+-------+-----
4780 | 257 | 3 | 3
358979 | 257 | 3 | 5
2210428 | 257 | 3 | 7
4198328 | 257 | 3 | 8
87469 | 257 | 3 | 10
1844138 | 257 | 3 | 13
62481 | 257 | 3 | 14
--------+-------+-------+-----
zskalgs | flags | proto | alg
--------+-------+-------+-----
4780 | 256 | 3 | 3
132748 | 256 | 3 | 5
2192269 | 256 | 3 | 7
4142767 | 256 | 3 | 8
87250 | 256 | 3 | 10
791434 | 256 | 3 | 13
61548 | 256 | 3 | 14
--------+-------+-------+-----
RSA key size distribution (1000 or more instances), by zone count:
kskdomains | bits
------------+------
67580 | 4096
5149822 | 2048
302182 | 1536
2992 | 1280
1333428 | 1024
8392 | 512
------------+------
zskdomains | bits
-----------+------
13287 | 4096
110595 | 2048
306770 | 1280
6115735 | 1024
8169 | 512
-----------+------
大卫对 RFC 的回答中的链接会将alg数字转换为实际算法。
Victor 会定期将这些数据的更新发布到dns-operations列表。如果您参与组织的 DNS 操作，我强烈建议您订阅该列表。