本当にあった「SaaSタグ×ドロップキャッチ」の怖い話……組織におけるドメイン名管理に必要な要件とは

　「Internet Week 2022」において11月29日、DNSに関する話題を集めたプログラム「DNS DAY」が開催された。本稿では、その盛り沢山の話題の中から、恒例となっているセッション「DNS Update」のほか、ブランドレピュテーションリスク[*1]の大きさから注目を集めている、ドメイン名ライフサイクルマネージメントの話題を中心に取り上げる。

HTTPS RRへの対応が進み、「.tk」を含むいくつかのccTLDが統計情報の調査対象から除外

　「DNS Update」最初の報告は、WIDEプロジェクトの関谷勇司氏による「Root DNS Update」である。Mルートサーバーには大きな障害・攻撃はなく順調に運用できていること、新たな拠点として、アメリカのグアム、マレーシアのクアラルンプール、タイのバンコクを追加したことなどが報告された（図1）。

図1：2022年11月時点でのMルートの拠点（赤字が追加された拠点）

　続いて、株式会社日本レジストリサービス（JPRS）の池田和樹氏による「JP DNS Update」では、jpゾーンを管理するJP DNSの状況に関する報告が行われた。JPドメイン名の登録数は増加傾向が続いており、JP DNSへのクエリ数の伸び率も増加していること（図2、図3）、IPv6で到達したクエリ数の比率には大きな伸びはないが、増加傾向にあること（図4）などが報告された。

図2：JPドメイン名登録数の推移

図3：JP DNSへのクエリ数の推移

図4：IPv6でトランスポートされたクエリの比率

　一般社団法人日本ネットワークインフォメーションセンター（JPNIC）の小山祐司氏による「逆引きDNS Update」では、逆引きDNSにおけるlame delegationの改善に関する報告が行われた。

　lame delegationは、DNSにおいて委任先の権威DNSサーバーが委任されたゾーンの情報を適切に返さない状態を示す用語である。あるゾーンがlame delegationになっていると、そのゾーンの名前解決の遅延や失敗が発生するだけでなく、ドメイン名の管理権限を奪われる「ドメイン名ハイジャック」の原因にもなり得るため、注意が必要である。

　小山氏によると、JPNICが管理する逆引きゾーンに占めるlame delegationの割合は現在、0.2％程度となっている（図5）。逆引きDNSは一般利用者が普段使うものではないため、意識することは少ないかもしれない。しかし、送信元IP アドレスの逆引きゾーンが名前解決できなくなると、メールサーバーに受け取りを拒否されたり、アクセス時の認証に支障が生じたりする可能性がある。そのため、逆引きゾーンの管理者は、JPNICがlame delegationであると判断する条件や実施している対策（図6）をきちんと確認し、lame delegationを起こさないように運用する必要がある。

図5：逆引きゾーンに占めるlame delegationの割合

図6：JPNICでlameであると判断する条件と対策

　NTTコミュニケーションズ株式会社の小坂良太氏による「フルサービスリゾルバー利用状況」では、OCNのフルサービスリゾルバー（キャッシュDNSサーバー）に到達するクエリとレスポンスを分析した結果が報告された。小坂氏によると、2019年から2021年にかけて観測されたクエリ数の急増は落ち着きを見せたものの、その原因の1つであるHTTPSリソースレコード（RR）のクエリ数の増加は現在も続いており、2022年10月現在で全体の15％に達したとのことであった（図7、図8）。

図7：ユーザーからのクエリ数

図8：ユーザークエリにおけるクエリタイプの割合

　小坂氏からは、権威DNSサーバーから返されるHTTPS RRのレスポンスを分析した結果として、使用頻度の高い有名なドメイン名にヒント情報（ipv4hint・ipv6hint）なしのHTTPS RRが設定されていること、HTTPS RRが設定されているユニークなドメイン名の数は19万を超えており、実際に使われ始めていること、夜（21時ごろ）にレスポンス数が増えることから、HTTPS RRは現時点ではビジネス用途よりも、コンシューマーがアクセスするドメイン名に設定されている傾向にあるように思えるといった項目が示された（図9）。

図9：HTTPSレコードの利用数（レスポンス数）

　また、小坂氏からは、「到達するHTTPS RRのalpnパラメーター（アクセス先のウェブサーバーで使用可能なプロトコル）の内容を見ると、QUICで通信するHTTP/3にウェブサーバーを対応させる際、HTTPS RRを設定しているのではないか」という考察も示された（図10）。

図10：HTTPSレコードが設定されているドメイン数（FQDN数）

　こうした状況から、ユーザーが使用するウェブブラウザーやアプリにおけるHTTPS RRのサポートが進み、ウェブサービスの提供側におけるHTTP/3への対応が進むことで、HTTPS RRの利用・普及がさらに進んでいくと考えられる。引き続き、HTTPS RRの動向には注目していきたい。

