プロフィール
Research
Research のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。
IETF
DNSSEC復旧は署名者だけでは制御できない複数の時計で進む
秘密鍵が使えなくなっても、直前までに署名されたゾーンは応答を続けられる。利用者から見れば平常運転、運用者から見れば期限付きの猶予である。DNSOP の新しい作業文書は、この猶予を壊さずに署名機能を戻す手順を示す。同時に、復旧の時間は署名装置だけのものではないと教える。
ケースファイル
DNS 障害は51件の問い合わせを呼んだ。原因はまだ特定されていない
APNIC Labs が2026年8月に行った実験では、明確な否定応答は1テスト当たり約4件だった。`SERVFAIL` は51.73件、無応答は83.46件に達した。権威サーバーが受けた負荷は測れたが、どの層が繰り返したかは測れていない。
IETF
接続経路を変えたあと、ポータルは何を同じ端末とみなすのか
同じ端末から同じ URI を開いても、サーバーに見える接続の条件は変わりうる。キャプティブポータルのセッションを支えるのは固定の番号ではなく、各構成要素が維持する期限付きの対応関係である。
IETF
自己署名の委任更新が証明するのは鍵であって権限ではない
新しい鍵が「この秘密鍵を持っている」と自己紹介するのは簡単だ。難しいのは、その持ち主が子ゾーンの委任を変更してよいと誰が決めたかを示すことである。DNSOP の提案は、この二つを別の状態として扱う。実装と監査も同じ区別を守らなければならない。
ケースファイル
パージは受理された。それでも下流 CDN は拒否できる
制御画面に `201 Created` が返れば、仕事は前へ進んだように見える。IETF の CDNI Triggers v2 改訂20は、その後に起きる拒否を追う。さらに下流の CDN が断ったとき、失敗は別事業者の状態資源へ姿を変えて戻り、拒否した主体の名前さえ伏せられ得る。
IETF
設定を変えたあと、以前の性能試験は何を証明できるか
同じ機種を使い続けても、同じ仕事をさせているとは限らない。RFC 9411 が結びつけるのは製品名ではなく、セキュリティーの有効性と性能を測ったときの構成である。
ケースファイル
レジストリロックの定足数は承認を数えても、権限の独立性は証明しない
別々の二人が承認しても、同じメール基盤と回復窓口に依存していれば、攻撃者が越える境界は一つかもしれない。EPP のレジストリロック案は承認数を扱えるが、承認者の支配が独立していることまでは示さない。
ケースファイル
ICMP がノードを名乗っても、本人確認にはならない
IETF の作業草案・第 05 版は、応答元アドレスだけでは発信ノードを十分に特定できない場合、ノード情報を付ける義務を強めた。その情報は障害解析を助ける一方、認証されておらず、MTU に収めるため元パケットの引用部分を削ることもある。
IETF
手入力をやめても、同じ遅延を測り続けるとは限らない
経路選択のための静かな基準値と、利用者の待ち時間を捉える観測は別の仕事だ。RFC 8570 の測定上の区別は、手動設定から動的測定への移行にも責任の境界をつくる。
ケースファイル
EPP残高は取引を止めても、その根拠となる台帳は示さない
機械が読み取れる残高と、後から判断を説明できる証拠は同じではない。REGEXT で検討中の EPP 残高マッピングは、レジストラが使える資金状態を共通化する。一方、その値を生んだ会計記録まで運ぶ設計ではない。
ケースファイル
保有者指定のRDAP参照は発見範囲を広げてもレジストリ権限は広げない
一つの検索結果に見えても、途中で話者が替わることがある。下位データへ到達する新しい道を作るなら、その境界も画面と記録に残さなければならない。
リーダー
モハメド・アワン・ラ：マレーシアの初期インターネットで受け継がれた能力と権限の境界
技術的能力が組織再編、経営交代、所有権の変化を越えてどのように受け継がれ、どこで権限の境界にぶつかったのかを検証する。
ケースファイル
EPPサーバー検証の成功は日付付きの方針判断であり、健全性証明ではない
緑の表示は、それを生んだ観測より長く残り得る。新しい EPP 案は判定を運べるようにするが、永続的な真実にはしない。
ケースファイル
EPPの「同一主体集合」は外部ポリシーを不可分な境界に変える
コマンドに書かれるドメイン名は一つでも、移転や削除の結果は列挙不能な一群へ及び得る。電文は残るが、その境界を描いた規則はプロトコルの外にある。
インターネット史
招待客の一覧を自分で運んだブロードキャストパケット
UDP データグラムは遠隔サブネットへブロードキャストとして到着する。ところが IPv4 ヘッダーの中には、もっと狭い指示があった。名前のあるホストだけが処理を続ける。SDBM はパケット一つ一つを、その場限りの会員名簿にした。
IETF
更新を止めず、CAA の認可も広げない移行
証明書発行経路を統合するとき、古い入口を残せば可用性は守りやすい。だが同じ CA 識別ドメインの下で、その入口だけがアカウントや検証方式の制約を違って解釈すれば、残したのは予備経路ではなく別の認可規則である。RFC 8657 は、この移行上の緊張を明確にしている。
ケースファイル
EPP拡張レジストリが記録するのは共存であり、勝者ではない
似た機能を持つ二つの拡張が、異なる XML 名前空間のまま同じ公式レジストリに載ることがある。それは整理不足ではない。実装の世界で別々の選択が生きているという、消してはならない記録である。
IETF
通知を一つにまとめても、仕事が一つになるわけではない
画面の通知を差し替えることと、Web Push の待機メッセージを置き換えることは別の操作だ。どちらを使うにしても、消してよい情報の範囲と、利用者が戻ったときに仕事を取り戻す方法はアプリケーションが決めなければならない。
ケースファイル
外側の Bundle はすべて配送された。それでも内側の Bundle は未受信だった
BIBE のトンネルには、同じ「配送済み」では括れない二つの到達点がある。外側の BPv7 bundle が decapsulation endpoint に着くことと、中身の断片が一つのオブジェクトに戻り BPA に受信されることだ。DTN ワーキンググループの新しい draft は、その間にあるローカルで静かな失敗を、運用上の独立した事実として扱っている。
ケースファイル
DNSフィルタリング通知は一つの説明ではなく三つの判断の連鎖だ
フィルタリングされた名前の理由を示すリンクが画面に現れると、DNS がそのまま説明を返したように見える。実際には、リゾルバが何を出すかを決め、アプリケーションが何を見せるかを決め、利用者が取得するかを決めている。