web-dev-qa-db-ja.com

DNSSEC KSK / ZSKの許容可能なキーの長さはどれくらいですか？

私はネームサーバーにDNSSECを実装することを検討する任務を負っています。これの技術的な側面（キーの生成、ゾーンの署名、ロールオーバーの準備）は比較的簡単ですが、私はロジスティックの問題に遭遇しました。

私が読んでいるドキュメントによると、1024ビットはゾーン署名キーに適したサイズであり、適切な手順は、ゾーンごとに1つのZSKであり、約1か月のロールオーバーがあります。

ただし、適切なエントロピーを備えた適度に高速なコンピューターでは、1024ビットのキーを生成するのに最大10分かかります...そして私が3000ゾーン以上のホストで働いている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
domain-name-systembinddnssec
7
Shadur

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の代わりに [〜＃〜] egd [〜＃〜] または haveged のようなものを使用することです。

より安全なRNGが必要な場合は、専用のハードウェアRNGを使用することをお勧めします。 TLDまたは銀行ドメインを管理していない限り、これらはDNSSECにとっておそらくやり過ぎです。

KSKでは/ dev/randomに固執することもできますが、ZSKでは/ dev/urandomが適しているはずです。

4
Cakemox

一般的なコンセンサスは、ZSKは1024ビットで四半期ごとにロールアラウンドする必要があり、KSKは2048ビットで数年ごとにロールアラウンドする必要があるということだと思います。

2
Chopper3