　また、OCNのフルサービスリゾルバーに到達するDNSクエリにおいて、IPoE（IPv6）経由のトラフィックの割合が全体の70％を超えており、1日の総クエリ数においても50％を超えていることが紹介された。IPoEの普及により、ユーザーにおけるIPv6の利用率が確実に上がっていることが伺える（図11）。

図11：OCN DNSのIPv4/IPv6のトラフィック割合

　JPRSの高松百合氏による「DNS Update～ドメイン名全般～」では、gTLDを含むドメイン名全般に関する話題が報告された。高松氏からはまず、インターネットのドメイン名の総数が昨年同時期から減少した旨と（図12）、本件は単純な減少ではなく、「.tk」（トケラウ）を含むいくつかのccTLDが統計情報の調査対象から外されたことが原因の1つとなっている旨が示された（図13）。

　高松氏の発表では、統計情報の出典として、ベリサイン社が四半期ごとに公開している「Verisign Domain Name Industry Brief」[*2]が使われている。ベリサイン社では、.tkなど5件のccTLDについて2021年第4四半期以降、統計情報とトレンドの計算から除外する旨を発表している[*3]。

図12：全TLDでのドメイン名数

図13：登録数の多いTLD（.tkが外れている）

　また、高松氏からはgTLDの登録数については特に目立った動きは見られなかったこと（図14、図15）、ヨーロッパ地域ではコロナ禍に伴い、ドメイン名の登録数が増える時期があったが現在ではそれも落ち着き、少しずつ増えるという従来からの傾向が復活してきている旨が報告された。

図14：登録数の推移（gTLD）

図15：登録数の推移（.gTLD/.com以外）

　新gTLDの登録数については、相変わらず増えたり減ったりという状況のようである（図16、図17）。新gTLDの次回募集開始に向けた動きについては、現在はICANN事務局において設計および実装の検討評価をする運用設計フェーズ（Operational Design Phase：ODP）の段階であり、具体的な募集開始時期については、現時点で未定であるとのことであった（図18）。

図16：新gTLDの登録数の推移

図17：新gTLD登録数の内訳

図18：新gTLD次回募集に向けた動き

組織におけるドメイン名管理に必要な要件とは

　「ドメイン名ライフサイクルマネージメント」のセッションは、NTTコミュニケーションズ株式会社の神田敦氏、株式会社リクルートの須藤悠氏、NTTコミュニケーションズ株式会社の藤崎智宏氏の3名がそれぞれ発表を行い、日本DNSオペレーターズグループ幹事の高田美紀氏がファシリテーターとして参加者から質問を受け、議論を誘導するという形式で行われた。以降では、使用していたドメイン名を悪用される怖さを具体例で説明した神田氏の発表を中心に、ドメイン名の使用を止める際に必要な対策にフォーカスを当てて取り上げる。

　神田氏の発表「本当にあったドロップキャッチの怖い話～Visionalistの場合～」では、ドロップキャッチの中でも、外部情報の表示やアクセス解析などに用いられるSaaSタグに含まれるドメイン名をドロップキャッチされることがどれくらい怖いかという点に、フォーカスが当てられている。

　SaaSタグとは、SaaSを利用するためにウェブサイトに埋め込まれるコード、あるいはそのコードへのリンクであり、ウェブページ内に埋め込まれ、そのページが読み込まれた際にユーザー側の端末上で動作する。

　SaaSタグで注目すべき点は、サービスを提供する事業者とサービスを利用するウェブサイト管理者の間で、責任と作業範囲が分担されていることである。サービスを利用開始・終了する際、サービス事業者のタグを埋め込んだり削除したりすることは、顧客であるウェブサイト管理者の裁量で可能である。しかし、サービス事業者がサービスそのものを終了する場合、顧客のウェブサイトに埋め込まれたタグを、自らの判断で削除することは不可能である。そのため往々にして、サービスの終了後に顧客のウェブサイトに埋め込まれたタグが放置されている状態が発生することになる（図19、図20）。

図19：（SaaS）タグとは

図20：タグを用いるSaaSの特徴

図21：SaaSタグ×ドロップキャッチが怖い理由

　この状態で、悪意のある第三者がタグに含まれるドメイン名をドロップキャッチできた場合、そのドメイン名のアクセス先にウェブサーバーを設定して任意のコードを置いておくだけで、タグが埋め込まれたウェブサイトにアクセスしたユーザー側の端末でそのコードを実行させることができてしまうことになる（図21）。つまり、タグが放置されているウェブサイトがあればあるほど、攻撃者にとっておいしいターゲットになるのである。神田氏は、NTTコムオンラインが提供していたウェブアクセス解析サービス「Visionalist」の事例[*4]を使い、この問題を説明した（図22～図24）。

図22：Visionalistで起きたことのタイムライン

図23：見つかった不審なスクリプト（抜粋）

図24：Visionalist以外でも、繰り返し発生するSaaSタグドロップキャッチ

