サーバーの上にある層 — ドメイン、CDN、トランジット

サーバーをどこに置くかは、三つの決定のうちの一つにすぎず、結果を左右することはめったにありません。サーバーの上には、別の誰かが運用するドメイン名があります。サーバーの手前には、ほとんどのサイトの場合、これも別の誰かが運用するリバースプロキシがあります。どちらもホストのポリシーに縛られず、ホストの司法管轄にも属しておらず、しかもホストにはまったく及ばない裁判所の命令一つで動かされ得ます。これはオフショアホスティングがカバーしない部分であり、それがどこで止まるのかを正確に知っておく価値があります。

三つの層、三つの異なる持ち主

そもそもアクセス可能なサイトは、少なくとも三つの別々の事業者に依存しており、それぞれが独立して機能を停止し得ます。

名前。レジストラがお客様にドメイン名を販売し、レジストリがそれが属する拡張子を運用しています。二つの会社、たいてい二つの国であり、後者はお客様のことなど聞いたこともありません。

手前。CDN、リバースプロキシ、エニーキャストのエッジなど、お客様に代わって応答する何かがあれば、それは訪問者の接続を、お客様のサーバーが目にする前に終端します。したがってそれは構造上オリジンのアドレスを知っており、苦情を受け取るのもそれです。

回線とマシン。ホスト、その回線を提供するトランジット事業者、施設、そしてサーバーが属するアドレス範囲です。これは人々が比較検討して選ぶ層であり、三つのうちホスティングの司法管轄が実際に統治するのはこの層だけです。

断ち切る価値のある習慣は、これらを一つの購入だと考えることです。実際には三つあり、その三つすべてを一つの手に — あるいは一つの法体系のもとに — 置くことこそが、一枚の命令ですべてを一度に止められる原因になります。

ドメイン — レジストラと、その上にあるレジストリ

レジストラは小売店です。レジストリは、その拡張子を運用する卸売業者であり、購入前にほとんど誰も確認しない層です。

レジストラを動かすもの

2024年4月5日以降、認定レジストラには、ICANNが「DNS Abuse」と呼ぶものに対して行動する契約上の義務が課されています。行動可能な証拠を握った時点で、そのドメイン名を無力化するために合理的に必要な緩和措置を速やかに取らなければなりません。この規則で有用なのはその定義の部分です。DNS Abuseとは、マルウェア、ボットネット、フィッシング、ファーミング、そしてそれらの配送手段としてのスパムを意味します。ウェブサイトのコンテンツは対象外であり、著作権も — 明示的に — 対象外です。

これは安心材料ではなく、しきい値として読んでください。レジストラが動く義務を負う前に、苦情がどのような形を取らねばならないかを示すと同時に、そのリストの外側にあるものはすべて、裁判所または当局からの命令として到着しなければならないことも示しています。命令であれば、より遅く、確認可能で、不服申し立てもできます。この両面とも、これから受け取ることになる苦情を処理する前に知っておく価値があります。

レジストリに何ができ、それがどこに位置するか

レジストリにはただ一つ、絶対的なレバーがあります。ドメイン名にステータスを設定して、それをゾーンから除去することです。そうなればその名前は、レジストラがどう考えていようと、サーバーがどこにあろうと、誰に対しても、どこでも名前解決されなくなります。ホスティング層には何一つこれを緩和する手段がありません。なぜならホスティング層はそもそも関与していないからです。

これは理論上の話ではありません。2026年6月、テキサス州の地方裁判所は、.comを運用するVerisignに対し、motherless.comをregistry holdに置くよう命じる差押令状を発行しました。運営者はルクセンブルクの会社で、同州の年齢確認法にもとづくテキサス州の判決を無視していました。命令は、ドメイン名を取り戻す条件として914万ドルの保証金を設定しました。サイトはテキサス州でホストされておらず、会社もテキサス州にはありませんでした。ドメイン名は.comの中にあり、.comはアメリカ合衆国の会社が、アメリカ合衆国の司法管轄のもとで運用しています。それだけで十分でした。

