中国工商銀行の「.icbc」コントロールプレーン――DNSトラフィック、RDAP、ブランド・レジストリ運用のコスト

要約

中国工商銀行（Industrial and Commercial Bank of China Limited、ICBC）は、自社ブランドのトップレベルドメイン「.icbc」を運用している。トップレベルドメインとは、インターネット上のアドレスで最後のドットに続く部分であり、「.com」や「.jp」と同じ階層に位置する。「.icbc」は一般向けに大量のドメイン名を販売するための空間ではなく、銀行自身のブランド名に結び付いた、限定的な名前空間である
この仕組みが重要なのは、公開されているドメイン数が少なくても、運用責任まで小さくなるわけではないからだ。ICBCは、名前の重複を防ぎ、DNSによる到達経路を維持し、登録データとセキュリティ情報を整合させ、障害や運用主体の変更に備えるコントロール面を持つ。影響を受け得るのは、銀行のリスク管理部門、レジストリ運用担当者、登録変更を処理するレジストラ、セキュリティ対応者、そして将来「.icbc」のアドレスを利用する可能性のある人々である

中国工商銀行（Industrial and Commercial Bank of China Limited、ICBC）は、自社ブランドのトップレベルドメイン「.icbc」を運用している。トップレベルドメインとは、インターネット上のアドレスで最後のドットに続く部分であり、「.com」や「.jp」と同じ階層に位置する。「.icbc」は一般向けに大量のドメイン名を販売するための空間ではなく、銀行自身のブランド名に結び付いた、限定的な名前空間である。

この仕組みが重要なのは、公開されているドメイン数が少なくても、運用責任まで小さくなるわけではないからだ。ICBCは、名前の重複を防ぎ、DNSによる到達経路を維持し、登録データとセキュリティ情報を整合させ、障害や運用主体の変更に備えるコントロール面を持つ。影響を受け得るのは、銀行のリスク管理部門、レジストリ運用担当者、登録変更を処理するレジストラ、セキュリティ対応者、そして将来「.icbc」のアドレスを利用する可能性のある人々である。

公開資料は、「.icbc」で障害が発生したことも、顧客向け銀行サービスがこのドメインに依存していることも示していない。一方で、今後確認すべき対象は明確である。ルートからの委任、権威DNSサーバー、登録データへのアクセス、DNSSECのセキュリティ情報、担当連絡先、例外処理、復旧時の責任分担が、時間の経過やシステム変更の後も一致しているかどうかだ。

BTW Mediaの中国工商銀行ディレクトリは、本稿で扱う企業主体を確認するための公開情報を提供している。

画像：北京・西長安街にある中国工商銀行本店。撮影：Boubloub、CC0。

この写真が写しているのは中国工商銀行の本店建物だけである。「.icbc」のレジストリ基盤、ZDNSのシステム、DNSまたはRDAPサービス、運用担当者、性能、インシデント、顧客への結果を写したものではない。

何が起きているのか

「.icbc」は、Industrial and Commercial Bank of China Limitedをスポンサー組織とする、実際にルートへ委任されたトップレベルドメインである。IANAの委任記録では、2015年4月9日に登録され、2024年12月12日に更新されたことが示されている。ICANNのレジストリ契約情報では、同社が2015年2月19日付の契約に基づくレジストリ運用者として記録され、「.icbc」はSpecification 13のブランド・レジストリとして扱われている。

ここでいうレジストリとは、トップレベルドメインの名前、状態、登録者に関する情報、技術情報を管理する記録機能と運用主体を指す。レジストリは、ブランド名そのものの意味を決める主権者ではない。グローバルな名前解決システムの中で、名前の一意性、登録状態、委任先、セキュリティ情報、変更履歴、運用継続性を維持する、境界の定められた記録管理者である。

