調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。

記事
ARINのNETルート一覧は子ネットワークを含まない
空の一覧は、検索範囲を見なければ決定的に映る。ARIN のルーティングレジストリ API では、通常の NET 一覧は直接登録で止まり、下位の再割り当てには別の問い合わせが必要だ。

北米のクラウドサービストレンド
旧い判断が消えたと各エッジ群が証明するまでロールバックは終わらない
Fastly のコントロールプレーンは以前のサービスバージョンを短時間で再有効化できる。しかし復旧の終点は API 応答ではなく、重要な POP のリクエストが撤回済みルールを実行しなくなったことを確認した時だ。

ICANN
ドメイン名を管財人の管理下に置くとき――Office Depot対Zuccarini
登録者への窓口は複数国のレジストラに分散していた。一方、`.com`のレジストリはカリフォルニア北部にあった。裁判所は、この技術的な一点を判決執行の法的な所在地へ変換した。

ICANN
ICANNがレジストラを終了させた後、ドメインは誰が引き受けるのか
利用可能な登録データがあると確認された後、手続は競争的な選定と迅速な選定に分かれる。どちらの枝を選ぶかで、データベース上の移管だけでなく、利用者がいつアカウントを使えるかまで変わる。

インターネット史
SMTP が切断せずに忘れられたメール――RSET はトランザクションをどう区切ったか
送信者と一人目の宛先を受理した後で、二人目が拒否される。メールそのものは取りやめたいが、正常な接続まで捨てる必要はない。`RSET` は、その未完了メールだけを消したことを双方で確認するための命令だった。

インターネット史
終端の先にも設定がある:DHCPが借りた起動用フィールド
一つの領域で End を見つけても、設定情報を読む仕事が終わるとは限らない。DHCP は起動用の名前を置く古い領域を借りながら、それぞれの境界を残した。必要だったのは、空間を増やす工夫だけでなく、どこをどの順番で読むかという共通の約束だった。

インターネット史
同じ宛先でも、同じ相手とは限らない:DNS NSIDが残す手掛かり
監視画面に並ぶ応答時間が、どのサーバーのものか分からない。任播で共有されるアドレスはサービスの入口にはなるが、応答した実体の名前にはならない。NSID は、その区別を一回の DNS 応答の中に残すための仕組みだった。

インターネット史
照合を止めるべき瞬間:ECN Nonceが消えた一ビットに求めたもの
混雑の印が付いたパケットは、内容を届けながら、送信時の小さな違いを失う。ECN Nonce はその違いを使って受信側の報告を確かめようとした。だが、正しい照合には、照合できない区間を認める仕組みも必要だった。

インターネット史
ポート1で名前を告げる:TCPMUXがホストに残した選択
新しいサービスのたびに専用の番号を得る必要はあるのか。1988年の TCPMUX は、共通の入口で名前を受け取り、その先のプログラムを各ホストに選ばせた。ただし、入口での承諾は処理の成功まで約束するものではなかった。

インターネット史
1ビットではサービスを動かせない:DNS WKSが現在の状態を証明できなかった理由
接続を一度も試さず、DNS にあるポートの一覧だけでメールサーバーを候補から外す。WKS の歴史は、正確に符号化された情報にも、判断を任せられない境界があることを示した。

ケースファイル
同じ 256 でも、同じ記録ではない:IPFIX の観測ドメインが定める証拠の範囲
接続が戻り、収集装置に再び 256 という番号が届く。前の接続で覚えた項目の並びを当てはめれば、数字は読めるかもしれない。しかし再接続の前後で、その番号が指す定義まで同じとは限らない。障害は通信の停止ではなく、意味の連続性を勝手に仮定した瞬間に始まる。

インターネット史
一台のサーバーが知る名前しか答えられなかった問い:DNSがIQUERYを退役させた理由
かつて DNS には、Question 欄を空にし、Answer 欄へ先に資源レコードを置く問い合わせがあった。サーバーは、その値を持つ名前を逆に探して返す。名前から値へ進めるなら、値から名前へ戻ることもできそうに見える。しかし DNS が分散していたのはデータだけではない。権威をたどる道筋も名前に沿って分散していた。任意のレコード値には、その値を完全に知るサーバーへ導く委任の道がなかった。IQUERY が返せたのは、選ばれた一台が偶然知っている範囲だった。

