トピック
DNS 委任権限
「トピックの観点から見たDNSトピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
ICANN
.jp救済手続の2026年改正：JP-DRP手続規則が変えたもの、変えなかったもの
.jp 登録をめぐる救済手続が、2026年に静かに変わった。日本ネットワークインフォメーションセンター（JPNIC）の理事会は2026年2月17日、JP ドメイン名紛争処理方針（JP-DRP）のための手続規則を改正し、改正版を2月24日に公開、4月1日に施行した。電子メール添付での提出解禁や証明書要件の緩和など、手続を起こす側の実務負担を下げる変更が中心で、誰が手続を起こせるか、何を主張しなければならないか、不服の登録者がどう応じられるかという救済の骨格には手を触えていない。本稿は、この改正が「.jp…
ケースファイル
`NoError` は返った。それでもサービス取引は一度も成功しなかった
RFC 9665 の SRP は、署名付きの一回の DNS Update でホストとサービスを登録できる。しかし応答コードが証明するのは登録処理の受理であり、権威サーバーでの可視性、エンドポイントの本人性、アプリケーションの成功ではない。
IETF
設定は届いた。それでも公開ゾーンは存在しなかった：RFC 9527
RFC 9527は、家庭内ネットワークの命名機関にドメイン名と正引き・逆引き管理先を自動で渡す。そこから先の委任、公開、署名、外部到達性は、別の現実として確かめなければならない。
IETF
名前の列は見えた。接続先の身元までは証明していない――RFC 9532
RFC 9532 は、HTTP プロキシが次ホップを名前解決した際に得た CNAME の連鎖をクライアントへ返す仕組みを定めた。隠れていた経路を照らす有用な情報だが、DNSSEC の証明でも、接続先を認証する資格情報でもない。
ICANN
日本レジストリサービスと.jp権限の連鎖：IANA再委任から2025–2026年の規則改正まで
.jp ドメイン名の管理権限は、1986年の委任から2002年の契約体系、そして2025–2026年の規則改正に至る一連の文書によって付与され、拘束され続けている。この記事は、その権限の連鎖を文書ごとに検証し、公表時点でどの管理の仕組みが実際に有効であるかを確認する。
グローバルの機関トレンド
ISC-AGP1（AS210764）：ルートサーバー登録を支える管理権限の連鎖
ISC-AGP1（AS210764）：ルートサーバー登録を支える管理権限の連鎖の調査概要では、今回の動き、読者が確認できる公開証拠、関係する組織、地域的背景、市場への影響度、今後起こり得るインフラへの影響を解説します。グローバルの機関トレンドの調査・分析の文脈では、この動きをネットワーク運用、事業者戦略、ガバナンス上の判断、資本の流れ、顧客への依存、規制圧力、提携の動き、強靱性への備え、調達リスク、サービス継続性に結び付けて示します。
グローバルの機関
BIND 9 の修正はどこで止まるのか：ISC のサポート境界と、下流が引き受ける仕事
Internet Systems Consortium（ISC）は、ある BIND 9 の欠陥が修正に至るかどうかを決める三つの線を、みずから公開している。どのブランチがサポートされ続けるか、どの深刻度が公開アドバイザリを発動させるか、そして修正版を載せるのは各ブランチの最新の月次リリース一本だけであるという原則だ。ISC 自身の文書、Debian のパッケージ基盤が残した記録、コミュニティが維持するライフサイクル一覧を突き合わせると、この線の内側で速く動くものと、外側に残されるものが見えてくる。主体となる組織の記録は[ディレクトリの項目](https…
ICANN
ICANNは自らの違反を宣言できる。救済の実行は、なお他者の判断を待つ
ICANN の説明責任アーキテクチャの中核は、同社が自らの定款と細則に違反したかを独立に判断する仕組みにある。だが判断と救済は同じ強さを持たない。独立レビュー手続き（IRP）のパネルが下す決定は最終的かつ拘束的な仲裁と位置づけられる一方、是正は勧告にとどまる。この非対称は条文上の話ではない。.WEB をめぐる二度の IRP と、2025年の共同再審請願の終わり方が、それを具体的に示している。
記事
ARINのDS自動更新案は終了した。親ゾーンの判断はまだ別の仕事だ
子ゾーンが新しい鍵を知らせることと、親ゾーンがその知らせを受け入れることは同じではない。ARIN は１月、DNSSEC の DS レコードを自動更新したいという提案に利点を認め、内部で優先順位を検討すると答えたうえで提案を終了扱いにした。終了したのは提案の処理であって、資源保有者が頼れる親ゾーン更新の証明ではない。
ICANN
ガーナの検証率上昇とナイジェリアの「.ng」署名は、別の責任を示す
ICANN の新しい報告は西アフリカの DNSSEC 導入を一つの進歩として描く。しかし、利用者に届く応答を検証する通信事業者と、国別ドメインを署名する登録管理者では、動かせる装置も説明責任も違う。
インターネット史
RFC 2352は法人名をドメイン名にしようとしたが、二つの台帳は一つにならなかった
法人登記は、ある法域で誰が名称を持つかを示す。DNS 委任は、ある枝にラベルが存在することを示す。1998年の RFC 2352は両者を一本の経路に結ぼうとした。ところが RFC Editor の注記は、接続しても権限、移行費用、公開上の同一性までは統合されないことを、本文と同じ記録の中に残した。
IETF
DNSの鍵が一致しても、アプリケーションの許可はまだ出ていない
DANE クライアント認証草案の第14版は、DNSSEC で検証した TLSA レコードと TLS クライアントの証明書または生公開鍵を結び付ける。しかし、その一致が証明するのは鍵の管理であり、サービス利用や個別操作の権限ではない。
ICANN
ICANNが新gTLD申請を止める権限と、申請後に実際に得られる救済
新 gTLD プログラムの第1ラウンドは終了しており、公開されている申請者向け文書は2012年6月4日版の Applicant Guidebook である。申請を拒否し、または延期する権限はプログラム規則と理事会の決定にあり、異議を申し立てた申請者が最終的に受け取るのは、理由を付した最終決定か、定款・規則との整合性についての宣言であって、文字列の委任を命じるものではない。
記事
StorkのDNSシリアル比較は「取得できたゾーン」から始まる
APNIC 62で示されたのは、複数の DNS サーバー間の差分を一つの画面で見つける力だった。その結果を読むには、先にデーモン、ビュー、ゾーン設定のうち何が観測集合に入り、いつ取得されたかを確かめる必要がある。
IETF
RFC 9874：あるクライアントのEPP削除が別の顧客のDNSを壊す
削除要求を出したクライアントにとって正しい成功応答でも、別のクライアントが管理するドメインの名前解決を損なうことがある。RFC 9874が扱うのは、EPP 上の操作権限と DNS 上の依存関係が一致しない場面である。必要なのは一つの成功コードではなく、影響範囲、通知、復元期限、非同期パージまで結ぶ記録だ。
IETF
転送は暗号化された。それでもゾーンの複製には管理者が要る――RFC 9103
XoT が排除するのは、平文の AXFR／IXFR を経路上で読む受動的な観測者である。要求ごとの認可、受信後の複製管理、通常の DNS 応答から残る露出までを自動的に解決するわけではない。
IETF
予備の権威サーバーは答えた。キャッシュ済み鍵では検証できなかった――RFC 8901
第一の権威 DNS 事業者が停止しても、第二の事業者は応答できる。しかし検証リゾルバーがその答えを受理できるとは限らない。RFC 8901が扱う DNSSEC 冗長性は、NS の本数ではなく署名者間の同期契約である。
ICANN
430万件のIDN登録は、ユニバーサルアクセプタンスの達成件数ではない
名前がルートに存在し、登録統計に含まれ、DNS で解決できても、最初のアカウント作成画面で拒まれることがある。ICANN の2026年報告書は、多言語識別子の供給が広がった事実と、それを扱うソフトウェア経路が未完成である事実を同じ資料の中に残した。
IETF
ルート問い合わせが減っても、通信量の勘定は軽くならない
LocalRoot は、再帰リゾルバーから Root Server System へ出ていく通常の問い合わせを大幅に減らせる。一方で、公開元の選定、変更確認、ルートゾーン取得、ZONEMD と DNSSEC の検証、状態の切替、期限前のフォールバックという別の通信と判断を生む。2026年の短期測定は、この更新側の勘定が問い合わせ側を上回り得ることを示した。
ICANN
ICANNはAFRALOの提案を整理したが、採択はしていない
この往復書簡を読む起点は、Board 議長の返信ではなく送付状にある。AFRALO は共同声明を ICANN Board へ「情報提供を目的として」提出した。ところが本文には、資金、実施主体、数値目標を伴う提案が並ぶ。2ページの返信は問題意識を認め、既存事業を示し、使命の境界を引いた。提案一式を拒否した文書でも、実施を決めた文書でもない。