从我一直在阅读的文档中,对于区域签名密钥,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
解决方法
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天更换一次的东西,它可能是安全的.
另一种选择是使用像EGD或haveged这样的东西作为/ dev / random的替代品.
如果您想要更安全的RNG,那么使用专用硬件RNG会更好.除非您管理TLD或银行域,否则这些可能对DNSSEC而言过度.
您可能希望坚持使用/ dev / random作为KSK,但/ dev / urandom应该对ZSK有利.
原文地址：https://www.jb51.cc/html/228851.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
