JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

ドメイン名関連会議報告

2021年

Interop Tokyo 2021 JPRS活動報告

2021/04/30

JPRSは、4月14日から16日までの3日間にわたり幕張メッセで開催された「Interop Tokyo 2021」にブース出展しました。Interop Tokyoは、最新のICTとそのソリューションを体感できるイベントで、2020年は新型コロナウイルス感染症拡大の影響によりオンライン開催のみとなりましたが、本年は感染防止対策を徹底した上での、リアル＆オンライン開催となりました。

JPRSブースでは、「5分で学べる！」と題した動画放映型のミニセミナーに加え、参加者との距離を十分に確保した上で、15分の生プレゼンテーション型のセミナーを実施し、ドメイン名とDNSやサーバー証明書の基礎知識、サブドメインテイクオーバーの概要と対策について情報提供を行いました。

今回のFROM JPRSでは、JPRSブースで実施した五つのミニセミナーの内容についてお届けします。

  1. 1. 5分で学べる！ドメイン名の基礎知識
  2. 2. 5分で学べる！サーバー証明書の基礎知識（常時SSL化編）
  3. 3. 5分で学べる！DNSの名前解決の仕組み
  4. 4. 5分で学べる！サブドメインテイクオーバー
  5. 5. 15分で学ぼう！サブドメインテイクオーバーの概要と防止策

なお、各セミナーの動画は以下からご覧いただけます。

Interop Tokyo 2021出展ブースのセミナー動画公開のお知らせ
https://jprs.co.jp/topics/2021/210419.html

Interop Tokyo 2021の様子

Interop Tokyo 2021の様子

1. 5分で学べる！ドメイン名の基礎知識

ドメイン名は、WebサイトのURLやメールアドレスに使われ、インターネット上の住所表示と言われています。以下の例の「example.co.jp」に当たる部分がドメイン名となります。

  例）               URL            https://example.co.jp
                   メールアドレス       taro@example.co.jp

ドメイン名は「.（ドット）」で区切られた階層構造になっており、末尾から左側に向かってTLD（Top Level Domain）、2LD（2nd Level Domain）、3LD（3rd Level Domain）と呼びます。「example.co.jp」の場合は、「jp」がTLD、「co」が2LD、「example」が3LDとなります。

▽2種類のTLD（ccTLDとgTLD）

TLDには、ccTLDとgTLDの2種類があります。ccTLD（Country Code Top LevelDomain）は、国別トップレベルドメインとも言われ、国や地域に割り当てられているTLDです。日本であれば「.jp」、フランスであれば「.fr」などです。地域では、欧州連合の「.eu」、南極の「.aq」などに割り当てられています。ccTLDの割り当ては、国際標準規格「ISO 3166-1 alpha-2（2文字で国や地域を表わす規格）」に従っています。そのため、2文字であればccTLDと判断できます。

gTLD（Generic Top Level Domain）は、分野別トップレベルドメインとも言われ、国や地域によらないTLDです。「.com」や「.net」、「.org」などはよく目にすると思います。gTLDは、2013年以降、「.toyota」「.google」「.tokyo」など、さまざまなものが登場しました。現在、gTLDは1200以上存在しており、3文字以上であれはgTLDと判断できます。

▽TLDの管理

冒頭で「ドメイン名はインターネット上の住所表示」と紹介しましたが、実際の住所が重複しないように、ドメイン名も重複しないように管理されています。その管理を行っているのが、TLDごとに存在する「レジストリ」と呼ばれる登録管理組織です。「.jp」はJPRS、「.com」や「.net」はVerisign（ベリサイン）がレジストリとなっています。

▽「.jp」の特徴

それぞれのTLDには特徴があり、日本のccTLD「.jp」には、大きく二つの特徴があります。一つ目は、登録できる対象が日本国内に住所を持つ組織・個人・団体であるという「登録要件」があることです。また、「co.jp」には、日本で登記された企業であるという、追加の要件もあります。そのため、「.jp」であれば日本に関するコンテンツやサービス、「co.jp」であれば日本の企業であることを、分かりやすく伝えられるようになります。