一般化できる教訓は、その事件そのものにあるのではありません。選ぶ拡張子は、サーバーを置く国の選択とまったく同じように、司法管轄の選択であるということであり、たいていの人はそれを習慣で選んでいます。その拡張子を誰が、どの法律のもとで運用しているか、そしてその法体系がレジストリに命令を出す慣行を持っているかどうかを尋ねてください。そのうえで、そこに唯一のドメイン名を置きたいかどうかを決めてください。

ドメイン名のプライバシーは、公開の問題であって、知識の問題ではない

WHOISやRDAPでの秘匿は、一括スクレイパーや何気ない照会を止めます。しかしレジストラを無知にするわけではありません。認定を受けている以上、登録データを保持する義務があり、他の誰とも同じように法的手続きのもとでそのデータを開示します。レコードの手前に置かれたプライバシーサービスは、公開設定であって盾ではありません — そして、そもそも何も尋ねなかったレジストラは、持っていないものを開示できません。これはまったく別の性質であり、対価を払う価値があるのはこちらだけです。

手前のプロキシ — 何を削除し、何を転送するか

CDNはキャッシングを行う仲介者です。サイトを永続的に保存しているわけではないため、「ファイルを削除する」ことは通常できません。CDNにできるのは、プロキシするのをやめることです — これは、到達可能性の維持とオリジンの秘匿の両方をプロキシに依存しているサイトにとっては、一つの動作でテイクダウンと開示を同時に行うことに等しくなります。

より興味深いのは日常的な振る舞いのほうであり、最大手のプロバイダーはそれを明確に公表しています。単にプロキシしているだけのサイトについて悪用報告を受け取ると、そのプロバイダーは苦情をサイト運営者とホスティングプロバイダーの両方に転送し、問題のコンテンツのオリジンIPアドレスをホスティングプロバイダーに提供するとしています。この二つはいずれもそのプロバイダー自身の悪用対応ポリシーからの引用であり、買い手が代金を払っていると思い込んでいるものとは正反対です。

つまりプロキシは、お客様とホストの悪用対応窓口とのあいだの緩衝材ではありません。それは配達人です。苦情をホストまで運び、どのマシンを見ればよいかをホストに正確に伝えます。苦情の扱い方を基準にホストを選んでいたのであれば、それで構いません — 苦情は望んだとおりの場所に届きます。しかし苦情がそこで止まることを期待してプロキシを選んでいたのなら、そうはなりません。

同じプロバイダーのドキュメントは、お客様の側にも義務を課しています。積極的に管理・監視されている悪用対応の連絡先アドレスを維持すること、そして悪用報告の通知には二十四時間以内に応答することです。期限内に応答しなければ、報告されたコンテンツが削除またはブロックされ、アカウントの停止や解約につながる可能性があります。お客様のコンテンツを削除する権限を持たないはずの仲介者が、それでも自分自身のために削除条項と、時計を書き込んでいるのです。

一つだけ重要な例外があります。同じ会社がホスティングも行っている場合 — オブジェクトストレージ、サーバーレスプラットフォーム、メディアやページの製品など — その会社はそのコンテンツについてはホスティングプロバイダーであり、そう明言しており、アメリカ合衆国の法律が定める形の、反対通知つきのnotice-and-takedown手続きのもとでコンテンツを削除します。同じベンダーの二つの製品が、まったく異なる二つの答えを持つのです。実際に自分が使っているのはどちらなのかを知ってください。

CDNが隠さないもの、オリジンが見つかる経路

多くの人が、たった一つの理由でサーバーの手前にプロキシを置いています。オリジンのアドレスを公開インターネットから隠すためです。それが実際にどれだけうまく機能するかを知る価値はあり、正直な答えを言えば、五つのありふれた失敗のいずれかがそれを台無しにするまでは機能する、というものです。どれも特殊なものではなく、プロキシのベンダー自身がそれらを文書化しています。