ケースファイル
TXT レコードは正しかった。それでも委託先はドメインではない――ACME DNS-01 と委任された検証権限
アプリ、CI、社員アカウント、証明書保管庫から委託先を外した企業が、契約終了を完了扱いにした。だが DNS には `_acme-challenge` を委託先の検証ゾーンへ送る委任が残っていた。委託先の ACME アカウントが新しいワイルドカード証明書を注文すると、正しい TXT ダイジェストが現れ、プロトコル上の検査はすべて成功した。壊れていたのは ACME ではなく、DNS まで届かなかった権限棚卸しだった。

ケースファイル
境界を越えたのは1経路、消えるのはセッション:BGP maximum-prefix の統治
BGP の maximum-prefix は、受信する経路数に上限を置くための機能である。しかし、設定された動作がセッション切断なら、上限を越えた1経路だけでなく、それ以前に同じ隣接から学習していた経路も同時に失われる。必要なのは大きな数字ではなく、数え方、守る資源、正当な増加、切断後の到達性まで説明できる境界である。

インターネット史
どのパケットが届いたかを言えない応答――KarnのアルゴリズムがTCPに測定を拒ませた理由
同じシーケンス範囲が二度送られる。最初の送信に対するタイマーが切れ、再送が行われ、その後に一つの ACK が前進する。受信の進展は分かる。しかし、その ACK を生んだのが遅れて届いた最初の送信なのか、再送なのかは分からない。Karn のアルゴリズムは、この欠けた因果関係を無理に埋めなかった。TCP は、根拠のない往復時間を時計に教えるより、測定値を一つ失う方を選んだ。

ケースファイル
DNS 応答が Secure でも、接続先はまだ選ばれていない:SSHFP 指紋の権限境界
運用担当者は `ssh db` と入力した。ネットワーク由来の検索サフィックスが短い名前を別の完全修飾名へ展開した。その SSHFP は DNSSEC Secure、提示されたホスト鍵の指紋も一致した。証明はすべて正しかった。ただし、利用者が意図したデータベースではなく、クライアントが選んだホストについてである。

ケースファイル
署名は通った。それでも From は署名者ではない――DKIM ドメイン署名の権限
画面の From ドメインには `bank.example`、判定には DKIM pass と出た。実際に署名したのは攻撃者の `receipt-alert.example` だった。検証は正しい。一つのドメインの証拠を別の名前へ移した判断が誤っていた。

ケースファイル
ダイジェストは一致した。それでも送信者は不明だった――HTTP `Content-Digest` が持つ権限の限界
設定ファイルは通信中に壊れたのではない。最初から有害で、しかも正しく計算された `Content-Digest` が付いていた。サービスは「検証済み」と表示し、そのまま変更を適用した。攻撃者はハッシュ関数を破っていない。本文とダイジェストの両方を自分で用意しただけだ。

インターネット史
沈黙が誤って推測したマスク――ICMPは新しいホストにサブネットをどう教えたか
起動したばかりのホストには IPv4 アドレスがある。しかし、どの宛先が同じ回線上にあり、どこから先をゲートウェイへ渡すべきかはまだ分からない。そこでマスクをブロードキャストで尋ねる。返事はない。古い仕様はアドレスクラスに基づく非サブネット化マスクを暫定利用させたが、その推測が誤り得ることも認めていた。正規の agent が存在しないのではなく、一時的に停止しているだけかもしれないからだ。agent が戻れば、自発的な Reply が過去の推測を直す。この小さな仕組みは、沈黙から選ぶ暫定動作と、設定を公示する権限を分けていた。

ケースファイル
ヘッダーはクライアントを名乗った。接続元は同意しなかった:HTTP `Forwarded` とプロキシ連鎖の権限
本来は二段のリバースプロキシだけが到達できるオリジンに、外部から直接接続できる経路が残っていた。送信者は管理用許可リストのアドレスを `X-Forwarded-For` の左端に置き、IP 制御を通過した。文字列の解析は成功していた。失敗したのは、その接続元に過去の通信経路を証言する権限がなかったことである。
