概略
前回「ダングリングDNSとドメインの終活【前編】」では、放置されたDNSによるセキュリティ被害について記しました。
今回は、悪用リスクを軽減するために、不要になったドメインの破棄における注意点などについて記します。人間のターミナルケアになぞらえて ドメインの終活 などと呼ばれています。
安易にドメインを取得・廃棄するのではなく、一度取得したドメインは生涯面倒を見る心意気が必要です。なぜなら、登録を放棄した瞬間から、そのドメインは第三者の手に渡る可能性があり、意図せずフィッシングやマルウェア拡散などに悪用されることがあるからです。たとえ利用をやめたサービスのドメインであっても、かつてそこにアクセスしていた利用者や検索エンジンのキャッシュを通じて、引き続き人が訪れることは少なくありません。廃棄は終わりではなく、新たなリスクの始まりでもあるのです。
そのため「廃棄しない」という選択肢も含め、慎重な検討が求められます。どうしても廃棄せざるを得ない場合には、最後まで適切に管理・整理してから手放すことが肝要です。
本稿に記載した内容は、個人的な見解を示したものであり、筆者の所属する企業・団体の公式見解ではありません。
ドメインを廃棄する理由
まず、なぜドメインを廃棄しなければならないのでしょうか。
事情はドメインを取得した組織・個人によって様々です。たとえば、一時的なキャンペーンのために利用していたが役目を終えた場合、組織の統廃合や社名変更で旧ブランドが不要になった場合、あるいは維持コストの削減を目的とする場合などが挙げられます。
しかし、その前段の話として 取得したドメインは原則として廃棄しない 方針を定めることも重要と考えています。長期にわたり保持することで、将来的なブランド価値の保全やサイバー攻撃の防止につながるからです。
ドメイン廃棄に伴うリスク
ドメインを廃棄した後、そのドメインは第三者に再登録され、過去の利用者を狙った攻撃に利用される可能性があります。これを「ドメインテイクオーバー」と呼び、特に次のような被害が懸念されます。
- 旧サイトにアクセスしてきた利用者をフィッシングページへ誘導する
- かつて送られていたメールアドレスに届くはずの通信を横取りする
- ブランドを装った偽サービスやスパム拡散に利用される
こうした事態は「もう使っていないから安全だろう」と油断した隙に発生します。ドメイン廃棄は単なる契約解除ではなく、外部にリスクを押し出す行為であるという認識が不可欠です。
ドメイン廃棄までにやること
ドメインを廃棄することを決定したら、様々な対応を行わなければなりません。
- アクセス元の調査
- 廃棄予定ドメインへのアクセスが残っていないかをログやアナリティクスで確認
- リンクの整理
- 外部サービスやパートナーサイトに残るリンクを洗い出し、可能であれば削除を依頼
- 終了案内の掲示
- サイト訪問者にサービス終了を明示し、誤解や詐欺利用の余地を残さない
- メール関連設定の整理
- SPF・DMARC・NULL MX レコードなどで、送信や受信の扱いを明確化
- 監視と猶予期間
- 廃棄前に一定期間はキャッチオールで監視し、予期せぬ利用が残っていないかを確認
アクセス元の調査とリンクの整理
Webサーバーなどのアクセスログを確認して、廃棄予定のサイトへのアクセスがどこから来ているのかを確認して一覧にします。リンク元は HTTP の Referer ヘッダーで確認することができます。特に、業務システムや自治体、教育機関など、外部の公式サイトからリンクされているケースでは、廃棄後も一定の利用者が誤って訪れる可能性があります。
もしも、リンク元に依頼ができるのであれば、廃棄予定のサイトへのリンクを削除してもらうようにお願いすることになります。組織的な相手であれば問い合わせ窓口や管理者情報を通じて依頼することが可能ですが、個人運営のサイトや更新が止まっているサイトでは対応が期待できない場合も多いでしょう。さらに注意すべきは、個人的なブックマークや古いメールに残るリンクからのアクセスです。これらは事前に削除依頼を出すことができないため、アクセスそのものを完全に防ぐことは不可能です。したがって、廃棄前の段階で「このサイトは終了しました」というメッセージを常に返す体制を整えておくことが、利用者の混乱や攻撃者によるなりすましを防ぐうえで不可欠となります。
また、検索エンジンへの対処も忘れてはいけません。Google や Bing などの主要な検索エンジンは、管理者向けに提供している「Search Console」や「Webmaster Tools」からインデックス削除の申請が可能です。これを活用すれば、廃棄予定のページが検索結果に表示され続けることを防げます。さらに、robots.txt や noindex メタタグを設定してクロール対象から除外することも効果的です。ただし、これらの設定変更が反映されるまでには一定の時間がかかるため、廃棄直前ではなく、余裕を持って作業を行うことが望ましいでしょう。
加えて、SNS 上で共有されているリンクや、古いプレスリリース・報道記事内の参照リンクも潜在的な流入経路となります。これらを完全に制御することは困難ですが、「終了案内ページ」にリダイレクトしておけば、リンクを辿ってきた利用者がそのまま攻撃サイトへ誘導されるリスクを軽減できます。
終了案内の掲示とリダイレクト
閉鎖したサービスへのアクセスがあった場合には、そのサービスが終了したことを示す適切な案内を掲示すべきです。そして、サービスへのアクセスはつねにトップページから行われるとは限りません。深い階層のページや直接ブックマークされた URL から訪問されるケースも多く、どのパスにアクセスがあったとしても、サービス終了の案内を必ず表示することが重要です。仮に存在しないパスであったとしても、単純に Not Found を返すだけでは利用者に「サービスが終わったのか、ページが消えただけなのか」が伝わらず不親切です。サービス終了を明確に伝えることで、利用者の混乱を防ぐだけでなく、後から攻撃者が同じドメインを取得して悪用した際に、利用者が正規サイトと誤解してしまうリスクも減らせます。
また、終了告知ページには単なるテキストだけでなく、公式のロゴや企業名を入れることで「正規の終了案内である」と認識してもらう工夫も有効です。問い合わせ先やサポート窓口を併記しておけば、利用者が困惑して別の場所(不正サイトやSNSでの誤情報)に誘導されるリスクも抑えられます。
もしも、サービスを引き継ぐ新サイトがある場合は、案内に加えて新サイトへのリダイレクトを行うことも大切です。ここで重要なのは、検索エンジンに対しても「移転した」という情報を適切に伝えることです。HTTPステータスコードとして一時的な 302 Foundではなく、恒久的な移転を意味する 301 Moved Permanentlyを使用することで、SEO上も新サイトへの評価が引き継がれ、利用者が古いリンクを踏んでも自然に新サイトへ到達できるようになります。
リダイレクトと文書ID
新サイトへのリダイレクトを行う際に、ただトップページへのリダイレクトを行うのではなく、利用者が閲覧したいコンテンツと紐づくロケーションへのリダイレクトを行うべきです。
https://www.example.jp/XXXX.html を閲覧したいと考えているユーザーを https://www.new.example.com/ に誘導するのではなく、ユーザーが閲覧したいと考えている XXXX.htmlの内容が書かれたパスを付与すべきです。これにより、ブックマークや外部リンクからのアクセスを極力無駄にせずに済みます。
もちろん、ウェブサイトの構造が大幅に変わってしまい、1対1の紐づけが困難となるケースもあるでしょう。その場合は、リダイレクト先で「該当ページが移動した／統合された」ことを説明し、検索やサイトマップを提示するなど、利用者が目的の情報に辿り着けるよう配慮すべきです。
一方で、リダイレクトの設計を誤ると、利用者に大きな混乱を招くことがあります。ドメイン廃止とは毛色が異なりますが、実際に IPA(情報処理推進機構)や一部の官公庁サイトがリニューアル時にリダイレクトを十分に行わなかった事例1 2 があり、旧リンクが大量に 404 Not Foundとなってしまいました。外部からの参照が多い公的機関のサイトでは、こうした不備が利用者の混乱や情報へのアクセス断絶を招くため、設計段階からURLの継続性や適切なリダイレクト運用を考慮する必要があります。
URLは、その名の通り本来一意であるべきものであり、WWWを考案した Tim Berners-Lee氏は Cool URIs don't change の中で "URLをどのように設計するかが非常に重要" と説いています。URLには「設計」が必要であり、著者名・タイトル・状態(old、draftなど)といった「変化しうる情報をURLに埋め込むべきではない」とされています。
この問題意識に関連して、メールサーバー qmailの作者などで知られる D.J.Bernstein氏はDocument IDという仕組みを提案しています。すべてのドキュメントには一意の識別子を付与するというもので DJB氏は head /dev/urandom | md5sum でランダム性のある文字列を生成して使っています。Qiitaにおいても、投稿記事は識別子(UUID)で管理されており、同様の考え方に基づいています。
こうした試みはいくつかの自治体でも確認されており 四日市市などが実践しています。 四日市市ではコンテンツに「問い合わせ番号」を付与し、それをURLにしています。
東京都もコンテンツに「記事ID」というものを付与していますが、 URLとの紐づけはないため Lee氏が理想とする「変化に強いURL設計」とはやや方向性が異なります。
メール関連設定の整理
電子メールに関する DNSレコードも、ドメインを廃棄するまでに必ず整理しておくべき対象です。ウェブサイトが停止しても、メールは思わぬ経路から送信・受信される可能性があり、特に「なりすましメール」や「スパム拡散」に悪用されやすいからです。ドメインを廃棄する段階でのメール設定は、攻撃者に余地を与えないための最後の防御線とも言えます。
まず重要なのは、今後そのドメインから正規のメールを送信しないことを外部に表明することです。これを実現する仕組みとして SPF や DMARC を活用します。SPF では「このドメインからメールは送らない」と明示的に設定し、DMARC では「このドメインから届いたメールは破棄してよい」と指示を与えます。これにより、攻撃者が廃棄予定のドメインを詐称してメールを送信した場合でも、受信側がその正当性を疑い、排除することが可能になります。
一方で、受信の制御も必要です。そのドメインでのメールを受信しないことを知らしめるためにRFC7505で定められた NULL MXレコード を使うことができます。これはMXレコードの宛先を「.(ドット)」とすることで、そのドメインにメールサーバーは存在しないことを示します。送信元の MTAはこれを検知し、RFC5321で規定された 550エラーを返して送信者に差し戻します。
しかし、注意しなければならないのは、NULL MX を設定すると自分自身も含めてドメイン宛のメールが一切受け取れなくなる点です。終活の過程では、まだどこかのサービスがそのドメイン宛メールを利用している可能性があるため、いきなり受信を停止するのは望ましくありません。そこで有効なのが、「サブドメインも含めてメールをすべて受け取るキャッチオールメール転送の運用」です。キャッチオールを導入すれば、廃棄直前までどんなアドレス宛にメールが届いているかを把握でき、必要な通知や利用状況を見逃さずに済みます。そのうえで、不要であることが確認できた時点で NULL MX に切り替えるのが安全な流れです。
| 概略 | 説明 | 例 |
|---|---|---|
| SPF | このドメインからのメールは送信しない | @ TXT "v=spf1 -all |
| DMARC | このドメインからのメールは破棄してよい | _dmarc TXT "v=DMRC1; p=reject; aspf=s" |
| NULL MX | このドメイン宛にメールは受信しない | @ MX 0 . |
| Catch-ALL | すべてのサブドメインのメール受信 | *.example.jp. MX 10 mail.example.jp. |
ただし、ワイルドカードMXレコードをサポートしていない DNSプロバイダーも存在します。また、キャッチオールを行うにはメールサーバー側で任意のサブドメイン・ユーザー宛メールを受け入れる設定を用意する必要があります。そのため、環境に応じて現実的に可能かどうかを判断し、段階的に整理することが求められます。
当然ですが、こうしたDNSレコードを使った制御は、ドメインを完全に廃棄してしまったあとでは機能しません。制御をしつづけるためにはドメインを保持しておく必要があります。
ドメイン廃棄の決定
Webやメールサービスの状態を把握して、利用がなくなってきたら、いよいよドメインの正式な廃棄を決定します。ここで重要なのは「本当に利用がなくなったのか」を冷静に判断することです。表面的にアクセスが減っていても、古いシステムがまだ内部で参照している場合や、外部の取引先が連絡に使っている可能性もあります。廃棄を決める前に、アクセスログ・メール転送の記録・検索エンジンのインデックス状況を総合的に確認し、残存利用がないかを慎重に調べるべきです。
また、いきなり廃棄してしまうのではなく、監視と猶予期間を設けることが推奨されます。たとえば「キャッチオールメール転送」や「アクセスログのモニタリング」を数か月間継続し、意図しない利用が残っていないかを観察するのです。この猶予期間を通じて、廃棄予定のドメインにまだ届いている通知メールや残っているアクセス経路を把握し、必要に応じて代替手段を利用者に案内することができます。
猶予期間を設けるもう一つの利点は、組織内外への周知の時間を確保できることです。廃棄予定ドメインの利用者や関係者に対して、公式に「このドメインは廃止予定である」ことを明示し、代替サイトや新しいメールアドレスへの移行を案内すれば、混乱やセキュリティリスクを抑えられます。
さらに、正式に廃棄する前に「ドメインを維持するか完全に手放すか」の判断も改めて考えるべきです。ドメイン維持には一定のコストがかかりますが、被害が生じた場合の影響を考えれば「維持し続けること自体が最良の防御策」であるケースもあります。とくにブランド名やサービス名を含むドメインは、形式上利用していなくても守りのために保持する価値があります。
最終的に廃棄を選択する場合でも、廃棄の直前まで監視を継続すること、そして十分な猶予期間を設けて整理を済ませることが、セキュリティ上も利用者対応の観点からも欠かせないプロセスです。
最後に
ドメインは安易に増減すべきものではなく、最後まで責任を持って育てるべき資産であり、雑に放置すると思わぬ祟りを呼び込むことになりかねません。
どうしても廃棄する際には、単なる解約手続きではなく、安全に廃棄することを心がけなければなりません。廃棄の決定は、事業上の理由だけでなく、セキュリティ上のリスク評価を含めて総合的に行うべきです。