IANAの公開ページには、WHOIS、RDAP、八つの権威ネームサーバーが掲載されている。WHOISは登録情報をテキスト形式で照会する従来型の仕組みであり、公開上の接続先は whois.nic.icbc である。RDAPは、登録データを構造化された形式で取得するHTTPベースの仕組みであり、「.icbc」向けの公開ベースも示されている。

委任とは、DNSルートが、あるトップレベルドメインをどの権威ネームサーバーに問い合わせるべきかを公表する割り当てである。IANAの委任報告と準備状況資料は、委任前に申請主体の確認、技術的適合性の確認、連絡先の確認といった段階が完了したことを示している。これは、委任時点に必要な手続きと技術的準備が確認されたことを意味する。しかし、委任後のすべての時点で、すべての義務が継続的に満たされていたことを証明するものではない。

この区別は重要である。公開資料から確認できるのは、ICBCがブランド・レジストリを持ち、DNS、WHOIS、RDAP、契約上の報告といった外部向けの制御面を備えていることだ。公開資料だけでは、内部システムの構成、担当者数、監視方法、変更承認手順、ベンダーとの契約内容、インシデント履歴、復旧訓練の成果までは分からない。

また、本稿の主体はIndustrial and Commercial Bank of China Limitedである。名称が似ているICBC Financial Services LLCやICBC Standard Bank PLCなど、別の法人と混同してはならない。ICBCの2025年年次報告書は、銀行グループ全体のサイバーセキュリティ、技術、業務継続に関するリスクの背景を示すが、「.icbc」のDNS性能、RDAPの品質、レジストラ連携、障害復旧の成否を直接測定した資料ではない。

なぜ重要なのか

ブランド・トップレベルドメインは、外から見ると企業名を付けたマーケティング資産に見える。しかし、技術的には名前と記録を制御するためのコントロールプレーンである。コントロールプレーンとは、利用者に直接コンテンツを届ける部分ではなく、どの名前が存在し、どこへ委任され、誰が変更でき、どのセキュリティ情報が正しいかを決める管理層をいう。

2026年1月の公開月次報告では、「.icbc」のドメイン数は一つだった。この数字だけを見ると、非常に小規模なレジストリに見える。しかし、一つのドメインしかなくても、ルートからの委任、権威DNSの運用、DNSSEC、WHOISとRDAP、レジストラ経由の変更、ホスト情報、月次報告、データエスクロー、緊急時の移管準備は必要になる。

DNS、すなわちDomain Name Systemは、人が読む名前をネットワーク上の到達先へ結び付ける分散型の仕組みである。トップレベルドメインがルートに存在する以上、公開ドメイン数が少なくても、DNS全体の調整関係から外れることはできない。運用コストの一部はドメイン数に比例するが、連絡先管理、鍵管理、委任整合性、報告、復旧準備のようなコストは固定的に発生する。

ブランド・レジストリの目的は、取引量よりも制御にある場合が多い。Specification 13は、一般消費者へ広く販売するレジストリとは異なり、ブランドとその関係者のために限定的な名前空間を運用できる契約上の枠組みを与える。この制限は、一般向け販売、登録者対応、公開市場での紛争を減らし得る。しかし、DNSの仕組みそのものを簡単にするわけではない。

むしろ、利用頻度の低い操作ほど、例外時の負担が大きくなることがある。日常的に多数の登録を処理するレジストリでは、登録や変更の経路が繰り返し使われる。一方、静かなブランド・レジストリでは、ネームサーバー変更、連絡先更新、DNSSECの鍵更新、緊急移管のような操作がまれである可能性がある。まれな操作でも、必要な瞬間には正しく実行できなければならない。そのためには、担当権限、手順、連絡網、検証方法、復元方法を長期間維持する必要がある。

「一つのドメイン」という集中も、リスクを自動的に小さくしない。仮にその一つが重要であれば、単一の変更ミスが公開名前空間全体に影響する可能性がある。逆に、実利用が限定的なら、顧客への影響も小さい可能性がある。ただし、公開資料はどちらも証明していない。確認できるのは、名前空間が小さくてもレジストリとしての責任範囲は実在する、という点までである。

