JPNIC's contributions to the Internet community can be made, with the support of JPNIC members.
○This document is invalid due to expiration.
JPNIC Translated Document
Source document: jpnic/jp-named.doc
Date of the source: October 1, 1991
Date of the last update of this translation: February 14, 1996
This is a translation of a JPNIC document. JPNIC provides this
translation for convenience of those who can not read Japanese. But it
may contain mis-translations, and is by no means official. One should
consult the source document written in Japanese for detail.
-----------------------------------------------------------------------
ON NAME SERVERS AND THEIR SETTING (Ver. 1.7)
October 3, 1989
(Final revision date: October 1, 1991)
Hiroaki Takada
Information Sciences Division, Faculty of Science,
University of Tokyo, Japan
hiro@is.s.u-tokyo.ac.jp
NOTE: Since this document was written at the initial period of
starting up domestic name servers, the readers are requested to
understand that there will be many points in this document that
do not agree with the present situation. Also, any volunteers
willing to fully update this document would be welcomed heartily.
This document is prepared centered around the technical descriptions
of the information required at the time of setting name servers.
The method of acquiring an IP address, the method of acquiring a
domain name, obtaining permission of connection to a domestic IP
network, and obtaining permission of connection to Internet are
all outside the scope of this document.
1. What is a Name Server
In general, a name server is a server used for searching an IP
address from a host name. Although there are a number of standards
for name servers, the standard used in Internet, that is, BIND
(Berkeley Internet Name Domain Server) is described below. For more
details of BIND, the reader should consult the documents given in
the reference.
The feature of BIND is that it has a structure of a distributed
database supporting domain names with a hierarchial structure. The
management of the addresses within the respective domains is carried
out by the manager of that domain.
Further, a name server plays a very important role at the time of
transferring electronic mail. The mail transferring rule being used
currently in JUNET is one in which the transfer destination is entered
statically for each domain. This method puts a big load on the domain
master machine of each domain. During mail transfer using a name
server, since the address of the target machine is found out by
inquiring with the name server and the mail is then transferred
directly to that machine, it is possible to reduce the load on the
domain master and also to make the aintenance operations simpler.
In addition, there is a function by which it is possible to specify
an intermediary machine for mails addressed to domains or machines
that are not connected to an IP (MX record).
The transfer of mails in Internet is already being changed over to
a method using name servers, and hence it is essential to make correct
settings in the name servers if mail has to be received directly
from Internet.
2. Servers and Resolvers
Although normally referred to simply as name server setting, it
actually involves the setting on the server side as well as the
setting on the resolver side (or the client side). The settings on
the server side consist of preparing the settings file for the name
server (named or in.named in Unix) in order to let the address of
the user's domain known to all, starting the name server, and letting
the presence of that name server known all over the required region.
This type of a name server is called the primary server of that domain.
The files to be set are /etc/named.boot and the files entered in it.
In addition, in order to meet any inquiries coming in while the primary
server is down, it is also very important to start an authorized
secondary server.
A resolver is a group of libraries for calling a name server and
converting the host name into an IP address. The settings on the
resolver side consist of making the settings necessary for using the
name server from the user's machine. The files to be set are
/etc/resolv.conf, etc. Every application (telnet, ftp, rlogin, etc.,)
that needs to get the IP address from the host name will be getting
the IP address by calling the resolver rather than by searching
/etc/hosts. However, since the actual mechanism involved in this
process differs very widely depending on the machine,
it is necessary to know what type of name servers is the user's
machine compatible with.
Further, very often a name server for caching the data set by others
(identical program as that of a primary server) is also started up
in order not to put any load on other name servers. Such a name server
is called either an (unauthorized) secondary server or a caching server
(the operations of these two are different). It is possible to
consider the method of their starting to follow the concept of the
settings on the resolver side and it is possible for a name server to
operate as a primary server for a particular domain while operating
as a secondary server for other domains.
These two settings are independent of each other and it is possible
that only one setting is made while the other setting is not made.
3. Organization of BIND Distributed Servers
The organization of distributed name servers in BIND is described
here. The intent of having hierarchial domain names is to let the
manager of a domain make the settings within that domain. In other
words, firstly a root primary server has been determined for the entire
Internet. The root primary server knows which machines are the name
servers for each of the top domains. For example, the primary server
at the root of Internet knows which machine is the name server of jp.
Similarly, the server of jp knows the servers of *.jp (such as ac.jp,
go.jp, etc.) and the server of ac.jp knows the machines of *.ac.jp
(such as u-tokyo.ac.jp, keio.ac.jp, etc.). Therefore, it is possible
for the name server on the searching side to get the address of a
host belonging to any domain by searching down the hierarchy if it
knows at least the root name server.
Therefore, after the setting of the primary server in a domain is made,
it is necessary to contact the manager of the name server of the
higher level domains and get the entries pertaining to the name server
of the lower level domains made in the settings of the higher level
domain name server.
4. Situation Within Japan
Recently, even inside Japan the region having IP links is growing
rapidly. In addition, the need of making settings of name servers
is increasing also because of the addition of IP links with Internet.
However, it has been pointed out that there is a serious problem
in making the settings of name servers in the domestic network.
This problem is as follows. When there is a machine that can not be
connected to Internet is present in a name server that can be seen
from the Internet side, and when there is any mail from Internet to
that machine, an attempt will be made to send that mail directly to
that machine. However, the mail can not be sent because that machine
is not connected to Internet. On the other hand, it will be very
inconvenient if machines that are not connected to Internet but are
connected to the domestic network cannot be searched using name servers.
In view of this, it was decided to solve this problem using the
following method while operating the IP network within Japan. At
the time of making the settings on the server side, the name servers
that can be seen from the Internet side and the name servers that can
be seen from the domestic side are started up separately, and machines
that are connected to the domestic network but can not be connected
to Internet are forbidden from being registered in the former name
server. (The mail may not reach if such machines are registered by
mistake.) Of course, if the contents registered in these two servers
are the same, (that is, when all the machines can be connected to the
Internet side,) it is possible to use a single server to carry out
the two functions. Further, it goes without saying that there need be
only a domestic name server for domains that do not have any machines
permitted connection to Internet.
In other words, this implies that there will be two series of name
servers - the name servers in Series A in which are registered only
the machines that are permitted connection to Internet and the name
servers in Series B in which all the machines that are connected to
the domestic network in Japan are registered. However, since it will
not be possible to search a part of the domestic machines from the
former name server and the foreign name servers can not be searched
from the latter name server, it will be necessary to have a third series
of name servers in Series C from which it is possible to search all
that machines that are connected to both the domestic network and the
foreign network. Since this series of name servers only inquire the
other two series of name servers, there is no need to carry out any
settings on the server side (that is, these name servers only function
as secondary servers or caching servers) and hence are not a series
in terms of the domain hierarchy.
5. Organization of Name Server Series
While the three series of name servers described in the previous section
need to be prepared, the important thing in this is to clearly determine
which machine actually becomes the server of which series. The machines
belonging to the different series will be used in the following manner.
Series A: These servers manage the machines that are visible from abroad.
Since these servers are only accessed from abroad, the
reliability will become higher and the traffic too will become
lower if these machines are placed in locations having links
to international circuits. In addition, the machines belonging
to this series do not use any name servers hierarchially above
themselves but will have to call the name servers of other
machines depending on the setting of /etc/resolv.conf.
Series B: The name servers of this series manage all the machines
connected to the domestic IP network in Japan. These name
servers can be accessed by the domestic machines that are not
permitted connection to international circuits. Since these
name servers are not related to Internet, these name servers
should be placed in locations at which they are easily accessed
by domestic network users and, if necessary, it may be better
to start up a secondary server also.
Series C: The servers in this series do not manage any machine and are
accessed by the domestic machines that are permitted connection
to the international network. Since these servers also access
the international network, they are best placed in locations
having links to the international network and also it may be
better to start up a secondary server.
With the above factors under consideration, the following organization is
being used at present. (An asterisk * at the end of the server name
indicates that it is a primary server. All others in series A and B are
authorized secondary servers.)
Series B Series C Series A
------------------------------------------------------------------------
root ccut.cc.u-tokyo(*) --- nic.ddn.mil.(*)
etc.
jp ccut.cc.u-tokyo(*) kogwy.cc.keio jp-gate.wide.ad.jp.(*)
utsun.s.u-tokyo ns.tisn.ad.jp.
*.jp ccut.cc.u-tokyo(*) kogwy.cc.u-tokyo jp-gate.wide.ad.jp.(*)
utsun.s.u-tokyo ns.tisn.ad.jp.
u-tokyo ccut.cc.u-tokyo(*) relay.cc.u-tokyo ns.tisn.ad.jp.(*)
utsun.s.u-tokyo jp-gate.wide.ad.jp.
As has been mentioned earlier, the organization of Series C has
different implications that that of the other two series. At the time
of starting name servers in each domain, one should start by adding the
entries for that domain in the above table.
Further, when setting new name servers, it is recommended to refer
to the settings made in these machines.
The same method is used for the servers for reverse indexing
(in-addr.arpa). jp-gate and ns.tisn will function as the secondary
servers for reverse indexing for all the networks connected to
international circuits, and jp-gate and ns.tisn are to be registered
as the servers for Internet. ccut will be the primary server for
in-addr.arpa which includes only the domestic network. It will be
possible to search for both the networks connected to Internet and
the networks that are visible only from the domestic side from a
machine in Series C (that is, kogwy and utsun which are at the root)
by making that machine a secondary server of the arpa domain of
Internet and also a secondary server of the domestic in-addr.arpa domain.
This utilizes the fact that the addresses of reverse indexing are
entered directly within the arpa domain in the name servers of Internet.
6. Precautions in Name Server Setting
The precautions that need to be taken at the time of setting name
servers but that have not been described in the reference documents
(1) and (2) are explained below.
6.1 On the 'ANY' entries
In reference document (1), although it has been specified to write ANY
in the information fields not limited to IP, there are cases when the
named field can not handle an ANY entry. It is preferable to enter IN
in all the fields.
6.2 On the MX record
The MX record is a setting that is very important at the time of sending
a mail. Although it is convenient to write wild card specifiers in the
MX record, care will have to be taken in doing so. This is because even
if the MX record has been written using wild card specifiers, the MX
record corresponding to the wild card will not be used if the
corresponding address entry is different. For example, if the entries
are made as follows:
$ORIGIN is.s.u-tokyo.ac.jp.
* IN MX 5 spica.is.s.u-tokyo.ac.jp.
spica IN A 133.11.14.1
acrux IN A 133.11.14.5
the mail addressed to acrux.is.s.u-tokyo.ac.jp will not be sent to
spica but will be sent directly to acrux. When this is to be modified,
it is necessary to specify the MX records individually without using
wild cards as follows:
$ORIGIN is.s.u-tokyo.ac.jp.
* IN MX 5 spica.is.s.u-tokyo.ac.jp.
spica IN A 133.11.14.1
acrux IN A 133.11.14.5
IN MX 1 spica.is.s.u-tokyo.ac.jp.
Because of this, it will be necessary to enter the full MX record for
each machine in the case of most machines when although the address is
to be registered but the mail is desired to be received through the
mail server, or when the machine is not connected to IP although it has
been registered in the name server.
6.3 On the machines that cannot receive e-mail
There is a user attempting to send a e-mail to that machine, retrials
will be made continuously until the time out condition occurs
(this may be three days or even seven days).
One method of avoiding this is that of setting another appropriate
machine that can receive e-mail in the MX record of that machine as was
described in Section 6.2 above, and taking the appropriate steps in the
machine that can receive the e-mail in the event of receiving such a
e-mail. Such appropriate steps can be either determining the name of
the user to whom the e-mail is addressed or sending back the e-mail
to the sender as an error. In the former case, it is sufficient to
set the name of the machine that cannot receive e-mail as a different
name of the machine that can receive the e-mail by setting sendmail.cf.
6.4 On the MX records for domains
When e-mails are to be received in the form of [user name@domain name],
it is necessary to specify the MX record for that domain. It is
preferable to specify this in accordance with the JUNET convention so
far. It is also advisable to use the letter "@" at the time of
specifying the MX records for domains. For example, the e-mails
addressed to user@is.s.u-tokyo.ac.jp will be delivered to spica if
the specification is made as follows:
$ORIGIN is.s.u-tokyo.ac.jp
@ IN MX 0 spica.is.s.u-tokyo.ac.jp
Apart from this, it is also possible to use the same method when
wishing to receive e-mail to an address that is not a host name.
However, the prerequisite is that such an address should be interpreted
by sendmail.cf as its own address.
6.5 On other records
Since the HINFO record is nothing but a mere comment, whether or not
to set this record can be determined at the discretion of each domain.
It is safer to set the WKS record. In that case, it is sufficient to
enter only smtp at the present stage (whereby there will be no fear of
losing incoming mail). The records MB, MR, and MINFO are still in the
experimental stage are not being used frequently at present.
6.6 On forwarders
It is preferable that the name servers of Series C become the secondary
servers of the jp domain. If they are not, the specification in the
forwarders field should be set for a Series C name server that is at
a higher level than that machine itself and make the corresponding slave
setting. Here, a name server at a higher level is one that is closer
to the root servers of Series C, that is, closer to kogwy.cc.keio.ac.jp
or utsun.s.u-tokyo.ac.jp. In addition, in case the higher level server
is down for some reason, it is preferable to specify several servers
in the forwarders field. In such settings, it is necessary to write
the nearer servers first.
If this is not done, even if the root server is searched once, the
servers jp-gate.wide.ad.jp or ns.tisn.ad.jp will be given as the primary
servers of jp and it will not be possible to get the correct domestic
address. In addition, this also has the effect of reducing the number of
searches of the name servers for foreign circuits.
6.7 On authorized and unauthorized secondary servers
Although no clear descriptions have been given in the reference
documents, secondary servers are of two types, namely. authorized
secondary servers and unauthorized secondary servers. An authorized
secondary server is one for which there is an entry of the NS record
in the settings file of the primary server and in the settings file of
the next higher level domain, and cannot be started up without the
permission of the manager of the primary server. It is preferable
to provide at least one authorized secondary server for each primary
server to take over in the event the primary server is down for some
reason. In this case, it is not necessary that the secondary server
be placed within the same domain.
The unauthorized secondary servers are the other secondary servers and
can be started up freely. It is better to conceive of such unauthorized
secondary servers as a part of the settings on the resolver side.
The biggest difference between these two types of servers is that while
an authorized secondary server is accessed when it is not possible
to access the primary server at the time of searching for host names,
etc., from the root side, the unauthorized secondary servers will never
be used unless the address is clearly set in /etc/named.boot or
/etc/resolv.conf.
6.8 Other precautions
The Serial field in the SOA record of the name server settings file
plays a very important role at the time of taking out the data of
the secondary servers. It is necessary to make sure that the value is
always increased every time the set data is updated.
In addition, when the settings file of a name server is updated,
it is necessary either to start up the name server again or send the
HUP signal. The host names within the settings file of a name server
will be the relative names with respect to the origin of the file
unless there is a period "." at the end of the host name. Hence,
it is important not to forget entering the final period "." at the
end of an MX record or a PTR record, etc. The origin of a file is
obtained from /etc/named.boot unless otherwise altered using a
$ORIGIN specification.
It appears that the NS or MX entries should have been completed within
each settings file. Although this rule is a "suggested practice" in
the case of the name servers of Series A (that is, in the case of the
name servers of domains that can be searched from the root of Internet)
it will apparently (not quite certain) be a "compulsory" rule to be
followed in the case of name servers of Series B with no servers of
Series A. Particularly, care will have to be taken in the case of
files for reverse indexing in which there is a tendency to forget
this rule.
In the case of the secondary name servers of a large number of domains,
the name server process uses much more memory than is normally thought
and hence care will have to be taken in this regard. For example,
the name server of utsun is using about 3MB of memory.
6.9 Additional hint
After a name server has been set, very often it is helpful in detecting
errors in setting to dump and check the data using the nslookup command
and to check the dump in the named condition. It is very helpful to check
the cache file of secondary servers because it is easy to check this file.
7. The Problem of Name Servers being Liars
8. Example of Name Server Placement
8.1 The u-tokyo.ac.jp domain
In the u-tokyo.ac.jp (University of Tokyo) domain, there are both
machines that can be connected and machines that cannot be connected to
from Internet. Therefore, it is necessary to separately start up the
name servers of both Series A and Series B. Also, in order to reduce
the traffic and make the searching operations more efficient, it is
preferable to start up a name server of Series C.
In actuality, as is shown in the table in Section 5 above, we decided
to use ns.tisn as the primary server of Series A and ccut as the
primary server of Series B. In addition, relay is set as the name
server of Series C. As per the guidelines given in Section 6.6, relay
specifies kogwy and utsun using the forwarders declaration.
Among the client machines in the University of Tokyo, the machines
that can be connected to Internet use relay as their name server.
However, when a large number of client machines are present within a
single organization (such as a division or a department), it is
preferable to have a local name server in order to reduce the load
on relay. Such a local name server will become an unauthorized name
server of the required domain (that is accessed very frequently) and
specifies relay in the forwarders field. (Even if it does not become
a full secondary server, it has the effect of improving performance
because this name server carries out caching.) Although it is possible
to specify kogwy or utsun as the forwarders, it is preferable to
specify relay first in order to reduce the traffic.
On the other hand, the client machines that can not be connected to
Internet use ccut as their name server. Again, when a large number
of client machines are present within a single organization, it is
preferable to have a local name server. This local name server will
become an unauthorized name server of the required domain (that is
accessed very frequently) and specifies ccut in the forwarders field.
The forwarders specification is optional.
8.2 The s.u-tokyo.ac.jp domain
All the client machines within the s.u-tokyo.ac.jp domain (Faculty
of Science, University of Tokyo) can be connected to Internet.
Therefore, there is no need to separately start up both a name server
of Series A and a name server of Series B. In order to reduce the
traffic and make the searching operations more efficient, it is
necessary to start up a name server of Series C.
In actuality, we decided to use ns.tisn as the primary server of
Series A and Series B. In addition, utsun is used as the name server
of Series C because it is in the local domain.
The client machines within the Faculty of Science use utsun as their
name server. However, when a large number of client machines are
present within a single organization (such as a department), it is
preferable to have a local name server. This local name server will
become an unauthorized name server of the required domain (that is
accessed very frequently) and specifies utsun in the forwarders field.
Actually, several secondary servers have been started up so that the
number of machines that directly access utsun as their name server has
been reduced.
9. Correspondence to the Resolver in each Machine and OS
In the following, whether or not named is new indicates whether or not
the function such as directory, forwarders, and slave that are being
supported by the versions 4.8 and later of BIND are present. Further,
the latest version of BIND is 4.8.3 which is a considerably improved
version of 4.8 and hence it is preferable to use this version.
4.3 BSD
1. A new version of named has been released.
2. All the clients conform to BIND. However, it is necessary
to make such a setting at the time of preparing the libraries.
Sun OS 4.0
1. The new version of named is the standard. It is possible
to compile with some minor modifications for BIND 4.8.3.
2. ypserv conforms to BIND. However, there are some bugs in
the ypserv of Sun OS 4.0.1, but a patching tape is available.
These bugs have been removed in version 4.0.3. Further,
it is also possible to obtain conformation by replacing the
related libraries among the shared libraries.
In Sun OS 4.0, the descriptions in the manual regarding the method
of making the settings so that ypserv looks at the name server are
hard to understand. In Sun OS 4.0, it is necessary to mark the
related DBM files for YP so as to refer to the name server. In
specific terms, by correcting the /var/yp/Makefile
$(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byname;
to the line-
$(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byname;
and entering touch /etc/hosts; make, the name server will be referred
to at the time of getting the address from the host name. In addition,
although by adding -b in the line-
$(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byaddr;
the name server will be referred to even at the time of reverse
indexing, this setting is no recommended because of problems of security.
VAX (Ultrix 3.0)
1. The new version of named is the standard.
2. The clients conform to BIND. It is possible to set in /etc/svcorder
so that the searching is made in the sequence yp, bind, local.
LUNA (UNIOS-B 1.20Beta)
1. The old version of named is the standard.
2. All the clients conform to BIND. YP will be searched first
and named will only be searched next if the entry is not found.
Apollo SR10
1. The old version of named is the standard. It is possible
to compile after making some corrections for BIND 4.8.2.
2. All the clients appear to conform to BIND. (Apparently,
whether or not named is called is determined depending on
not whether resolv.conf is present but on whether named is
present locally. However, the details are not known.)
We have not made any investigations regarding the other machines
and operating systems.
10. Distribution
This document can be copied, distributed, and modified freely.
However, when any modifications are made to this document, such
modifications should be clearly described in the subsequent document.
Further, it is forbidden to delete the name of the author or to alter
or delete the contents of the different sections.
In addition, the author does not undertake any responsibility
whatsoever for any damages caused by any discrepancies in this document.
The author would be grateful for communication regarding any errors or
discrepancies in this document detected by any person or persons.
Also, any comments on the contents of this document will be highly
appreciated.
11. Acknowledgments
The author wishes to express his deep gratitude to Mr. Jun Murai,
Mr. Jun Ogami, and many others for their valuable comments on the
contents of this document.
REFERENCES
[1] Dunlap, K.J. and Karels, M. J., Name Server Operation Guide for
BIND (Release 4.8).
[2] manual page for NAMED(8), RESOLVER(3)(5), GETHOSTBYNAME(3).
[3] RFC974, MAIL ROUTING AND THE DOMAIN SYSTEM.
[4] RFC1032, DOMAIN ADMINISTRATORS GUIDE.
[5] RFC1033, DOMAIN ADMINISTRATORS OPERATIONS GUIDE.
[6] RFC1034, DOMAIN NAMES - CONCEPTS AND FACILITIES.
[7] RFC1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION.
