ページの先頭です

ページ内移動用のリンクです
  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review（IIR）
  5. Vol.24
  6. 3.技術トレンド

Internet Infrastructure Review（IIR）Vol.24
2014年8月22日発行RSS

目次

3.2 名前衝突問題

ひとまず動けば良いと、利便のために導入された方式が後々問題を引き起こす場合があります。Name Collision（名前衝突）の問題もこれに該当すると言えます。例えば、社内や家庭内など、管理が明確で特定の人しか利用しない環境では、存在しないTLD（勝手TLD）を用いた独自の内部用ドメイン名空間が利用される場合があります。小規模の場合はhostsファイルなどを利用してホスト名を直接クライアントに登録してしまうこともありますし、クライアント数が増えてくると、社内向けキャッシュサーバやファイアウォールで内部からの勝手TLDの問い合わせに応答するようにDNSを設定し、クライアントを特に設定変更することなく内部用ドメイン名でアクセスできるようにしている場合もあります。設定時には当初の目的を達成し動くように見えるのですが、インターネットは変化し続けており、標準技術を利用して標準以外の設定を行っているとどこかで歪みが生じてしまいます。実は近年、rootゾーンに新規のTLDが追加されており、既にその数は300を越えてまだまだ追加が続いています。ここで内部で利便のために設定していた勝手TLDと追加されたTLDがぶつかると、正規に登録したドメイン名が利用できなかったり意図しないサイトに接続してしまったりといった問題が生じてしまいます。これを名前衝突問題と呼びます（図-1）。問題回避のためには、内部用ドメイン名であっても一意性が担保されたドメイン名を利用することです。既に何らかの登録しているドメイン名があるのならば、そのドメイン名に内部用のサブドメインを設定して利用したり、いっそのこと内部用に新規のドメイン名を登録したりすることで、利用しているドメイン名の一意性が将来にわたって担保できるため安心です。

図-1 名前衝突の例

名前衝突問題はサーバの電子証明書にも関わってきます。電子証明書を発行するパブリック認証局は、これまで組織内部のサーバでも電子証明書を利用できるように、勝手TLDの内部用ドメイン名であっても電子証明書を発行してきました。通常のサーバ用電子証明書であれば、電子メールやWebサイトへの特定文字列の登録などでドメイン名保持の確認ができるのですが、勝手TLDではそのような確認ができないので、特段の確認なく電子証明書が取得できていました。すると、新規に追加されたTLDでドメイン名を登録した場合、過去に誰かがそのドメイン名に対応する電子証明書を取得している可能性が出てきてしまいます。電子証明書関連の任意団体であるCA/Browser Forumでは、この名前衝突問題を受け、今後は段階的に内部用ドメイン名向けの電子証明書を制限する運営基準を策定しました。既に現状で発行されている内部用ドメイン名向けの電子証明書は、有効期限が2015年11月1日以降とならないように設定されています。また、新規TLDが追加された場合は、120日以内に関連する電子証明書が失効されるほか、2016年10月には、これまで発行された電子証明書を含め、勝手TLDやインターネットから存在が確認できないドメイン名を用いた内部用ドメイン名に対するすべての電子証明書が失効される予定です。

クライアントには、DNSで名前解決する際にドメイン名を補うサーチリストや、DNSサフィックスといった機能を実装している場合があります。これはユーザが完全なドメイン名（FQDN）を指定しなくても、その先頭部分を入力すれば意図するドメイン名を指定できるようにする機能です。組織内部ではドメイン名部分が共通の場合が多く、複数のサーバや機器に接続するのに何度も同じドメイン名を入力しなくても済むように利用されています。しかし、これもまた名前衝突問題と関わってきます。クライアントの実装に因るところが大きいのですが、「.」が1つでも含まれたドメイン名がアクセス先に指定されると、ひとまずそのドメイン名をDNSで問い合わせ、レコードが存在しなければサーチリストのドメイン名を補って再度問い合わせる挙動が多いようです。そうすると、これまでは初回の問い合わせに対応するドメイン名が存在しなかったために、ドメイン名が補完され意図したドメイン名で名前解決できていたものが、その後の環境変化で初回の問い合わせに応答が得られた場合、意図しないサイトに接続してしまう可能性があります。新たに登録されたTLDにはtokyoやnycといった地域名も含まれており、サブドメインでこれらの地域名を利用して運用している場合には特に注意が必要です。無論、実際にはすべての追加されるTLDと内部でのサブドメイン運用、DHCPなどで配布するDNSのサーチリストを総合的に見て影響を考える必要があります。利用者にはできるだけ完全なドメイン名でアクセスするように誘導しておくのが将来にわたって安心です。

ICANNでは名前衝突問題を早くから認識しており、影響を軽減するために対策を重ねてきました。先に挙げたCA/Browser Forumの運営基準はICANNとの対話による成果ですし、実際のDNSの問い合わせ状況に基づき、新規のTLD導入の危険性評価もしてきました。調査には主にDNS-OARCのA Day in the Life of the Internet（DITL）プロジェクト（※1）で収集された主要な権威サーバからのデータが利用されました。内部用ドメイン名は組織内などで利用されているはずですが、設定ミスやモバイル端末が外部で接続試行した場合などにDNS問い合わせが外部に漏れ出します。これはrootサーバなどでも検知できるため、勝手TLDの利用を推定することができます。この調査では特にhomeとcorpという勝手TLDを利用した問い合わせが格段に多いことが判明し、これらを新規TLDとして認めると問題が多すぎるということで、この2つに関しては無期限に委任保留する旨を決定しました（※2）。また、それ以外の新規TLDに関してもDITLなどのデータへの出現頻度に基づき、名前衝突の可能性が高い一部のセカンドレベルのドメイン名については、登録を禁止する制限付きで委任されることとなりました。

日本国内でもJPNICで新gTLD大量導入に伴うリスク検討・対策提言専門家チームを設立して、名前衝突問題に関する検討を行い提言を文章としてまとめています（※3）。名前衝突の問題は思わぬ所で影響が出てしまう可能性があるため、組織内の設定や文章に記載したURLなど、今までは問題なく動いていたものも含めて見直し、実は危うい前提に成り立っていないかを今一度確認してみてることをお勧めします。

3.技術トレンド

ページの終わりです

ページの先頭へ戻る