　ドロップキャッチに限らず、かつて使用していたドメイン名を悪意のある第三者に登録されてしまうことはブランドレピュテーションの大きなリスクである。では、その問題にどのように対処すればいいのであろうか。神田氏はサービス事業者、つまりドメイン名登録者が取りうる対策として4つの案を提示した（図25、図26）。

図25：取りうる対策（1）

図26：取りうる対策（2）

　個人的によく聞くのは、最初に挙げられている、サービスへの通信量をモニターして十分にトラフィックが減ったことを確認してからドメイン名を廃止するという対策だが、通信量のモニタリングコストは決して安くなく、適切なタイミングでサービスを終了するためには、サービス事業者として何らかの基準で終息を判断しなけなければならないことになる。また、ドメイン名の廃止に伴うトラブルが発生しないようにするための仕組みの導入、トラブルが発生した際の組織へのダメージやその回復にかかるコストは、相当に高額なものとなりうる。

　そうした状況を考えた場合、神田氏が言うように、「ドメイン名の維持費はそれほど高いものではない。1年で3000円としても、10年で3万円、100年でも30万円」「使用を終了したドメイン名を（半）永久的に保持するというのが、実は一番安上がりで確実なのかもしれない」という言葉には重みがあった。

　続いて須藤氏から、リクルートにおける取り組みが紹介された。同社では社内でドメイン名の管理フローを整備し、集約しているとのことで、ドメイン名の使用を止める際には第三者に登録されないように、ドメインパーキングに移行する仕組みが作られているとのことである（図27）。須藤氏からは、登録した部門・組織がなくなった際にも対応できるように、ドメインパーキングには全社横断で取り組み、そのための予算を確保することが重要である旨が示された（図28）。

図27：ドメイン名の管理指針

図28：サービス終了後のドメインパーキングのコストについて

　藤崎氏からは、NTTコミュニケーションズ社内で活動している「ComNIC（コムニック）」という社内のNIC（ネットワークインフォメーションセンター）が紹介された。ComNICではドメイン名の廃止について「独自ドメイン名に関し、第三者が再取得し悪用した際の風評被害等のリスクを考慮し、利用終了から2年保持したのち、解約、廃止することとする」というルールが整備されていることが説明された（図29、図30）。

図29：ドメイン管理ルール（廃止）

図30：組織における資源管理に関する課題等

　本セッションでは会場やオンライン参加者から質問が相次ぎ、活発な議論が行われた。須藤氏や藤崎氏から示されたように、登録・廃止を含むドメイン名の管理については、使いたい部門それぞれに任せるのではなく、組織を横断するかたちでの体制作りが重要であり、そうした対応が必要であるという認識を、組織として共有することが不可欠である。つまり、ドメイン名のライフサイクルマネージメントに必要なのは、組織全体におけるリスクマネージメントなのである。

SVCB/HTTPS RRの標準化は、TLS ESNIのRFC発行後になる見込み

　最後に、JPRSの藤原和典氏による「IETF/RFC動向」の中から、SVCB/HTTPS RR[*5]の標準化の状況を説明した部分を紹介する。本提案に関する作業はすでに終了しており、RFC発行待ちとなっているが、発行には時間を要する見込みとなっている。

　藤原氏はその理由として、SVCB/HTTPS RRの仕様がTLS（Transport Layer Security）の検討を行うtls WGが標準化作業を進めている「TLS ESNI」[*6]の仕様を参照しており、RFC発行はESNIのRFC発行後になると見込まれている旨を解説した（図31）。

　なお、本稿で紹介した小坂氏の発表にあるように、HTTPS RRは一部のウェブブラウザーやCDN（Content Delivery Network）サービスにおいてRFCの発行前から使われており、インターネット上のDNSトラフィックのかなりの部分を占める状態になっている。

図31：SVCB/HTTPS RRについての進捗具合

　今回、DNS DAYは「ハイブリッドWeek」のプログラムの1つとして、オンラインと東京大学伊藤謝恩ホールの会場にて開催された。筆者は会場で参加したが、参加者との距離感がより近く感じられ、話者のマイク経由ではつかみ切れない会場内での反応など、オンラインでは得られない豊富な情報も得ることができた。発表後に話者を捕まえて内容の確認をしたり、名詞を交換したりと、リアルイベントで行われることのメリットはやはり大きいと感じた。

　もちろん、オンラインでの参加にも、物理的な距離の壁を越えられる、感染症のリスクを回避できるといったメリットがある。開催者側は大変であろうが、オンライン／オフラインの双方によるハイブリッド形式での開催は時代の要請でもあり、今後も継続して欲しいと思う。

　今回のDNS DAYはプログラムの内容が濃く、記事の執筆時にどの話題を取り上げるべきかの絞り込みに苦労するという楽しさもあった。入ってきた情報量が、それだけ豊富であったということの裏返しでもあるからだ。

　この記事を読まれている方も、このようなイベントにどんどん参加していただきたい。書き切れなかった情報の中に、あなたの望む情報があるかもしれないのだから。