ガイド一覧

mDNkitのガイドは以下のドキュメントから構成されています。

概要説明
- mDNkitの紹介
mDNkit の提供する多言語ドメイン名処理方式
インストールと設定
その他
- 参考文献

一般ユーザの方はまずmDNkitの紹介をご覧ください。そのあと、使用する多言語ドメイン処理方式 (あなたのシステムで利用できる処理方式についてはシステム管理者にお尋ねください) に応じて runmdn、 mDN Wrapper、 mdnsproxy のいずれかをご覧ください。

アプリケーションを多言語ドメイン名対応させようとするアプリケーション作成者の方は、まずmDNkitの紹介と多言語ドメイン名変換 APIをご覧ください。その後、必要に応じて mDNkit 仕様書の MDN ライブラリの仕様を参照するとよいでしょう。

本キットをインストールするシステム管理者の方はすべてのガイドに一通り目を通しておくことをお勧めします。

本キットはフリーソフトウェアです。本キットの使用、再配布等に関する条件については LICENSE.txt をご覧ください。

mDNkit の紹介

mDNkitは、現在多言語ドメイン名を使うために提案されている各種の方式を使用して多言語ドメイン名を扱えるようにするためのパッチ、ツール、ライブラリをまとめたものです。

従来、ドメイン名には、英字、数字(およびハイフン)しか使えませんでした。多言語化されたドメイン名とは、ドメイン名としてこれらに加えて日本語などいろいろな言語の文字を使えるようにしたものです。その実現方式として、現在インターネットドラフトでいくつかの提案がなされています。(参考文献参照)

ここでは、多言語ドメイン名を扱うために必要な、次の二つの基本的な機能について説明します。

エンコーディング変換
NAMEPREP

mDNkit はこれらの機能を次に示すような複数の方法で実現しています。

アプリケーションでの変換・NAMEPREP
クライアントでの変換・NAMEPREP
プロキシサーバでの変換・NAMEPREP
DNS側でのドメイン名の変換

エンコーディング変換

DNS で多言語ドメイン名を使えるようにするには、まず DNS サーバ間で多言語ドメイン名として使用する標準エンコーディング (コードセット) を決める必要があります。現在提案されている方式は、いずれもISO10646 をベースとしたエンコーディングで、大きく次の2つに分けられます。

従来のドメイン名として使うことのできる文字だけを使ったエンコーディング
UTF-8 のように、従来のドメイン名としては正しくない文字列となるエンコーディング

1. の方法は、エンコード結果が従来のドメイン名としても使える文字列になるので、多言語ドメイン名を既存のDNSが受付けることができる文字列で表現することができます。この場合、DNSサーバ自体は既存のものがそのまま使えます。このエンコーディングは、エンコーディング結果が ASCII 文字だけから構成されることから ACE (ASCII Compatible Encoding) とも呼ばれています。

2.の方法では、DNS サーバをそのエンコーディングに対応するように改造する必要があります。

現時点では 1. の ACE を使用することで、既存の DNS サーバをそのまま使うことができるという方式が有力です。

いずれの方式に関しても、DNS サーバの持つドメイン名のデータはあらかじめそのエンコーディングで用意する必要があります。

一方、アプリケーションは一般的には SJIS 等のローカルエンコーディングを使用するので、多言語ドメイン名を使えるようにするためにはどこかでエンコーディングの相互変換をする必要があります。

つまりアプリケーションは多言語ドメイン名をローカルエンコーディングで扱い、DNS サーバは標準エンコーディングで扱うので、クライアントと DNS サーバの間のどこかでアプリケーションの指定したローカルエンコーディングのドメイン名を標準エンコーディングのドメイン名へ変換し、また DNS サーバからの応答に含まれる標準エンコーディングのドメイン名をクライアントで表示可能なローカルエンコーディングに戻さなければなりません。

このためには次の4種類の方法が考えられます。

a. アプリケーションで変換: クライアントアプリケーションでエンコーディングを変換する。
b. リゾルバライブラリでの変換: クライアントのリゾルバライブラリでエンコーディングを変換する。
c. DNS サーバでの変換: DNS サーバでエンコーディングを変換する。
d. プロキシサーバでの変換: クライアントと DNS サーバの間にエンコーディング変換用の中継サーバを設ける。

