Skip to main content
Resources

ルートゾーンKSKのロールオーバー

このページは以下の言語でもご覧いただけます。

ステータスの更新については、[ロールオーバーステータス] ページを参照してください。アップデートは、https://mm.icann.org/listinfo/ksk-rollover メーリングリストに送信されます。リゾルバに緊急事態が発生した場合は、直ちに次の情報を参照してください。

Root Zone KSK Rollover

概要
リソース
参加のお願い
背景
ドラフトタイムライン
運用計画
コミュニケーション計画

最新技術情報

2018年2月1日 - KSKロールオーバーの草案に関する発表

2017年12月18日 - ルートKSKロールオーバープロジェクトに対する更新

2017年10月17日 - ルートKSKロールオーバーの延期

2017年9月27日 - ICANN、KSKロールオーバーの延期を発表

2017年9月4日 - DNS検証リゾルバの現在のトラストアンカーの確認

2017年9月4日 - 最新のトラストアンカーによるDNS検証リゾルバの更新

2017年7月11日 - KSK-2017をDNSで公開

概要

ICANNは、ルートゾーンKSK運用者のためのDNSSEC実践書で求められているように、ルートゾーンドメインネームシステムのセキュリティ拡張(DNSSEC)KSKロールオーバーを実行する予定です[TXT、99 KB]。

KSKのロールオーバーとは、新しい暗号公開鍵と秘密鍵のペアを生成し、新しいパブリックコンポーネントをリゾルバの検証作業を運営するインターネットサービスプロバイダ、企業のネットワーク管理者および他のドメインネームシステム(DNS)リゾルバ運用者、DNSリゾルバソフトウェア開発者、システムインテグレータ、および ルートの「トラストアンカー」をインストールまたは出荷するハードウェアおよびソフトウェアディストリビューターなどの、当事者に配布することを意味します。KSKは、ゾーン署名鍵(ZSK)に暗号で署名するために使用されます。このZSKは、ルートゾーンメンテナがインターネットDNSのルートゾーンにDNSSECで署名するために使用されます。

DNSSEC検証DNSリゾルバがロールオーバーの後も機能するようにするには、最新のKSKを保守する必要があります。最新のルートゾーンKSKを使用しないと、DNSSEC検証DNSリゾルバはDNSクエリを解決できません。

KSKロールオーバー計画は、ルートゾーンを管理する複数の団体によって策定されています。ICANNは、IANA機能運用者として、Verisignはルートゾーンメンテナとして、米国商務省の電気通信情報管理局(NTIA)はルートゾーン管理者としての役割を担っています。NTIAの役割は、2016年10月1日に終了しました。KSKロールオーバー計画は、2016年7月に開示され、コミュニティのルートゾーンKSKロールオーバーの設計チームの推奨事項を取り入れています[PDF、1.01 MB]。

リソース

関連情報やその他のリソースについては、下記を参照してください。

参加のお願い

ご質問について
メールの件名に「KSK Rollover」と記載して、globalsupport@icann.orgにメールでご質問をお送りください。

イベントへの参加
イベントカレンダを参照して、今後予定されているKSKロールオーバーに関するプレゼンテーションイベントをご確認ください。

ソーシャルメディアの活用
ハッシュタグ#KeyRollを使用して、関連するトピックの議論にご参加ください。https://twitter.com/icann

KSKロールオーバーのディスカッションリストへの参加
関連するトピックに関する公開ディスカッションに参加できるメーリングリストにサインアップしてください。https://mm.icann.org/listinfo/ksk-rollover

メッセージの拡散
このWebページを他のユーザーと共有し、KSKロールオーバーとその影響の周知にご協力ください。

背景

2009年、RZMパートナーが協力して、DNSSECをルートゾーンに展開しました。そして、最終的には2010年7月に認証可能な署名済みのルートゾーンが初めて公開されました。

ルートゾーンKSKの生成およびメンテナンスの要件 [PDF、116 KB]、およびそれぞれのRZMパートナーの役割は、NTIAによって規定されました。それらの要件をルートゾーンメンテナ(Verisign)およびIANA機能運用者(ICANN) が満足するための手順については、別途、DPS (DNSSEC Practice Statement) として発表されています。Verisign DNSSEC署名サービスDPS[PDF、138 KB]およびルートゾーンKSK運用者DPS[TXT、99 KB]。

NTIAとICANNの間で締結されたIANA機能契約は、2010年7月に変更されて、ルートゾーンKSK管理に関する役割が追加されました。そして、それらの要件は、その契約の後続の改訂に引き継がれました。

NTIAとVerisignの間で締結された共同契約についても、VerisignのルートゾーンZSK運用者の役割を反映する形で、2010年7月に変更されました。

IANA機能契約により、ルートゾーンKSKロールオーバーが要求されましたが、詳細な要件や詳細なタイムラインや実装計画は提供されていませんでした。ルートゾーンKSK運用者のDPSにはこの件が記載されており、セクション6.5のロールオーバーに関する以下の要件に従うこととします。

「それぞれのRZ KSKは、要件に定められたキーセレモニーによって、または運用の5年後にロールオーバーされる。」

タイムライン

これらのタイムラインは運用上の考慮事項に基づいて変更されることがあります。

  • 2016年10月27日: 新しいKSKが生成され、KSKロールオーバープロセスが開始。
  • 2017年7月11日: DNSで新しいKSKを公開。
  • 2017年9月19日: ルートネームサーバーからのDNSKEYレスポンスの規模を増大。
  • 2018年2月1日: KSKロールオーバー再開計画に関するパブリックコメントの募集を開始しました。締め切りは2018年4月2日です。
  • ルートKSKロールオーバープロジェクト計画が更新され次第、詳しい情報を発表する予定です。

運用計画

  1. 2017年KSKロールオーバーの運用実施計画[PDF、741 KB] - 8段階のプロセスのタイムラインなど、2017年のKSKロールオーバープロジェクトを完了するための運用手順を詳細に説明します。- 2017年9月27日に発表された延期を反映するため、本ドキュメントは現在更新中です。
  2. 2017年KSKロールオーバーのバックアウト計画[PDF、506 KB] - 運用計画を実施するときに発生する問題に基づいて、予測される運用計画からの逸脱について説明します。- 2017年9月27日に発表された延期を反映するため、本ドキュメントは現在更新中です。
  3. 2017年KSKロールオーバーの外部テスト計画[PDF、516 KB] - 外部のシステムがKSKのロールオーバーに対応する準備ができているかどうかを評価するために、インターネットの一般利用者がアクセスできる運用テスト環境の準備について説明します。
  4. 2017年KSKロールオーバーの監視計画[PDF、480 KB] - ルートサーバーへのトラフィックにおけるルートゾーンのトラストアンカーの変更の影響を監視する計画について説明します。
  5. 2017年KSKロールオーバーのシステムテスト計画[PDF、519 KB] - KSKロールオーバーに関連するICANNのインフラストラクチャへの変更をテストするために必要な操作について説明します。

コミュニケーション計画

ICANNは、現在KSKを利用しているユーザーがこの変更を把握していることを確認するために、アウトリーチキャンペーンを幅広く行っています。

過去のニュース

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."