主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
IETF
秘密のサーバー名にも公開の玄関が要る――ECHが引き直すTLSのプライバシー境界
鍵を更新した直後、ある利用者だけが古い DNS キャッシュを持っている。暗号そのものは正しくても、玄関側には開けられない。この時間差を扱えなければ、ECH は仕様上の保護で終わり、運用上の境界にはならない。
記事
ARINのRDAP Bottom検索は末端一覧ではなくカバレッジを返す
`/21`を照会すると、直接割り振りの`/22`と管理用の`/8`が同じ応答に現れる。`rdap-bottom`を子孫の一覧だと考えれば逆転に見えるが、実際に求めているのはレジストリ上の全域カバレッジである。
ICANN
一つの窓口、期限なし：ゾーンファイルへのアクセスは誰が認めるのか
CZDS では、多数の gTLD レジストリに一つの窓口からゾーンファイルを申請できる。ただし、画面が共通だからといって、許可権限まで一か所に集まったわけではない。
ICANN
偽造書簡が Sex.com を動かした――Kremen対Cohen、Network Solutions
この事件で移されたのは物理的な物ではない。権威ある登録状態が書き換えられ、誰がドメイン名の行き先を決められるのかが変わった。裁判所は、その支配利益をどこまで財産として扱えるかを問うた。
記事
ARINのNETルート一覧は子ネットワークを含まない
空の一覧は、検索範囲を見なければ決定的に映る。ARIN のルーティングレジストリ API では、通常の NET 一覧は直接登録で止まり、下位の再割り当てには別の問い合わせが必要だ。
北米のクラウドサービストレンド
旧い判断が消えたと各エッジ群が証明するまでロールバックは終わらない
Fastly のコントロールプレーンは以前のサービスバージョンを短時間で再有効化できる。しかし復旧の終点は API 応答ではなく、重要な POP のリクエストが撤回済みルールを実行しなくなったことを確認した時だ。
ICANN
ドメイン名を管財人の管理下に置くとき――Office Depot対Zuccarini
登録者への窓口は複数国のレジストラに分散していた。一方、`.com`のレジストリはカリフォルニア北部にあった。裁判所は、この技術的な一点を判決執行の法的な所在地へ変換した。
ICANN
ICANNがレジストラを終了させた後、ドメインは誰が引き受けるのか
利用可能な登録データがあると確認された後、手続は競争的な選定と迅速な選定に分かれる。どちらの枝を選ぶかで、データベース上の移管だけでなく、利用者がいつアカウントを使えるかまで変わる。
ケースファイル
同じ 256 でも、同じ記録ではない：IPFIX の観測ドメインが定める証拠の範囲
接続が戻り、収集装置に再び 256 という番号が届く。前の接続で覚えた項目の並びを当てはめれば、数字は読めるかもしれない。しかし再接続の前後で、その番号が指す定義まで同じとは限らない。障害は通信の停止ではなく、意味の連続性を勝手に仮定した瞬間に始まる。
ケースファイル
TXT レコードは正しかった。それでも委託先はドメインではない――ACME DNS-01 と委任された検証権限
アプリ、CI、社員アカウント、証明書保管庫から委託先を外した企業が、契約終了を完了扱いにした。だが DNS には `_acme-challenge` を委託先の検証ゾーンへ送る委任が残っていた。委託先の ACME アカウントが新しいワイルドカード証明書を注文すると、正しい TXT ダイジェストが現れ、プロトコル上の検査はすべて成功した。壊れていたのは ACME ではなく、DNS まで届かなかった権限棚卸しだった。
ケースファイル
境界を越えたのは1経路、消えるのはセッション：BGP maximum-prefix の統治
BGP の maximum-prefix は、受信する経路数に上限を置くための機能である。しかし、設定された動作がセッション切断なら、上限を越えた1経路だけでなく、それ以前に同じ隣接から学習していた経路も同時に失われる。必要なのは大きな数字ではなく、数え方、守る資源、正当な増加、切断後の到達性まで説明できる境界である。
ケースファイル
DNS 応答が Secure でも、接続先はまだ選ばれていない：SSHFP 指紋の権限境界
運用担当者は `ssh db` と入力した。ネットワーク由来の検索サフィックスが短い名前を別の完全修飾名へ展開した。その SSHFP は DNSSEC Secure、提示されたホスト鍵の指紋も一致した。証明はすべて正しかった。ただし、利用者が意図したデータベースではなく、クライアントが選んだホストについてである。
ケースファイル
署名は通った。それでも From は署名者ではない――DKIM ドメイン署名の権限
画面の From ドメインには `bank.example`、判定には DKIM pass と出た。実際に署名したのは攻撃者の `receipt-alert.example` だった。検証は正しい。一つのドメインの証拠を別の名前へ移した判断が誤っていた。
ケースファイル
ダイジェストは一致した。それでも送信者は不明だった――HTTP `Content-Digest` が持つ権限の限界
設定ファイルは通信中に壊れたのではない。最初から有害で、しかも正しく計算された `Content-Digest` が付いていた。サービスは「検証済み」と表示し、そのまま変更を適用した。攻撃者はハッシュ関数を破っていない。本文とダイジェストの両方を自分で用意しただけだ。
ケースファイル
ヘッダーはクライアントを名乗った。接続元は同意しなかった：HTTP `Forwarded` とプロキシ連鎖の権限
本来は二段のリバースプロキシだけが到達できるオリジンに、外部から直接接続できる経路が残っていた。送信者は管理用許可リストのアドレスを `X-Forwarded-For` の左端に置き、IP 制御を通過した。文字列の解析は成功していた。失敗したのは、その接続元に過去の通信経路を証言する権限がなかったことである。
ケースファイル
TLSコンテキストを選んだ名前に、要求を許可する権限はない：SNIという経路ヒント
障害ではなく、成功ログが問題を隠した。ClientHello の`tenant-a.example`から意図した証明書が選ばれ、TLS 1.3も完了した。ところが認可層は、その選択ラベルを利用者の tenant ID として受け取った。クライアントはまだ何者とも確認されていなかった。
ケースファイル
証明書署名は通った。それでも握手は終わっていない：TLS 1.3 `Finished` の証拠境界
監視基盤は、サーバーの CertificateVerify 検証が成功した瞬間に「認証済み接続」を一件加算した。直後の`Finished`は不正で、クライアントは`decrypt_error`として接続を終了した。署名が証明した内容は正しかった。誤っていたのは、その証明にまだ到達していない完了状態まで背負わせた運用側だった。
インターネット史
返り道を証明したトークン――DNS Cookiesが身元証明ではない理由
EDNS に加わった小さなオプションは、DNS サーバーが UDP の送信元アドレスから読み取れる事実を一つ増やした。送信者が誰かではない。その見かけ上のアドレスへ以前送った応答を誰かが受け取り、サーバー発行のトークンを持ち帰った、という限定された事実である。
ケースファイル
エッジは HTTP/2、オリジンは HTTP/1.1：TLS ALPN が決められるのは一つの接続だけ
ブラウザーは `h2` と `http/1.1` を提示し、エッジは `h2` を選んだ。TLS は完了し、HTTP/2 のフレームも正しく流れた。それを根拠に資産台帳がオリジンを「HTTP/2 ネイティブ」と記録した瞬間、正しい観測は誤った主張になった。エッジは TLS を終端し、別の接続でオリジンへ HTTP/1.1 を送っていたからだ。
ケースファイル
CA 名は載っていた。それでも主体は許可されない：TLS `certificate_authorities` が持つ選択ヒントの権限
サーバーが示した CA 名に合うため、クライアントはある証明書を選んだ。サーバー側のパス検証も成功した。しかしサービスは、その主体が対象テナントに登録されていないとして操作を拒んだ。暗号処理は壊れていない。壊れていたのは、CA 名の一致をアクセス許可まで引き上げた運用上の意味づけだった。