Guide List

The mDNkit guide is comprised of the following documents.

Ordinary users should refer to Introduction to mDNkit. Depending on the method of processing multilingual domain names (ask the system administrator which method your system can uses), refer to runmdn, mDN Wrapper, or mdnsproxy.

Creators who attempt to make the application support multilingual domain names must first refer to Introduction to mDNkit, then Multilingual Domain Name Conversion API. After that, refer to MDN Library Specification in mDNkit specifications as necessary.

It is recommended that the system administrator that installs this kit carefully read through all the guides.

This kit is free software. Read the LICENSE.txt for information on the use and redistribution conditions of this kit.


Introduction to mDNkit

The mDNkit comprises the patches, tools and libraries to support multilingual domain names using various schemes currently under review.

Traditional domain names can only use alphabetic characters, numerics and hyphens. In addition to these characters, multilingual domain names can also handle Japanese and a great number of characters in other languages. Several recommendations for how these are to be implemented are offered in the form of Internet drafts. (See Reference Documentation).

This section describes the two basic functions required to support multilingual domain names.

mDNkit implements the functions using the following several methods.


Encoding conversion

First, the standard encoding (code set) to be used for multilingual domain names between DNS servers must be determined to enable use of multilingual names in DNS. Currently recommended systems are all based on ISO10646 encoding and classified into the following two types.

  1. Encoding that uses only characters that can be used in traditional domain names
  2. Encoding that uses characters that are not legal in traditional domain names such as UTF-8

With method 1, the encoded result are character strings that could also be used in traditional domain names, allowing you to use a multilingual domain name in the existing DNS server. Existing DNS servers can be used with this method. This encoding is called ACE (ASCII Compatible Encoding) because the encoded result only consists of ASCII characters.

With method 2, the DNS server has to be modified to support the encoding.

At this point, method 1 is prominent because the existing DNS server can be used as is with ACE.

Whichever method is selected, the domain name data held by a DNS server has to be prepared in that encoding.

On the other hand, applications normally use SJIS or other local encoding so some type of interconversion must be performed at some point to enable the use of multilingual domain names.

Thus applications handle multilingual domain names in local encoding, whereas the DNS server handles them in standard encoding. This requires that at some point between the client and the DNS server the domain names in local encoding specified by an application should be converted to domain names in standard encoding, and that domain names in standard encoding in the response from the DNS server are returned to local encoding that can be interpreted by the client.

The following four methods have been proposed to implement this.

a. Conversion is performed by the application
Encoding is converted by the client application.

application-side conversion

b. Conversion is performed by the resolver library
Encoding is converted by the resolver library of the client.

resolver-side conversion

c. Conversion is performed by the DNS server.
Encoding is converted by the DNS server.

server-side conversion

d. Conversion is performed by a proxy server
An intermediate server is set up between the client and the DNS server to handle encoding conversions.

proxy conversion

Which method should be used as the standard is currently under study. At this point, the method based on IDNA architecture is prominent. With this method, corresponding to a. above, the application executes encoding conversion before calling the name resolution function. For that reason, this kit is created based on that method. However, applications need to be rewritten to use this method. Therefore, other methods are provided as well in order to use the existing applications to support multilingual domain names.

System c. unduly increases the complexity of DNS server implementation and thereby its load, making it less desirable, therefore, methods a., b and d. are recommended for use in this kit.


NAMEPREP

In addition to encoding conversion, normalization is another important function to enable handling of multilingual domain names.

As stated above, the recommended encoding of domain names between DNS servers are all based on ISO10646, the problem is that a number of characters that look identical can be denoted in a number of different ways. Unless a single unique method of notation is provided for such characters, the domain name that a user thinks correct may not be able to resolve.

Another problem is that upper case and lower case characters in domain name of traditional ASCII domain names are treated as equivalents. If this method is carried over to the handling of multilingual domain names in its present form, the matching process will be slowed down. To ensure higher efficiency, it may a good idea to use only lower case or upper case letters.

Normalization is the method used to convert domain names to canonical form using a set of standards. Normalization is normally performed just before encoding conversion, thus it is called NAMEPREP (NAME PREPeration), meaning that the name is processed beforehand. Basically, NAMEPREP and encoding conversion is a pair, therefore, there are the following four types, as with encoding conversion.

Like encode conversion, the third option is not desirable.

