萌えドメインなのに……「anime.moe」の登録をICANNが禁じている理由とは

　「.moe」や「.tokyo」など、日本でのニーズが比較的多そうな新gTLDの一般登録受付が7月下旬に相次いでスタートした。空いているドメイン名（文字列）を先願制（早い者順）で登録できるようになったわけだが、先に誰かに登録されてしまったわけでもないのに、登録できないドメイン名が新gTLDにはかなりの数存在しているという。

　これまで一般にはあまり大きな話題とはなっていなかったが、実はこの状況は「DNS名前衝突ブロックリスト」に起因するもので、「.moe」や「.tokyo」に限らず、他の新gTLDでも同様にありうることだ。そこで、以前から新gTLDの状況について継続的な情報提供を実施している一般社団法人日本ネットワークインフォメーションセンター（JPNIC）技術部の小山祐司氏、株式会社日本レジストリサービス（JPRS）技術広報担当の森下泰宏氏に情報提供いただき、「DNS名前衝突ブロックリスト」の“実際のところ”を整理した。

「.moe」で使いたいドメイン名が登録できない!?

　今回の件が改めて注目されたのは、ある人が「.moe」のランドラッシュ（事前登録申請）時に欲しいドメイン名を申し込んだところ、拒否されたという事例が出たことによる。当初、「.moe」を管理するレジストリ事業者である株式会社インターリンクが何らかの意図を持って登録をブロックしたのではないかという疑いがかけられることとなったが、それに対する説明のために、インターリンク自身が公式ブログ上で『なぜ私が欲しい「.moe」ドメイン名を取れないの？』という記事を6月末に公開した。

株式会社インターリンクの公式ブログ記事『なぜ私が欲しい「.moe」ドメイン名を取れないの？』

　このブログ記事は、欲しいドメイン名を登録できない理由として、新gTLDにはレジストリの意思とは関係なくそれぞれ定められた「ブロックリスト」なるものが存在し、そこにリストされている文字列は登録できないようにブロックしなければいけないとされていることを説明したものだ。これから分かることは、前述の人が使いたいドメイン名を登録できなかったのはインターリンクの意思によるものではないということである。

　それによると、登録できないドメイン名には以下の3つのパターンがあるという。

• そのドメイン名が「標準予約リスト」に載っている
• そのドメイン名が「プレミアム予約リスト」に載っている
• そのドメイン名が「DNS名前衝突ブロックリスト」に載っている

　まず「標準予約リスト」は、インターネットのドメイン名とIPアドレスを管理する組織であるICANNが、インターネットにおける混乱を避けるために、国名やその他の重要だと考えられる名称や略称、そして1文字と2文字のドメイン名を登録できない文字列として定めたもので、すべての新gTLDで共通のものとなっている。

　次に「プレミアム予約リスト」は、レジストリとなる組織が新gTLDの新設をICANNに申請した時点で予約したドメイン名の一覧である。このリストの内容は公開されていないが、例えば「dns」「whois」といったレジストリの機能を果たす上で重要な文字列や、商品価値が高くなる（＝後で高額で販売できる）と考えられる文字列が入っているものと思われる。

　「標準予約リスト」および「プレミアム予約リスト」に含まれるドメイン名が登録をブロックされるのは納得できるし、妥当性もある。しかしながら、最後の「DNS名前衝突ブロックリスト」は、新gTLDプログラムが始まった当初は存在しなかったものなのだ。実は、今回のポイントはここにある。

　インターリンクのブログ記事中では、「.moeの名前衝突ブロックリストには約38,000件が掲載されています」「DNS名前衝突ブロックリストに掲載されているドメイン名はICANNが2006年から2013年にかけて行ったリサーチに基づいて作成され、残念ながら新gTLDレジストリが掲載されているドメイン名に関して変更を行うことはできません。ICANNにより、すべての新gTLDレジストリはリストに掲載されているドメイン名の登録をブロックすることが課せられております」といったことが書かれている（後述するが、今回の調査期間は2006年から2012年までが正しい）。

ブロックの背景――“名前衝突”とは

　「DNS名前衝突ブロックリスト」の説明に入る前に、まずは“名前衝突”という問題があることを理解してほしい。この問題を簡単に言ってしまうと、組織内ネットワークやキャリアサービス用の閉域網などで使われている“名前”と、インターネット上の“ドメイン名（名前）”が“衝突”することによる不具合を防ぐために出された注意喚起である（だから“名前衝突”と呼ぶ）。2013年10月以降、1300を超える新gTLDの運用が開始されることで、この問題が顕在化した。

　余談めくが、“ドメイン名”はインターネットのみに存在するとされる。組織内ネットワークやキャリアサービス用の閉域網などで使われている“名前”を“ドメイン名”と呼んでしまうと、単に“ドメイン名”と言った時にそれがインターネットにおける名前であると特定できずに混乱する人が現れるかもしれないからだ。しかし、その使い分けを厳密に行うと分かりづらいと感じるかもしれない。そのため、本記事中では以降、インターネットにおけるドメイン名と、こうした内部用で使われる名前（ドメイン名）を総称して単に“名前”と表記することにする。

