ドメイン管理、中央集権型から分散型へ
インターネット空間は、ネット上のサーバや端末に、数字の羅列から成るIPアドレス（例えば「192.0.2.0/24」）を割り当て、それらの間でデータを通信することによって成り立っている。ただし、IPアドレスは数字の羅列であるため、多くの人にとって認識や記憶が難しい。このため、個々のIPアドレスに文字列から成るドメイン名（例えば「example.com」）が割り当てられ、ネット空間は構築されている。このような文字列による「住所の定義付け」はドメイン・ネーム・システム（DNS＝Domain Name System）と呼ばれ、インターネットや双方向の情報のやり取りを前提とするWeb2.0を支える技術として必要不可欠な存在になっていた。
ネット上の住所の根幹となるのが、ドメイン名の「ドット」の右側（「.com」や「.net」や「.org」など）に位置するトップレベルドメイン（TLD＝Top Level Domain）である。TLDは1998年に設立された非営利団体ICANN（Internet Corporation for Assigned Names and Numbers）によって管理され、ICANNの下、特定のTLDを管理するレジストリ事業者や、TLDの下（「ドット」の左側）の個別ドメインを取り扱うレジストラ事業者が調整を担っている。
従来型インターネットやWeb2.0におけるドメイン管理は、ICANNを頂点として、個々の事業者が個別名を調整・仲介する「中央集権的な構造」によって成り立ってきたと言って良い。
一方、データを分散的に記録・管理するブロックチェーン技術を活用し、Web３と呼ばれる次世代のインターネットが普及しつつある。利用者個人の情報がブロックチェーン上、秘匿性が高い形で管理・送受信されるため、公的機関の管理や検閲を受けにくい。
このWeb３的な取り組みは、情報や資産の管理だけではなく、ネット上の住所＝ドメイン名の管理においても広がっている。Web3におけるTLDの運用は、ICANNを頂点とした中央集権的な構造のDNSとは異なるものだ。ドメイン名がブロックチェーン上で管理されるため、個々のネット利用者が好みの文字列を容易に登録・更新できる。この仕組みはブロックチェーン・ネーミング・サービス（BNS＝Blockchain Naming Service）と呼ばれ、「分散型の構造」を取っていることが特徴である。（図表1）
BNSはビットコインから派生したブロックチェーンを使ったNamecoinや、オリジナルのブロックチェーンを使ったHandshake、イーサリアムを使ったENSやDecentrawebなど複数のサービスが存在しており、それぞれ利用するブロックチェーンや記録される情報・データの種類が異なる。
図表1 DNSとBNS
Web3空間での住所重複＝名前衝突
Web3空間でのドメイン管理の特色とは何か。まず、ドメイン名を含むデータがパーミッションレスに（管理者の許可無しに）記録されることで、利用者は政府や公的機関、レジストリ業者などによる情報の検閲やプライバシー侵害を受けずにインターネットを利用しやすくなるとされる。また、トップレベルドメイン（TLD）の登録費用もWeb2.0の仕組みよりは総じて安くなる可能性がある。ICANNが2012年に新たなTLDを募集した際、1件当たりの申請手数料は18万5000米ドルに上った。これに対し、一部のブロックチェーン・ネーミング・サービス（BNS）ではTLD登録が入札方式であり、人気がない文字列は事実上無料になることがある。
さらに、一部のBNSはドメイン名に暗号資産のウォレットアドレス機能を持たせることができ、ドメイン名に直接送金することが可能になっている。インターネット上の住所を指す文字列、それ自体が資金口座になる形である。
上記のようなWeb3の特色に着目すれば、ブロックチェーンによるドメイン管理＝BNSはインターネットのサービスやビジネスの可能性を大幅に広げると言えそうだ。しかし、中央集権構造から分散型に管理体制が移ることで発生するリスクも当然存在する。特に、中央集権的な管理者がいないために増える「住所＝ドメイン名の重複」は無視できない問題である。
ドメイン名の重複問題はサイバーセキュリティの専門家の間では、「名前衝突（Name Collision）」と呼ばれ、従来以上にリスクが高まることが懸念されている。
以下、デロイト トーマツ サイバーセキュリティ先端研究所が分析したTLDの名前衝突の実態について整理したい。ポイントは、
① なぜ名前衝突は問題なのか
② Web3空間での名前衝突
③ Web3空間とWeb2.0空間の間で増加し得る名前衝突
――の3点である。
① なぜ名前衝突は問題なのか
ドメイン名が重複する「名前衝突」は、ICANNが管理するWeb2.0時代のインターネットでも懸念されてきた。既存の組織内ネットワークで使われるドメイン名と、ICANNが設定したインターネット上のドメイン名の間で、同じ文字列が使われた結果、通信障害を引き起こした事例がいくつか報告されている。
例えば、
・旧チェコスロバキアを指すトップレベルドメイン（TLD）として「.cs」が登録された直後、組織内ネットワークで「computer science」の意味の「.cs」というドメイン名を利用していた大学・研究機関で不具合が多発した（※1）
・インターネット上のサーバ認証で、公共性を持つドメイン名と同じ名前を用い、組織内ネットワーク利用目的での証明書を取得し、フィッシング詐欺に悪用された（※2）
・内部向けの情報がインターネット上で同一の名前を利用しているネットワークに流出した（※3）
・ 仮想プライベートネットワーク（VPN＝Virtual Private Nork)や特殊な環境で、組織内のサーバに対して公共的なドメイン名を検索する際、文字列が重複している場合、目的の機器に到達できない
――といった具合である。
Web3時代のブロックチェーン・ネーミング・サービス（BNS）は分散構造であり、利用者がドメイン名の文字列を自由に更新・管理できるのが特徴である。その結果、Web2.0時代のDNSよりも、同じアドレスが登録される名前衝突が起きやすくなっている。当然、Web2.0時代同様に、名前衝突による通信障害やデータ流出、データの詐取などのリスクも懸念される。（図表2）
図表2 名前衝突のイメージ
デロイト トーマツ サイバーセキュリティ先端研究所作成
さらに、一部のBNSでは先述の通り、ドメイン名によって暗号資産のウォレットアドレスを記録・管理することができる。この結果、Web3空間では、誤送金のリスクが高まる可能性がある。
例えば、異なる2つのBNSにおいて、全く同じ文字列のドメイン名が登録された場合、あるBNS上のアカウントWに暗号資産を送ったつもりでも、別のBNS上で同一ドメイン名を持つアカウントZに誤って送金してしまうミスが起こり得る。このような脆弱性を狙われ、高度な詐欺やマネーロンダリングに悪用される危険性は無視できない。（図表3）
図表3 名前衝突の想定リスク
② Web3空間での名前衝突
デロイト トーマツ サイバーセキュリティ先端研究所は2023年、利用者がトップレベルドメイン（TLD）を設定・管理・運用できるHandshake、Decentrawebの2つのブロックチェーン・ネーミング・サービス（BNS）の間で、どのくらいTLDが重複しているのか（名前衝突が起きているのか）調査した（※4,5）。
2023年7月27日～8月10日に収集したデータに基づくと、Handshakeには1159万5404件のTLDが設定されていた。一部は期限切れといった理由で無効になっており、有効なTLD数は1104万2187件だった。また、Decentrawebには1万1889件のTLDが設定され、そのうち有効なものは8134件だった。
この2つのBNSサービスの間で、同じ文字列が使われていた（名前衝突していた）TLDは6973件に上った。Decentrawebの場合、有効なTLDの85％がHandshakeでも使われており、ドメイン名が重複していたことになる。名前衝突しているTLDは、そのいずれもが、潜在的に通信障害や誤送金などのリスクを抱えていると言える。（図表4）
図表4 BNS間の名前衝突の分析結果
実際に名前衝突したTLDを分析すると、3文字で構成されたものが1265件と全体の18％を占め、5文字以下のものが全体の過半となった。名前衝突の危険を避けるためには、複数種類の文字（英字、数字、絵文字）を組み合わせ、文字列を長く、複雑にすることが有効策となるが、利用者にとって使いにくくなることは否めない。
③ Web3空間とWeb2.0空間の間で増加し得る名前衝突
さらに、デロイト トーマツ サイバーセキュリティ先端研究所は、Handshake、Decentrawebの2つのブロックチェーン・ネーミング・サービス（BNS）と、ICANNが管理するドメイン・ネーム・システム（DNS）の間で、どの程度のトップレベルドメイン（TLD）が名前衝突を起こしているのかも分析した。「Web3空間の住所記帳制度」と「Web2.0空間の住所記帳制度」を比較調査した形である。
この結果、Handshakeと従来のDNSの間では10件、DecentrawebとDNSの間では2件のTLDが重複していることが判明した。「.music」「.kids」というTLDは、2つのBNSとDNSのいずれにも登録されていた。（図表5）
図表5 DNSとBNSの間の名前衝突
デロイト トーマツ サイバーセキュリティ先端研究所作成
このうち、「.music」はHandshakeでアクセスした場合、「計画的中断」と呼ばれるIPアドレス「127.0.53.53」に応答するように設定されており、Handshakeの該当ドメイン保有者側で通信障害などを避ける技術的な対策を試みたと見られる。一方、「.kids」は調査時点では、保有者側で対応は取られておらず、リスクが相対的に高い状態で放置されていた。
計10件という名前衝突の数は、Web3空間のHandshakeとDecentrawebの間で確認された6973件に比べると少ない。だが、懸念すべき点は、ICANNが新規のTLDの申請を受け付ける予定であることである。これまで、組織内ネットワークやWeb3空間で「ICANNのTLDにはない」として使われていた文字列が、ICANNのドメイン名として新たに追加され、名前衝突を引き起こす可能性は高い。
ICANNが2012年に受け付けた追加申請によって、「.ads」や「.app」など1200件以上のTLDが登録された。ICANNは2023年7月、2012年に続く2回目のTLD追加申請受付に関する計画を公表しており、手続きが始まれば、Web2.0空間の登録ドメイン名の数は急増する。Web3空間とWeb2.0空間をまたがる名前衝突は、2023年調査の計10件から増えると見て良いだろう。
分散型を前提としたガバナンスが焦点
頻発が懸念されるブロックチェーン・ネーミング・サービス（BNS）による名前衝突に対し、有効な対策はあるのだろうか。
調査対象としたBNSのHandshakeとDecentrawebは、既存のトップレベルドメイン（TLD）や著名企業・ブランドのドメイン名をリスト化し、登録できない仕組みを導入している。今後、ICANNが追加する新規TLDについても、登録除外を検討すると見られる。ただし、「分散型管理」を前提としたBNSでは利用者コミュニティによる議論、合意が不可欠であり、新規のTLDすべてに速やかに対応するのは困難である。サービスを運営する事業者側が取り得る対応は、BNSの保有者や利用者に名前衝突の問題や通信障害、誤送金といったリスクを十分に注意喚起することにとどまりそうだ。
強力な介入や対策を見込めない中、利用者側にとっては、
1. ドメイン名を登録する際に既存のTLDと重複していないか調べる
2. 英数字・絵文字を組み合わせたTLDを登録する
3. 自身のドメイン名にアクセスする他の利用者に利用BNS（例えばHandshake）を周知する
――といった予防措置を取ることが重要になる。
まずは、事業者と利用者の双方が、HandshakeとDecentrawebという2つのBNSの間で6973件もの名前衝突が起きていたという現実を認識すべきだろう。そのうえで、（１）コミュニティに適した情報共有・協議の手法、（２）分散型を前提とした合意形成のプロセス――を構築していけるか。Web3空間の安全性、利便性を高めるために、それぞれの参加者がリテラシーを高め、柔軟なガバナンスの仕組みを整えていくことが求められている。
＜参考文献・資料＞
（※1） Internet Architecture Board, “IAB comment on stability of ISO 3166 and other infrastructure standards,” Sep 24, 2003.
（※2） 一般社団法人日本ネットワークインフォメーションセンター、「新gTLD の導入に伴う『内部利用目的での証明書への影響』に関する SSAC による勧告について」、2013年7月。
（※3） 一般社団法人日本ネットワークインフォメーションセンター、「新 gTLD 大量導入に伴う名前衝突(Name Collision)問題とその対策について」、2014年6月9日。
（※4） 伊藤大貴、高田雄太、 熊谷裕志、 神薗雅紀、「ブロックチェーンネーミングサービスにおけるトップレベルドメイン名前衝突の調査」、2023年11月。
（※5） Daiki Ito, Yuta Takata, Hiroshi Kumagai, and Masaki Kamizono, "Investigations of Top-Level Domain Name Collisions in Blockchain Naming Services," to appear in Proceedings of The ACM Web Conference (WWW'24), May 2024.
