ドメインはペットと同じ――最後まで面倒を見る覚悟はあるか

失効ドメイン、サブドメイン・テイクオーバー、そして「ドメイン供養」の話

はじめに――自分で立ち上げたサーバーを閉じる

自分で立ち上げたMastodonサーバー「mikumikudance.cloud」を閉鎖することにした。

自分で名前を考え、ドメインを取得し、DNSを設定し、証明書を用意し、サーバーを構築した場所だ。
だから、閉鎖を決めることに悔しさがないわけではない。

しかし現在は、MikuMikuDanceに関係のないアカウントや投稿が増え、当初想定していたコミュニティとしての役割を失いつつある。資金面や管理負担も含め、形だけを残すことには、もはや意味がないと判断した。

サーバーは停止できる。
インスタンスも削除できる。
けれど、ドメインはそれで終わりではない。

そこで閉鎖後も一定期間はドメインを保持し、アクセスに対して「410 Gone」を返すことにした。

私は、これをドメインの「供養」だと考えている。

1．Webサイトを閉じても、名前は消えない

Webサイトやサーバーは、停止すれば実体を失う。

しかし、一度インターネット上で使われたドメイン名は、簡単には消えない。

検索エンジンのインデックス、SNSへの投稿、ブログやニュース記事からのリンク、利用者のブックマーク、送受信されたメール、証明書の公開記録、DNSの履歴、Archive.orgなどのアーカイブサービス。

Mastodonのような分散型SNSであれば、アカウントURIや投稿の参照先が他のサーバーにも残る。

つまり、サーバーを削除しても、そのドメインが存在していた事実や、そこに積み上がった信用までは消えない。

ここで強調したいのは、ドメインは単なる文字列ではないということだ。

それは住所であり、看板であり、サービス名であり、ときには組織そのものの信用を示す記号でもある。

2．失効したドメインは「過去の信用ごと」再利用される

ドメインの更新を停止し、失効させると、一定期間を経た後に第三者が取得できるようになる。
第三者が取得すること自体は、制度上何も不正ではない。
しかし、過去に使われていたドメインには、すでにリンクや信用が残っている。

昔のWeb記事に掲載されたURLをクリックする人もいる。
古いパンフレットやPDFからアクセスする人もいる。
メールアドレスをアドレス帳に保存したままの人もいる。

そのドメインがオンラインカジノ、成人向けサイト、広告サイト、マルウェア配布サイト、フィッシングサイトとして再利用されたらどうなるだろう。

利用者から見れば、

ということになる。

新しい所有者は、ドメイン名だけでなく、過去に蓄積されたリンクと信用を居抜きで利用できてしまう。

これは単なるWebサイトの閉鎖問題ではない。
過去の信用資産を第三者へ明け渡す問題だ。

3．サブドメイン・テイクオーバーはさらに厄介

ドメインそのものを失効させなくても、似た問題は起きる。

代表的なのが、サブドメイン・テイクオーバーだ。

たとえば、あるサブドメインを外部のクラウドサービスやホスティングサービスへCNAMEで向けていたとする。
サービス終了時にクラウド側のリソースだけを削除し、DNSレコードを残してしまうと、その参照先が宙ぶらりんになることがある。
その後、第三者が同じクラウド側の名前やリソースを取得できれば、元のサブドメインを自分のサイトへ向けられる可能性がある。

重要なのは、第三者がDNSを改ざんしたわけではないという点だ。
管理者自身が残した設定を、第三者が利用しただけである。
攻撃というより、廃止手順の不備に近い。だからこそ厄介だ。

4．go.jpのサブドメインで起きたこと

この問題は、個人サイトや小規模サービスだけの話ではない。

過去には、官公庁のgo.jp配下のサブドメインが、サービス終了後の不適切なDNS管理によって第三者に利用され、オンラインカジノへ誘導される状態になった事例もあった。

これはかなり深刻な問題だ。

