DNS server setup

This document describes how to configure a DNS server to enable handling of multilingual domain names. This configuration procedure does not differ greatly from that used for configuring ASCII domain names. However, two points have to be borne in mind.

A patch may have to be installed in the DNS server
Zone master file and other encoding must be converted

Configure a DNS server according to the following procedure.

Determine the encoding and normalization scheme.
Set a DNS server.
Create named.conf, a zone master file.

When UTF-5 is used for encoding during file generation, the last item, specific problems occur. These problems are discussed in the following section.

UTF-5 specific problems

For information on external specifications and internal processing of mdnconv, the encoding conversion tool, used in the setup, refer to the mdnconv specifications.

To enable the client to access these DNS servers, encoding, conversion and normalization using bind9 with a multilingual domain name patch installed、the runmdn command、the mDN Wrapper or similar tool must be used on the client side or access has to be made via dnsproxy, a proxy server that performs encoding and conversion. dnsproxy configuration is described in DNS Proxy Server configuration.

Determining Encoding and Normalization Scheme

The encoding and normalization scheme to be used for a DNS server must be determined prior to DNS setup.

Encoding scheme should be selected to suit a DNS multilingual system to be assessed. The following are some of the currently proposed encoding and normalization schemes. Various other systems are also being proposed. For details, see reference document.

RACE: Row-based ASCII Compatible Encoding for IDN
The encoding scheme is RACE. Since this is only an encoding proposal, it does not prescribe normalization.
Using the UTF-8 Character Set in the Domain Name System
The encoding scheme is UTF-8 while the normalization scheme is``locale-sensitive downcasing'', which is locale dependent and is not supported by the mDNkit. The closest resembling system is unicode-lowercase, a non-locale dependent uppercase-to-lowercase mapping scheme.
Using the Universal Character Set in the Domain Name System (UDNS)
The encoding scheme is UTF-8 and normalization is unicode-form-c and unicode-lowercase.
UTF-5, a transformation format of Unicode and ISO 10646
The encoding scheme is UTF-5. Since this, also, is only an encoding proposal, it does not prescribe normalization.

When UTF-5 encoding is employed, it is essential to distinguish it from traditional domain names by adding ZLD (zero level domain). Consequently, it is necessary to determine which type of ZLD is to be used.

Refer to the MDN library specifications for information on other encoding and normalization schemes supported by the mDNkit.

Refer to the converter module for information on encoding schemes
Refer to the normalizer module for information on normalization schemes.

Of course, multiple types of encoding schemes can be employed for one DNS server.In such a case, a different type of encoding would be assigned to each zone. However, a client or dnsproxy enabled to support multilingual domain names through mDNkit assumes that a DNS server employs a single encoding scheme. Such techniques that start up multiple dnsproxies to handle all encodings would have to be used for dnsproxy.

Setting up a DNS server

When ASCII compatible encoding (ACE: ASCII Compatible Encoding) such as RACE or UTF-5 is used, the encoding results legal characters in traditional host names and allow use of current DNS servers. However, the other encoding schemes, especially UTF-8, requires the use of a bind9 DNS server (named) with a multilingual domain patch installed, or a bind8 DNS server with an 8-bit through patch installed.

For information on procedures for adding or installing these patches, refer to Adding and installing bind9 patch and Adding and installing bind8 patch.

Creating `named.conf` and a zone master file

The writing of named.conf and zone master files for multilingual domain names does not differ from those of traditional domain names. The only difference is that the domain names contain kanji or other non-ASCII characters.

Since the DNS server does not contain the encoding coversion function, the encoding of the named.conf file and zone master file read by DNS must be adjusted to encoding determined by the encoding and normalization scheme. mdnconv is the code conversion tool designed to solve this problem.

Although an ASCII character editor allows direct entries with RACE and UTF-5, you would be forced to accurately enter code strings such as bq--gbjzg23bn4.bq--3bhbm5km. for 「こんにちは.世界.」. Thus the conversion tool radically simplifies the character entry task.

Editors that allow direct editing with UTF-8 can also be used. However, since such editors will probably not support normalization; encoding conversion is again the recommended procedure.

For example when the following command is executed, the db.somezone.euc zone master file is converted to db.somezone.race RACE encoding and is simultaneously normalized according to Unicode Normalization Form C.

% mdnconv -noconf -in EUC-JP -out RACE -normalize unicode-form-c \
	db.foo.euc > db.foo.race

-in option specifies encoding of input text, -out specifies output text encoding and -normalize specifies the normalization scheme.Refer to mdnconv specifications for a list of options and other values.

