要約
- APNICの公式発表によると、2026年1月27日15時45分から28日9時45分まで（UTC+10）、RDAPに対して意図しない厳格なブラウザー完全性チェックが働いた。
- 18時間の間、一般的なブラウザーのUser-Agentと一致しない文字列を含むRDAPリクエストの約10%が遮断された。これはリクエストの比率であり、利用者数ではない。
- DDoSや乱用自動化への防御は正当である。ただしUser-Agentは自己申告のソフトウェア名であり、利用者の身元や権限を証明しない。
- 9月に4種類のUser-Agentで行った低頻度の観測では、すべて同一のRDAP JSONが返った。これは現在の一点観測であり、1月の詳細や全経路を証明するものではない。
- APNICは機密ルールを公開せずに、クライアント種別、エッジ判断、オリジン到達、応答形式、展開・切り戻し時刻を結ぶ短いサービス証跡を出せる。
正常に見える一回を、完了証明にしない
まず現在の観測から始める。2026年9月5日20時34分UTC、https://rdap.apnic.net/ip/202.12.29.0に対し、低い頻度で4回のGETを送った。すべてapplication/rdap+jsonを要求したが、User-Agentの形を変えた。一つは明示的なUser-Agentなし、一つは用途を明示した自動化用User-Agent、一つはcurl/8.7.1、最後はMozilla/Safari型のブラウザー文字列である。
結果は4回ともHTTP 200、内容種別はapplication/rdap+jsonだった。本文は3,857バイトで、SHA-256はすべてd6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853に一致した。応答ヘッダーからは、経路にCloudflareが残っていることも分かる。
この瞬間については、良い結果である。同じ照会が、ブラウザー風かどうかにかかわらず同じ登録情報へ到達した。しかし、これを「完全に修復済み」という証明に広げてはいけない。対象は一つのIP照会、一つの送信元経路、一つの時刻、低い頻度に限られる。別の照会、HTTPメソッド、地域、エッジ拠点、通信事業者、速度を試していない。
1月の設定も再現していない。したがって、当時のステータスコード、遮断画面、対象ソフトウェアやルール閾値は、この試験からは分からない。カナリアの意味は一度の合格ではなく、条件を固定し、違いが生じた時刻を継続的に残せることにある。
1月の記録が述べていること
APNICのサービス告知は、開始を2026年1月27日火曜日15時45分、終了を28日水曜日9時45分と記している。いずれもUTC+10で、継続時間は18時間、影響を受けたサービスはRDAPである。
原因の説明も明確だ。Cloudflare設定の変更により、意図せず厳格なブラウザー完全性チェックが行われた。その間、一般的なブラウザーのUser-Agentと一致しない文字列を含むRDAPリクエストのおよそ10%が遮断された。
ここで数えられているのはリクエストである。10%の利用者、10%のネットワーク運用者、10%のツールという意味ではない。一つのツールは多数の照会を送れる。失敗後の再試行も母数に入り得る。公開情報には、固有クライアント数や業務影響の件数がない。比率の対象を勝手に置き換えれば、正確な告知を不正確な物語に変えてしまう。
告知は、具体的なUser-Agent、応答コード、本文、地域、エッジ拠点、設定式を明かしていない。セキュリティ上、明かさない方がよい情報もある。そこから特定のコマンドラインツールが必ず失敗した、非ブラウザーのすべてが拒否された、あるいは特定の組織が損害を受けたと推測する根拠はない。
それでも、運用上の境界は見える。一部の照会はRDAPアプリケーションの判断前にエッジで除外された。オリジンだけを見た監視は、その需要を数えられない。ブラウザー型のヘッダーだけを送る外形監視は、別のクライアント種別が閉め出されても正常と報告できる。
防御する責任を先に認める
RDAPが機械処理しやすいことは、無制限の処理義務を意味しない。資源情報の確認、資産管理、インシデント対応に便利な自動照会は、過剰な収集やDDoSにも利用できる。公共サービスの容量を守ることは、APNICの運用責任の一部である。
APNICが2020年に説明したRDAP基盤では、rdap.apnic.netと各国インターネットレジストリのRDAP宛て通信をCloudflareが受け、負荷分散とDDoS防御を提供した上でGoogle Cloud側へ代理転送する。したがってエッジの判断は、利用者が経験するサービスの外側ではない。実行中の経路そのものである。
CloudflareのBrowser Integrity Checkにも合理的な目的がある。公式文書によれば、迷惑・不正トラフィックに多いHTTPヘッダーを調べ、User-Agentが欠けている、または標準的でないリクエストにチャレンジを出すことがある。挙動、頻度、評判などと合わせるなら、有用なリスク信号になり得る。適用を設定ルールで限定できることも文書化されている。
よって論点は「Cloudflareを使うべきではない」でも「ボット対策を無効にせよ」でもない。対話型ウェブサイト向けの普通像を、機械プロトコル全体の入場条件にしてよいのか、である。1月の効果をAPNIC自身が「意図しない」と説明した以上、これは動機の問題ではなく、設定範囲と検証の問題として扱うべきだ。
RDAPにとってブラウザーは一つの客でしかない
APNICは2021年、RDAPをHTTPまたはHTTPSで提供されるJSONで、機械が容易に解析できるものと説明した。単一のクライアントで多くのRDAPサービスの応答を扱え、HTTPキャッシュも活用できる。この価値は、人が画面を操作しなくても構造化情報を一貫して取得できる点にある。
RFC 9082はドメイン、ネームサーバー、エンティティ、IPネットワーク、AS番号に対する統一的なREST照会を定義する。RFC 7480はHTTPの使い方を定める。ブラウザー内アプリも正当なクライアントで、CORSに関する規定もある。しかし標準はブラウザーを唯一の正常形とはしていない。
コマンドライン、ソフトウェアライブラリ、IP資産台帳、abuse対応システム、レジストリ間処理がブラウザーの完全な文字列を送らなくても不思議ではない。それはRDAPから外れた姿ではなく、RDAPが選ばれる理由に沿った姿である。
「ブラウザーらしくない」を「プロトコル利用者らしくない」と読み替えると、この関係が逆転する。ウェブページでは異常かもしれないヘッダーが、専用プロトコルでは誠実な自己記述になり得る。一般的な防御ルールを共有する際には、その二つの母集団を分けなければならない。
User-Agentに権限を背負わせない
RFC 9110がUser-Agentに与えている役割は、リクエストを送ったソフトウェアに関する情報である。製品識別子やコメントによって、互換性調整や診断に使える。値はクライアントが申告する。短くもでき、別製品を装うこともできる。
User-Agentは利用者を認証しない。APNIC会員か、ネットワーク技術者か、研究者か、悪質な収集者かを証明しない。照会目的、許容速度、契約、法的権限も含まない。よく知られたブラウザー名は権利を付与せず、無名の小さなスクリプト名は権利を奪わない。
だからといって信号を捨てる必要はない。高い頻度、反復パターン、送信元評判、認証状態などと組み合わせれば判断材料になる。問題は、証明力の弱い一項目に、アクセスを一括して止める強い権限を与えることである。
その設計はクライアントへ間違った学習を与える。正直なツール名で失敗し、ブラウザー名で成功するなら、開発者はブラウザー名をコピーする。悪質なボットも同じことをする。結果として、エッジが観測する「ブラウザー」は増えるが、実際のソフトウェア分類は分からなくなる。分類器が自ら訓練データを汚す。
429を万能な答えにしない
RDAPの安全仕様は可用性とDDoS対策を認めている。RFC 7481は単一クライアントへの抑制やHTTP認証の利用を想定する。RFC 7480はレート制限にHTTP 429を推奨し、クライアントに頻度を下げ、Retry-Afterがあれば従うよう求める。
これは機械に理解できる制御である。照会自体が不正なのか、容量上の理由で待つべきなのかを区別できる。追加の容量を認証済み利用へ割り当てるなら、ブラウザー外観よりも権限との関係が明確になる。
ただし、1月のBrowser Integrity Checkによる全遮断が429でなければならなかった、と断定はできない。レート制限とボットチャレンジは別の仕組みで、告知には各応答の詳細がない。必要なのは規格を武器にすることではなく、どの層がどの理由で何を返したかを機械可読に分けることである。
HTMLのチャレンジ画面がHTTP 200を返しても、RDAP JSONではない。エッジで遮断されオリジンへ届かなければ、オリジンの成功率だけでは利用者の失敗を表せない。ステータス、内容種別、エッジ処理、オリジン到達を別々に持つべき理由がここにある。
セキュリティ規則ではなく、サービス証跡を公開する
必要な公開物はWAF設定の複製ではない。閾値、評判情報、式、迂回方法は非公開のままでよい。外から検証できないのは、正当なクライアント種別が実際の配信経路を通ってRDAPの結果へ到達するかどうかである。
最小のカナリアは四つでよい。User-Agentなし、目的を明示した自動処理、一般的なコマンドラインクライアント、ブラウザー。それぞれについて、エッジで通過・抑制・チャレンジ・遮断のどれだったか、オリジンへ着いたか、HTTP状態種別、内容種別、遅延、必要ならRetry-Afterを保存する。
次に設定変更の系譜を付ける。設定識別子、適用範囲、責任者、レビュー担当、展開時刻、切り戻し時刻、確認時刻である。公開する範囲は、ブラウザー向けルールがRDAPホストやパス全体へ誤適用されていないと示せる程度でよい。クライアント種別ごとの集計遮断率も、閾値を露出しない形なら有用だ。
APNICはすでに利用者側の測定枠組みを持つ。2025年第2四半期の可用性記事では、5秒以内にエラーでないHTTP応答を得たRDAP試験を成功とし、成功数を総試験数で割る。この方法にクライアント種別を加えれば、同じ指標を実際のプロトコル利用へ近づけられる。
2026年第1四半期の事務局報告には、すべての中核登録サービスが99.99%以上だったとの記載がある。短い概要だけでは、1月の出来事と比較するための分母や算定方法が分からない。誤りだと断じる根拠はない。むしろ、どの時間帯、エッジ結果、クライアント種別が指標に含まれるかを結ぶ証跡が必要である。
言える範囲を狭く保つ
本稿は、APNICのRDAPが現在も壊れているとは述べない。すべての機械クライアントが遮断されたとも、特定の運用者に特定の損害が出たとも述べない。公開情報にない応答コード、地域、文字列、ルールを補わない。9月の4回観測を普遍的な修復証明にも使わない。
APNICまたはCloudflareが標準を無視した、と決めつける根拠もない。APNICが記録したのは意図しない設定効果である。ここから確実に導けるのは、機械プロトコルのクライアント分類をブラウザー型の監視だけに任せてはならない、という運用上の教訓だ。
防御と互換性は両立できる。両者を結ぶのは、外観を権限と取り違えず、実行経路の結果をクライアント種別ごとに残す短い証跡である。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加