Skip to main content

ICANN、KSKロールオーバーにおける注意事項についての包括的なガイドを発行

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

2018年8月22日ロスアンゼルス発 – ICANN組織は、インターネットドメインネームシステム(DNS)を保護する暗号鍵を変更する準備を初めて進めており、ユーザーのための注意事項に関するガイドを公開しました。

「ルート鍵署名鍵(KSK)のロールオーバー」と呼ばれる鍵の変更は、現在のところ、2018年10月11日に予定されています。


新しいICANNガイドは、さまざまなレベルの技術的専門知識を有するユーザーを対象としています。


詳細な注意事項を確認でき、ロールオーバーを準備されているあらゆるユーザーにとって役立つガイドになります。このガイドは、ICANN組織が進めているロールオーバーに対する認識を向上いただくための継続的な取り組みの一環であり、ロールオーバープロセスの詳細について説明しています。

本ガイドは、ここから入手いただけます[PDF、192 KB]。ガイドを最も有効に活用できるのは、ロールオーバー時にどのような作業を実施するべきかについての明確な指示を必要とする検証リゾルバのオペレータです。ロールオーバーの前後や、ロールオーバー中に、ロールオーバーについての記事を執筆される非技術系のジャーナリスト、ブロガー、その他のユーザーの方にとっても有用な内容になっています。さらに、本ガイドは、ロールオーバーが実施された後に、リゾルバの障害の兆候についてDNSを監視する研究者にとっても有用となります。

ICANN組織は、ルートKSKロールオーバーによるユーザーへの影響は最小限になると予測していますが、少数の割合のインターネットユーザーで、ドメイン名の解決について問題が発生することが予測されており、オンラインの正しい目的地にアクセスできなくなることがあります。現在のところ、DNSSEC(ドメイン名システムのセキュリティ拡張)を検証する再帰リゾルバの中で、誤って構成されるリゾルバの数は少ないと考えられていますが、これらのリゾルバに依存するユーザーの一部で問題が発生する可能性があります。本ガイドでは、どのようなユーザーで問題が最も発生しやすいか、また、さまざまなタイミングでどのような種類の問題が発生するかについて説明します。まとめ:

問題の影響を受けないユーザー:

  • 新しいKSKを設定したリゾルバに依存するユーザー
  • DNSSEC検証を実施しないリゾルバに依存するユーザー

問題の影響を受けるユーザーとその影響:

  • すべてのユーザーのリゾルバが新しいKSKをトラストアンカー構成で使用していないと、ロールオーバーから48時間以内の任意の時点で名前解決エラー(通常は、「サーバーエラー」またはSERVFAILエラー)がユーザーに表示され始めます。注:影響を受けるリゾルバのオペレータが、検証が失敗していることをいつ認識するかを予測することはできません。

データを分析したところ、リゾルバが検証しているユーザーの99%以上がKSKロールオーバーの影響を受けないことが分かっています。ロールオーバーへの対応ができている少なくとも1つのリゾルバを使用しているユーザーは、ロールオーバー後でも、通常、DNSまたはインターネットを同じように使用できます(リゾルバがDNSSEC検証をまったく実行しない場合にも、ユーザーは同じようにDNSまたはインターネットを使用できます。現在では、DNSSEC検証を実施していないリゾルバを利用しているユーザーは全体の約3分の2ほどと見積もられています)。

最後に、ロールオーバーは現在2018年10月11日に実施される予定ですが、この実施日については、ICANN理事会の承認が待たれています。

##

KSKロールオーバーの最新情報: https://www.icann.org/resources/pages/ksk-rollover

ソーシャルメディア: #Keyroll

###

ICANNについて

ICANNの使命は、グローバルインターネットの安定性、セキュリティ、統一性の確保を支援することです。インターネット上の別のユーザーにたどり着くには、コンピュータや他のデバイスにアドレス、つまり名前または番号を入力する必要があります。コンピュータが互いに相手の場所を認識するには、アドレスが一意でなくてはなりません。ICANNでは、このような全世界で一意の識別子の調整とサポートを支援しています。非営利の公益組織として1998年に設立されたICANNは、世界中の参加者によるコミュニティを形成しています。


More Announcements
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."