国際化ドメイン名の表示が有効なトップレベルドメイン
これは、Mozilla プロジェクトが開発するソフトウェアで国際化ドメイン名 (IDN) を表示しているトップレベルドメイン (TLD) の一覧です。
特定の TLD で IDN の表示を有効にするには、その関係レジストリが利用可能な文字を記載したポリシーを発行、維持していることが条件となります。それらの文字に同形異義語が含まれる場合、異なる個人や団体によって酷似したドメインが登録されるのを防ぐ方法がそのポリシーで明記されていなくてはなりません。
【訳注: JP ドメイン名のポリシーについては JPRS による声明 をご参照ください】
Mozilla 製品で自社の管理する TLD の IDN 表示を有効にして欲しいレジストリがありましたら Gerv までご連絡ください。必要に応じて、レジストリのホームページと、利用可能な文字の一覧や同型異義語を回避する方法を明記したポリシーへのリンクをお知らせください。発行されているポリシーにレジストリが従っていない、あるいはポリシーが変更されて、上で述べたような禁止すべき状況を認めるようになっていることに気付いた方は Mozilla セキュリティグループ までご連絡ください。
| .ac | レジストリ | ポリシー |
| .at | レジストリ | ポリシー (利用可能な文字の一覧) |
| .biz | レジストリ | ポリシー |
| .br | レジストリ | ポリシー |
| .ch | レジストリ | ポリシー |
| .cl | レジストリ | ポリシー |
| .cn | レジストリ | ポリシー (JET ガイドライン) |
| .de | レジストリ | ポリシー |
| .dk | レジストリ | ポリシー |
| .fi | レジストリ | ポリシー |
| .gr | レジストリ | ポリシー |
| .hu | レジストリ | ポリシー (セクション 2.1.2) |
| .info | レジストリ | ポリシー |
| .io | レジストリ | ポリシー |
| .is | レジストリ | ポリシー |
| .jp | レジストリ | ポリシー |
| .kr | レジストリ | ポリシー (JET ガイドライン) |
| .li | レジストリ | ポリシー (.ch レジストリによる管理) |
| .lt | レジストリ | ポリシー |
| .museum | レジストリ | ポリシー |
| .no | レジストリ | ポリシー (セクション 4) |
| .org | レジストリ | ポリシー (利用可能な文字の一覧) |
| .pl | レジストリ | ポリシー |
| .se | レジストリ | ポリシー (用語集参照) |
| .sh | レジストリ | ポリシー |
| .th | レジストリ | ポリシー |
| .tm | レジストリ | ポリシー |
| .tw | レジストリ | ポリシー (JET ガイドライン) |
| .vn | レジストリ | ポリシー (利用可能な文字の一覧) |
特定の TLD の IDN をテスト目的で有効にするには、バージョン 1.5 以降の Firefox で about:config を開き、「network.IDN.whitelist.tld」というブール値の設定を追加します。「tld」の部分は TLD に置き換え、「true」に設定します。この手順はセキュリティ上のリスクを伴うため、ユーザの皆さんにはお勧めできません。
設計原理
私たちがこのような対策を行っている理由について述べた素晴らしい解説が、Neil Harris 氏によって NANOG メーリングリスト に投稿されました。以下はその引用です。
「Mozilla/Opera の偽装対策機構は、幅広い公開分析や議論に基づいたもので、次のような利点があります。
- ユーザにとっての文字の視覚表示という、実際の問題に対応している - 問題は、まさしく文字通り、見る人次第なのです。
- コーディングと配布が容易 - Mozilla の実装の場合、コードは 10 行程度に過ぎません。
- シンプルで非政治的な原則に基づいています。
- ソフトウェアとともに配布するデータのサイズが最小限で済みます。
- 様々な代替案が検討され、却下されていく中で残った唯一の方法です。却下された他の多くの案と異なり、DNS プロトコルの修正やラベル別「言語」コードの配布が不要で、DNS の多重参照、ブラウザへの巨大文字テーブルの追加、WHOIS 情報へのリアルタイムアクセスも必要としません。
- これまでの ICANN の提案と比べて、より徹底的に問題を分析した結果に基づくものであり、Unicode コミュニティの経験や、RFC 3743 のために行われた CJK 言語 (中国語・日本語・韓国語) の偽装問題に関する過去の調査を反映しています。例えば、ICANN が提案した単純な筆記体文字の制限だけでは問題を解決できません。ラテンアルファベットにも区別しづらい同型異義語が数多く含まれるためです。
- IDN を二流市民として扱うようなことはしません。
- 言語や筆記体文字に依存しません。
- レジストリごとの原則によって拡張可能であるため「例外」を設ける必要がなく、自社管理ドメインが簡単に偽装されないよう期待されるレジストリが、顧客向けサービスと思われるような変更を行う際に、そのレジストリに代わって作業を行う必要がありません。
- そして中でも、レジストリからアプリケーションユーザへ信頼の輪をつなぐにあたって、技術的ではない、人間的な方法が使われていることです。
ユーザの立場からみれば、レジストリが自社の偽装対策ポリシーを持っている場合、それを公開しようとしない状況は理解しがたいと言わざるを得ません。そのため、ソフトウェアベンダーがそれらのレジストリの IDN ラベルを自社ソフトウェアで表示しても安全であると考えられます。
もちろん長い目で見れば、レジストリのもっとも一般的な偽装対策の実践が、RFC あるいは Unicode コンソーシアムによって成文化されるのが適当だろうと思います。しかしそれまでは、ソフトウェアベンダーによる特別リストの保守が、短期的には、レジストリに対して、信頼のおける偽装対策ポリシーを実装、発行させるための強い動機付けになるでしょう。」