移行する前に公開していたレコード。DNSは公開情報であり、アーカイブされます。プロキシの背後に移行したサイトのほとんどは、移行前のアドレスが誰かの過去データセットの中に、永続的に残っています。ベンダー自身のガイダンスは、導入後にオリジンのアドレスをローテーションすることを求めています — それをしていなければ、移行は見かけだけのものでした。

プロキシを通していないまま残したレコード。サブドメインが一つ、そのマシンを直接指しているだけで十分です。mail、ftp、cpanel、dev、staging、vpn、一度だけ設定した監視用ホストなど。作成した記憶があるものだけでなく、ゾーン内のすべてのレコードを点検してください。

マシンから送信されるメール。オリジンがメールを送信していれば、そのアドレスはヘッダーの中を運ばれます。存在しないアドレス宛てにメッセージを送れば、それを乗せたまま配送不能通知が返ってきます。メールは、秘匿しようとしているマシンとは別のマシンに置くべきものです。

Certificate Transparency。公に信頼された証明書はすべて、それが対象とする名前とともにログに記録されます。ログはアドレスそのものは渡しませんが、試すべきサブドメインの完全な一覧は渡します。非公開だと思っていたものも含めてです。

網羅的なスキャン。アドレス空間全体が継続的にスキャンされ、その応答内容によってインデックス化されています。むき出しのアドレスから配信される特徴的なページは、調査ではなく、データベースの検索一つで見つかります。

対策はよく知られており、手軽さの順ではなく、強度の順に実施する価値があります。

1. アウトバウンド専用のトンネル。オリジンがエッジへ向けて接続を開き、どのポートでも待ち受けをしません。見つけるべきポートが存在しないため、アドレスが漏れたとしても意味を持たなくなります。このリストの中で唯一、ルールを正しく設定できているかに依存しない選択肢です。
2. エッジからの相互TLS。オリジンは、プロキシの証明書を提示するクライアントに対してのみ応答します。アドレスは漏れるかもしれませんが、応答はしません。強力であり、アドレスが公になっても効力を保ちます。
3. プロキシの公開アドレス範囲へのファイアウォール。何もしないよりはましで導入も容易ですが、範囲は変化しますし、ベンダー自身の比較資料もこの方法をスプーフィングに弱いものとして挙げています。解決策ではなく、最低限の下限として扱ってください。
4. 日常の手入れ。エッジの背後に入ったらオリジンのアドレスをローテーションし、メールをそのマシンから移し、変更のたびにプロキシを通していないレコードを点検してください。露出のほとんどは、巧妙な攻撃ではなく、この三つのいずれかです。

プロキシは、ブラウザを持つ見知らぬ他人からオリジンを隠します。プロキシ自身からオリジンを隠すことはありません — 定義上、プロキシはそれを知っており、苦情を受け取れば、それが何であるかをホスティングプロバイダーに伝える義務を負っています。

マシンの下 — トランジット、プレフィックス、施設

サーバーのさらに下には、もう一組の当事者がいます。そしてそれは、ホストがふだん最も語りたがらない相手です。

トランジット事業者。ホストは誰かから接続性を購入しています。その事業者にはそれぞれ独自の悪用対応窓口、契約、リスク許容度があり、お客様を厄介者だと判断した事業者が、ホストに代わって判断を下してしまうことがあります。事業者がいくつあるかを尋ねてください — 一社しかなければ、単一障害点であると同時に単一のポリシー窓口でもあります — そしてもっと鋭い質問もしてください。ホストは事業者側のブロックリストを、お客様のトラフィックに対して黙って受け入れていないか、と。