いずれの方式を標準とするのか現在検討が進められていますが、現時点では IDNA というアーキテクチャに基づく方式が有力です。これはアプリケーションが、名前解決の関数を呼び出す前にあらかじめ変換を実行しておくという方式で、上の a. に対応する方式です。したがって本キットもこの方式に基づいて作られていますが、この方式を使用するためにはアプリケーションを書き換える必要があるため、既存のアプリケーションを使用して多言語ドメインを扱うために他の方式も提供しています。

ただし c. の方式は DNS サーバに不必要に複雑な機構を持ち込むこと、負荷を高めることなどの問題があり好ましくないため、本キットでは提供せず、それ以外の a.、b.、d. の3通りの方法を提供します。

NAMEPREP

多言語ドメイン名を扱うためには、エンコーディング変換の他にも重要な機能があります。それはドメイン名の正規化です。

すでに述べたように、DNS サーバ間で使用されるドメイン名のエンコーディングとして提案されている方式はいずれも ISO10646 をベースとしていますが、 ISO10646 では見かけ上全く同一の文字を表す方法が複数ある場合があります。このような文字に対してその表現方法を1つに統一しないと、ユーザが正しい (と思える) ドメイン名を入力したにも関わらず、名前解決ができないという不都合が生じることになります。

また、従来の ASCII ドメイン名では、ドメイン名のマッチングの際に大文字と小文字は同一視されていました。これをそのまま多言語ドメイン名にも適用することは、マッチングの処理効率などの点で問題があり、あらかじめすべて小文字あるいは大文字に統一するのがより効率的だと考えられます。

このようにドメイン名をあらかじめ設定した基準にしたがって標準形に変換するのが正規化です。この処理はエンコーディング変換の直前に行われるため、名前をあらかじめ前処理しておくという意味で NAMEPREP (NAME PREPeration) と呼ばれています。基本的には NAMEPREP はエンコーディング変換と組になっているので、エンコーディング変換と同じく

アプリケーションでの正規化
リゾルバライブラリでの正規化
DNS サーバでの正規化
プロキシサーバでの正規化

の4種類の方法が考えられます。そして3番目の方式が好ましくないこともエンコーディング変換と同じです。

NAMEPREP で規定されている正規化はすべての多言語ドメイン名に適用されるものですが、地域あるいは言語によっては NAMEPREP の正規化だけでは足りない、別の正規化を行いたいという場合があります。このため、mDNkit では地域化のために次の2つの処理を用意しました。これらは NAMEPREP 処理の直前に実行されます。

デリミタマッピング: ドメイン名の区切り (デリミタ) 文字であるドット "." の代りに誤って入力しがちな文字をドットに変換します。
トップレベルドメインに基づくローカルマッピング: ある文字を別の文字に変換するマッピング処理を行います。ただしどの文字をどの文字にマッピングするかというルールは入力されたドメイン名のトップレベルドメイン (例えば .jp や .kr) 毎に指定できます。これにより、ドメイン名の属す地域固有の正規化を可能にします。

アプリケーションでの変換・NAMEPREP

この方式は、アプリケーションレイヤでエンコーディング変換および NAMEPREP という多言語ドメイン名の処理をすべて行うというものです。すでに説明したように、この方式は IDNA と呼ばれており、多言語ドメイン名の処理方式として現在もっとも有力視されています。この方式では IDN エンコーディングとして ACE を使うことを前提としています。

conversion/NAMEPREP by libmdn API

IDNA にしたがってアプリケーションですべての処理を行うことには次のような利点があります。

多言語ドメイン名はリゾルバライブラリに渡される時点で、ASCII 文字から構成される名前に変換されているので、既存のリゾルバライブラリや DNS サーバを修正する必要がない。
アプリケーションで処理が行われるので、名前解決だけでなくメールやウェブ等の他の処理にも適用可能である。

逆にこの方式には次のような問題があります。

アプリケーションの改造が必要である。

本キットでは、多言語ドメイン名を扱うためのアプリケーション用に、シンプルな多言語ドメイン名変換 API を提供しています。この API を使用することより、アプリケーションに多言語ドメイン名の処理機能を簡単に組み込むことができます。

BIND 9 に対するパッチ