Normalization prescribed by NAMEPREP applies to all multilingual domain names. However, depending on the area and language, normalization by NAMEPREP may not be sufficient and other normalization may be desired. For that reason, mDNkit provides the following two processes for local use. These are executed immediately before NAMEPREP processing.

Delimiter mapping
Converts characters that tend to be entered mistakenly instead of dot ".", the delimiter character in domain names.
Local mapping based on top level domain
Performs a mapping process that converts some characters to other characters. The rules for which characters are mapped to which can be specified for the top level domain (for example, .jp or .kr) of the entered domain names. This makes normalization specific to the area where a domain name belongs.

Conversion/NAMEPREP by Application

With this method, multilingual domain name processing such as encoding conversion and NAMEPREP are all performed in the application layer. As explained before, this method is called IDNA and is the most prominent multilingual domain name processing method at the moment. This method uses ACE from IDN encoding as a precondition.

conversion/NAMEPREP by libmdn API

There are the following advantages in performing all processing by the application according to IDNA.

On the contrary, this method has the following disadvantages.

This kit provides a simple Multilingual domain name conversion API for applications to support multilingual domain names. By using this API, multilingual domain name processing functions can easily be incorporated into applications.

Patch for BIND 9

This patch provides encoding conversion and NAMEPREP functions to dig and nslookup commands attached to BIND 9. It becomes possible to specify multilingual domain names for the argument of those commands in local encoding.

With the previous version, a patch for the BIND 9 resolver library is provided and this allows the local encoding host name to be directly specified to the name resolution function such as gethostbyname. With this version, however, basically encoding conversion is performed at the application side based on IDNA, thus incorporation of the multilingual domain name processing into this resolver library was abolished.


Conversion/NAMEPREP by the client

Some users want to modify their applications to incorporate the multilingual domain name processing but cannot because they don't have the source, but in actuality they want to use existing applications as is but with multilingual domain names.

runmdn command

This command allows Unix applications to handle multilingual domain names without the need to recompile. The command does this by utilizing the dynamic link of shared libraries to dynamically replace the name resolving functions provided by the resolver library with versions that enable multilingual domain name processing.

conversion/NAMEPREP by runmdn

runmdn has some restrictions and cannot apply to every application. For details, refer to each description.

mDN Wrapper

This command allows Windows clients to also handle multilingual domain names without recompiling. To do so, a DLL mechanism is used to add the multilingual domain name processing function to some of the functions of WINSOCK that perform name resolution.

conversion/NAMEPREP by winsock wrapper

mDN Wrapper has some restrictions and cannot apply to every application. For details, refer to each description.


Conversion/NAMEPREP via a proxy server

As stated above, conversion and NAMEPREP should ideally be performed on the client side. The problem is that there are clients that do not allow such modifications because the source is not made public or runmdn cannot apply.

To cope with such situations, the mDNkit provides a DNS proxy server that receives DNS queries that include multilingual domain names in local encoding from a client and converts these to standard encoding acceptable to a DNS server supporting multilingual domain names, and conversly, converts multilingual domain names in the DNS server response to a format that is understood by the client.

When mdnsproxyis used, the domain names in the local code of the client side can be used as multilingual domain names without modification if domain names are not checked and converted on the client side.

mDNkit - mDNS Proxy Server


Domain Name Conversion on the DNS Side

The domain names in the zone master file and named.conf file on the DNS server side must be converted to the prescribed encoding. (the above reason i.e. adding conversion functionality to the DNS server is not considered here).

mDNkit assumes that the administrator generate these files in local encoding and only convert them as need dictates and to this end provides mdnconv, a conversion tool to handle conversion from local encoding to multilingual domain names.

mDNkit - mDN converter

Note: Zone master files in local encoding can be converted to multilingual encoding, but some multilingual encoding may not be possible to convert back to local encoding. This is because in come encoding schemes the encoded character strings cannot be distinguished from normal ASCII character strings, and it is impossible to know which part of the file should be converted back to local encoding. Still, since backward conversion is necessary for the DNS management, backward conversion is supported for some encodings.


Multilingual support by DNS

Some encodings used by DNS servers requires that the DNS server itself handles domain names with 8-bit transparency. To handle such encoding, mDNkit provides patch that makes BIND 8 8-bit transparent. This patch also turns nslookup and resolver in BIND 8 8-bit transparent.


Notes

Refer to the following documents for information about the usage of mDNkit.

Refer to the documents listed below for the specifications of each programs, libraries and configuration files.