DNSSEC KSK/ZSK 可接受的密钥长度是多少？

Question

我的任务是研究在我们的名称服务器上实施 DNSSEC。虽然这方面的技术方面（生成密钥、标志区域、准备翻转）相对简单，但我遇到了后勤问题。

从我一直在阅读的文档来看，1024 位对于区域签名密钥来说是一个很好的大小，正确的程序是每个区域一个 ZSK，大约一个月的滚动

然而，在一台具有良好熵的相当快的计算机上最多需要 10 分钟来生成一个 1024 位的密钥......而我为超过三千个区域的主机工作的 ISP。除非我以某种方式使流程从头到尾自动化，否则这是行不通的——即使我这样做了，到流程完成时，几乎是开始 NEXT 翻转的时候了。

简而言之，这是不可行的。现在，我将 DNSSEC 限制为明确要求的客户，但这充其量只是权宜之计。

我的问题：

• 我的密钥长度是否太过分了？
• 如何加快密钥生成过程？
• 我应该为每个区域以及 ZSK 创建单独的密钥签名密钥吗？

编辑：添加了我用来生成密钥的确切命令：

caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256 -f KSK -b 1280 -n ZONE example.com 
Generating key pair.............................+++++ ...+++++ 
Kexample.com.+008+10282

real    9m46.094s
user    0m0.092s
sys 0m0.140s

caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256  -b 1280 -n ZONE example.com 
Generating key pair.........................+++++ .........+++++ 
Kexample.com.+008+22173

real    12m47.739s
user    0m0.124s
sys 0m0.076s

Answer 1

dnssec-keygen/dev/random默认读取。如果系统上的熵较低，您将无法获得足够的随机数据来及时生成密钥。strace 可能会显示很多内容，例如：

select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "5%\5\32\316\337\241\323", 46)  = 8
read(3, 0x7fff5b6c3df0, 38)             = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\305\35\201c\31\343\251\21", 38) = 8
read(3, 0x7fff5b6c3df0, 30)             = -1 EAGAIN (Resource temporarily unavailable)

/dev/random如果没有足够的熵，则会阻塞，因此可能需要一段时间。

您有几种选择可以让这一切进展得更快。最简单的方法是使用更改-r /dev/random来-r /dev/urandom使用非阻塞（但不那么安全）随机数生成器。对于您希望使用数年的 GPG 或 SSH 密钥之类的东西来说，这可能不被认为是安全的，但对于您每 30 天就会更改一次的东西来说，它可能是安全的。

另一种选择是使用EGD或hadged之类的东西来替代/dev/random.

如果您想要更安全的 RNG，那么最好使用专用的硬件 RNG。除非您管理 TLD 或银行域，否则这些对于 DNSSEC 来说可能有点过大了。

对于 KSK，您可能希望坚持使用 /dev/random，但 /dev/urandom 对于 ZSK 应该很好。