1.タイトル RFC発行直前!? 国際化ドメイン名サイトを運用するには 2.発表者 小島 育夫(JPNIC) 3.時間 2003 年 1 月 24 日(金) 11:33-12:00 発表 11:33-11:45 質疑応答 11:45-12:05 4.発表の焦点,論点,議題 IDN(国際化ドメイン名)に関する internet-draft のRFC化が10月24日に承認され、本格 運用の段階がせまっている。 国際化ドメイン名サイトを運営するためには、DNSやWebサーバの設定が必要になるので、 ここではzoneファイルやhttpd.confなど設定ファイルの書き方や設定状況の確認方法な ど、サーバオペレータにとって必要となる作業を中心に解説する。 5.発表の流れ 発表者:小島 育夫 社団法人日本ネットワークインフォメーションセンター (なぜJPNICから?の自問に対して自分自身で回答) JPNICが、国際化ドメイン名の検討を開始し、ツールキット(idnkit)の開発を 行い、技術仕様の標準化にも大きく貢献してきました。このような経緯から RFCが発行され安定的な運用が行われる段階まで、国際化ドメイン名に関する 活動を見守っていくことがJPNICの責任であろうと考え、今回の発表をさせて いただくことになりました。 ・今回は具体的なオペレーションを中心に解説したい。 ・国際化ドメイン名とは - IETFで標準化作業が進められているプロトコル - 従来ASCII文字だけだったドメイン名を非ASCII文字に拡張したもの - もちろん,日本語に限らず2バイト系文字一般で使える ・日本語ドメイン名とは - 国際化ドメイン名の技術を使用し,日本語で使われる文字で表現される ドメイン名 - レジストリのサービス仕様 ・標準化状況 - 2002/10/24 にRFC化が決定 ・各種仕様に関して簡単に説明,IDNAの構造について解説 ・国際化ドメイン名による影響  - サーバー側の変更は不要(ASCII文字に変換するため)だが,クライアント 側のIDNA対応は必須 ・サーバ管理者への影響  - zoneファイルやhttpd.confなどに,日本語をそのまま記述できない →ASCII文字に変換して記述する必要がある  - 日本語で設定を書き→変換ツール(idnconv) →ASCIIでの設定になる  - digなどをIDNA対応にする - 変換ツールを活用する (意見募集)変換のためのWebページを用意した方がいいかな? ・ユーザへの広報 - Mozillaの開発チームからidnkitを利用したいとの連絡があった IDNA対応ブラウザの第1号になる可能性大 - MSなども対応を検討中…らしい - すぐ使いたい人にはidn wrapperをかますか,RACEベースのOpera6/7か IE+i-Navを使う方法がある(但しIDNA準拠じゃないよ) ・問題点・課題 - ドメイン名が長くなった場合の影響について(ラベル名63バイトという制限の中で) - 実装(ADSLルータ)によっては、名前解決できないものもあるらしい - キャッシュのためにメモリが食われる可能性がある  - IDNA非対応クライアントへの対応はどうするのか? - 非ASCIIドメイン名のDNS queryの影響 [発表終了・質疑応答へ] Q:RACEとPunycodeの両方を出力してくれるツールはないのか? - idnkitは、コンパイル時にオプションを指定することで、いずれにも 対応可能 会場からの意見: - お客さんに喜んでもらえるエンジニアを目指すべきでは Q:国際化ドメインはWWWでの対応がメインなのか? - URL中の国際化ドメイン名は、ユーザの目にふれる部分であり、 国際化ドメイン名の対応に関しては、ブラウザがもっとも進んで いるため、説明させていただいた 国際化ドメイン名は、Webのためだけのものではなく、他のアプリ ケーションでも利用できる技術である - 今後他のアプリケーションにも対応を促したい Q:ドメイン名のラベルが長くなることで、Queryの応答がUDPでなく てTCPになりFirewallではじかれるようにならないか - 国際化ドメイン名は、ASCIIのみで表現していたドメイン名と比べ、 一般的に長くなる傾向があるが、ラベル名63バイトの制限の中で エンコーディングされる。IDNAは、DNSプロトコルに影響を与える ものでは無いため、そのような心配はない。 - 国際化ドメインが普及する事によって,今まで明らかにならなかった 問題が顕在化してくることは考えられる。 Q:国際化ドメインとは,実はbindの限界に挑戦しているのかも? - 国際化ドメインの導入に関しては,DNSを極力いじらない(悪い影響を与えない) 事を重視してきた - 国際化ドメイン名の割り当て,利用状況に関して司会が会場に挙手を求める →どちらも挙手は少なかった (参加者の間で議論が盛り上がる:IDNAの仕様に関する質疑応答) - 日本にはローカルルールがあるがidnkitはどんな言語にも対応しているのか →マッピングルールで対応できるようなものはあるが、すべてに対応する ことは不可能 - 半角カナはドメイン名には使えないよ - ユーザは、利用するクライアントプログラムが、IDNA対応版か未対応版 なのかを判断することが難しい - 結局,DNSサーバ側をいじる必要があるのでは? →現段階(RFC化直前)で仕様を大幅にいじるのは難しい… rootサーバへの影響などを考えると最善策を検討したい。 →レジストラが独自にやってる国際化ドメイン対応サービス(サーバ側 で特別なナビゲーションを行う方法)は,ICANNから非難されている →IDN検討の初期の頃はそういう考え方もあったが、DNS以外のドメイン名 を使用するプロトコルにも影響するので、アプリケーションでの対応と いうことになった。サーバ側で対処する方法は、どんな文字セットやロ ーカルエンコーディングで送られてきているかをサーバが知る術はない ので、実質的に不可能。DNSは回答を推量するシステムではない。 - tracerouteなど(逆引きに関して)は、IDNAに対応しているのか? →パイプで idnconv をかませる方法がある。 →各種ツールのIDNA化については、協力をいただきたい。 - nkfやlessにPunycode逆変換機能があると嬉しい人がいる? →国際化ドメイン名運用を支援するツールがさらに整備される事を希望する ユーザがちらほら。 - ユーザーベースでの啓蒙活動も必要だろう。 [おしまい] 6.まとめ  国際化ドメインに関しては,マーケッティングレベルからの要求が大きく,標準化の 運用面について JPNIC では配慮はしているが,実際に運用を始めないと未知数な部分 が残っている事も否定できない。サーバ運用側の負担を最小にするために,サーバー側 の変更を最小にするというポリシーで仕様を設計してきたが,DNSサーバソフトにに渡 すクエリーがどうしても長くなるなど,クライアント側だけでの対応にも限界が見えて きているのかもしれない。  質疑応答の最後の方では参加者同士の議論が白熱し,「論」をテーマとした今回の JANOG11セッション全体の目標としては,いい線を行っていたのではないかと思う。 7.所感  まず,セッション全体を見た印象では,まだまだ議論が足りないような印象を受け た。運用開始後も,新しい問題が出る可能性があり,継続的に議論を続けていく必要 があるのではないかと。  だが,個人的には,googleなどの優秀な検索サイト,インターネットナンバーなど の単純化サービスのなどの出現で,ドメイン名自体を国際化する必然性が薄れてきて いる現状で,どこまで実際にユーザーに使われるのかどうか疑問な点もある。(技術的 には可能なのだが,メールで国際化ドメインというのはユーザーサイドには特にピンと 来にくい部分かと推測される)  ドメイン名は上手に利用してナンボのものであり,一部の業者で取得する事自体を 煽っているのは望ましい傾向ではないと思うのだが…。そこに関しては,レジストラ や取得代行業者の良識ある行動を求めるばかりである。 8.記録者 大内 泰明(@Hana Communicaion Networks)