☰

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

tag-icon • tag-icon domain-name-system bind dnssec
DNSSEC KSK/ZSK 可接受的密钥长度是多少？

我受命研究如何在我们的名称服务器上实施 DNSSEC。虽然这方面的技术方面（生成密钥、签署区域、准备轮换）相对简单，但我遇到了一个后勤问题。

从我读过的文档来看，1024 位对于区域签名密钥来说是一个合适的大小，正确的程序是每个区域一个 ZSK，大约一个月的滚动更新

但是，在速度相当快且熵值相当高的计算机上，生成 1024 位密钥最多需要 10 分钟……而我工作的 ISP 托管着三千多个区域。除非我以某种方式从头到尾自动化该过程，否则这是不可能的——即使我这样做了，等到该过程完成时，也快到下一次轮换开始的时候了。

简而言之，这是不可行的。目前，我限制 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

答案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 天更改一次的密钥，这可能是安全的。

另一种选择是使用类似胃镜检查或者哈格德作为 的替代/dev/random。

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

您可能希望坚持使用 /dev/random 作为 KSK，但 /dev/urandom 应该适合 ZSK。

答案2

我认为普遍的共识是，您的 ZSK 应该是 1024 位并且每季度轮换一次，而您的 KSK 应该是 2048 位并且每隔几年轮换一次。

相关内容