翻訳文

一般社団法人日本ネットワークインフォメーションセンター
最終更新2017年5月31日

KSKロールオーバー(KSKの更新):よくあるご質問と回答

2017年5月31日

鍵署名鍵(KSK)とは何ですか？

• ルートゾーンのおける鍵署名鍵(KSK)は、 暗号化された公開鍵と秘密鍵から成る鍵の組み合わせであり、 DNSSEC (Domain Name System Security Extensions)において重要な役割を担っています。 ルートゾーンサーバが、 DNSを利用した名前解決の起点としての役割を果たしているのと同じように、 ルートゾーンKSKは、 DNSSECバリデーションにおける信頼の起点^*1の役割を果たしています。
• どのようなドメイン名も、 DNSにおける名前解決をルートゾーンから開始しますが、 これと同様に、DNSSECバリデーションを行うソフトウェアは、 ルートゾーンにおけるKSKを信頼し、 DNSにおいて署名されたデータの信頼性を検証するために、 ルートゾーンKSKを起点として連続する鍵と署名による「信頼の連鎖」を構築します。

鍵署名鍵(KSK)の更新は何をするのですか？

• KSKの更新プロセスは、 新たなKSK (KSK-2017)をルートゾーンに取り入れることにより、 ルートゾーンのトラストアンカー^*2を更新します。

なぜKSKを更新するのですか？

• 暗号鍵を永久に使い続けるのはよくないためです。 パスワードと同じく適宜変更が必要です。
• 円滑に通常の運用が行われている時点で前もって変更を行うことが、 緊急時に対応するよりも望ましいためです。
• DNSSECが2010年に運用開始されたとき、 NTIA^*3はKSKの更新を要求し、 ルートゾーンを管理するパートナーがそれに伴い、 5年の運用後に鍵を変更する要求をまとめました。 なお、NTIAの役割は2016年10月1日に終了^*4しています。

KSKの更新を知っておくべき対象者は誰ですか？

• ISP、企業ネットワークの運用者およびDNSSECバリデータを運用しているその他の方は、 それぞれのシステムで利用している新たな鍵署名鍵の公開部分を更新する必要があります。

対象者はどのように周知されるのですか？

• ICANNは、 現在のKSKの利用者が変更を把握することを担保するために、 広範囲な周知キャンペーンを実行しています^*5。
• 関心のある人は、更新が議論されているICANNのウェブサイトにて、 更新に向けたスケジュールとKSKに関する最新情報、 メーリングリストへの参加ができます。
• また、 ソーシャルメディアで#KeyRollのハッシュタグをフォローすることで随時情報を受け取ることができます。

インターネットユーザへの影響は何ですか？

• 円滑に更新が完了した場合、 エンドユーザが変更を意識することはありません。

どのような問題が起こりえますか？

• DNSSECバリデーションを行っている一部のソフトウェアは、 新たなKSKに更新されない、 またはIANAのウェブサイトに公開されているトラストアンカーファイルの変更に対応できない可能性があります。
  これらの問題が広範囲にわたる場合、ルートゾーン管理者は、 システムを安定した状態に戻せるよう、 変更を覆す必要があると判断する可能性があります。
  これは「撤回シナリオ」(back out scenario)と呼ばれています。 例えば、新たな情報が、 更新における次の段階が問題につながる可能性を示唆するようなことがあり、 もし必要であれば、 安定性確保のために更新プロセスにおける特定の段階の期間を延長する場合もあります。

撤回シナリオまたは期間延長に伴いどのような影響がありますか？

• 撤回または期間延長の目的は運用上の安定性維持ですので、 エンドユーザへの影響は最小限となります。

撤回はまたは延長はどれくらい続きますか？

• 恒久的に続くかもしれませんし、あるいは、 撤回の原因が調査されて是正されるまでかもしれません。 不具合の修正はその後、新たなKSK更新プロセスに組み込まれます。

ネットワーク運用者にとってのKSK更新による費用的な影響はどの程度ですか？

• ほとんどの場合、KSK更新の準備に向けて少額の関連費用がかかるでしょう。 しかし専任のIT担当者がいるネットワーク運用者は、 日常のネットワークメンテナンス間に特にコストをかけることなくKSK更新の準備をすることができるでしょう。
• 更新の準備をした後は、 ネットワーク運用者への費用面での影響は最小限に抑えられます。 DNS名前解決のインフラを検証するネットワーク運用者は、 鍵の自動更新を確認でき、 インフラの変更や運用手順の変更を行う必要はありません。
• ネットワーク運用者が更新に対する準備ができていないにも関わらずDNSSECを有効にしている場合、 費用的に大きな影響のあるリスクを伴います。 トラストアンカーが新しい鍵を反映するように更新されていない場合、 DNSリゾルバは、新しい鍵の下で署名された応答を改ざんされたものとして扱い、 それらの応答を破棄します。 これにより、エンドユーザーがドメイン名を検索するたびにエラーが発生し、 ユーザーからの問い合わせが発生する可能性があります。

KSKの更新は具体的にどのように行われますか？

• 8つの段階で進められ、約2年かかることが予測されています。 8つの各段階では、予定されているキーセレモニー^*6と連動します。
• KSKは、 ルートゾーンにある特定のドメイン名についてのすべての情報であるDNSKEY Resource Record Set (RRset)を署名します。 これらの署名は、キーセレモニー中に生成され、 Signed Key Responses (SKRs)の一部となります。

8つの段階の時期はいつですか？

段階 A: 鍵生成 (2016年10月)
　・KSK-2017 を第一鍵管理設備にて生成
段階 B: 鍵複製 (2017年2月)
　・KSK-2017 を第二鍵管理設備にコピー。この時点でKSKは利用可能な状態に突入する資格を持つ
段階 C: 段階 Dでの利用のためKSK-2017を利用した最初のデータ署名 (2017年5月)
　・鍵署名要求がされた最初のセットを署名
段階 D: 公開 (2017年8月) [訳注：7月]^*7
　・KSK-2017をルートゾーンで公開
　・KSK-2010およびKSK-2017の両方を、ルートゾーン署名で利用
段階 E: 切り替え (2017年11月) [訳注：10月]^*8
　・KSK-2017のみをルートゾーン署名で利用
段階 F: 失効(2018年2月) [訳注：1月]^*9
　・KSK-2010をルートゾーンから外す
段階 G: 削除 1 (2018年5月) [訳注：3月]^*10
　・KSK-2010を第一鍵管理設備から削除
段階 H: 削除 2 (2018年8月)
　・KSK-2010 第二鍵管理設備から削除

今取れる対策は何ですか？

• DNSSECバリデーションを行うソフトウェアを作っている、 またはメンテナンスしている開発者は、 RFC5011への対応を確かめるべきです。
• RFC5011に対応していない、 またはRFC5011を利用しないように設定しているソフトウェアは、 公開部分のトラストアンカーファイルをこちらから入手可能です。
• このファイルは、リゾルバの起動時および、 DNSルートゾーンにおけるDNSKEY RRsetのKSKが変更されたときに、 取り直される必要があります。
• ソフトウェア開発者およびDNSSECバリデータの運用者は、 自分のシステムがRFC5011を正しく実装し、 KSK更新時に自動的に更新されるかを評価するうえで、 ICANNが開発した運用テスト環境^*11にアクセスすることが可能です。