二つ目は、登録に関わる事業者が日本の法人組織であるという点です。レジストリのJPRS、登録を取り次ぐ指定事業者は共に、日本の法人組織です。そのため、何かあった際、サポートが日本語で受けられるというメリットがあります。「.jp」を取り扱う指定事業者は、以下より確認できます。

指定事業者一覧（JPRS）
https://jprs.jp/registration/list/

2. 5分で学べる！サーバー証明書の基礎知識（常時SSL化編）

普段、Webサイトを閲覧している時、Webブラウザーに「保護されていない通信」や「安全ではありません」といったメッセージが表示されることがあります。これは、閲覧中のWebサイトにサーバー証明書が設定されておらず、安全に接続されていないことを利用者に知らせる警告メッセージです[*1]。

なぜ、このような警告メッセージが表示されるのでしょうか。その理由を知るためには、インターネットの通信について知る必要があります。

▽ポイント1. インターネット上の通信は、そのままでは暗号化されない

通販サイトで商品を購入する場面を想像してください。利用者はパソコンやスマートフォンで商品を選び、購入に必要な個人情報やクレジットカード情報などを入力することになります。こうした情報はすべて、インターネット上を流れます。

インターネット上の通信は暗号化されていません。そのため、通信内容を第三者がのぞき見ることができた場合、そのままでは重要な情報が漏れたり、不正に使われたりする可能性があります。

▽ポイント2. 暗号化するために、サーバー証明書を設定する必要がある

そのため、第三者にのぞかれても情報が漏れないように、通信を暗号化して情報を守る必要があります。

このために使われるのが「サーバー証明書」です。Webサイトにサーバー証明書を設定している場合、URLが「https」で始まるものになります。末尾のsは「secure（安全）」を表しています。

以前は、個人情報やクレジットカード情報などをやりとりする部分のみを暗号化したWebサイトを多く見掛けました。しかし、現在はそれだけでは不十分であることが広く認知され、トップページを含めWebサイトとの通信全体を暗号化[*2]することが一般的になってきています。

▽ポイント3. https（暗号化）への対応が当たり前になってきた

こうした状況を受け、2021年4月14日にリリースされたGoogle Chrome 90では、URLバー（アドレスバー）にドメイン名を入力した際の仕様が変更されました[*3]。Chrome89では、そのドメイン名にhttpで接続していましたが、Chrome90では最初にそのドメイン名にhttpsで接続し、接続できなかった場合にhttpで接続するようになっています。

Googleでは以前の仕様を、多くのWebサイトがhttpsをサポートしていなかった、過去のものであると説明しています。このような状況からも、サーバー証明書を設定してWebサイト全体をhttpsに対応させることはもはや特別なことではなく、標準的に設定するものであるという認識が広がっていくものと考えられます。

▽サーバー証明書もJPRS

最後にJPRSサーバー証明書のご紹介です。JRPSもサーバー証明書を提供していますので、インターネット上の通信の暗号化をお考えの際は、ぜひご検討ください。
https://jprsサーバー証明書.jp/

[*1]
iPhone/iPad/Macで「安全ではありません」が表示される理由とその解決方法 | JPRS
https://jprs.jp/pubcert/about/guide/20190513-safari-warning.html
[*2]
常時SSL化について | JPRS
https://jprs.jp/pubcert/about/aossl/
[*3]
A safer default for navigation: HTTPS
https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html

3. 5分で学べる！DNSの名前解決の仕組み

利用者からの要求に応じ、名前に対応する情報を取り出すことを「名前解決」といいます。名前解決の例として、ドメイン名に対応するIPアドレスの検索や、メールサーバーホスト名の検索などが挙げられます。

