名前衝突問題――その意外な影響と対策：なぜ希望するセカンドレベルドメイン名が取れないか（1/2 ページ）

一見、自分とは無関係の問題に見えながら、意外と広範囲に影響を及ぼす「名前衝突（Name Collision）」の問題。「新gTLDで自分が欲しい名前が登録できない」という問題も、名前衝突問題と関係している。その背景をJPNICとJPRSに尋ねてみた。

» 2014年07月25日 18時00分公開

[遠山孝，＠IT]

　「名前衝突（Name Collision）」は、インターネットにとって解決しなければいけない重要な問題である。一見、自分には無関係と思えるような話題だが、その影響範囲は意外と広範囲にわたる。

　折しも、インターネット上で「新gTLDで自分が欲しい名前が登録できない」という話題が出てきている。これは、明らかに名前衝突問題と関係しているものだ。

　そのことを確認するために、一般社団法人日本ネットワークインフォメーションセンター（JPNIC）および日本レジストリサービス（JPRS）に対して取材を行った。対応してくれたのは、JPNICの奥谷泉氏、JPRSシステム部の佐藤新太氏の2人である。

セカンドレベルでの名前衝突に注意

　まず最初に、名前衝突問題についておさらいしておこう。2014年6月9日に、JPNICから「名前衝突（Name Collision）」の問題に関する情報提供が行われた。

【関連リンク】

内部システムで利用しているドメイン名にご注意！

～名前衝突(Name Collision)問題の周知と対策実施のお願い～

https://www.nic.ad.jp/ja/topics/2014/20140609-01.html

　簡単に名前衝突問題とは何かをまとめると、従来、「既存のTLDに存在しないから問題ない」としてイントラネットで使っていたドメイン名（以降、JPNICに習い「勝手TLD」とする）が、実際に新しくgTLDとして追加されたドメイン名と同じ文字列であった場合に不具合が起こる可能性がある、というものだ。

　考えられる被害としては、「サービスが利用できない」とか「情報が漏えいする」といったものがある。この問題についてはすでに以下で記事になっているので、詳細を知りたい方はそちらをご覧いただきたい。

【関連記事】

サービスが使えなくなったり、意図しない通信先にアクセスしたり：

増えるgTLDで高まる「名前衝突」のリスクに注意を、JPNICが呼び掛け

http://www.atmarkit.co.jp/ait/articles/1406/09/news132.html

　さて、その名前衝突だが、ここにきてセカンドレベルドメイン名（SLD）の登録という面からも問題が顕在化してきている。具体的には、新gTLDにおいてある種の文字列が登録できないというものである。例えば、.moeドメイン名では以下のように、“anime.moe”や“otaku.moe”といった文字列を登録できない。

【関連リンク】

なぜ私が欲しい「.moe」ドメイン名を取れないの？

http://nic.moe/blog/2014/06/30/why-is-my-moe-domain-unavailable/

　これは、レジストリ自身が決めた何らかの予約ドメイン名であったり、ICANNが指定する新gTLDにおける標準予約リスト（国名や重要と考えられる略称、1文字や2文字のドメイン名といったものが登録できないようにリスト化されている）に入っているからという理由によるものではない。

　実は名前衝突の問題は、TLDだけでなく、SLDにおいても起こる可能性がある。このため、すでに使用された実績があるドメイン名についてはブロックする必要がある。名前衝突を起こしている、もしくは名前衝突をする可能性があるドメイン名の登録を認めてしまうと、そのドメイン名の登録者や利用者に不利益が発生するかもしれないからだ。

　そこでICANNは、ルートサーバーに対して送られた過去の問い合わせ記録から、新gTLDごとにその実績のリストを「ブロックリスト」として作成したというのが実際のようである。

　ちなみに、このブロックリストは、今回の新gTLDプログラムが始まった当時には存在していなかった。名前衝突という問題の重要性が認識されたことにより、その対策として作られたものである。

　その意味では、レジストリにとっても予期していなかったブロックだといえるかもしれない。今回、登録したいのにできない文字列があった場合、その文字列が新gTLDごとに作られたブロックリストに入っているか否か、調べた方が良いだろう。

ブロックリストの内容と調べ方

　では、どのような文字列が該当するのだろうか。ICANNのサイトには、そのための説明とブロックリストが掲載されている。

　「Reports for Alternate Path to Delegation Published」は全体の枠組みに関する話であり、「Download the Alternate Path to Delegation Reports and Lists of SLDs to block for all proposed new gTLDs」はTLDごとのセカンドレベルにおけるブロックリストである。

