ハッシュ値を求めるための
計算コストの増加 無 有
• NSEC3
はNSEC
に比較しドメイン名の秘匿性は高 まるが、ハッシュ計算のためのコストが増加する⇒
NSEC3
とNSEC
は用途に応じて使い分ける–
ゾーンデータを秘匿する必要が無い場合、NSEC
のほう が各 サーバの負荷の増加を抑えられるwww.example.jp の A の署名検証 (1)
① 上位から
NS
とDS
を受け取る– JP
の権威サーバからexample.jp
のDS (DS
の署名検証 の解説は省略)
とNS
の情報を受け取る② 当該ゾーンの
DNSKEY
を受け取る– example.jp
の権威サーバから、example.jp
のDNSKEY(
複数)
とRRSIG(
複数)
を受け取る③ DNSKEY
からKSK
を識別する– DNSKEY
は複数(2
個以上)
存在するので、フラグが257
のDNSKEY(1
個以上)
を識別する④ KSK
を特定する– KSK
とDS
の鍵ID
、DNSSEC
アルゴリズム番号を比べ、www.example.jp の A の署名検証 (2)
⑤ KSK
を認証する– DS
のハッシュアルゴリズムに従ってKSK
のハッシュ値を 計算し、DS
にあるハッシュ値と比較してKSK
を確認する⑥ DNSKEY
を認証する–
③で受け取ったDNSKEY
に付随したRRSIG(
複数)
の鍵ID
からKSK
の鍵ID
と一致するものを識別し、署名検証を 行いDNSKEY
を認証する⑦ DNSKEY
からZSK
を識別する– DNSKEY
のフラグが256
のものを識別する ここでZSK
は複数存在する可能性があるwww.example.jp の A の署名検証 (3)
⑧ www.example.jp
のA
を受け取る– example.jp
の権威サーバから、A
とRRSIG(1
個以上)
を 受け取る⑨ www.example.jp
のA
を認証する– RRSIG
の鍵ID
と一致するZSK
で署名を検証する–
必ずしも処理はこの順番ではなく、実装に依存する–
署名検証の際、署名の有効期間、ドメイン名など他のRRSIG
のパラメータもチェックされる– DS
やDNSKEY
、RRSIG
等は、署名検証後もTTL
の有鍵更新と再署名
鍵更新
• 鍵更新： Key rollover
–
同じ鍵を長期間使い続けると、様々なリスクが生 じる–
不注意、偶発的事故、鍵の盗難、暗号解読等• リスクを最小に抑えるため、 DNSSEC 対応 ゾーンの運用では定期的な鍵更新 ( 鍵の交 換 ) を行う
–
例えばSE(
スウェーデン)
の場合、年に1
回新しいKSK
を生成し、2
年間利用する運用を行っている鍵更新時に留意すべきこと
• 鍵更新は、 DNSSEC の信頼の連鎖が途切れ ないよう、注意深く作業する必要がある
–
鍵情報(DS
やDNSKEY)
と署名(RRSIG)
はDNS
のレコードである⇒ キャッシュサーバはこれらをキャッシュする
• キャッシュしている情報と、あらたにキャッシュ サーバが受け取る情報の整合性を確保する
• 2 種類の鍵更新手法
–
事前公開法(Pre-Publish Key Rollover)
ZSK の更新
事前公開法 (1/2)
① DNSKEY
に新旧のZSK
を登録する–
新ZSK
を作成し、旧ZSK
と共にDNSKEY
に登録し(
この 状態でKSK
を含めてDNSKEY
は最低3
個)
、旧ZSK
で ゾーンを署名– DNSKEY
のTTL
時間(+
セカンダリの転送時間)
待つ–
全てのキャッシュサーバが新旧のZSK
を含んだDNSKEY
をキャッシュするようになり、旧RRSIG
でも新RRSIG
でも署名を検証できるようになる② ゾーンの署名鍵を新
ZSK
に切り替える–
ゾーン内の最長のTTL
時間(+
セカンダリの転送時間)
待 つ全てのキャッシュサーバから旧 で署名した が
ZSK の更新
事前公開法 (2/2)
③ 旧 ZSK を DNSKEY から削除する
ドキュメント内
DNSSECチュートリアル ～実践編～
(ページ 47-55)