Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

「欠陥ドメイン名」が世界的に増えそうな件について

JPRSが「JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定」というプレスリリースを出しましたが、それに対して高木浩光氏から問題提起及び公開質問状のが行われました。 さらに、徳丸浩氏が、実際にcookieで問題が発生することを検証されていました。

高木浩光氏が以下のように述べられています。

何もしなければ、「都道府県型JPドメイン名」の登録が始まっても、cookieを利用できないなどの欠陥ドメイン名となることが予想される。

「都道府県型JPドメイン名」が開始されるにあたって、指摘されているような問題は実際に発生すると思われるので、JPRSが公開質問状に答えることを期待したいところです。

で、今回のこの文章は、「都道府県型JPドメイン名」とは直接は関係がなく、その周辺事項を調べてみた話です。 最近、ICANNが「New gTLDs」とか言いながら雨後のタケノコのようにTLDを増やそうとしているので、恐らく同様の問題が世界中で発生すると予想されるという話題です。

雨後のタケノコのように増えそうなNew gTLDs

これまで、TLDは「ほとんど増えない」ものでした。 数年に一度ICANNが「増やす」と明確に決めたり、国家が増減する以外でTLDが増える事はあまりありませんでした。

しかし、そのような状況が一気に変わろうとしています。 ICANNが「New gTLDs」を開始したため、来年(実際に増えるのは再来年?)から毎年数百のNew gTLDが誕生する可能性があります。

「New gTLDs」の申請は、来年1月12日から3ヶ月間ICANNで受け付けられる予定ですが、現時点では、たとえば、スコットランドが「.scot」を申請したり、ロンドンが「.london」を申請するという記事が出ていました。 他に、ベルリン、ニューヨーク、パリ、ローマ、シドニーがNew gTLD取得を目指しているとあります。 日本の都市としては東京都が「.tokyo」の取得を目指しています(参考1参考2)。

「New gTLDs」とは多少異なりますが、アダルト専用の「.xxx」TLDが開始されたというのもあります。

日本では、キヤノンが.canonを目指すと発表したり、日立が.hitachiの取得を目指すという話題もあります。

New gTLDの審査費用が185000米ドルです。 これは、審査に落ちたとしても返って来ません。 さらに、状況に応じて追加審査が必要な場合には個別に追加費用がかかります。

実際に運用するときには四半期ごとに6250米ドルの固定手数料および、その後のドメイン登録および更新ごとに発生する取引手数料0.20米ドルの2種類の手数料がかかります。 さらに、そのTLDでの登録数が5万件を超えた場合、四半期毎に0.25米ドルを支払う必要があります。

「欠陥TLD」?

今回のPublic Suffix Listに関連する話題で「cookieが利用できないなどの欠陥ドメイン名」という単語が登場しています。

同様に近い将来に「Webにおいてcookieが利用できなかったり、メールが届かなかったり、一部アプリケーションで利用不具合が発生する欠陥TLD」が登場する可能性もありそうです。 新規TLDの場合、メールが届かないなど、様々なアプリケーションでも不具合が発生することを以下の記事が述べています。

たとえば、昔はTLDが必ず3文字以下だったこともあり「.info」を入力しようとしても「不正なドメイン名」として却下してしまうスクリプトがいまだにWeb上に存在します。

さらに、同記事ではSkype、Android、TweetDeckなどで新しい「.xxx TLD」が他のTLD同様の使い方が出来ない点を紹介しています。 DNSのシステムに欠陥があるわけではなく、世界中に無数に存在するアプリケーションがTLD運用の現状にキャッチアップしていないという話なので、完全な解決は事実上困難だったりもします。

Public Suffix Listも、恐らく新規TLD運用上の大きな障害の一つになりそうです。 最新のPublic Suffix Listにアップデートしてないユーザが多い間は、その新TLDを利用したWebサイト運用に支障があるかも知れません。

そう思うと、ICANNに申請したり、New gTLD取得のコンサルティングを依頼したり、New gTLD運用を外注したりのために数千万円を使ったうえで、実際に運用開始したら「欠陥TLD」だったという悲劇を見る組織が登場する可能性もありそうです。

IDN ccTLDの「.日本」

まだICANNへの申請も行われておらず、いつ開始されるのかは未定ですが、「.jp」に並んで日本のIDN ccTLD(Internationalized Domain Name country code Top Level Domain)として、「.日本」の運用が開始される予定です。 数年かけて議論が行われた後に、管理運営事業者の公募が行われましたが、結局、最終的に応募したのがJPRS一社で、JPRSが「.日本」を運用することが決まっています。

この「.日本」は、「.jp」の付加サービスとして提供され、「.日本」のドメイン名登録者は「.jp」の登録者と完全に一致させることが決まっています。 そのため、「tokyo.jp」は「tokyo.日本」としても名前解決できるようになることが予想されます。

IDN ccTLDは、今後世界中で増加する予定です。 特に、アルファベット(というか英語)が利用されていることを嫌う地域では、独自の言語によるドメイン名の利用が急速に拡大することが予想されます。

このようなIDN ccTLDは、Public Suffix Listに登録される項目を増加させる要因になりそうです。

