JPNIC Blog JPNIC

インターネット資源の健康度を測る -ITHIのご紹介-

dom_gov_team 

前回までにICANNの技術政策文書そのものをご紹介してきましたが、今回はICANN OCTOが行っている取り組みであり、各種技術政策文書等でも活用されるIdentifier Technologies Health Indicators (ITHI)を紹介します。

 

ITHIはICANNの管理するインターネット資源、すなわちIPアドレスやドメイン名などの現在の健康度とそのトレンドを測るため、実際のトラフィックや脅威情報などを分析して数々のメトリクスを算出し定期的に公開するプロジェクトです。主要なIXPやDNSサーバ運用者、情報セキュリティ企業などと協力し、プライバシーに配慮しながら実際のパケットをサンプリング・分析したり、ICANNに登録されている情報や商用のブロックリストと照らし合わせたりすることで、実世界のインターネット資源がどの程度適切に管理・運用されているかをいくつもの項目に分かれたメトリクスとして公開しています。メトリクスの詳細や現在の数値などは、ダッシュボードにアクセスすることで誰でも閲覧できるようになっています。

メトリクスの分類

メトリクスにはM1からM11とEAIの12種類があり、さらに各メトリクスの中で最大3階層のサブメトリクスが設けられています。ここでは一番大きな分類を紹介します。

M1: Whoisデータの不正確性

M1メトリクスは現在非公開となっています。

M2: Domain Name Abuse[1]

M2メトリクスは不正利用されているドメイン名について、そのTLDや登録しているレジストラに基づいて分析しています。また、不正の種類として、フィッシング、マルウェア配布、C&Cとボットネット、スパムの4種類を定義しており、これらはICANN OCTOが実施している別のプロジェクトであるThe Domain Abuse Activity Reporting (DAAR) Systemを利用して分析しています。不正利用されているドメイン名の検知には商用のブロックリストなどが用いられています。

M3: DNSルートトラフィック分析

M3メトリクスはDNSルートサーバへのトラフィックを基に、実際に名前解決されている適切でないドメイン名の種類などを分析しています。また、DNSの追加仕様ともいえるEDNS、DNSSEC、QNAME minimizationについても分析しています。

M4: DNS再帰サーバ分析

M4メトリクスはDNSリゾルバへのトラフィックを基に、実際に名前解決されているドメイン名の種類などを分析しています。また、クライアントのDNSSEC対応率も分析しています。

M5: 再帰リゾルバの完全性

M5メトリクスはDNSリゾルバからDNS権威サーバへのトラフィックなどを基に、キャッシュ更新の動作やDNSSEC検証の動作などについて分析しています。また、特定のリゾルバやリゾルバサービスにどのくらいのクライアントが集中しているのかも分析しています。

M6: DNSパラメータに関するIANAレジストリ

M6メトリクスはネットワークトラフィックのパケットキャプチャや各種 DNS サーバのログ、オープンデータなどから、レジストリごと・パラメータセットごとについて、IANAレジストリにパラメータが登録されている各種技術の使用状況などを分析しています。

M7: DNSSEC デプロイメント

M7メトリクスはTLDおよびccTLDごとにDNSSEC署名を行っているゾーンの割合を分析しています。また、使用しているDNSSECアルゴリズムごとの分析も行っています。

M8: DNS権威サーバ分析

M8メトリクスはDNS権威サーバから見たクエリの状態やリゾルバの技術対応状況などを分析しています。

M9: 権威サービスの集中化

M9メトリクスは1ドメイン名あたり平均していくつの権威サービスを使用しているかなど、DNS権威サーバ運用のサービス集中化について分析しています。

M10: DNSリゾルバサービスの集中化

M10メトリクスは国ごとにどのくらいオープンDNS (公開リゾルバサービス) を利用しているかなど、DNSリゾルバ運用のサービス集中化について分析しています。

M11: TLDとSLDでのDNSSECデプロイメント

M11メトリクスはTLD別などでのDNSSEC署名率や使用しているDNSSECアルゴリズムの割合などを分析しています。

EAI: メールサーバのEAI (Eメールアドレス国際化) 対応

EAIメトリクスはTLDごとにどれくらいEAIに対応したメールサーバがあるかなどを分析しています。12のメトリクスで唯一、現在だけでなく過去のデータもCSV形式で提供しています。

主要なメトリクスと読み方

このようにメトリクスの大分類だけでも12、サブメトリクスを含めると非常に多くのデータを分析しているITHIですが、その中でも特にインターネットの健康度を測るための主要なメトリクスのデータについて、その読み方を含めてご紹介します。

M3.1: ルートサーバが受信したクエリのうちNXDOMAINだった割合

ルートサーバでは、DNSのルートからTLDに対する権威サーバの委任情報を提供しています。そのため、詳細なホスト名の情報などを提供する他の権威サーバと比べると、NXDOMAIN(クエリされたドメイン名は存在しない)という応答は少ないはずです。つまり、この値が低いほど健康であるといえます。しかし実際は、組織内部のみで使っているプライベート用途TLDなどがクエリされています。これらはルートサーバに不必要な負担をもたらすだけでなく、このようなドメイン名が外部の権威サーバにクエリとしてリークすると、組織内部のホストやネットワーク構成などセキュリティにかかわる情報を推測する手がかりとなります。なお、プライベート用途TLDについては関連するSAC113という文書について前回の記事でご紹介していますので、あわせてご覧ください。