技術層を読み解く

月次カウンターが示すもの、示さないもの

ICANNの2026年1月報告では、「.icbc」について一つのドメイン、七つのネームサーバー、三つの稼働中レジストラが報告されている。レジストラとは、レジストリとの接続を通じてドメイン名の登録や変更を取り次ぐ事業者または認定された運用窓口である。

同月のアクティビティーファイルには、DNSのUDP問い合わせが199,814,952件受信され、同数が応答されたこと、TCP問い合わせが1,814,759件受信され、同数が応答されたことが記載されている。さらに、ホスト確認が8件、ホスト作成が22件、RDAP問い合わせが0件と報告されている。

これらは大きく見える数字だが、稼働率やサービス品質の測定値ではない。あくまで、レジストリ契約に基づく報告枠組みの中で提出された月次カウンターである。受信数と応答数が同じだからといって、可用性100％、成功率100％、障害ゼロ、高速応答、優れた顧客体験を意味するわけではない。

稼働率を算出するには、測定地点、集計期間の境界、再試行の扱い、エラー分類、時計の同期、地域分布、キャッシュの影響、サンプリング方法、監視対象外の時間、独立検証の有無などが必要になる。公開CSVのカウンターだけでは、その条件がそろわない。TCPとUDPの数字も、それぞれの分類で報告された量を示すにすぎず、個々の利用者が目的のサービスへ正常に到達したことまでは示さない。

この慎重さが必要な理由は、過去の「.icbc」報告に、応答カウンターが受信カウンターをわずかに上回る例があるからだ。2025年12月、2025年1月、2024年1月の比較資料を単純に「応答数÷受信数」で計算すると、一部で100％を超える値が生じ得る。閉じた一つの測定系列として完全に対応する値なら、そのような率は成立しない。

不一致の正確な原因は公開ファイルだけでは確定できない。集計時刻の差、収集地点の違い、再試行、カテゴリ定義、後処理、報告上の分類など、複数の要因が考えられる。しかし、原因を推測して特定の説明を断定すべきではない。確実に言えるのは、これらのカウンターから単純な成功率を作るのは危険だということだ。

ホスト確認8件とホスト作成22件についても同じ境界がある。数字は、そのカテゴリで活動が報告されたことを示すが、誰が何の目的で操作したのか、通常変更だったのか例外処理だったのか、どのレジストラ経路を使ったのか、最終的な記録が正しかったのかは分からない。ドメイン数が少ないレジストリでは個々の変更が重要になり得るが、カウンターは変更統制の品質を証明しない。

RDAP問い合わせ0件も、RDAPが停止していたこと、誰にも利用されなかったこと、完全に正常だったことのいずれも証明しない。その報告期間と定義において0件と記録された、という事実だけである。問い合わせが少ないインターフェースでは、外部利用者によって不整合が発見される機会が減るため、運用者自身による確認の重要性が高まる場合もある。

委任、DS、SOA、DNSSEC

公開DNS観測では、「.icbc」の権威ネームサーバーとして次の八つの名前が確認されている。

a.zdnscloud.cn.
b.zdnscloud.cn.
c.zdnscloud.cn.
d.zdnscloud.cn.
f.zdnscloud.cn.
i.zdnscloud.cn.
g.zdnscloud.com.
j.zdnscloud.com.

これらのZDNSブランドを含むホスト名は、公開委任が指している権威DNSの境界を観測できる証拠である。しかし、ICBCと特定事業者との非公開契約、内部アーキテクチャ、担当人数、監視分担、鍵の保有者、障害時の責任、エスカレーション経路を示すものではない。ホスト名から、私的な責任配分を推測してはならない。

同じ観測では、DSレコードも確認されている。DSはDelegation Signerの略で、親ゾーンが子ゾーンのDNSSEC鍵を検証するために保持する要約情報である。公開値は、キータグ52120、アルゴリズム8、ダイジェスト型2である。