　名前衝突という問題は、次のように考えると分かりやすい。

　現在では、インターネットではない内部ネットワークにおいてもDNSを使用し、インターネットと同じような名前解決サービスを利用した運用が行われていることが多い。その際、例えば「.home」「.corp」といったインターネットで使われていない名前であれば、内部ネットワークの外、すなわちインターネットにその名前解決要求が漏れても、従来であれば直接的な問題にはつながりにくかった。しかし、内部ネットワークで使っていた名前が新gTLDと重なると、インターネット上に実在する名前と内部ネットワークでの利用を前提にしている名前が衝突してしまうことになる。

　この場合、名前解決要求はどちらに届くのだろうか？

　これは、他人事ではない。ICANNの調査によれば、ルートサーバーに到達する名前解決要求の件数の上位には、「.com」や「.net」といった正規のトップレベルドメイン（TLD）に続いて、「.local」「.home」「.corp」などといったインターネット上には存在しないはずの名前がランクされていることが分かっている。

　こうした内部利用向けと考えられる名前に対する名前解決要求が外部に漏れるのは、さまざまな原因が考えられる。

　すぐに思いつく原因の1つとしては、ネットワーク機器における不適切な設定が挙げられる。通常、内部ネットワークで専用の名前を使う場合には、その名前を内部に閉じた形で解決できるようにするための設定を適切に行う必要がある。しかし、その設定が十分ではない場合に、このような問題が発生する可能性がある。

　あるいは、サーチリストの不備も考えられる。サーチリストは、例えば「info」と入力すると「info.example.jp」という形に補うというように、名前を適切に補完するためのものだ。この設定が不十分であった場合、内部向けの名前を不適切に補完した形でインターネット側に名前検索をしてしまうケースがあり、これも内部の名前が外部に漏れ出す原因の1つとなりうる。

　いずれにせよ、内部ネットワークから漏れてはならないはずのやり取りが意外と外に漏れ出しているということは事実なのである。ざっと考えても、名前衝突の問題が予期しないウェブサイトへの接続や、意図しない受取人へのメール配信など、セキュリティ上の重大な問題につながる恐れがあることに対しては注意が必要だ。

“名前衝突”の仕組み（JPNICの「名前衝突（Name Collision）問題に関するサイト」より画像転載）

　名前衝突の問題は、もともとが「.home」や「.corp」などのTLDの部分に関する衝突に注目した形で注意喚起が出されているため、それを見た側もトップレベルの部分を中心として考えがちだが、実際にはそれだけではない。

　「DNS名前衝突ブロックリスト」を理解するためのポイントは、このような名前衝突はセカンドレベルにおいても起こりうるという点である。多くのgTLDでは、セカンドレベル（例えば「anime.moe」であれば「anime」の部分）に対してドメイン名登録サービスが提供されている。そのため、名前衝突を起こしている、もしくは名前衝突を起こす可能性のあるドメイン名がセカンドレベルに登録されてしまうことが登録者および利用者の不利益につながることになりうるのだ。そのために、衝突の可能性がある名前は十分な対策が取られるまでブロックする必要が出てくる。

　「DNS名前衝突ブロックリスト」は、この問題の緩和策として考え出されたものである。

　この名前衝突の問題はすでに弊誌でも記事にしているので読まれた方も多いと思われるが、まだの方はそちらを先に読むことをお勧めする。また、昨年の「Internet Week 2013」における「DNS DAY」の記事でもこの問題を紹介している。できれば、下記の記事3本もあわせて読んでいただきたい。

「DNS名前衝突ブロックリスト」に含まれる文字列とは

　「DNS名前衝突ブロックリスト」は、ICANNのウェブサイトから圧縮ファイル「Download the Alternate Path to Delegation Reports and Lists of SLDs to block for all proposed new gTLDs」をダウンロードし、解凍することで誰でも手に入れられる。このファイルは、新gTLDごとに、セカンドレベルドメインにおいてブロックすべき文字列がリスト化され、CSV形式で保存されているものだ。ファイル数は2636個にもなり、それぞれのCSVファイルには「（新gTLD名）-apd-list-12nov13-en.csv」という名称が付けられている。関心のある方は、その内容を確認してみるとよいだろう。ZIPファイルで約54MBあり、解凍すると100MB強になる。

　実際にリストの中身を見てみると、そこに記載されている文字列は新gTLDごとに数や内容が大きく異なっていることがよく分かる。単純にリストアップされた件数だけを見ると、最多は「.wow」の20万5447件。その一方で、0件の新gTLDも17ある。「.moe」では正確には3万8812件あり、「.tokyo」では2万6182件が掲載されている。