このパッチは BIND 9 に付属する dig や nslookup コマンドに、エンコーディングの変換や NAMEPREP の機能を持たせるものです。これらのコマンドの引数に多言語ドメイン名をローカルエンコーディングで指定することが可能になります。

なお、以前のバージョンでは BIND 9 のリゾルバライブラリに対するパッチを提供し、これにより gethostbyname 等の名前解決関数に直接ローカルエンコーディングのホスト名を指定することが可能でしたが、本バージョンでは IDNA に基づいてアプリケーション側で変換を行うことが基本となりますので、このリゾルバライブラリへの多言語ドメイン名処理の組み込みは廃止しました。

クライアントでの変換・NAMEPREP

アプリケーションを改造して多言語ドメイン名処理を組み込もうにもソースがないので改造ができない、というように既存のアプリケーションをそのまま使用して多言語ドメイン名を利用したい、という要求があります。このため、mDNkit では次のような方式を提供し、このようなアプリケーションでも多言語ドメイン名を名前解決できるようにしています。

runmdn コマンド

このコマンドは、Unix アプリケーションを再コンパイルすることなしに多言語ドメイン名を扱えるようにします。これは共有ライブラリの動的リンク機構を利用して、リゾルバライブラリの提供する名前解決用の関数を多言語ドメイン名の処理を付加したバージョンに動的に置き換えることで実現されます。

conversion/NAMEPREP by runmdn

runmdn にはいくつかの制限事項があり、すべてのアプリケーションに適用できるものではありません。詳しくはそれぞれの解説をご覧ください。

mDN Wrapper

これは Windows クライアントを、やはり再コンパイルなしに多言語ドメイン名を扱えるようにするものです。DLL の機構を利用して、名前解決を行う WINSOCK の一部の関数に多言語ドメイン名の処理を付加することで実現されています。

conversion/NAMEPREP by winsock wrapper

mDN Wrapper にはいくつかの制限事項があり、すべてのアプリケーションに適用できるものではありません。詳しくはそれぞれの解説をご覧ください。

プロキシサーバでの変換・NAMEPREP

すでに述べたように、エンコーディング変換や NAMEPREP はクライアント側で実行するのが理想的だと考えられますが、実際問題としてソースが公開されていないためそのような改良のできないクライアントや、runmdn が適用できないクライアントが存在します。

そこで mDNkit では、クライアントからローカルエンコードされた多言語ドメイン名を含むDNS要求を受け取り、多言語化対応した DNS サーバが受付けられる標準エンコーディングのドメイン名に変換し、また逆に DNS サーバからの応答の多言語ドメイン名をクライアント側で認識できる形式に戻す DNS proxy サーバを用意しました。

mdnsproxyを使うと、クライアント側がドメイン名のチェックや変換を行なっていなければ、クライアント側のローカルコードで記述されたドメイン名を、そのまま多言語ドメイン名として使うことができるようになります。

mDNkit - mDNS Proxy Server

DNS側でのドメイン名の変換

DNS サーバ側のゾーンマスタファイルや named.conf ファイル上のドメイン名は、あらかじめ、規定されたエンコーディングに変換されている必要があります (前述の理由により DNS サーバに変換機能を持たせる方法はここでは考えません)。

mDNkitでは、管理者はこれらのファイルをローカルエンコーディングで作成して必要に応じて変換して使うものと想定し、ローカルエンコーディングから多言語ドメイン名で必要とするエンコーディングへの変換ツールmdnconvを提供します。

mDNkit - mDN converter

注: ローカルエンコーディングで記述されたゾーンマスタファイルを多言語エンコーディングへ変換することはできますが、多言語エンコーディングによっては逆変換ができないことがあります。これは、エンコーディングによってはそのエンコーディングでエンコードされた文字列と通常の ASCII 文字列が区別できず、ファイルのどの部分を逆変換すべきか判定できないものがあるためです。しかし、DNSの管理のためには、逆方向の変換も必要になると思いますので、一部のエンコーディングに対しては逆変換をサポートしています。

DNS自体の多言語化

DNS サーバの使用するエンコーディングによっては、 DNSサーバ自体がドメイン名を8ビット透過で扱うことを要求するものもあります。このようなエンコーディングへの対処のために mDNkitにはBIND 8を8ビット透過にするためのパッチが含まれています。このパッチはBIND 8に含まれている nslookup、resolverについても8ビット透過にします。