domain-name-system – DNSSEC KSK / ZSK的可接受密钥长度是多少?

前端之家收集整理的这篇文章主要介绍了domain-name-system – DNSSEC KSK / ZSK的可接受密钥长度是多少?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我的任务是研究在我们的名称服务器上实现DNSSEC.虽然技术方面(生成密钥,签名区域,准备翻转)相对简单,但我遇到了后勤问题.

从我一直在阅读的文档中,对于区域签名密钥,1024位是一个很好的大小,正确的程序是每个区域的一个ZSK,大约有一个月的翻转

但是,在具有良好熵的相当快的计算机上生成1024位密钥需要长达10分钟…而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

解决方法

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,"\305\35\201c\31\343\251\21",38) = 8
read(3,30)             = -1 EAGAIN (Resource temporarily unavailable)

/ dev / random block如果没有足够的熵,那么可能需要一段时间.

你有几个选择可以让它变得更快.最简单的方法是使用更改-r / dev / random到-r / dev / urandom来使用非阻塞(但不安全)的随机生成器.对于像您希望使用多年的GPG或SSH密钥这样的东西,这可能不被认为是安全的,但是对于每30天更换一次的东西,它可能是安全的.

另一种选择是使用像EGDhaveged这样的东西作为/ dev / random的替代品.

如果您想要更安全的RNG,那么使用专用硬件RNG会更好.除非您管理TLD或银行域,否则这些可能对DNSSEC而言过度.

您可能希望坚持使用/ dev / random作为KSK,但/ dev / urandom应该对ZSK有利.

猜你在找的HTML相关文章