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.
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.
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.
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.
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.
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.
.
", the delimiter character in domain names.
.jp
or .kr
) of the entered domain names. This makes normalization specific to the area where a domain name belongs.
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.
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.
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.
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.
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.
runmdn has some restrictions and cannot apply to every application. For details, refer to each description.
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.
mDN Wrapper has some restrictions and cannot apply to every application. For details, refer to each description.
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.
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.
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.
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.
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.