共有するプレフィックス。評価システムは顧客単位ではなく、アドレス範囲単位で動きます。お客様は隣人を引き継ぐことになり、しかもそれが誰なのかを知らされることもありません。これは、何でも受け入れる避難所を自称するプロバイダーが持つ、具体的な代償です。ブロックリストはアドレス範囲全体に及び、お客様のメールもAPI呼び出しも、その中に含まれています。

施設とハードウェア。ラックを借りているということは、独自の悪用対応ポリシーを持つ大家が、ホストの上に見えないかたちで存在するということです。そしてホストの上にある層はどれも、お客様には決して見えない理由でサービスを止められる、もう一つの当事者です。

この記事の目的は各層を説明責任のある状態にすることですから、この層についても同じ基準で答えます。トランジット事業者は二社、BGPで負荷分散し、Chișinăuへ合計20ギガビット。レイヤー3・レイヤー4のフィルタリングは、すべてのポートの上流で、全顧客に対して無償で提供します。事業者側のブロックリストは顧客トラフィックには適用しません。何かをブロックしなければならないなら、それは裁判所がそう命じ、当社がお客様に伝えます。ハードウェアは借り物ではなく、一つの国で、購入先の会社自身が所有しています — 詳細はネットワークのページと施設のページにあります。

そして隙間をはっきり述べておきます。当社はドメインを販売しておらず、お客様がサーバーの手前に置くプロキシも運用していません。その二つの層はお客様自身のものです。レジストリや転送される苦情について上で述べたことはすべて、書かれたとおりにお客様にも当てはまり、ホスティングの司法管轄が — 当社のものも含めて — その一語たりとも変えることはありません。

三つの層を、三つの別々の手に

この記事全体は、結局のところわずかな数の決定に集約され、そのどれにも費用はかかりません。

1. 三つの層、三つの供給元、三つの法体系。ドメイン名、エッジ、サーバーが一つの会社の手にあれば、命令一枚ですべてが消える距離しかありません。三つの手に分かれていれば、そのうちの一つに対する命令が出ても、残る二つは動き続け、お客様には時間が残ります。
2. どの層にも同じ三つの質問をしてください。何を転送させられるのか、何を削除させられるのか、何を開示させられるのか。これらは互いに独立して破られます。三つすべてを一文で答える供給元は、質問を理解していません。
3. プロキシは転送するものだと想定して構成してください。実際に転送するのですから。すべての苦情が、オリジンのアドレスを添えてホストに届くものと想定してください。その結果が問題であるなら、直すべきはホスティング層か、公開している内容のほうであり、仲介者をもう一段追加することではありません。
4. オリジンをきちんと閉じてください。アウトバウンド専用トンネルか相互TLS、メールは別のマシンへ、導入後にアドレスをローテーション、プロキシを通していないレコードを点検する。四項目、どれも地味なことばかりですが、実際の露出のほとんどをこれでカバーできます。
5. ドメイン名を単一障害点として扱い、あらかじめ備えてください。どのレジストリが、どの法律のもとで自分の拡張子を運用しているかを知っておいてください。別の拡張子で、別のレジストラに、予備のドメイン名を一つ持ち、いざというとき人々にどう使ってもらうかをあらかじめ決めておいてください。

ここで述べたことは、サーバーの手前にプロキシを置くことに反対する議論でもなければ、オフショアホスティングに反対する議論でもありません — どちらの主張をするにしても、当社は奇妙な発信源でしょう。ここで述べているのは、三つの層が三つの別々の購入であり、三つの別々の障害モードを持つということ、そして人々が最も厳しく吟味する層が、実際に彼らを終わらせる可能性が最も高い層とは限らないということです。当社が実際に運用している層についても同じ基準を当てはめたいのであれば、四半期ごとの数字と法執行機関向けのページで確認できます。

このプラットフォームを運用するエンジニアが執筆し、本日 に見直しました。内容に誤りがある、または古くなっている場合は、顧客パネルからお知らせください。実際、ここに載っている内容の半分ほどはそこから届いたものです。