　また、「.moe」ではインターリンクのブログ記事にあるように「anime」や「otaku」といった文字列がブロック対象である一方で、「000000e6ffcf」あるいは「00bb」「00cz」のようにランダムな文字列や機械的に生成されたと考えられる連続した文字列なども多く含まれている。その文字列に直接の意味が無いと思われるものであっても、ブロック対象となっているのである。「.tokyo」でも同様で、「sato」や「suzuki」のような意味のある文字列に混じって、「00000005a87a」や「01h01711」といった文字列がブロック対象となっている。

　前述の「.moe」のランドラッシュでブロックされた名前とは、こうした「DNS名前衝突ブロックリスト」に含まれている文字列であったのだ。

「DNS名前衝突ブロックリスト」はどのようにして作られたのか？

　では、「DNS名前衝突ブロックリスト」にリストアップされた文字列はどのようにして決められたのだろうか。

　ICANNがこの件についてまとめた報告書を公開しているページ「Reports for Alternate Path to Delegation Published」を見ると、「DNS名前衝突ブロックリスト」は、2006年から2012年の「DITL」の結果に基づいたものだということが書かれている。

　DITLとは「Day in the Life of the Internet」の略で、「インターネットのある1日の姿・状況を記録する」日のことである。アクセスの傾向に影響を与えそうなイベントがある日を避け、1年に2日間の記録を取る。DNSにおいてそれを行うのは、DNSの運用・分析・調査研究などを通じ、DNSをより安全で高品質なものとすることを目的としている「DNS-OARC」と呼ばれる非営利組織である。

　つまり、「DNS名前衝突ブロックリスト」は、過去のDITLの記録日において、実際にルートサーバーまで到達した名前解決要求のうち、新gTLDと同じTLDを持っていた名前解決要求の内容（文字列）をリスト化したものだと考えるとよい。それらの文字列がなぜルートサーバーに到達したのかについてはさまざまな理由が考えられ、なかなかに興味深い。前述のように内部ネットワーク用の名前解決要求が設定不備によりインターネット上に漏れた場合のほか、例えば「otaku.moe」のようなインターネット上には存在しない（間違った）名前を誰かがウェブブラウザーなどに入力してしまった場合も、ルートサーバーに対する名前解決要求が発生することになるからだ。

　「DNS名前衝突ブロックリスト」に記載されたブロック対象の総数は680万件とも言われ、膨大な数ではある。しかし、DITLでの記録は作為なく淡々と行われたものであるから“客観的な事実”として使うことができる。そのため、「DNS名前衝突ブロックリスト」は実績ベースで作られたという点で妥当なものと言えるだろう。

　ICANNにとって「新しいgTLDの追加」は、その組織の誕生時より、米国政府が1998年に発行した「ホワイトペーパー」によって具体的に課せられた使命の1つとなっている。今回の名前衝突という問題はgTLDを大幅に増やしたことで顕在化したわけだが、gTLDを追加していけば遅かれ早かれどこかで問題となったであろうことは間違いない。その意味では、手段や進め方に全く問題がないとは言えないものの、ICANN設立当初の目的を達成するための活動をしていると感じる。

「DNS名前衝突ブロックリスト」の解除は各レジストリ次第

　「DNS名前衝突ブロックリスト」はICANNによって指定されたものであるため、レジストリはICANNとの契約上、それに従うことが要求される。しかし、その状態がずっと継続するというのも好ましくないと思える。ICANNもその点については認識しており、JAS Global Advisorsというコンサルティング会社にブロックリストの取り扱いに関する推奨対策の作成を委託している。同社による推奨対策は報告書の形で公開され、8月1日付でICANN理事会が承認（採択）した。それらの資料は、下記URLから閲覧できる（なお、TLDにおける名前衝突に関しては、後者の資料に、「.corp」と「.home」に加え、「.mail」も新gTLDとしての新設を無期限延期にすると書かれている）。

　これで、最終的にレジストリが取り得る選択肢として、以下の2つが用意されることになった。これらのいずれを選ぶかは、各レジストリ次第である。

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

“名前衝突”は身近な問題

　繰り返すが、名前衝突の問題は決して他人事ではない。今回の記事はセカンドレベルにおけるブロックリストの問題に焦点を置いたが、企業などのシステム管理者から見れば、本質的な問題は、名前が衝突することによる情報漏えいのリスクやアクセス不能といったトラブルをどのようにして防ぐかである。一方、当該ドメイン名の登録者や利用者から見ると、いかにして無用なリスクを減らすかという点を考えなければいけない。こうしたドメイン名が原因でトラブルが起こったら、多くのもの（顧客や信用など）を失うかもしれないのである。

　新gTLDは、今後も増やされていくであろう。今回、あなたの身近でたまたま名前衝突が起きなかったとしても、それが将来にわたって続くとは限らない。名前衝突という問題への対処法は明確かつ実現可能なものである。できるだけ多くのシステム管理者の方々にこの件の重要性が届き、早急の対応がなされることを期待したいし、ドメイン名登録者の方々には名前におけるリスクについて考えてみていただきたい。そのためにも、JPNICが公開している以下のサイトの内容をよく読んでみてほしい。

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