DNSの名前解決では「情報が欲しい人」「情報を探す人」「情報を提供する人」の3種類の人物が登場します。DNSではこれらをそれぞれ「スタブリゾルバー」「フルリゾルバー（キャッシュDNSサーバー）」「権威DNSサーバー」と呼びます。

▽スタブリゾルバーの役割

スタブリゾルバーはPCやスマートフォンなど、利用者側の機器で動作します。Webブラウザーやメールソフトなど、名前解決が必要になったアプリケーションから呼び出されたスタブリゾルバーは「名前解決を実行して、その結果を教えてください」という問い合わせを、フルリゾルバーに送ります。この問い合わせを「名前解決要求」と呼びます。

▽フルリゾルバーの役割

スタブリゾルバーから名前解決要求を受け取ったフルリゾルバーは、名前解決を実行します。フルリゾルバーは権威DNSサーバーの階層構造をたどる形で名前解決を実行し、得られた結果をスタブリゾルバーに返します。

また、フルリゾルバーは名前解決の効率を上げるため、権威DNSサーバーから得た応答をしばらくの間蓄え、次回以降の名前解決に活用します。この仕組みのことを「キャッシュ」と呼びます。

▽権威DNSサーバーの役割

フルリゾルバーから問い合わせを受け取った権威DNSサーバーは、自分が保持している情報を応答します。

DNSでは、委任によって作られる管理の単位のことを「ゾーン」と呼びます。権威DNSサーバーは親から委任されたゾーンの情報と、自分が委任したゾーンの委任先（どの権威DNSサーバーに委任したか）の情報を保持し、DNSの階層構造を形作ります。

▽名前解決の流れ

example.jpのIPアドレスを検索する場合を例として、名前解決の流れをご紹介します。

フルリゾルバーは、事前にインストールされたルートサーバーの一覧を持っています。スタブリゾルバーから名前解決要求を受け取ったフルリゾルバーはルートサーバーの一覧を参照して、ルートサーバーに問い合わせを送ります。

ルートサーバーはjpを委任しているため、jpを委任している旨と、その委任先を応答します。応答を受け取ったフルリゾルバーはその情報をキャッシュに蓄え、その案内に従い、jpの権威DNSサーバーに問い合わせを送ります。

jpの権威DNSサーバーはexample.jpを委任しているため、example.jpを委任している旨と、その委任先を応答します。応答を受け取ったフルリゾルバーはその情報をキャッシュに蓄え、その案内に従い、example.jpの権威DNSサーバーに問い合わせを送ります。

example.jpの権威DNSサーバーはexample.jpのIPアドレスを保持しているため、その情報をフルリゾルバーに応答します。これが名前解決の最終結果となり、フルリゾルバーはその情報をキャッシュに蓄えた上で、スタブリゾルバーに応答します。

そして、この名前解決により「ルートはjpを委任していること」「jpはexample.jpを委任していること」「example.jpのIPアドレスは192.0.2.1」という情報がフルリゾルバーのキャッシュにしばらくの間蓄えられ、次回以降の名前解決に活用されます。このように、キャッシュを活用することで権威DNSサーバーに再問い合わせをする必要がなくなり、名前解決の負荷と時間を軽減できます。

4. 5分で学べる！サブドメインテイクオーバー

最近、期間限定のキャンペーンサイトや特設サイトの終了後にそのサイトへのアクセスを奪い、詐欺サイトや詐欺サイトに誘導するおとりサイトを開設する事例が報告されています。

アクセスを奪う手法はサイトの中身を直接書き換える方法と、攻撃者のサイトにアクセスを誘導する方法に分けられます。アクセスを誘導する方法にはさまざまなものがありますが、このミニセミナーでは、DNSの運用ミスに付け込む「サブドメインテイクオーバー」の概要と防止策について解説しました。

▽CDNサービスを利用した期間限定サイトの開設