　ブロックリストはTLDごとに作られ、CSV形式でファイル化されており、それが圧縮された形で置かれている。下記のURLからはその圧縮ファイルがダウンロードできるので、興味のある方は解凍して中身を見てみるとよいだろう。解凍すると2000強のファイルが入ったフォルダーができるが、ファイル名の先頭にTLDの名前が付いているので、それを頼りに見たいリストを見つけることができるだろう。

【関連リンク】

Reports for Alternate Path to Delegation Published

http://newgtlds.icann.org/en/announcements-and-media/announcement-2-17nov13-en

Download the Alternate Path to Delegation Reports and Lists of SLDs to block for all proposed new gTLDs（ZIPファイル）

http://www.icann.org/en/about/agreements/registries/apd-reports-17nov13-en.zip

　そのブロックリストを個別に見ると、gTLDごとにブロックすべき名前の数や内容が大きく異なっていることが分かる。

　筆者が見た限りでは、最多は.wowの20万5447件だが、ブロック数がゼロの新gTLDも17ドメイン名ある。.moeはレジストリ自身のブログで約3万8000件と述べられている（実際には、3万8812件）。また例えば、.tokyoには2万6182件のブロックリストがあり、.kyotoには1435件のブロックリストがあることなどが見て取れる。

　ではなぜ、このような形で新gTLDごとに大きな差異が生じてしまったのであろうか。その理由は、ブロックリストの根拠となったデータが2006年から2012年にかけて記録されたルートサーバーへの問い合わせ実績に基づいており、「好んで使われる文字列」と「あまり意識されなかった文字列」とで大きな開きができてしまったことにあると思われる。

　ここで「ルートサーバーへの問い合わせ」と書いたが、実際には「記録は、1年のうち“Day in the Life of the Internet（DITL）”として決めた2日分だけである」（佐藤氏）という点に注意してほしい。DITL以外の日に、このブロックリストにはない問い合わせがあったかもしれないが、それは記録されていないということである。

　余談めくが、DITLとは、その名の通り「インターネットのある1日の姿・状況を記録する日」のことである。DNSにおけるDITLの記録（ログ）を取っているのは、「DNS-OARC」と呼ばれる、DNSの運用・分析・調査研究などを通じ、DNSをより安全で高品質なものとすることを目的としている非営利組織である。

【関連リンク】

DNS-OARC

https://www.dns-oarc.net

ブロック対象とされた文字列はどうなる？

　さて、ここで気になるのが、ブロック対象とされた文字列の今後であろう。ICANNのサイトによれば、大きく、

ブロックを継続する
名前衝突の事象を調査し、問題が発生しないことをICANNに示すことによりブロックを解除できるようにする

という選択をそれぞれのレジストリが行うことになっている。

　ただし、本記事執筆時点では後者に関する詳細はまだ決まっていない。ICANNが「JAS（JAS Global Advisors）」というコンサルティング会社にブロックリストの取り扱いに関する推奨対策の作成を委託し、それが報告書の形で上がっており、ICANN理事会での審議・承認待ちとなっている状況だということである。

　その内容のポイントを奥谷氏の説明を基にまとめると、「セカンドレベルの委任開始前に名前衝突の有無を確認するため、90日間にわたりブロックリストに掲載された文字列に対して事前にループバックアドレス“127.0.53.53”を返すように求める（AおよびSVRレコード）。これにより、当該ドメイン名と名前が衝突するシステムの管理者がユニークなIPアドレスが応答されることで名前衝突の事象に気付き、調査の助けとすることができる」という。

　以下は、そのことを記述した箇所からの引用だ。

RECOMMENDATION 7: ICANN require registries that have elected the "alternative path to delegation" rather than a wildcard, instead publish appropriate A and SRV resource records for the labels in the ICANN 2LD Block List to the TLD’s zone with the 127.0.53.53 address for a period of 90 days. After the 90 day period, there shall be no further collision related restrictions on the registry.

【出典】

Mitigating the Risk of DNS Namespace Collisions

https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf

JAS Global Advisors LLC

https://www.jasadvisors.com/

　結果がどうなるかは予想の範囲を超えないものとなるため、ここでの言及は差し控える。だがいずれにしても、ICANNは対策を考えているということは確認できた。

　また、7月7日付で以下のInformational RFC（RFC 7304）が公開されたことも付記しておく。RFCのStandardでもなくBCPでもないが、名前衝突を回避するために取り得る手段と陥りやすい事例について簡単にまとめ、技術情報として示したものである。