Public Suffix Listの現状

Public Suffix List (effective TLD Names)一覧は以下にあります。

http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1

TLDだけしか書かれていない部分がある一方で、DynDNS.com Dynamic DNS zonesとして多くのエントリがあったりと、データがあるところと無い所で結構差があるようです。 日本に関しては、JPRSのWebサイトに掲載されている情報が入っています。

Public Suffix List vs ネットワークエンジニア

Public Suffix Listに対するネットワークエンジニアの感想は決して前向きではなさそうです。 たとえば、今回の話題に対して「そもそも壊れているのはcookieの仕様だ」という意見がありました。

インターネットプロトコルの標準化などが行われているIETFにおいても、同様の意見が多いようです。

2008年時点でPublic Suffix List作成の協力依頼がIETFのDNSOPメーリングリストに投稿されましたが、反対意見が多く出されるとともに4日間ぐらいこの話題でメールが続いていました。

力武健次氏による日本語での要点まとめが参考になります。

元メール

IETFのDNSOP WGでPublic Suffix Listに関する議論を発生させたのは、DNS管理者にPublic Suffix List作成の協力を依頼する内容でした。

各種反論メール例

以下のような反論がありました。

以下のような文章で始まる長文

As you have no doubt concluded by now, you've touched a nerve. :) It doesn't seem to me that you have, but I hope that you will not interpret the strong reaction you've received as an attack.

「そもそもDNSによる名前空間は管理ヒエラルキーを表現したものではないので、DNS側ではなくクッキー側で議論すべき」という意見

The DNS naming hierarchy does neither follow nor imply administrative hierarchy. Therefore, as others already suggested, the discussion of the need or the way cookies' scopes are defined is more needed than details of a data collection scheme that appears to be in conflict with very basic properties of the protocol.

IETFのdnsext WGのChairに以下のように「spectacularly bad idea」と言われてしまっています

Is there any way to turn this off in Firefox 3? Because it seems to me (as I argued before in response to Yngve's I-D) that this is a spectacularly bad idea.

「この仕組みは新規参入者への障壁になる」という意見

The problem with any such mechanisms is that the barrier of entry for new players (that does not match the currently used list -- including non-upgraded software) is increased. More than what people think.

When we added TLDs with more characters than three, we had problems. Now we will with lists like these have similar problems again. Specifically as we are on the edge of getting new TLDs etc etc (IDN related issues, if nothing else).

This is already described in RFC 3696, Section 2.

「ハードコーディングしないでSPFのようにアップデート可能な方式の方が良いのでは?」という意見

You are *hard-coding* such a list into a 'product'? You do realize that a lot of people simply don't update their software I hope. Unfortunately for the OS's that need updating the most those people don't tend to update.

全体的には「セキュリティ上必要だ」とブラウザ開発者側(Web利用者側)が主張し、「そもそもクッキーの仕様そのものが壊れているので、ワーカラウンドをするのではなく根本を解決すべき」とプロトコル設計者側が反論するという構図で堂々巡りをしているようにも見えます。

これらを読んでいると、両者の言い分が理解できるので、なかなか難しいところだと思います。 クッキーをゼロから直すと言ってもすぐに直るわけではなく、放置すればセキュリティ上の大きなリスクが存在しています。 一方で、プロトコル設計者としては「え!?一点集中での管理とハードコーディング?」という点で「近い将来、管理しきれなくなるんじゃない?」という感想を持つのは自然だろうと思います。 たとえば、現在のPublic Suffix List内にある「DynDNS.com Dynamic DNS zones」のようなことを多数の事業者が行うと、リストが肥大化しそうです。

標準化の状況

「標準」としてのPublic Suffix Listを調べてみると、IETFで標準化されたRFCとしては、2011年4月に発行された「RFC6265: HTTP State Management Mechanism」のSection 5.3に「Public Suffix」が明確に述べられています。

しかし、肝心のPublic Suffixそのものに関しては、WG Draftになれていません。

DNSまわりの話は、IETF内でも最も議論が難しい部分でもあるため(というか閉鎖的にすら見えます。DNS業界怖い。)、Draftを発表されているOperaの方は今後も苦労しそうな雰囲気を感じます。

最後に

ここ数年、ICANNによって長年議論が続いてきた各種TLDが立て続けに開始されようとしています。

これによって、かなり多くのTLDがインターネット上に登場しそうですが、Public Suffix Listもその影響を受けてしまいそうです。 Public Suffix Listを利用するもの以外でも、特定のTLDに「うまくつながらない」というアプリケーションが色々登場する可能性があります。

最近のNew gTLDsの話題を見ていると、来年以降に雨後のタケノコのようにTLDが増えそうな雰囲気を感じるのですが、「これどうなるんだろう?」と思ってしまう今日この頃です。 (最近のTLDまわりの話は、お金のために動いてるようにしか見えないんですけど。。。)

最近のエントリ

過去記事

過去記事一覧

IPv6基礎検定

YouTubeチャンネルやってます!

Copyright (C) Geekなページ.
All rights reserved. 無断転載など、私的利用の範囲を逸脱した利用は禁止します.