期間限定のキャンペーンサイトを構築する際、外部のCDN（Content DeliveryNetwork）サービスを使って、自分のドメイン名のサブドメインでサイトを公開することがあります。例えば、example.jpの管理者がcampaign.example.jpというドメイン名で、期間限定のキャンペーンサイトを開設する際の手順の例は、以下となります。

 （1）CDNサービスを契約し、campaign.example.jpのWebサーバーを設定
 （2）example.jpの権威DNSサーバーに、campaign.example.jpのCNAMEレコードを設定
   ＜設定するCNAMEレコード＞
   campaign.example.jp. IN CNAME cdn.example.net.

▽期間限定サイトの終了

キャンペーン終了後にこのサイトを終了する場合、以下の二つを実施する必要があります。

 （1）CDNサービスを解約し、campaign.example.jpのWebサーバーを削除
 （2）example.jpの権威DNSサーバーから、campaign.example.jpのCNAMEレコードを削除

もし、終了時に（1）のWebサーバーの削除のみを実施し、（2）のCNAMEレコードの削除を実施しなかった場合、campaign.example.jpをサブドメインテイクオーバーされる可能性がある、危険な状態になります。

▽サブドメインテイクオーバーのシナリオ

この状態のドメイン名を見つけた攻撃者は、解約されたCDNサービスと同じCDNサービスを契約し、同じドメイン名でWebサーバーの設定を試みます。

もし、同じドメイン名でWebサーバーが設定できた場合サブドメインテイクオーバーが成立してしまい、example.jpの管理者が意図しないコンテンツがcampaign.example.jpのドメイン名で公開されてしまうことになります。

サブドメインテイクオーバー可能な状態は、外部からのDNS検索で発見できます。総当たり検索を高速に実行するツールがネット上で公開されており、攻撃者はそうしたツールを利用することで、攻撃対象を効率良く発見できます。

▽サブドメインテイクオーバーの防止策

サブドメインテイクオーバーの防止策には、CDNサービスの利用者ができるものと、CDNサービスを提供する事業者ができるものがあります。

利用者ができる防止策として、CDNサービスの使用終了時に、DNS設定も削除することが挙げられます。サイトを構築した際に設定したCNAMEレコードを忘れずに削除するようにすることで、サブドメインテイクオーバーの発生を防止できます。また、チェックツールを用いて、攻撃可能なDNS設定が残っていないかをチェックし、削除することも有効な対策となります。

事業者ができる防止策として、利用者がWebサーバーを設定する際の認証の強化と、Webサーバーを削除する際のCNAMEレコードの削除の確認が挙げられます。前者では、Webサーバーの設定時にサーバー証明書の提出を必須とする、後者では、Webサーバーを削除する際にCNAMEレコードの削除を確認し、削除されていない場合にはエラーとするといった対策が、一部のCDNサービス事業者により実施されています。

5. 15分で学ぼう！サブドメインテイクオーバーの概要と防止策

サブドメインテイクオーバーは2020年7月までに100件以上の被害事例が確認されており、その中には上場企業や地方公共団体のドメイン名も含まれています。被害事例の報告が現在も続いていることから、今回のInterop 2021では動画の展示に加え、1日4回の生プレゼンテーション型のセミナーも併せて実施しました。

セミナーでは動画で紹介した内容に加え、サブドメインテイクオーバーされた際の具体的な危険性や被害状況の紹介、著名企業や政府関係の公式サイトなど、検索で上位に表示されるドメイン名のサブドメインを利用したSEOポイズニングなどの内容を加え、時間を15分に延長して開催しました。

JPRSのWebサイトで公開中の情報提供資料

JPRSブースで配布した資料の一部は、JPRSのWebサイトでも公開しています。以下のURIからぜひご覧ください。また、最新情報をソーシャルメディアのJPRS公式アカウントより随時配信しておりますので、こちらも併せてご確認ください。
https://jprs.jp/sns.html

関連URI

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。