DNSSECは、DNSレコードへ暗号学的な署名を加え、検証対応リゾルバーが回答の真正性を確認できるようにする仕組みである。親側のDSと子側のDNSKEYが適切に対応しなければ、検証に失敗する可能性がある。DSが公開されていることは、DNSSECの検証連鎖に必要な要素が存在することを示す。しかし、鍵更新が常に成功してきたこと、フェイルオーバーが機能すること、将来の変更でも不整合が起きないことは証明しない。

SOAも観測されている。SOAはStart of Authorityの略で、ゾーンの基準となるサーバー、管理連絡先、シリアル番号、更新や再試行の時間設定を示すDNSレコードである。観測された主サーバーは a.zdnscloud.com.、責任者メールボックスに対応する値は td_dns_gtld.knet.cn. である。シリアルは1386050294、refreshは600、retryは3600、expireは1209600、minimumは3600と記録されている。さらに、nic.icbc について六つのIPv4アドレスと六つのIPv6アドレスが観測されている。

これらの値は、ある時点で外部から見えた状態を比較するための基準にはなる。後日、ネームサーバー集合、DS、SOAシリアル、管理連絡先、IPアドレス数が変わった場合、その変化自体を直ちに障害とみなすべきではない。重要なのは、変更が予定され、承認され、親と子の両方に反映され、登録データや復旧資料とも照合されたかである。

DNSSECの鍵更新は、暗号処理だけの仕事ではない。旧鍵と新鍵を併存させる期間、親側DSを変更する権限、変更を確認する観測地点、失敗時の戻し方、担当者への連絡、証拠の保存が必要になる。低頻度の変更であるほど、手順が古くなったり、権限者が変わったり、連絡先が失効したりする可能性を管理しなければならない。

委任では、親ゾーンの情報、子ゾーンのNS情報、ホストアドレス、必要なグルーレコードの整合性も重要である。グルーレコードとは、名前解決が循環しないよう、親側に掲載されるネームサーバーのアドレス情報である。これらがずれれば、場所や問い合わせ経路によって結果が変わる可能性がある。ただし、公開資料は「.icbc」でそのような不整合が発生したことを示していない。本稿が扱うのは、運用上監視すべき一般的な故障形態である。

RDAP、WHOIS、登録記録

IANAは whois.nic.icbc とRDAPベースを公開しており、「.icbc」のRDAPヘルプおよび nic.icbc のドメイン情報を返す公開エンドポイントも到達可能である。これは、外部から利用できる登録データ面が存在することを示す。

WHOISは歴史が長く、出力が比較的単純なテキスト中心である。RDAPはHTTP上で構造化されたデータを返し、機械処理、状態表現、イベント、通知、リンクの扱いに適している。両方を提供する場合、それぞれを独立した記録として扱うのではなく、同じ正規データを異なる形式で提示する面として管理する必要がある。

ドメイン名、状態コード、レジストラ参照、連絡先、作成・更新イベント、通知文、ポリシー情報が、WHOISとRDAPでずれれば、DNS自体が動いていても問題は残る。セキュリティ担当者が責任主体を確認できない、インシデントの連絡が遅れる、登録状態の法的・監査上の解釈が不明確になる、といった影響が考えられる。

このため、RDAPとWHOISの照合は、見た目を整える作業ではなく、記録管理の統制である。確認すべきなのは、両インターフェースが同じ権威データから生成されているか、差異が許容されたものか、誰が差異を調査するか、どの程度の時間で修正するか、レジストラ記録やエスクローデータとも一致するかである。

公開エンドポイントへ到達できることは、機能が存在する証拠になる。しかし、すべてのフィールドが常に正しいこと、負荷時にも同じ挙動をすること、将来の変更でデータ品質が維持されることは証明しない。到達可能性は、完全な品質監査ではない。

