[第86回ICANN会合報告] ccTLD関連の話題

本記事では、第86回ICANN会合（ICANN86）におけるccTLD関連の話題についてご紹介します。

IPR SGは、 Root Zone Databaseで確認可能なIANA Public Record（IANA公開情報）に関して、次の3点を深掘りするStudy Groupです。

1. 情報公開の目的
2. 公開される情報の正確性
3. 正確な情報の提供を強制可能か：漸進的遵守（graduated compliance）もしくは強制（enforcement options）

本セッションでは、2026年10月に開催されるICANN87までの報告書取りまとめに向けた情報を得るため、それぞれの項目について、セッション参加者への問い掛けが行われました。

「1. 情報公開の目的」に関しては、TLDに関する各種情報の確認というのが主な回答で、「2. 公開される情報の正確性」に関しては、「gTLDはICANNと契約関係にあるので正確であるが、ccTLDはそうとは限らない」「ccTLDは政府機関の関与がある場合、手続きが単純でないケースもある」といった回答がありました。

また、「3. 正確な情報の提供を強制可能か」に関しては、最初にIANA（PTI）のPresidentである、Kim Davies氏より、IANAは情報の正確性を上げるべく、「登録住所地へのクリスマスカード（紙）の送付」や「登録メールアドレスへの季節の挨拶の電子メール送付」のような手段で、TLDマネージャーへの継続的な連絡を行っていることが共有されました。

その後、「IANA やその他の関係者が何らかの対応を行うことで不正確な点が修正された事例を知っているか、その場合、どのような対応が行われたか」という質問に対しては、.lb（レバノン）のccTLDマネージャーが不在に陥った際の暫定対応が挙げられました。

大規模災害のような問題発生時におけるIANAの役割は、ICANNのポリシーなどには規定されておらず、そのような事象が発生した場合に、IANAはccTLDマネージャーに対して何かできるのか、できるとすれば何ができるのを探るStudy Groupです。

DR SGでは、「IANAは何をすべきかではなく、IANAは何ができるか」を探るためのシナリオスタディを実施し、その結果と考察がセッションで共有されました。

1. 規制の枠組み：厳格（例:NIS2）⇔特になし
2. 公開される情報の正確性
3. DNS運用：自前⇔外部委託
4. レジストリサービス：自前⇔外部委託
5. 規模（管理件数）：少ない（5千件以下）⇔多い（5百万超）

1. ccTLDマネージャーの組織形態：大規模民間組織

事象：戦争
状況：施設破損
IANAの役割：極小‐交代要員

2. ccTLDマネージャーの組織形態：島しょ国の政府

事象：サイクロン
状況：壊滅的崩壊
IANAの役割：唯一の主体

3. ccTLDマネージャーの組織形態：学術機関

事象：ハリケーン
状況：職員喪失
IANAの役割：調整

4. ccTLDマネージャーの組織形態：政府

事象：長期の電源喪失
状況：同上
IANAの役割：助言

5. ccTLDマネージャーの組織形態：NGO

事象：政変
状況：権限を巡る紛争
IANAの役割：門番

6. ccTLDマネージャーの組織形態：大規模な国の政府

事象：戦争
状況：運用権限者不在
IANAの役割：危機における権威体

シナリオスタディの結果、

• 災害そのものよりも、事前の備えが重要
• 事前の取り決めが、最も安価で最も強力な解決策
• 最も難しいのは、技術的なものではなく権限（統治）の問題
• 規模（組織、管理ドメイン名）」はリスクを判断する上で誤解を招きやすい指標

という考察が出されました。

第1部では、重要インフラを目標としたサイバー脅威の増加に伴い、特にEUのNIS2を筆頭に、米国や英国でも規制対象が拡大していることが共通する傾向として紹介されました。また、運用のレジリエンス（BCPやリスクマネジメント）、迅速なインシデント報告、最低限のセキュリティ基準の策定など、ccTLDに対する要求事項が増加していることが共有されました。

第2部では、規制強化の動きを受け、ccTLD側の実務的な対応や課題が共有されました。特にEUでは、従来からセキュリティや事業継続に関する取り組みを行ってきてはいるものの、新たな規制環境ではその取り組みを体系的に文書化し、必要に応じ証明を求められるとの見方が示された他、災害・有事対応の観点から、DR SGの取り組みも紹介されました。

セッション全体としては、DNSのレジリエンスは、単に技術的な運用だけでなく、各国での規制や政策、災害復旧体制などと密接に関わる経営課題であることが確認されました。ccTLDとしては、技術・運用におけるレジリエンスだけでなく、規制当局との関係構築や、自組織内での災害時の役割分担整理など、幅広い対応の必要性が認識されました。

ccNSOとGNSO Registry Stakeholder Group（RySG）による共同セッションは、2025年6月に開催されたICANN83から定期的に設けられています。これは、ccTLDとgTLDで異なる部分（ルールや契約関係など）はあるものの、同じレジストリとして両者に共通する話題に関し、情報共有・意見交換を行うことでお互いへの理解を深めることを目的としています。

これまでは、DNS Abuseに関連した話題が中心でしたが、今回は以下三つの話題が取り上げられました。

DNS Abuseに関連する話題は、ICANN内での関心が高く、新たなポリシーを検討中のGNSOだけでなく、GACやccNSOなどでも継続的に情報共有や議論が行われています。ICANN86では「DNS Abuse」がタイトルに含まれるセッションが八つ、それ以外にも多くのSO(Supporting Organization)／AC（Advisory Committee）で関連する話題が取り上げられました。

その中で、ccNSOの「ccTLDs and Registrars Tackling DNS Abuse」では、ccTLDとレジストラがDNS Abuseへの対応において、どのように連携できるかを議論する場となりました。特に、攻撃者はTLDの種別を問わずに悪用を行い、あるレジストラやTLDで対処されると、別のレジストラやTLDへ移動する可能性があり、ccTLDとレジストラ間での連携強化が重要であることが論点として提示されました。

全体は2部構成で、前半では.se（スウェーデン）、.no（ノルウェー）、Tucows、Namespaceが登壇し、ccTLDレジストリ側からは各国・地域の法制度やレジストリごとのサービスの違いを踏まえたレジストラとの連携の難しさが語られました。後半ではレジストラ側から、ccTLDごとに登録要件や確認方法が異なるため「DNS Abuseへの対応をできるよう必要な手段を提供して欲しい」といった意見や、登録者は通常レジストラ経由でドメイン名を登録することから、レジストリが登録者に直接連絡し確認を行うことへの懸念が示されました。