DNS Server Configuration

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. Only item to note is that it is necessary to convert encoding of zone master files, etc..

Configure the DNS server according to the following procedure.

1. Determine encording and normalization scheme.
2. Set up a DNS server.
3. Create named.conf, a zone master file.

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

In order to access the DNS server from the client, it is necessary to perform encoding conversion or normalization at the client side using Multilingual Domain Name Conversion API, runmdn or mDN Wrapper, or it is necessary to go through mdnsproxy, which is a proxy server to perform encoding conversion.庁。For details of the mdnsproxy setting, see mDNS 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 Documentation.

• Punycode version 0.3.3
  Proposal for Punycode (it was AMC-ACE-Z before) encoding scheme.
• RACE: Row-based ASCII Compatible Encoding for IDN
  Proposal for RACE encoding scheme.
• DUDE: Differential Unicode Domain Encoding
  Proposal for DUDE encoding scheme.
• Preparation of Internationalized Host Names
  Document that describes the normalization scheme called NAMEPREP that is performed before encoding of domain names.
• Internationalizing Host Names In Applications (IDNA)
  Document that describes how the application should process multilingual domain names.

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 nameprep 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 mdnsproxy enabled to support multilingual domain names through mDNkit assumes that a DNS server employs a single encoding scheme. Such techniques that start up multiple mdnsproxy to handle all encodings would have to be used for mdnsproxy.

---

Setting up a DNS server

With mDNkit, it is necessary to use ASCII compatible encoding (ACE: ASCII Compatible Encoding) such as Punycode or RACE. Therefore, the encoding results in legal characters in traditional host names and allows use of current DNS servers.

---

Creating named.conf, 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 non-ASCII characters such as Kanji.

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 Determining Encoding and Normalization Scheme. mdnconv is the code conversion tool designed to solve this problem.

Although an ASCII character editor allows direct entries with Punycode and RACE, you would be forced to accurately enter code strings such as bq--gbjzg23bn4.bq--3bhbm5km. for "U+3053 U+3093 U+306B U+3061 U+306F U+002E U+4E16 U+754C U+002E" ("Hello, World" in Japanese). Thus the conversion tool radically simplifies the character entry task.

For example when the following command is executed, the db.somezone.euc zone master file written in EUC-JP can be converted to db.somezone.race RACE encoding.

% mdnconv -in EUC-JP -out RACE db.foo.euc > db.foo.race

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

On the contrary, converting from RACE encoding to EUC-JP encoding is generally possible. But it is not always converted to the original EUC-JP file. 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.

Note that, in general, conversion from ASCII compatible encoding to local encoding cannot be performed. Refer to conversion information of 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 .local, a Punycode encoding file the suffix .puny and a RACE encoding version file the suffix .race. In such a case, the following type of Makefile could be written to allow automatic conversion using make when a file in local encoding is updated.

.SUFFIXES: .local .puny .race

.local.puny:
        mdnconv -in $(LOCALCODE) -out Punycode -nameprep $(NAMEPREP) \
            $< > $@
.local.race:
        mdnconv -in $(LOCALCODE) -out RACE -nameprep $(NAMEPREP) \
            $< > $@

LOCALCODE = EUC-JP
NAMEPREP  = 06

TARGETS = db.foo.puny

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.