M5.4.2: DNSSEC検証を行っているリゾルバの割合

観測できているDNSリゾルバのうち、実際にDNSSEC検証を行っているリゾルバの割合を示しています。つまり、この値が高いほど健康といえますし、同時に普及の道半ばであるDNSSECの普及率の一つの指標にもなります。

M3.3: ルートサーバが受信したNXDOMAINとなるTLDとその割合

上記でご紹介したM3.1の中でも、具体的にどのようなTLDが一番クエリされているのか、そのクエリはM3.3の中でもどのくらいの割合を占めているのかを示しています。つまり、このTLDが特異なものではなく、かつ値が低いほど健康であるといえます。トップページではその第1位のみが表示されていますが、M3メトリクスのページではそれ以外のTLDと割合なども閲覧することができます。

M4.2/4.3: リゾルバが受信した特定のTLDとその割合

M3.3と似たようなメトリクスですが、いくつか違いがあります。まず、観測点がルートサーバではなくリゾルバであることです。また、リゾルバで観測している関係で、NXDOMAINとなるクエリを調べているのではなく、受信したうちRFC6761に定義されたTLDと頻繁にリークしているプライベート用途TLDについて調べています。最後に、ここで示される割合は取り上げた2種類のTLDのクエリに占める特定のTLDの割合ではなく、受信したすべてのクエリに対する特定のTLDの割合となっています。そのため、M3.3の割合とM4.2/4.3の割合を一律に比較することはできません。トップページではその第1位のみが表示されていますが、M4メトリクスのページではそれ以外のTLDと割合なども閲覧することができます。

M5.6.1: サブネット内で最初のDNSクエリのうち半数を受信するリゾルバの数

M5.6とM5.7では、リゾルバサービスの集中化の具合について、観測されたうち50%および90%のクライアントからのクエリがどれだけのリゾルバに送信されているかを分析しています。M5.6.1はその中でも代表的なメトリクスです。この数値が大きいほど、クライアントからクエリが送られるリゾルバが分散されていることになります。逆に、プライバシーの視点では不必要に多くのリゾルバに対してクライアントがアクセスしたいドメイン名を知らせることになり、一概にこの数字だけを見て健康かどうかを判断するのが難しいメトリクスの一つです。

M2.2.1.1: 10,000ドメイン名に対するレジストラごとのフィッシングドメイン名の数

レジストラが登録しているドメイン名について、10,000ドメイン名中いくつのドメイン名がフィッシングに用いられているかを示しています。つまり、この値が低いほど健康であるといえます。なお、フィッシングに限らず不正利用されるドメイン名は特定のTLDやレジストラに偏る傾向があるため、この値だけを見てドメイン名不正利用に対する健康度の尺度とするのは難しく、ある不正をしているドメイン名の50%、90%が利用しているTLDやレジストラにおいてどれくらい不正利用されているドメイン名があるかというメトリクスもM2で提供されています。

ITHIを活用する

ITHIには上記でご紹介したよりも遥かに多いサブメトリクスがあり、そのすべての数字の意味を理解するのは難しいかもしれません。また、ITHIのほとんどのデータは現在ITHIダッシュボードでのみ提供されており、確認できる時系列も最新の値、過去3ヶ月の値、記録上の最低値、最高値などに限定されています。中には過去のデータをCSV形式で参照できるものや、ダッシュボード上で時系列推移グラフが提供されている場合もありますが、いずれにせよ機械的にデータを取り込んで分析するというよりも人間が数字を読んで理解する方が向いています。

それでも、継続的にメトリクスを確認することでインターネット全体のセキュリティに関する動向を掴む手がかりを得られる可能性があります。特に、ドメイン名やIPアドレス資源をユーザ企業に提供するような組織においては、自社で管理している資源の利用状況とITHIの特定のメトリクスとを照らし合わせることで特異な異常を検知する手がかりになるでしょう。また、インターネット資源について学ぶ上でITHIの過去のメトリクスを含めてトレンドとして認識することで、過去から現在への資源の使われ方の移り変わりや最近の情勢を知る手がかりになります。

現在ダッシュボード上で閲覧できない過去の詳細なデータやトレンド[2]に関しても、インターネットコミュニティ全体にとってより価値のある情報として今後活用できるようになることを期待します。

まとめ

本稿では技術政策文書そのものではなく、その作成やポリシー形成の背景に活用されるシステム・プロジェクトの一つであるITHIについて、その目的や概要、一部の主要なメトリクスの読み方などをご紹介してきました。ICANN OCTOが普段どのような技術的プロジェクトを行っているのか、インターネット上の識別子についてICANNがどのような観点から健全性を維持しようとしているのかを知るきっかけにして頂ければ幸いです。

 

[1] ICANNではDomain Name AbuseないしDNS Abuseという語はフィッシングなどDNSやドメイン名の不正利用を指すもので、DNS通信やプロトコル自体の不正利用は基本的に含まれません。なお、ITHIでは後者に関連したメトリクスをM3以降で確認することができます。

[2] APNICが運営するAPNIC Labsでは関連するデータをより詳細なグラフで提供しており、一部のデータは実際にITHIのメトリクス算出のために使用されています。

この記事を評価してください

この記事は役に立ちましたか?
記事の改善点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、 お問い合わせ先 をご利用ください。