go.jpは、日本政府機関が使用するための限定されたドメインだ。
一般の利用者は、URLにgo.jpが含まれていれば、政府機関の公式サイトだと認識する。

サブドメインであっても、その信用は親ドメインから継承される。
にもかかわらず、Webサイトだけを閉鎖し、DNSの参照関係を残してしまえば、その政府公式という信用を第三者へ渡すことになる。

「本体のドメインは無事だった」という話では済まない。

利用者から見れば、

という事実しか残らない。

何のために登録主体を限定し、go.jpという名前空間を守っているのか。
そこまで考えれば、サブドメインも親ドメインと同じ水準で管理されるべきなのは明らかだ。

5．ドメインはペットと同じ

少し強い比喩かもしれない。しかし私は、ドメインはペットに似ていると思っている。

ペットは、迎え入れる時の費用だけで飼えるものではない。
食費、医療費、生活環境、日々の世話、老後、そして最期までの責任がある。
「譲渡費用が無料だったから」「安く買えたから」という理由だけで迎え入れてよいものではない。

ドメインも同じだ。
初年度1円で取得できることがある。
キャンペーンで無料になることもある。

しかし、取得費用が安いことと、管理責任が軽いことは別だ。
ドメインを取得すれば、更新費用、DNS管理、証明書、メール、サーバー、監視、セキュリティ対策が必要になる。
そして、サービスを終了する時には、閉鎖告知、利用者の移行、DNSの整理、外部サービスとの紐付け解除、証明書の整理、メールの停止、ドメイン失効後のリスクまで考えなければならない。

もちろん、生き物とドメインを同一視したいわけではない。

言いたいのは、始める時の軽さだけを見て、終わらせる責任を考えないのは無責任だということだ。

6．「1円で取得」は、入口だけが安い

ドメイン取得サービスの広告では、初年度1円、無料、格安といった言葉が目立つ。
しかし、それは入口の価格にすぎない。

翌年以降の更新費用は別だ。
管理に必要な時間も別だ。
廃止時の後始末も別だ。

これは、プリンター本体を安く販売してインクで回収する仕組みに少し似ている。
ドメインの場合は、金銭だけではない。
一度名前を世に出すことで、利用者との関係、リンク、メールアドレス、検索結果、外部サービスとの接続が生まれる。

つまり、安く買ったのは文字列ではない。
長期的な責任が付随する名前を取得したのである。

7．ドメインは「永代供養」すべき対象である

私は、ドメインは命名したその日から永代供養すべき対象だと思っている。

ここでいう永代供養は、必ずしも個人が永久に更新料金を払い続ける、という意味ではない。

重要なのは、ドメインは一度使ったら完全に無かったことにはできない、という認識を持つことだ。

利用中は適切に管理する。
終了時には正式な閉鎖を告知する。
一定期間は410 Goneを返す。
DNSや外部サービスの参照を整理する。
失効させる場合は、第三者取得のリスクを理解したうえで判断する。

つまり、取得時点から廃止後までのライフサイクルを考えるということだ。

ドメインを「使っている期間だけ管理すればよい資産」と考えるのではなく、「一度名付けた以上、その痕跡と信用に責任を持つ資産」と考える必要がある。

8．410 Goneという静かな墓標

Webサイトの閉鎖後、単にサーバーを停止すれば、アクセスには接続エラーが返る。

404 Not Foundを返すこともできる。
しかし今回、mikumikudance.cloudでは410 Goneを返す予定だ。

410 Goneは、そのリソースが意図的に削除され、今後も戻る予定がないことを示すHTTPステータスだ。

404が「見つからない」であるのに対して、410は「ここには以前存在していたが、正式に終了した」という意味を持つ。

閉鎖後も一定期間この応答を残すことで、利用者、検索エンジン、外部サーバーに対して、サービスが恒久的に終了したことを明確に伝えられる。

Cloudflare Workersを使えば、サーバーを維持しなくても、Cloudflareのエッジ上で410を返し続けることができる。