RACE encoding also allows you to do the opposite; to convert from RACE encoding to EUC-JP encoding. But note that this is only because mdnconv is provided with RACE encoding specific processing; normally, it is not possible to convert from ASCII compatible encoding to local encoding. The reason is that it is not possible to distinguish between characters denoted in ASCII compatible encoding and those that use normal ASCII encoding in entered character strings. Refer to the conversion information, the mdnconv specifications, for details.

Consequently, the following procedure should be adhered to in creating and maintaining zone master files and other files that are to be read by a DNS server.First, create a file version in local encoding that is edited under version control. Then use mdnconv to convert encoding and normalize the file to generate a file with the encoding employed by a DNS server and use it as the file the DNS server will read.

However, executing mdnconv each time a locally encoded file has to be converted to a server encoded file is time-consuming. In this situation, use the make command to automate conversion.

For example, let's assume that a file in local encoding has the suffix .lc, a UTF-8 encoding file the suffix .utf8 and a RACE encoding version file the suffix .race. Then the following type of Makefile could be written to allow automatic conversion using make when a file in local encoding is updated.

.SUFFIXES: .lc .utf8 .race

.lc.utf8:
	mdnconv -in $(LOCALCODE) -out UTF-8 $(NORMALIZE) $< > $@
.lc.race:
	mdnconv -in $(LOCALCODE) -out RACE $(NORMALIZE) $< > $@

LOCALCODE = EUC-JP
NORMALIZE = -normalize unicode-form-c -normalize unicode-lowercase

TARGETS = db.foo.utf8 db.bar.race

all: $(TARGETS)

When multiple zone master files with different encoding schemes are attempted in a single DNS server, it may be necessary to include multiple encoding schemes in named.conf. Unfortunately, this cannot be handled with mdnconv so the include directive or similar command must be used to split the file so that each file does not contain multiple encoding schemes.

Finally, we will discuss UTF-5 specific problems.

UTF-5 specific problems

A number of problems occur when UTF-5 encoding is used as the domain name encoding of a DNS server.

ZLD specification
ASCII labels that appear singly

ZLD specification

Since UTF-5 is an ASCII compatible encoding scheme, domain names encoded in UTF-5 cannot be distinguished from regular ASCII domain names. By contrast, RACE, another ASCII compatible encoding scheme, appends (bq--), a prefix, to the beginning of each domain name label to allow differentiation from traditional domain names. But since UTF-5 does not have this feature a concept called ZLD is used to identify traditional domain names.

ZLD (zero level domain) is the top level domain appended at the end of a domain name. For example, when a utf5. top level domain is created, all UTF-5 encoded domain names can be made the subdomains of this top level domain making it possible to distinguish them from traditional domain names. Since this top level domain is automatically added to the area (dnsproxy in current mDNkit) where conversion from local encoding to UTF-5 encoding takes place and is automatically deleted when coding is returned from UTF-5 to local encoding, the application does not see this level. The top level domain to an application is at a still higher level, hence the name zero level domain. ZLD is of course visible to a DNS server, so DNS server settings must take ZLD into account.

Thus ZLD is required in UTF-5 encoding, whereas conversion from local encoding to UTF-5 encoding using mdncon requires that the ZLD part of the domain name is distinguished from other parts. For example when the domain name www.ニック.日本.utf5. is converted to UTF-5, it beccomes N7N7N7.J0CBJ0C3J0AF.M5E5M72C.utf5 (but ZLD is utf5.). Thus mdnconv must know what ZLD is. The option -zld is provided for this reason. When a domain name written in a zone master file or other file matches a specified ZLD, this option removes the matching portion from　conversion to output encoding. The conditions for a domain name and ZLD match are as follows:

The domain name ends in a period
ZLD matches the last part of the domain name

For example if ZLD is utf5., only the first of the following three domain names matches ZLD.

www.ニック.日本.utf5.
www.ニック.日本
utf5.ニック.日本.

Also, if used with the mdnconv option -auto, ZLD is often automatically added in which case there is no need to write ZLD in each zone master file. However, as addition of this option is not guaranteed, it may be best not to rely on it.

Single ASCII labels

By default, mdnconv converts to output encoding only domain names that contain two or more non-ASCII characters. Consequently, it does not convert domain names that are entirely made up of ASCII characters. This is to prevent ASCII domain names from being converted to UTF-5 when there are both ASCII domain names and multilingual domain names.

However, this gives rise to the following problem. A label containing only ASCII characters in a multilingual domain name that occurs independently in the zone master file is not converted to UTF-5. For example when the A record of the domain name www.ニック.日本.utf5. is denoted in the zone master file as shown below the www part is not converted to UTF-5.

$ORIGIN ニック.日本.utf5.
...
www	IN A 10.9.8.7

In this case, use FQDN, for example, to add non-ASCII characters.