トピック
DNS 委任権限
「トピックの観点から見たDNSトピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
ICANN
ICANNの権限はどの文書で作動するのか
ICANN の影響力は、インターネット全体を直接規制する一般的な権限から生じるのではない。使命を定める文書、コミュニティーが策定するポリシー、レジストリやレジストラとの契約、そして契約当事者による実施が連鎖することで、特定の決定が運用上の結果になる。問題は、誰が「最終決定者」かではなく、どの文書が権限を与え、誰が実行し、どの手続きで争えるかである。
ICANN
ICANNの.COM更新を追う：公開参加、理事会権限、契約発効、救済の境界
ICANN の.COM レジストリ契約更新は、単一の決定ではない。公開コメント、交渉、理事会の承認、委任された執行、そして契約の発効という複数の制度層を通過して成立する。本稿は、2024年の更新を一つの具体的な経路としてたどり、誰がどの文書によって権限を行使し、どの時点で提案が運用上の義務へ変わったのかを検証する。
ICANN
ICANNの権限はどこから来て、どの手続きで実装されるのか
ICANN のドメイン名調整における実務上の権限は、単一の公的命令から生じるものではない。定款・付属定款が制度上の任務と説明責任を定め、レジストリおよびレジストラとの契約が運用上の義務に変換し、契約遵守部門が苦情と証拠を段階的な執行手続きへ移す。問題が理事会や職員の行為に及ぶ場合、再考請求と独立審査という別の救済経路が関係する。本稿は、この権限が「任務」から「契約上の圧力」、さらに「救済」へ移る経路を追う。
ICANN
ICANNの権限はどこから来るのか――契約・技術運用・救済手段をたどる
ICANN の影響力は、単一の公的権限として与えられているわけではない。法人としての目的、マルチステークホルダーによる政策形成、レジストリやレジストラとの契約、IANA 機能をめぐる技術的な取り決め、そして異なる基準を持つ複数の救済手段が、別々の地点で実際の結果を生み出している。本稿は、規則が採択されてから契約上または技術上の措置として実行されるまでを追い、誰が何を止め、条件づけ、遅らせ、変更し、または修復できるのかを検討する。
IETF
Shumon Huqueと、DANEの永続ではなく証拠の継続を約束する拡張pin
「正しい記録がある」と「正しい記録がもうない」は、どちらも検証できる。しかし、何も返ってこない状態は同列ではない。RFC 9102の extension pin は、この三つを区別するためにある。server が将来も提供すると約束するのは、同じ TLSA ではなく、現在の DNSSEC 状態を client が確かめられる回答である。
ICANN
ICANNの権限はどこから来て、どこで救済されるのか
ICANN のインターネット識別子調整における権限は、政府の一方的な命令権としてではなく、組織規約、契約、委任された運用手続、そして説明責任の仕組みが連結した制度として現れる。本稿は、その権限がどの文書によって支えられ、どの地点でレジストリ、レジストラ、IANA 機能運用者、政府その他の主体の責任に接続し、争われた決定に対してどのような限定的救済が用意されているのかを追う。
IETF
応答できた時点では、Onion鍵の証明はまだ終わっていない：RFC 9799
Onion Service の証明書発行では、時系列を崩すと証拠の意味が変わる。サービスへの到達、ACME アカウントの認証、Onion 身元鍵による証明、記述子の伝播、CAA の確認、最終 CSR は、同じ「成功」の別名ではない。RFC 9799 は各段階に固有の鍵と期限を与える。
グローバルのクラウドサービス
almazcloud.network と AS210328：公開情報が示すもの、示さないもの
almazcloud.network と AS210328：公開情報が示すもの、示さないものの調査概要では、今回の動き、読者が確認できる公開証拠、関係する組織、地域的背景、市場への影響度、今後起こり得るインフラへの影響を解説します。グローバルのクラウドサービスの調査・分析の文脈では、この動きをネットワーク運用、事業者戦略、ガバナンス上の判断、資本の流れ、顧客への依存、規制圧力、提携の動き、強靱性への備え、調達リスク、サービス継続性に結び付けて示します。
IETF
Paul Mockapetrisと、応答全体を覆わなかった権威ビット
DNS 応答の先頭には権威ある別名があり、その先にはキャッシュ由来の宛先と補助的なアドレスが続くことがある。AA ビットは正しくても、パケット全体を「権威あり」と保存した台帳は正しくない。
IETF
DNSタイプ69と70は意味を外部台帳に委ねるが、その版を示さない
DNSSEC の検証画面が緑でも、過去の意味まで自動的に確定するわけではない。同じコードを UNECE や ISO のどの版で読んだのかが残っていなければ、署名済みのバイト列から当時の判断を再現できないからだ。新しい DNS タイプ69と70は、IANA が型を割り当て、外部機関が語彙を管理する分担を明確にした。次に必要なのは、その分担を壊さず解釈の根拠だけを保存することだ。
欧州・中東の機関
スウェーデンの「.se」を支える機関と、IP資源を配る別の仕組み
スウェーデンの国別トップレベルドメイン「.se」を管理する仕組みと、IP アドレスや AS 番号を配分する仕組みは、同じインターネット基盤に属していても同じ権限ではない。公開資料から確認できる役割を分けると、Internetstiftelsen の継続性、国家的な監督、RIPE NCC と IANA の番号資源制度、そして対象名の同一性をめぐる不確実性が見えてくる。
記事
AFRINICはNS2ダッシュボードを「リアルタイム」と呼ぶ――リンク先12件はすべて停止済みの単発測定だ
画面が今読み込まれたことと、観測が今も続いていることは同じではない。AFRINIC の公開 NS2 ダッシュボードは「リアルタイム Anycast ノード監視」を掲げる一方、組み込まれた RIPE Atlas 測定は12件すべてが単発で、すでに停止している。そこに残っているのは6地点の導入前後を比べる資料であり、17地点の現在を示す監視網ではない。
記事
DNSのバックアップ計画は第2のリゾルバーではない
APNIC Blog が9月9日に掲載した家庭内ネットワークの体験談は、冗長性を具体的な確認手順に戻す。代替サービスは、稼働し、端末まで届き、制御された障害試験を通り、元の状態へ戻せて初めて備えになる。
記事
RIPE NCCのK-root更新は一括表示では足りない――3拠点に3つの受入記録を
K-root 全体が一度も止まらず、個別拠点の更新だけが未完という状態はあり得る。むしろ Anycast の設計は、その両立を目指す。だからこそ、RIPE NCC が一つの計画項目にまとめたアムステルダム、ロンドン、東京の機器更新は、サービス全体の稼働表示ではなく、拠点ごとの証拠で閉じる必要がある。
グローバルの機関トレンド
ISCの運用統制は、設計された耐障害性をどこまで証明しているのか
Internet Systems Consortium（ISC）は、BIND、Kea、F-Root など、インターネットの名前解決とネットワーク運用を支えるソフトウェアおよびサービスに関わっている。公開資料からは、脆弱性対応、高可用性、障害通知、ルートサーバー運用という統制の設計を確認できる。しかし、設計や手順の公開だけでは、現場での継続性、復旧の実績、下流利用者による修正の完了までは証明できない。本稿は、ISC の公開記録を、予防・検知・対応・修復の連鎖として検証する。
IETF
`_for-sale`レコードは売却意思を示すが、売り手の権限は証明しない
DNS に「このドメイン名は譲渡可能だ」と掲示できれば、買い手は交渉の入口を見つけやすくなる。しかし、その掲示だけでは、誰が保有者を拘束できるのか、提示額が今も有効なのか、移転が完了するのかは分からない。RFC 10023が機械可読にしたのは発見のための意思表示であって、取引の権限証明ではない。
IETF
標準化はどこで運用依存になるのか――IETFの仕様、ネットワークの継続性、測定の限界
IETF の標準はネットワークを直接運用しない。それでも、QUIC、HTTP/3、DNSSEC、BGP、PIM-SM のような仕様が実装されると、接続の維持、経路の回復、名前解決の検証、マルチキャストの到達性は、標準文書だけでは完結しない複数の運用主体に分散する。問題は、仕様が存在するかではなく、障害時にどの主体が状態を戻せるかである。
IETF
DNSOPが採択したのは複数アルゴリズム問題で、「UNIVERSAL」ラベルではない
ワーキンググループ採択は、文案への賛成証明ではない。今回は、その違いが議長の結論そのものに書かれている。採択を支持する声は明確だった。しかし、提案された仕組みの複雑さは、今後の作業で解かなければならない。片方だけを引用すれば、DNSOP が残した判断の幅を消してしまう。
記事
LACNIC RDAP の delegationSigned は親の DS 存在を記録するが、DNSSEC 検証結果ではない
レジストリ応答の真偽値は、DNS のセキュリティ連鎖に対する最終判定のように見えやすい。LACNIC RDAP の `delegationSigned` が答えるのは、登録ビューで親ゾーンに DS レコードが存在すると報告されているか、という狭い問いである。リゾルバーを動かさず、子の鍵も検査せず、現在の検証成功を証明しない。
IETF
共通するネームサーバー1台は継続性の印であり、委任支配の証明ではない
キャッシュ済みの委任をリゾルバーが確かめ直す。親側の NS は大半が入れ替わったが、以前と同じ名前が一つだけ残っている。この共通部分は、キャッシュを継続扱いできるかという問いには役立つ。しかし、移行を誰が承認し、古い入口をなぜ残し、いつ消すのかまでは語らない。