This article is targeted at engineers who already understand DNS, TCP/IP, and basic crypto. We focus on the technical implementation and operational implications of PTI IANA, with concrete RFCs, code paths, and protocol-level detail.
PTIってなぜ作られた
2016年にIANAは米国政府の手を離れ、ICANNの子会社PTIに移管されました。インターネット史の大きな転換点です。技術者の視点から見ると、PTI IANAは単なる組織論ではなく、DNSプロトコル、レジストリ運用、セキュリティ実装の交差点に位置する。
2016年IANA移管の意義
関連RFC: RFC 1034/1035 (DNS基礎), RFC 7480 (RDAP HTTP), RFC 9476 (DNSSEC運用)等を参照のこと。実装観点で重要なのは、以下のスタックの理解である。
- Resolver -> Root -> TLD -> Authoritative の問い合わせフロー
- EDNS0オプション(EDNS Client Subnet等)の取扱い
- レジストリ-レジストラ間 EPP(Extensible Provisioning Protocol)プロトコル
米国政府が手を離した瞬間
実装観点では、PTI IANAに関する次のオペレーション要点を抑えておきたい。BINDやUnbound、PowerDNS等の主要DNSサーバーソフトウェアでの設定例、Anycast構成の運用、DNSSECチェーンの管理など、運用現場で発生する課題は多い。
PTIとICANNの関係
レジストリ運用の技術スタックでは、EPP over TLS、SRS(Shared Registry System)、Backend Registry Operator(BRO)構造、Escrow Agent(DAAA/Iron Mountain等)へのデータエスクロー要件など、ICANN契約上要求される技術項目が多岐にわたる。
国際的な意義
セキュリティ実装観点では、DNS Abuse対策(RFC 9499)、RPZ(Response Policy Zone)、Threat Intelligence Sharingプロトコル等の理解が運用上必須である。AI生成ドメインの大量自動取得対策として、ML-basedな新たな検知手法もICANN82で議論された。
もし再度米国管理に戻ったら
技術者として継続的に追うべきは、IETF DNSOP/REGEXT WG、ICANN OCTOチーム、DNS-OARC、各レジストリの技術ブログである。実装変更が即運用に影響する性質上、メーリングリスト購読を推奨する。
本記事内の図解は当方制作のオリジナル(SVG)です。ICANN/IGFの公式写真・スライドを引用する場合は、各セッションのアーカイブページのURLを末尾に明記しています。本文は ICANN/IGF 公式ドキュメント、現地参加メモ、および筆者の経験に基づきます。
参照
- ICANN 公式:
https://www.icann.org/ - IGF 公式:
https://www.intgovforum.org/ - 新gTLD 2026 Round:
https://newgtldprogram.icann.org/en - Applicant Guidebook (2026):
https://newgtldprogram-2026-agb.icann.org/en/2-preamble.html
更新履歴
第1稿投稿 2026年5月25日
