要約

  • 正規の処理段階が増えれば、同じ事業者の識別子が現れる回数も変わり得る。名称の重複だけでは、止めるべき循環を判定できない。
  • CDN-Loop は既存の内容を保持する協力を必要とする一方、その内容を信頼できる経路履歴とは扱わない。
  • 停止した理由を説明する記録と、実際の通過経路や悪意を立証する証拠は別物だ。運用の復旧で、帰属判断まで完了したことにはならない。

サービス名は変わらなくても、通り道は変わる

配信サービスに内部の処理段階を一つ加える。契約先の数は増えず、利用者が見るドメインも同じままだ。それでも、循環防止の仕組みが見るリクエストは、以前とは違う順序をたどる可能性がある。

この変更を「同じ CDN 内の最適化」とだけ記録すると、商務上は十分でも、運用上の説明が欠ける。同じ識別子の二度目の出現が、昨日は想定外でも、今日は正規の処理に含まれるかもしれないからだ。逆に、正常とされてきた回数が、どんな経路でも安全であるとは限らない。

これは特定の顧客環境で観測した障害ではない。本稿は構成変更や循環の実験を行っていない。問いは、公開文書が示す仕組みに絞られる。正常な処理の単位と、防御側が数える単位は、一致しているだろうか。

CDN-Loop を単に「同じ名前を見つけたら止める機能」と考えると、この問いが抜け落ちる。残すべき印、その印を読む規則、実際に意図された経路を、別々に説明する必要がある。

四つという数字を、そのまま基準にしない

2026 年 9 月 8 日に参照した Fastly の CDN-Loop 文書では、クラスタリングや shielding によって、Fastly のトークンが最大四つ含まれ得ると説明されている。重要なのは、四を他の環境に適用することではない。事業者の識別子と内部の処理段階が、一対一ではないという点だ。

その記述は Fastly の文書が扱う範囲の説明であり、別の CDN に許容回数を設定する根拠にはならない。現在の顧客設定を確認した結果でもない。同じ数値でも、経路や規則が違えば意味が変わる。

Cloudflare の現行ヘッダー文書は、CDN-Loop により同社ネットワークへの進入回数を制限する考え方を説明している。ページの更新日は 2026 年 5 月 5 日だ。また、2019 年 3 月 20 日の同社記事は、サブリクエストなど正規の反復処理にも触れている。後者は当時の事業者による説明であり、今日の全サービスについての保証ではない。

これらの資料から導けるのは優劣表ではなく、変更管理上の確認事項である。新しい段階を加えた後、同じ印の繰り返しは何を表すのか。契約図の箱が変わらないからといって、防御規則の前提も変わらないとはいえない。

構成の説明を細かくする目的は、際限なく複雑さを増やすことではない。止めるべき再入場と、サービスを完成させるための再処理を区別するのに必要な範囲だけ、正常な動きを言葉にすることである。

印を残す責任は、次の事業者に届く

2019 年 4 月の RFC 8586 は、協力する CDN 間で循環を検出するためのリクエストヘッダーを定義した。生成・転送するリクエストへの識別子の追加を推奨し、既存の内容の保持と、顧客設定による変更・削除を許さないことを仕組みの成立条件としている。別目的への転用も推奨していない。

アプリケーションを自由に変更できるサービスでも、そこを通る全情報を顧客が自由に書き換えてよいわけではない。ある場所で印を消すと、次の事業者が使うはずだった手掛かりまで失われる。

この関係では、設定の便利さを得る側と、防御上の負担を受ける側が分かれ得る。これは制度や権限の配置から生じる可能性であり、特定事業者が実際に不適切な設定を許しているという指摘ではない。

顧客にどの変更を許すか。中継処理で何を残すか。到着した内容を見てどこで止めるか。この三つの判断が別の担当に分かれること自体は問題ではない。問題は、構成変更の際に、そのつながりを誰も確認しないことだ。

RFC の公式情報ページは Proposed Standard と記載する。標準上の位置付けと、個々のサービスでの採用・互換性は別である。確認済みの技術的正誤表には文法規則の参照の訂正があるが、保持と信頼の区別を変えるものではない。

消してはいけないが、信じ切ってもいけない

RFC 8586 は同時に、どのクライアントもこのフィールドを作れるため、内容を信頼できないと注意する。その内容で動作を変える側は、別のサービス拒否の手段を生まないようにしなければならない。署名は可能でも、この仕様が方式を定義したり要求したりするものではない。フィールドや応答の違いから、事業者の存在や内部構成が見える可能性もある。

ここで必要なのは、信頼か削除かの二択ではない。共有する防御の手掛かりとして保持し、そこから断言できる範囲を限定することである。

停止ログが確かなら、ある規則がその時点で動作したことを説明できる。しかし、それだけで列挙された通過先すべてが実在の履歴だったとは証明できない。誰が原因を作ったか、悪意があったかについては、さらに別の裏付けが必要になる。

読める名前にも同じ限界がある。担当者に見覚えのある識別子は、調査の入口として有用だ。それが示す組織が、そのリクエストの記述に同意したことにはならない。名前の衝突を減らす設計と、履歴を認証する設計は、解こうとする問題が違う。

防御は、帰属調査の完了を待たずに働く必要がある。一方、防御が働いた事実をもって帰属調査が終わったと扱えば、運用上の判断に、本来ない証明力を与えてしまう。

オリジンに到着しなかったことの限界

途中で止められたリクエストは、オリジン側の到着記録に現れないことがある。オリジンの担当者が記録を見つけられないのは、十分あり得る観測だ。しかし、その空白だけでは、どの段階がどの理由で停止したかを説明できない。

必要なのは、当時の構成、正常な段階の並び、ローカルな判断を結び付ける記録である。本稿の提案であって、RFC が新たに要求するログ形式ではない。経路自体が変わったのか、経路を読む側の方針が変わったのかを、後から分けて検討できる程度の文脈があればよい。

すべての内部名を公表する必要はない。詳細が増えるほど証拠能力が高くなるとは限らず、信頼できない履歴の周囲に、実際の内部情報だけを大量に付け加える結果にもなり得る。共有相手と保存期間は、調査の目的に合わせるべきだ。

設定変更後に配信が戻ったとしても、それは主として復旧の説明になる。過去のフィールド内容をすべて事実に変えるものではない。原因の推定、復旧の確認、行為者の特定は、同じ報告書に載せられても、同じ確度で書く必要はない。

文書が示す範囲を越えない

本稿の根拠は仕様、公式の訂正情報、事業者の公開文書である。普及率、現在の攻撃頻度、顧客別の設定、競合サービスの信頼性を測ったものではない。動作例から全市場の状態を語ることはできない。

Lu Heng のインターネット統治における代理問題の論考は、権限とリスク負担が分かれる構造を見る問いを与える。ただし、そこでの登録制度への議論を CDN への事実認定に転用することはできない。BTW Media が主張より現実を扱う理由を述べた論考も、結論を先に選ぶのではなく、制約を説明する方法として読むべきだ。

CDN-Loop の制約は明快である。他者が必要とする印を残すことと、その印の全内容に責任を持つことは違う。サービスに一段を加えるたび、この違いを保ったまま正常な経路を説明し直せるかが問われる。