また、公開RDAPの背後にあるシステム構成も分からない。RDAP、WHOIS、レジストラ向け登録システム、DNS公開、エスクローが単一の正規データベースから生成されているのか、複数システムを同期しているのか、外部プラットフォームを利用しているのかは、公開資料からは判断できない。したがって、見えているインターフェースから私的な構成を断定することはできない。

誰に影響するのか

最初の関係者は、ICBC内部でブランド、技術、サイバーセキュリティ、法務、調達、ベンダー管理、業務継続を担当する部門である。ブランド・レジストリでは、単なるDNS設定を超えて、誰が名前を作成できるか、誰が連絡先を変更できるか、誰が鍵更新を承認できるか、誰が緊急時に操作を戻せるかを決める必要がある。

次に、レジストリの記録と技術サービスを日常的に扱う運用者がいる。ICBCがすべてを直接運用しているのか、どの部分をサービス事業者が担当しているのかは公開情報から分からない。それでも、スポンサー組織、技術運用面、レジストラ、公開連絡先、契約上の義務の間に調整が必要であることは明らかだ。

三つの稼働中レジストラという2026年1月の報告値も、統合作業の存在を示す。公開資料は、各レジストラがどの程度利用され、どの操作を処理し、直接契約なのかプラットフォーム経由なのかを示していない。しかし、認証情報、操作権限、登録ライフサイクル、失敗した処理の照合、例外申請の承認といった管理点は必要になる。

セキュリティ対応者にとっては、WHOISとRDAPの正確性、abuse窓口、DNSSEC、鍵と証明書の有効期限、変更履歴が重要になる。ブランドTLDは登録者が限定されるため、一般的な大量登録による不正利用が少ない可能性がある。その一方で、ブランド名を含む名前は利用者から真正性の印と受け取られる可能性がある。だからこそ、侵害、誤設定、なりすましの疑いが出た場合、誰がどこへ連絡し、誰が停止や修正を承認するかが曖昧であってはならない。

調達や保証を担当する部門は、公開上のZDNSネームサーバー境界を手掛かりにしながらも、それだけで責任分担を決めつけてはならない。必要なのは、契約書、責任分担表、アクセス権一覧、監視結果、変更記録、復旧手順、訓練記録、インシデント対応手順などの非公開証拠である。公開ホスト名は調査の出発点であって、契約構造の答えではない。

一般利用者や顧客への影響については、さらに慎重であるべきだ。「.icbc」を保有する能力があることと、顧客向けの本番サービスが実際にその名前空間へ依存していることは別である。公開資料は、「.icbc」が顧客の認証、銀行取引、ウェブアクセス、業務成果を改善したとも、逆に問題を起こしたとも示していない。

したがって、評価では三つの層を分けなければならない。

レジストリ能力
委任、権威DNS、DS、WHOIS、RDAP、契約、月次報告が存在することから、公開されたレジストリ制御面を持つ能力は確認できる。
製品・サービスの信頼性
稼働率、遅延、エラー処理、監視、変更成功率、インシデント対応、復旧訓練の結果がなければ評価できない。月次カウンターと一時点のDNS観測では証明できない。
顧客の本番成果
どのサービスが利用し、誰が依存し、どのような業務結果が得られたかという証拠が必要である。今回の公開資料には、その証拠はない。

この三層を混ぜると、公開情報が実際より多くを証明しているように見えてしまう。分けて考えれば、確認できる能力と、追加の保証証拠が必要な領域を明確にできる。

中国工商銀行の「.icbc」コントロールプレーン――DNSトラフィック、RDAP、ブランド・レジストリ運用のコスト

なぜ重要か

要約

何が起きているのか

なぜ重要なのか

技術層を読み解く

月次カウンターが示すもの、示さないもの

委任、DS、SOA、DNSSEC

RDAP、WHOIS、登録記録

誰に影響するのか

Sources

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説