インフラ費用は止める。
しかし、閉鎖の意思表示は残す。

これは、ドメインの供養方法としてかなり合理的だと思っている。

9．官公庁のドメインは公文書並みに管理すべき

官公庁のドメインは、公文書に近い水準で管理すべきではないか

私は以前、官公庁の情報システム部門で働いていた。

当時の私の業務経験の範囲では、ドメインやサブドメインについて、利用開始から廃止後までを一貫して追跡する仕組みが、少なくとも現場から明確に見える形で運用されているとは感じにくかった。

ただし、これはあくまで私が在職していた時期と、担当業務の範囲から見えた印象である。

その後、過去のサブドメイン悪用事例を踏まえて、各府省庁で点検や運用改善が進められている可能性は十分にある。現在も同じ状態が続いていると断定する意図はない。
そのうえで、制度として目指すべき方向については、改めて考える価値があると思う。

ドメインやサブドメインは、公文書そのものではない。
しかし、行政機関の真正性や信用を外部に示す情報資産である以上、公文書に近い水準のトレーサビリティを持って管理されるべきではないだろうか。

少なくとも、次のような情報を継続的に追跡できる仕組みが望ましい。

• ドメイン・サブドメイン名

• 利用目的

• 所管部署

• 管理責任者

• 委託事業者

• DNSレコード

• 外部サービスの参照先

• TLS証明書

• 利用開始日

• 終了予定日

• 廃止手順

• 廃止後の保持期間

• 失効判断の承認記録

作成時だけでなく、変更時、契約終了時、廃止時にも記録と確認が残る仕組みが必要だ。

10．各省庁での管理を補完する横断的な仕組みも必要ではないか

各省庁が個別にドメインを管理する方法には、担当者の異動、委託事業者の変更、契約終了時の引き継ぎ不足といったリスクがある。

現在、各府省庁やデジタル庁において、どの程度まで横断的な管理・監査の仕組みが整備されているかについて、私は最新の全容を把握していない。

そのため、現行制度が不十分だと一方的に断定することは避けたい。

一方で、制度設計としては、go.jp配下のDNS、証明書、サブドメイン台帳、外部サービスとの紐付け、廃止確認などについて、横断的に把握・監査できる仕組みがあることが望ましい。

各省庁がサービスの利用責任を持ち、共通基盤側が名前空間や監査を支える。

そうした役割分担であれば、完全な中央集権にせずとも、管理漏れを減らせる可能性がある。

11．ドメインを閉じることは、責任を捨てることではない

mikumikudance.cloudを閉鎖することは、私にとって少なからず悔しい決断だ。

自分で立ち上げた場所だから、できれば残したかった。
しかし、目的を失い、管理できず、費用だけが発生するサービスを形だけ残すことは、責任ある運営とはいえない。

閉鎖すること自体が無責任なのではない。
無計画に放置することが無責任なのだ。

利用者に告知し、移行期間を設け、サーバーを停止し、DNSを整理し、一定期間410 Goneを返す。
そして、ドメインをいつまで保持するのかを判断する。

始めた者には、終わらせ方を考える責任がある。

おわりに――名前を付けた瞬間から、終わらせ方を考える

Webサイトは消せる。
サーバーも削除できる。
コンテンツも削除できる。

しかし、一度世に出た名前の履歴は消えない。
ドメインには、利用者の記憶、検索結果、リンク、メール、信用が紐づいている。
だから、ドメインは取得した瞬間から、閉鎖後まで含めて管理責任が始まる。

1円で取得できるからといって、気軽に建ててよいものではない。
Webサイトを始める時には、終わらせ方まで考えておくべきだ。

一生面倒を見きれない人が、安易にペットを迎えるべきではないのと同じように。

ドメインは、命名したその日から供養が始まる。
そして最後に必要なのは、永遠に動かし続けることではない。

その名前が果たした役割を認め、適切な方法で静かに終わらせることなのだ。