有 ハッシュ値を求めるための 無
計算コストの増加
有 無
ゾーンデータの秘匿性
NSEC3 NSEC
• 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(
複数)
を受け取る③
KSK
を特定する– KSK
とDS
の鍵ID
、DNSSEC
アルゴリズム番号を比べ、KSK
を特定www.example.jp の A の署名検証 (2)
④
KSK
を認証する– DS
のハッシュアルゴリズムに従ってKSK
のハッシュ値を 計算し、DS
にあるハッシュ値と比較してKSK
を認証する⑤
DNSKEY
を認証する–
②で受け取ったDNSKEY
に付随したRRSIG(
複数)
の鍵ID
からKSK
の鍵ID
と一致するものを識別し、署名検証を 行いDNSKEY
を認証する⑥
www.example.jp
のA
を受け取る– example.jp
の権威サーバーから、A
とRRSIG(1
個以上)
を受け取るwww.example.jp の A の署名検証 (3)
⑦
RRSIG
からZSK
を識別する– RRSIG
の情報(
鍵ID
等)
に一致するDNSKEY
内にあるZSK
を識別する⑧
www.example.jp
のA
を認証する– ZSK
で署名を検証する•
必ずしも処理はこの順番ではなく、実装に依存する•
鍵ID
が衝突した場合は実際に計算して識別する•
署名検証の際、署名の有効期間、ドメイン名など他のRRSIG
のパラメータもチェックされる• DS
やDNSKEY
、RRSIG
等は、署名検証後もTTL
の有効時鍵更新と再署名
鍵更新
• 鍵更新： Key rollover
–
同じ鍵を長期間使い続けると、様々なリスクが生 じる–
不注意、偶発的事故、鍵の盗難、暗号解読等• リスクを最小に抑えるため、 DNSSEC 対応 ゾーンの運用では定期的な鍵更新 ( 鍵の交 換 ) を行う
– JP
ゾーンの場合、KSK
を年次で、ZSK
を月次で 更新する運用を行っている鍵更新時に留意すべきこと
• 鍵更新は、 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
で署名したRRSIG
が無くなるZSK の更新 ： 事前公開法 (2/2)
③ 旧 ZSK を DNSKEY から削除する
– DNSKEY
は新ZSK
とKSK
の状態になる新
ZSK
での 署名新
ZSK
での 署名旧
ZSK
での 署名旧
ZSK
でのRRSIG
署名KSK
新
ZSK KSK
旧
ZSK
新ZSK KSK
旧
ZSK
新ZSK KSK
旧
ZSK DNSKEY
③
②
① 初期状態
ZSK の更新： 二重署名法
① 新
ZSK
を作成し、新旧両方のZSK
でゾーンを署名–
ゾーン内の最大TTL
時間(+
セカンダリの転送時間)
待つ②
DNSKEY
のZSK
の旧ZSK
を削除し、新ZSK
でゾー ンを署名
ドキュメント内
DNSSECチュートリアル [ ]
(ページ 48-57)