Name Server Operations Guide
_
\bR_
\be_
\bl_
\be_
\ba_
\bs_
\be _
\b4._
\b8
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Sciences
The Berkeley Internet Name Domain (BIND) Server
implements the DARPA Internet name server for the UNIX|
\b-
operating system. A name server is a network service
that enables clients to name resources or objects and
share this information with other objects in the network.
This in effect is a distributed data base system for
objects in a computer network. BIND is fully intergrated
into 4.3BSD network programs for use in storing and
retrieving host names and address. The system adminis-
trator can configure the system to use BIND as a replace-
ment to the original host table lookup of information in
the network hosts file /_
\be_
\bt_
\bc/_
\bh_
\bo_
\bs_
\bt_
\bs. The default confi-
guration for 4.3BSD uses BIND.
2. Building A System with a Name Server
BIND is comprised of two parts. One is the user
interface called the _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br which consists of a group
of routines that reside in the C library /_
\bl_
\bi_
\bb/_
\bl_
\bi_
\bb_
\bc._
\ba.
Second is the actual server called _
\bn_
\ba_
\bm_
\be_
\bd. This is a dae-
mon that runs in the background and services queries on a
* The author was an employee of Digital Equipment
Corporation's Ultrix Engineering Advanced Development Group
and was on loan to CSRG when this work was done. Ultrix is
a trademark of Digital Equipment Corporation.
|
\b-UNIX is a Trademark of AT&T Bell Laboratories
SMM:11-2 Name Server Operations Guide for BIND
given network port. The standard port for UDP and TCP is
specified in /_
\be_
\bt_
\bc/_
\bs_
\be_
\br_
\bv_
\bi_
\bc_
\be_
\bs.
2.1. Resolver Routines in libc
When building your 4.3BSD system you may either
build the C library to use the name server resolver
routines or use the host table lookup routines to do
host name and address resolution. The default
resolver for 4.3BSD uses the name server.
Building the C library to use the name server
changes the way _
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\bb_
\by_
\bn_
\ba_
\bm_
\be(3N), _
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\bb_
\by_
\ba_
\bd_
\bd_
\br(3N),
and _
\bs_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\be_
\bn_
\bt(3N) do their functions. The name
server renders _
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\be_
\bn_
\bt(3N) obsolete, since it has
no concept of a next line in the database. These
library calls are built with the resolver routines
needed to query the name server.
The _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br is comprised of a few routines that
build query packets and exchange them with the name
Before building the C library, set the variable
_
\bH_
\bO_
\bS_
\bT_
\bL_
\bO_
\bO_
\bK_
\bU_
\bP equal to _
\bn_
\ba_
\bm_
\be_
\bd in
/_
\bu_
\bs_
\br/_
\bs_
\br_
\bc/_
\bl_
\bi_
\bb/_
\bl_
\bi_
\bb_
\bc/_
\bM_
\ba_
\bk_
\be_
\bf_
\bi_
\bl_
\be. You then make and install
the C library and compiler and then compile the rest
of the 4.3BSD system. For more information see sec-
tion 6.6 of ``Installing and Operating 4.3BSD on the
The basic function of the name server is to pro-
vide information about network objects by answering
queries. The specifications for this name server are
defined in RFC882, RFC883, RFC973 and RFC974. These
documents can be found in /_
\bu_
\bs_
\br/_
\bs_
\br_
\bc/_
\be_
\bt_
\bc/_
\bn_
\ba_
\bm_
\be_
\bd/_
\bd_
\bo_
\bc in
4.3BSD or _
\bf_
\bt_
\bped from sri-nic.arpa. It is also recom-
meded that you read the related manual pages,
_
\bn_
\ba_
\bm_
\be_
\bd(8), _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br(3), and _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br(5).
The advantage of using a name server over the
host table lookup for host name resolution is to avoid
the need for a single centralized clearinghouse for
all names. The authority for this information can be
delegated to the different organizations on the net-
|
\b=VAX is a Trademark of Digital Equipment Corporation
Name Server Operations Guide for BIND SMM:11-3
The host table lookup routines require that the
master file for the entire network be maintained at a
central location by a few people. This works fine for
small networks where there are only a few machines and
the different organizations responsible for them
cooperate. But this does not work well for large net-
works where machines cross organizational boundaries.
With the name server, the network can be broken
into a hierarchy of domains. The name space is organ-
ized as a tree according to organizational or adminis-
trative boundaries. Each node, called a _
\bd_
\bo_
\bm_
\ba_
\bi_
\bn, is
given a label, and the name of the domain is the con-
catenation of all the labels of the domains from the
root to the current domain, listed from right to left
separated by dots. A label need only be unique within
its domain. The whole space is partitioned into
several areas called _
\bz_
\bo_
\bn_
\be_
\bs, each starting at a domain
and extending down to the leaf domains or to domains
where other zones start. Zones usually represent
administrative boundaries. An example of a host
address for a host at the University of California,
Berkeley would look as follows:
_
\bm_
\bo_
\bn_
\be_
\bt._
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by._
\bE_
\bD_
\bU
The top level domain for educational organizations is
EDU; Berkeley is a subdomain of EDU and monet is the
There are several types of servers: Master, Caching,
A Master Server for a domain is the authority for
that domain. This server maintains all the data
corresponding to its domain. Each domain should have
at least two master servers, a primary master and some
secondary masters to provide backup service if the
primary is unavailable or overloaded. A server may be
a master for multiple domains, being primary for some
domains and secondary for others.
A Primary Master Server is a server that loads
its data from a file on disk. This server may also
delegate authority to other servers in its domain.
SMM:11-4 Name Server Operations Guide for BIND
A Secondary Master Server is a server that is
delegated authority and receives its data for a
domain from a primary master server. At boot time,
the secondary server requests all the data for the
given zone from the primary master server. This
server then periodically checks with the primary
server to see if it needs to update its data.
All servers are caching servers. This means that
the server caches the information that it receives for
use until the data expires. A _
\bC_
\ba_
\bc_
\bh_
\bi_
\bn_
\bg _
\bO_
\bn_
\bl_
\by _
\bS_
\be_
\br_
\bv_
\be_
\br is a
server that is not authoritative for any domain. This
server services queries and asks other servers, who
have the authority, for the information needed. All
servers keep data in their cache until the data
expires, based on a time to live field attached to the
data when it is received from another server.
A Remote Server is an option given to people who
would like to use a name server on their workstation
or on a machine that has a limited amount of memory
and CPU cycles. With this option you can run all of
the networking programs that use the name server
without the name server running on the local machine.
All of the queries are serviced by a name server that
is running on another machine on the network.
A Slave Server is a server that always forwards
queries it cannot satisfy locally to a fixed list of
_
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\bi_
\bn_
\bg servers instead of interacting with the
master nameservers for the root and other domains.
The queries to the _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\bi_
\bn_
\bg _
\bs_
\be_
\br_
\bv_
\be_
\br_
\bs are recursive
queries. There may be one or more forwarding servers,
and they are tried in turn until the list is
exhausted. A Slave and forwarder configuration is
typically used when you do not wish all the servers at
a give site to be interacting with the rest of the
Internet servers. A typically senario would involve a
number of workstations and a departmental timesharing
machine with Internet access. The workstations might
be administratively prohibited from having Internet
access. To give the workstations the appearance of
access to the Internet domain system, the workstations
could be Slave servers to the timesharing machine
which would forward the queries and interact with
Name Server Operations Guide for BIND SMM:11-5
other nameservers to resolv the query before returning
the answer. An added benefit of using the forwarding
feature is that the central machine develops a much
more complete cache of information that all the works-
tations can take advantage of. The use Slave mode and
forwarding is discussed further under the description
of the named bootfile commands.
4. Setting up Your Own Domain
When setting up a domain that is going to be on a
public network the site administrator should contact the
organization in charge of the network and request the
appropriate domain registration form. An organization
that belongs to multiple networks (such as _
\bC_
\bS_
\bN_
\bE_
\bT, _
\bD_
\bA_
\bR_
\bP_
\bA
_
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt and _
\bB_
\bI_
\bT_
\bN_
\bE_
\bT) should register with only one net-
The contacts are as follows:
Sites that are already on the DARPA Internet and
need information on setting up a domain should contact
HOSTMASTER@SRI-NIC._
\bA_
\bR_
\bP_
\bA. You may also want to be
placed on the BIND mailing list, which is a mail group
for people on the DARPA Internet running BIND. The
group discusses future design decisions, operational
problems, and other related topic. The address to
request being placed on this mailing list is:
_
\bb_
\bi_
\bn_
\bd-_
\br_
\be_
\bq_
\bu_
\be_
\bs_
\bt@_
\bu_
\bc_
\bb_
\ba_
\br_
\bp_
\ba._
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by._
\bE_
\bD_
\bU.
A _
\bC_
\bS_
\bN_
\bE_
\bT member organization that has not
registered its domain name should contact the _
\bC_
\bS_
\bN_
\bE_
\bT
Coordination and Information Center (_
\bC_
\bI_
\bC) for an
application and information about setting up a domain.
An organization that already has a registered
domain name should keep the _
\bC_
\bI_
\bC informed about how it
would like its mail routed. In general, the _
\bC_
\bS_
\bN_
\bE_
\bT
relay will prefer to send mail via _
\bC_
\bS_
\bN_
\bE_
\bT (as opposed
to _
\bB_
\bI_
\bT_
\bN_
\bE_
\bT or the _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt) if possible. For an organi-
zation on multiple networks, this may not always be
the preferred behavior. The _
\bC_
\bI_
\bC can be reached via
electronic mail at _
\bc_
\bi_
\bc@_
\bs_
\bh._
\bc_
\bs._
\bn_
\be_
\bt, or by phone at (617)
SMM:11-6 Name Server Operations Guide for BIND
If you are on the BITNET and need to set up a
domain, contact INFO@BITNIC.
The name server uses several files to load its data
base. This section covers the files and their formats
needed for _
\bn_
\ba_
\bm_
\be_
\bd.
This is the file that is first read when _
\bn_
\ba_
\bm_
\be_
\bd
starts up. This tells the server what type of server
it is, which zones it has authority over and where to
get its initial data. The default location for this
file is /_
\be_
\bt_
\bc/_
\bn_
\ba_
\bm_
\be_
\bd._
\bb_
\bo_
\bo_
\bt. However this can be changed
by setting the _
\bB_
\bO_
\bO_
\bT_
\bF_
\bI_
\bL_
\bE variable when you compile
_
\bn_
\ba_
\bm_
\be_
\bd or by specifying the location on the command
line when _
\bn_
\ba_
\bm_
\be_
\bd is started up.
A default domain may be specified for the
nameserver using a line such as
_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn _
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by._
\bE_
\bd_
\bu
The name server uses this information when it
receives a query for a name without a ``.'' that is
not known. When it receives one of these queries,
it appends the name in the second field to the
query name. This is an obsolete facility which
will be removed from future releases.
The directory line specifies the directory in
which the nameserver should run, allowing the other
file names in the boot file to use relative path
_
\bd_
\bi_
\br_
\be_
\bc_
\bt_
\bo_
\br_
\by /_
\bu_
\bs_
\br/_
\bl_
\bo_
\bc_
\ba_
\bl/_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn
If you have more than a couple of named files to be
maintained, you may wish to place the named files
in a directory such as /usr/local/domain and adjust
the directory command properly. The main purposes
of this command are to make sure named is in the
proper directory when trying to include files by
relative path names with $Include and to allow
Name Server Operations Guide for BIND SMM:11-7
named to run in a location that is reasonable to
dump core if it feels the urge.
The line in the boot file that designates the
server as a primary server for a zone looks as fol-
_
\bp_
\br_
\bi_
\bm_
\ba_
\br_
\by _
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by._
\bE_
\bd_
\bu _
\bu_
\bc_
\bb_
\bh_
\bo_
\bs_
\bt_
\bs
The first field specifies that the server is a pri-
mary one for the zone stated in the second field.
The third field is the name of the file from which
The line for a secondary server is similar to
the primary except that it lists addresses of other
servers (usually primary servers) from which the
zone data will be obtained.
_
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by _
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by._
\bE_
\bd_
\bu _
\b1_
\b2_
\b8._
\b3_
\b2._
\b0._
\b1_
\b0_
\b1_
\b2_
\b8._
\b3_
\b2._
\b0._
\b4 _
\bu_
\bc_
\bb_
\bh_
\bo_
\bs_
\bt_
\bs._
\bb_
\ba_
\bk
The first field specifies that the server is a
secondary master server for the zone stated in the
second field. The two network addresses specify
the name servers that are primary for the zone.
The secondary server gets its data across the net-
work from the listed servers. Each server is tried
in the order listed until it successfully receives
the data from a listed server. If a filename is
present after the list of primary servers, data for
the zone will be dumped into that file as a backup.
When the server is first started, the data are
loaded from the backup file if possible, and a pri-
mary server is then consulted to check that the
zone is still up-to-date.
5.1.5. Caching Only Server
You do not need a special line to designate
that a server is a caching server. What denotes a
caching only server is the absence of authority
lines, such as _
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by or _
\bp_
\br_
\bi_
\bm_
\ba_
\br_
\by in the boot
All servers should have a line as follows in
the boot file to prime the name servers cache:
_
\bc_
\ba_
\bc_
\bh_
\be . _
\br_
\bo_
\bo_
\bt._
\bc_
\ba_
\bc_
\bh_
\be
SMM:11-8 Name Server Operations Guide for BIND
All cache files listed will be read in at named
boot time and any values still valid will be rein-
stated in the cache and the root nameserver infor-
mation in the cache files will always be used. For
information on cache file see section on _
\bC_
\ba_
\bc_
\bh_
\be _
\bI_
\bn_
\bi_
\b-
_
\bt_
\bi_
\ba_
\bl_
\bi_
\bz_
\ba_
\bt_
\bi_
\bo_
\bn.
5.1.6. Forwarders Any server can make use of _
\bf_
\bo_
\br_
\b-
_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs. A _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br is another server capable of
processing recursive queries that is willing to try
resolving queries on behalf of other systems. The
_
\bf_
\bo_
\br_
\bw_
\ba_
\bd_
\be_
\br_
\bs command specifies forwarders by internet
_
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs _
\b1_
\b2_
\b8._
\b3_
\b2._
\b0._
\b1_
\b0_
\b1_
\b2_
\b8._
\b3_
\b2._
\b0._
\b4
There are two main reasons for wanting to do so.
First, the other systems may not have full network
access and may be prevent from sending any IP pack-
ets into the rest of the network and therefore must
rely on a forwarder which does have access to the
full net. The second reason is that the forwarder
sees a union of all queries as they pass through
his server and therefore he builds up a very rich
cache of data compared to the cache in a typical
workstation nameserver. In effect, the _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br
becomes a meta-cache that all hosts can benefit
from, thereby reducing the total number of queries
from that site to the rest of the net.
Slave mode is used if the use of forwarders is
the only possible way to resolve queries due to
lack of full net access or if you wish to prevent
the nameserver from using other than the listed
forwarders. Slave mode is activated by placing the
in the bootfile. If _
\bs_
\bl_
\ba_
\bv_
\be is used, then you must
specify forwarders. When in slave mode, the server
will forward each query to each of the the forward-
ers until an answer is found or the list of for-
To set up a host that will use a remote server
instead of a local server to answer queries, the
file /_
\be_
\bt_
\bc/_
\br_
\be_
\bs_
\bo_
\bl_
\bv._
\bc_
\bo_
\bn_
\bf needs to be created. This
file designates the name servers on the network
Name Server Operations Guide for BIND SMM:11-9
that should be sent queries. It is not advisable
to create this file if you have a local server run-
ning. If this file exists it is read almost every
time _
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\bb_
\by_
\bn_
\ba_
\bm_
\be() or _
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\bb_
\by_
\ba_
\bd_
\bd_
\br() is called.
5.2. Cache Initialization
The name server needs to know the servers that
are the authoritative name servers for the root
domain of the network. To do this we have to prime
the name server's cache with the addresses of these
higher authorities. The location of this file is
specified in the boot file. This file uses the
Standard Resource Record Format (aka. Masterfile
Format) covered further on in this paper.
There are three standard files for specifying the
data for a domain. These are _
\bn_
\ba_
\bm_
\be_
\bd._
\bl_
\bo_
\bc_
\ba_
\bl, _
\bh_
\bo_
\bs_
\bt_
\bs and
_
\bh_
\bo_
\bs_
\bt._
\br_
\be_
\bv. These files use the Standard Resource
Record Format covered later in this paper.
This file specifies the address for the local
loopback interface, better known as _
\bl_
\bo_
\bc_
\ba_
\bl_
\bh_
\bo_
\bs_
\bt with
the network address 127.0.0.1. The location of
this file is specified in the boot file.
This file contains all the data about the
machines in this zone. The location of this file
is specified in the boot file.
This file specifies the IN-ADDR.ARPA domain.
This is a special domain for allowing address to
name mapping. As internet host addresses do not
fall within domain boundaries, this special domain
was formed to allow inverse mapping. The IN-
ADDR.ARPA domain has four labels preceding it.
These labels correspond to the 4 octets of an
Internet address. All four octets must be specified
even if an octets is zero. The Internet address
128.32.0.4 is located in the domain 4.0.32.128.IN-
ADDR.ARPA. This reversal of the address is awkward
to read but allows for the natural grouping of
SMM:11-10 Name Server Operations Guide for BIND
5.4. Standard Resource Record Format
The records in the name server data files are
called resource records. The Standard Resource Record
Format (RR) is specified in RFC882 and RFC973. The
following is a general description of these records:
{_
\bn_
\ba_
\bm_
\be} {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bR_
\be_
\bc_
\bo_
\br_
\bd _
\bT_
\by_
\bp_
\be _
\bR_
\be_
\bc_
\bo_
\br_
\bd _
\bS_
\bp_
\be_
\bc_
\bi_
\bf_
\bi_
\bc _
\bd_
\ba_
\bt_
\ba
Resource records have a standard format shown above.
The first field is always the name of the domain
record and it must always start in column 1. For some
RR's the name may be left blank; in that case it takes
on the name of the previous RR. The second field is
an optional time to live field. This specifies how
long this data will be stored in the data base. By
leaving this field blank the default time to live is
specified in the _
\bS_
\bt_
\ba_
\br_
\bt _
\bO_
\bf _
\bA_
\bu_
\bt_
\bh_
\bo_
\br_
\bi_
\bt_
\by resource record
(see below). The third field is the address class;
there are currently two classes: _
\bI_
\bN for internet
addresses and _
\bA_
\bN_
\bY for all address classes. The fourth
field states the type of the resource record. The
fields after that are dependent on the type of the RR.
Case is preserved in names and data fields when loaded
into the name server. All comparisons and lookups in
the name server data base are case insensitive.
The following characters have special meanings:
. A free standing dot in the name field refers to
@ A free standing @ in the name field denotes the
.. Two free standing dots represent the null domain
name of the root when used in the name field.
\X Where X is any character other than a digit (0-
9), quotes that character so that its special
meaning does not apply. For example, ``\.'' can
be used to place a dot character in a label.
\DDD Where each D is a digit, is the octet correspond-
ing to the decimal number described by DDD. The
resulting octet is assumed to be text and is not
checked for special meaning.
( ) Parentheses are used to group data that crosses a
line. In effect, line terminations are not recog-
nized within parentheses.
Name Server Operations Guide for BIND SMM:11-11
; Semicolon starts a comment; the remainder of the
* An asterisk signifies wildcarding.
Most resource records will have the current ori-
gin appended to names if they are not terminated by a
``.''. This is useful for appending the current domain
name to the data, such as machine names, but may cause
problems where you do not want this to happen. A good
rule of thumb is that, if the name is not in of the
domain for which you are creating the data file, end
An include line begins with $INCLUDE, starting
in column 1, and is followed by a file name. This
feature is particularly useful for separating dif-
ferent types of data into multiple files. An exam-
$INCLUDE /usr/named/data/mailboxs
The line would be interpreted as a request to load
the file /_
\bu_
\bs_
\br/_
\bn_
\ba_
\bm_
\be_
\bd/_
\bd_
\ba_
\bt_
\ba/_
\bm_
\ba_
\bi_
\bl_
\bb_
\bo_
\bx_
\be_
\bs. The $INCLUDE
command does not cause data to be loaded into a
different zone or tree. This is simply a way to
allow data for a given zone to be organized in
separate files. For example, mailbox data might be
kept separately from host data using this mechan-
The origin is a way of changing the origin in
a data file. The line starts in column 1, and is
followed by a domain origin. This is useful for
putting more then one domain in a data file.
5.4.3. SOA - Start Of Authority
_
\bn_
\ba_
\bm_
\be {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bS_
\bO_
\bA _
\bO_
\br_
\bi_
\bg_
\bi_
\bn _
\bP_
\be_
\br_
\bs_
\bo_
\bn _
\bi_
\bn _
\bc_
\bh_
\ba_
\br_
\bg_
\be
@ IN SOA ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. (
SMM:11-12 Name Server Operations Guide for BIND
The _
\bS_
\bt_
\ba_
\br_
\bt _
\bo_
\bf _
\bA_
\bu_
\bt_
\bh_
\bo_
\br_
\bi_
\bt_
\by, _
\bS_
\bO_
\bA, record designates the
start of a zone. The name is the name of the zone.
Origin is the name of the host on which this data
file resides. Person in charge is the mailing
address for the person responsible for the name
server. The serial number is the version number of
this data file, this number should be incremented
whenever a change is made to the data. The name
server cannot handle numbers over 9999 after the
decimal point. The refresh indicates how often, in
seconds, a secondary name servers is to check with
the primary name server to see if an update is
needed. The retry indicates how long, in seconds,
a secondary server is to retry after a failure to
check for a refresh. Expire is the upper limit, in
seconds, that a secondary name server is to use the
data before it expires for lack of getting a
refresh. Minimum is the default number of seconds
to be used for the time to live field on resource
records. There should only be one _
\bS_
\bO_
\bA record per
{_
\bn_
\ba_
\bm_
\be} {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bN_
\bS _
\bN_
\ba_
\bm_
\be _
\bs_
\be_
\br_
\bv_
\be_
\br_
\bs _
\bn_
\ba_
\bm_
\be
IN NS ucbarpa.Berkeley.Edu.
The _
\bN_
\ba_
\bm_
\be _
\bS_
\be_
\br_
\bv_
\be_
\br record, _
\bN_
\bS, lists a name server
responsible for a given domain. The first name
field lists the domain that is serviced by the
listed name server. There should be one _
\bN_
\bS record
for each Primary Master server for the domain.
{_
\bn_
\ba_
\bm_
\be} {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bA _
\ba_
\bd_
\bd_
\br_
\be_
\bs_
\bs
The _
\bA_
\bd_
\bd_
\br_
\be_
\bs_
\bs record, _
\bA, lists the address for a
given machine. The name field is the machine name
and the address is the network address. There
should be one _
\bA record for each address of the
5.4.6. HINFO - Host Information
{_
\bn_
\ba_
\bm_
\be} {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bH_
\bI_
\bN_
\bF_
\bO _
\bH_
\ba_
\br_
\bd_
\bw_
\ba_
\br_
\be _
\bO_
\bS
ANY HINFO VAX-11/780 UNIX
_
\bH_
\bo_
\bs_
\bt _
\bI_
\bn_
\bf_
\bo_
\br_
\bm_
\ba_
\bt_
\bi_
\bo_
\bn resource record, _
\bH_
\bI_
\bN_
\bF_
\bO, is for
host specific data. This lists the hardware and
Name Server Operations Guide for BIND SMM:11-13
operating system that are running at the listed
host. It should be noted that only a single space
separates the hardware info and the operating sys-
tem info. If you want to include a space in the
machine name you must quote the name. Host infor-
mation is not specific to any address class, so _
\bA_
\bN_
\bY
may be used for the address class. There should be
one _
\bH_
\bI_
\bN_
\bF_
\bO record for each host.
5.4.7. WKS - Well Known Services
{_
\bn_
\ba_
\bm_
\be} {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bW_
\bK_
\bS _
\ba_
\bd_
\bd_
\br_
\be_
\bs_
\bs _
\bp_
\br_
\bo_
\bt_
\bo_
\bc_
\bo_
\bl _
\bl_
\bi_
\bs_
\bt _
\bo_
\bf _
\bs_
\be_
\br_
\bv_
\bi_
\bc_
\be_
\bs
IN WKS 128.32.0.10 UDP who route timed domain
IN WKS 128.32.0.10 TCP ( echo telnet
The _
\bW_
\be_
\bl_
\bl _
\bK_
\bn_
\bo_
\bw_
\bn _
\bS_
\be_
\br_
\bv_
\bi_
\bc_
\be_
\bs record, _
\bW_
\bK_
\bS, describes the
well known services supported by a particular pro-
tocol at a specified address. The list of services
and port numbers come from the list of services
specified in /_
\be_
\bt_
\bc/_
\bs_
\be_
\br_
\bv_
\bi_
\bc_
\be_
\bs. There should be only
one _
\bW_
\bK_
\bS record per protocol per address.
5.4.8. CNAME - Canonical Name
_
\ba_
\bl_
\bi_
\ba_
\bs_
\be_
\bs {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bC_
\bN_
\bA_
\bM_
\bE _
\bC_
\ba_
\bn_
\bo_
\bn_
\bi_
\bc_
\ba_
\bl _
\bn_
\ba_
\bm_
\be
_
\bC_
\ba_
\bn_
\bo_
\bn_
\bi_
\bc_
\ba_
\bl _
\bN_
\ba_
\bm_
\be resource record, _
\bC_
\bN_
\bA_
\bM_
\bE, specifies an
alias for a canonical name. An alias should be the
only record associated with the alias name; all
other resource records should be associated with
the canonical name and not with the alias. Any
resource records that include a domain name as
their value (e.g. NS or MX) should list the canoni-
5.4.9. PTR - Domain Name Pointer
_
\bn_
\ba_
\bm_
\be {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bP_
\bT_
\bR _
\br_
\be_
\ba_
\bl _
\bn_
\ba_
\bm_
\be
7.0 IN PTR monet.Berkeley.Edu.
SMM:11-14 Name Server Operations Guide for BIND
A _
\bD_
\bo_
\bm_
\ba_
\bi_
\bn _
\bN_
\ba_
\bm_
\be _
\bP_
\bo_
\bi_
\bn_
\bt_
\be_
\br record, _
\bP_
\bT_
\bR, allows special
names to point to some other location in the
domain. The above example of a _
\bP_
\bT_
\bR record is used
in setting up reverse pointers for the special _
\bI_
\bN-
_
\bA_
\bD_
\bD_
\bR._
\bA_
\bR_
\bP_
\bA domain. This line is from the example
_
\bh_
\bo_
\bs_
\bt_
\bs._
\br_
\be_
\bv file. _
\bP_
\bT_
\bR names should be unique to the
_
\bn_
\ba_
\bm_
\be {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bM_
\bB _
\bM_
\ba_
\bc_
\bh_
\bi_
\bn_
\be
miriam IN MB vineyd.DEC.COM.
_
\bM_
\bB is the _
\bM_
\ba_
\bi_
\bl_
\bb_
\bo_
\bx record. This lists the machine
where a user wants to receive mail. The name field
is the users login; the machine field denotes the
machine to which mail is to be delivered. Mail Box
names should be unique to the zone.
5.4.11. MR - Mail Rename Name
_
\bn_
\ba_
\bm_
\be {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bM_
\bR _
\bc_
\bo_
\br_
\br_
\be_
\bs_
\bp_
\bo_
\bn_
\bd_
\bi_
\bn_
\bg _
\bM_
\bB
Postmistress IN MR miriam
_
\bM_
\ba_
\bi_
\bn _
\bR_
\be_
\bn_
\ba_
\bm_
\be, _
\bM_
\bR, can be used to list aliases for a
user. The name field lists the alias for the name
listed in the fourth field, which should have a
corresponding _
\bM_
\bB record.
5.4.12. MINFO - Mailbox Information
_
\bn_
\ba_
\bm_
\be {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bM_
\bI_
\bN_
\bF_
\bO _
\br_
\be_
\bq_
\bu_
\be_
\bs_
\bt_
\bs _
\bm_
\ba_
\bi_
\bn_
\bt_
\ba_
\bi_
\bn_
\be_
\br
BIND IN MINFO BIND-REQUEST kjd.Berkeley.Edu.
_
\bM_
\ba_
\bi_
\bl _
\bI_
\bn_
\bf_
\bo_
\br_
\bm_
\ba_
\bt_
\bi_
\bo_
\bn record, _
\bM_
\bI_
\bN_
\bF_
\bO, creates a mail
group for a mailing list. This resource record is
usually associated with a mail group _
\bM_
\ba_
\bi_
\bl _
\bG_
\br_
\bo_
\bu_
\bp,
but may be used with a _
\bM_
\ba_
\bi_
\bl _
\bB_
\bo_
\bx record. The _
\bn_
\ba_
\bm_
\be
specifies the name of the mailbox. The _
\br_
\be_
\bq_
\bu_
\be_
\bs_
\bt_
\bs
field is where mail such as requests to be added to
a mail group should be sent. The _
\bm_
\ba_
\bi_
\bn_
\bt_
\ba_
\bi_
\bn_
\be_
\br is a
mailbox that should receive error messages. This
is particularly appropriate for mailing lists when
errors in members names should be reported to a
person other than the sender.
5.4.13. MG - Mail Group Member
{_
\bm_
\ba_
\bi_
\bl _
\bg_
\br_
\bo_
\bu_
\bp _
\bn_
\ba_
\bm_
\be} {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bM_
\bG _
\bm_
\be_
\bm_
\bb_
\be_
\br _
\bn_
\ba_
\bm_
\be
_
\bM_
\ba_
\bi_
\bl _
\bG_
\br_
\bo_
\bu_
\bp, _
\bM_
\bG lists members of a mail group.
Name Server Operations Guide for BIND SMM:11-15
An example for setting up a mailing list is as fol-
Bind IN MINFO Bind-Request kjd.Berkeley.Edu.
IN MG Ralph.Berkeley.Edu.
IN MG Painter.Berkeley.Edu.
IN MG Riggle.Berkeley.Edu.
IN MG Terry.pa.Xerox.Com.
5.4.14. MX - Mail Exchanger
_
\bn_
\ba_
\bm_
\be {_
\bt_
\bt_
\bl} _
\ba_
\bd_
\bd_
\br-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bM_
\bX _
\bp_
\br_
\be_
\bf_
\be_
\br_
\be_
\bn_
\bc_
\be _
\bv_
\ba_
\bl_
\bu_
\be _
\bm_
\ba_
\bi_
\bl_
\be_
\br _
\be_
\bx_
\bc_
\bh_
\ba_
\bn_
\bg_
\be_
\br
Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV.
*.IL. IN MX 0 RELAY.CS.NET.
_
\bM_
\ba_
\bi_
\bn _
\bE_
\bx_
\bc_
\bh_
\ba_
\bn_
\bg_
\be_
\br records, _
\bM_
\bX, are used to specify a
machine that knows how to deliver mail to a machine
that is not directly connected to the network. In
the first example, above, Seismo.CSS.GOV. is a mail
gateway that knows how to deliver mail to
Munnari.OZ.AU. but other machines on the network
can not deliver mail directly to Munnari. These two
machines may have a private connection or use a
different transport medium. The preference value
is the order that a mailer should follow when there
is more then one way to deliver mail to a single
machine. See RFC974 for more detailed information.
Wildcard names containing the character ``*''
may be used for mail routing with _
\bM_
\bX records.
There are likely to be servers on the network that
simply state that any mail to a domain is to be
routed through a relay. Second example, above, all
mail to hosts in the domain IL is routed through
RELAY.CS.NET. This is done by creating a wildcard
resource record, which states that *.IL has an _
\bM_
\bX
The following section contains sample files for
the name server. This covers example boot files for
the different types of servers and example domain data
SMM:11-16 Name Server Operations Guide for BIND
5.5.1.1. Primary Master Server
; Boot file for Primary Master Name Server
; type domain source file or host
directory /usr/local/domain
primary Berkeley.Edu ucbhosts
primary 32.128.in-addr.arpa ucbhosts.rev
primary 0.0.127.in-addr.arpa named.local
5.5.1.2. Secondary Master Server
; Boot file for Primary Master Name Server
; type domain source file or host
directory /usr/local/domain
secondary Berkeley.Edu 128.32.0.4 128.32.0.10 ucbhosts.bak
secondary 32.128.in-addr.arpa 128.32.0.4 128.32.0.10 ucbhosts.rev.bak
primary 0.0.127.in-addr.arpa named.local
5.5.1.3. Caching Only Server
; Boot file for Caching Only Name Server
; type domain source file or host
directory /usr/local/domain
primary 0.0.127.in-addr.arpa /etc/named.local
Name Server Operations Guide for BIND SMM:11-17
5.5.2.1. /etc/resolv.conf
; Initial cache data for root domain servers.
. 99999999 IN NS SRI-NIC.ARPA.
99999999 IN NS NS.NASA.GOV.
99999999 IN NS TERP.UMD.EDU.
99999999 IN NS A.ISI.EDU.
99999999 IN NS BRL-AOS.ARPA.
99999999 IN NS GUNTER-ADAM.ARPA.
99999999 IN NS C.NYSER.NET.
; Prep the cache (hotwire the addresses).
SRI-NIC.ARPA. 99999999 IN A 10.0.0.51
SRI-NIC.ARPA. 99999999 IN A 26.0.0.73
NS.NASA.GOV. 99999999 IN A 128.102.16.10
A.ISI.EDU. 99999999 IN A 26.3.0.103
BRL-AOS.ARPA. 99999999 IN A 128.20.1.2
BRL-AOS.ARPA. 99999999 IN A 192.5.25.82
BRL-AOS.ARPA. 99999999 IN A 192.5.22.82
GUNTER-ADAM.ARPA. 99999999 IN A 26.1.0.13
C.NYSER.NET. 99999999 IN A 128.213.5.17
TERP.UMD.EDU. 99999999 IN A 10.1.0.17
SMM:11-18 Name Server Operations Guide for BIND
@ IN SOA ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. (
IN NS ucbvax.Berkeley.Edu.
Name Server Operations Guide for BIND SMM:11-19
SMM:11-20 Name Server Operations Guide for BIND
; @(#)ucb-hosts 1.1 (berkeley) 86/02/05
@ IN SOA ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. (
IN NS ucbarpa.Berkeley.Edu.
IN NS ucbvax.Berkeley.Edu.
ANY HINFO VAX-11/780 UNIX
ANY HINFO VAX-11/780 UNIX
ANY HINFO VAX-11/750 UNIX
ANY HINFO VAX-11/750 UNIX
IN WKS 128.32.0.10 UDP syslog route timed domain
IN WKS 128.32.0.10 TCP ( echo telnet
toybox IN A 128.32.131.119
toybox IN MX 0 monet.Berkeley.Edu
miriam ANY MB vineyd.DEC.COM.
postmistress ANY MR Miriam
Bind ANY MINFO Bind-Request kjd.Berkeley.Edu.
ANY MG Ralph.Berkeley.Edu.
ANY MG Zhou.Berkeley.Edu.
ANY MG Painter.Berkeley.Edu.
ANY MG Riggle.Berkeley.Edu.
ANY MG Terry.pa.Xerox.Com.
Name Server Operations Guide for BIND SMM:11-21
; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05
@ IN SOA ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. (
IN NS ucbarpa.Berkeley.Edu.
IN NS ucbvax.Berkeley.Edu.
4.0 IN PTR ucbarpa.Berkeley.Edu.
6.0 IN PTR ernie.Berkeley.Edu.
7.0 IN PTR monet.Berkeley.Edu.
10.0 IN PTR ucbvax.Berkeley.Edu.
6.130 IN PTR monet.Berkeley.Edu.
This section contains information for starting, con-
trolling and debugging _
\bn_
\ba_
\bm_
\be_
\bd.
The hostname should be set to the full domain
style name in /_
\be_
\bt_
\bc/_
\br_
\bc._
\bl_
\bo_
\bc_
\ba_
\bl using _
\bh_
\bo_
\bs_
\bt_
\bn_
\ba_
\bm_
\be(_
\b1). The
following entry should be added to /_
\be_
\bt_
\bc/_
\br_
\bc._
\bl_
\bo_
\bc_
\ba_
\bl to
start up _
\bn_
\ba_
\bm_
\be_
\bd at system boot time:
_
\bi_
\bf [ -_
\bf /_
\be_
\bt_
\bc/_
\bn_
\ba_
\bm_
\be_
\bd ]; _
\bt_
\bh_
\be_
\bn
/_
\be_
\bt_
\bc/_
\bn_
\ba_
\bm_
\be_
\bd [options] & _
\be_
\bc_
\bh_
\bo -_
\bn ' _
\bn_
\ba_
\bm_
\be_
\bd' >/_
\bd_
\be_
\bv/_
\bc_
\bo_
\bn_
\bs_
\bo_
\bl_
\be
This usually directly follows the lines that start
_
\bs_
\by_
\bs_
\bl_
\bo_
\bg_
\bd. Do Not attempt to run _
\bn_
\ba_
\bm_
\be_
\bd from _
\bi_
\bn_
\be_
\bt_
\bd.
This will continuously restart the name server and
defeat the purpose of having a cache.
When _
\bn_
\ba_
\bm_
\be_
\bd is successfully started up it writes
its process id into the file /_
\be_
\bt_
\bc/_
\bn_
\ba_
\bm_
\be_
\bd._
\bp_
\bi_
\bd. This is
SMM:11-22 Name Server Operations Guide for BIND
useful to programs that want to send signals to _
\bn_
\ba_
\bm_
\be_
\bd.
The name of this file may be changed by defining _
\bP_
\bI_
\bD_
\b-
_
\bF_
\bI_
\bL_
\bE to the new name when compiling _
\bn_
\ba_
\bm_
\be_
\bd.
The _
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\bb_
\by_
\bn_
\ba_
\bm_
\be() library call can detect if
_
\bn_
\ba_
\bm_
\be_
\bd is running. If it is determined that _
\bn_
\ba_
\bm_
\be_
\bd is
not running it will look in /_
\be_
\bt_
\bc/_
\bh_
\bo_
\bs_
\bt_
\bs to resolve an
address. This option was added to allow _
\bi_
\bf_
\bc_
\bo_
\bn_
\bf_
\bg(_
\b8_
\bC) to
configure the machines local interfaces and to enable
a system manager to access the network while the sys-
tem is in single user mode. It is advisable to put
the local machines interface addresses and a couple of
machine names and address in /_
\be_
\bt_
\bc/_
\bh_
\bo_
\bs_
\bt_
\bs so the system
manager can rcp files from another machine when the
system is in single user mode. The format of
/_
\be_
\bt_
\bc/_
\bh_
\bo_
\bs_
\bt has not changed. See _
\bh_
\bo_
\bs_
\bt_
\bs(_
\b5) for more
information. Since the process of reading /_
\be_
\bt_
\bc/_
\bh_
\bo_
\bs_
\bt_
\bs
is slow, it is not advised to use this option when the
system is in multi user mode.
There are several signals that can be sent to the
_
\bn_
\ba_
\bm_
\be_
\bd process to have it do tasks without restarting
SIGHUP - Causes _
\bn_
\ba_
\bm_
\be_
\bd to read _
\bn_
\ba_
\bm_
\be_
\bd._
\bb_
\bo_
\bo_
\bt and
reload the database. All previously cached data is
lost. This is useful when you have made a change
to a data file and you want _
\bn_
\ba_
\bm_
\be_
\bd's internal data-
base to reflect the change.
When _
\bn_
\ba_
\bm_
\be_
\bd is running incorrectly, look first
in /_
\bu_
\bs_
\br/_
\ba_
\bd_
\bm/_
\bm_
\be_
\bs_
\bs_
\ba_
\bg_
\be_
\bs and check for any messages
logged by _
\bs_
\by_
\bs_
\bl_
\bo_
\bg. Next send it a signal to see
SIGINT - Dumps the current data base and cache
to /_
\bu_
\bs_
\br/_
\bt_
\bm_
\bp/_
\bn_
\ba_
\bm_
\be_
\bd__
\bd_
\bu_
\bm_
\bp._
\bd_
\bb This should give you an
indication to whether the data base was loaded
correctly. The name of the dump file may be
changed by defining _
\bD_
\bU_
\bM_
\bP_
\bF_
\bI_
\bL_
\bE to the new name when
compiling _
\bn_
\ba_
\bm_
\be_
\bd.
_
\bN_
\bo_
\bt_
\be: the following two signals only work when
_
\bn_
\ba_
\bm_
\be_
\bd is built with _
\bD_
\bE_
\bB_
\bU_
\bG defined.
Name Server Operations Guide for BIND SMM:11-23
SIGUSR1 - Turns on debugging. Each following
USR1 increments the debug level. The output goes
to /_
\bu_
\bs_
\br/_
\bt_
\bm_
\bp/_
\bn_
\ba_
\bm_
\be_
\bd._
\br_
\bu_
\bn The name of this debug file
may be changed by defining _
\bD_
\bE_
\bB_
\bU_
\bG_
\bF_
\bI_
\bL_
\bE to the new
name before compiling _
\bn_
\ba_
\bm_
\be_
\bd.
SIGUSR2 - Turns off debugging completely.
For more detailed debugging, define DEBUG when com-
piling the resolver routines into /_
\bl_
\bi_
\bb/_
\bl_
\bi_
\bb_
\bc._
\ba.
Many thanks to the users at U.C. Berkeley for falling
into many of the holes involved with integrating BIND into
the system so that others would be spared the trauma. I
would also like to extend gratitude to Jim McGinness and
Digital Equipment Corporation for permitting me to spend
most of my time on this project.
Ralph Campbell, Doug Kingston, Craig Partridge, Smoot
Carl-Mitchell, Mike Muuss and everyone else on the DARPA
Internet who has contributed to the development of BIND. To
the members of the original BIND project, Douglas Terry,
Mark Painter, David Riggle and Songnian Zhou.
Anne Hughes, Jim Bloom and Kirk McKusick and the many
others who have reviewed this paper giving considerable
This work was sponsored by the Defense Advanced
Research Projects Agency (DoD), Arpa Order No. 4871 moni-
tored by the Naval Electronics Systems Command under con-
tract No. N00039-84-C-0089. The views and conclusions con-
tained in this document are those of the authors and should
not be interpreted as representing official policies, either
expressed or implied, of the Defense Research Projects
Agency, of the US Government, or of Digital Equipment Cor-
SMM:11-24 Name Server Operations Guide for BIND
[Birrell] Birrell, A. D., Levin, R., Needham, R. M., and
Schroeder, M.D., "Grapevine: An Exercise in Dis-
tributed Computing." In _
\bC_
\bo_
\bm_
\bm. _
\bA._
\bC._
\bM. _
\b2_
\b5, 4:260-274
[RFC819] Su, Z. Postel, J., "The Domain Naming Convention
for Internet User Applications." _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt _
\bR_
\be_
\bq_
\bu_
\be_
\bs_
\bt
_
\bF_
\bo_
\br _
\bC_
\bo_
\bm_
\bm_
\be_
\bn_
\bt _
\b8_
\b1_
\b9 Network Information Center, SRI
International, Menlo Park, California. August
[RFC973] Mockapetris, P., "Domain System Changes and Obser-
vations." _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt _
\bR_
\be_
\bq_
\bu_
\be_
\bs_
\bt _
\bF_
\bo_
\br _
\bC_
\bo_
\bm_
\bm_
\be_
\bn_
\bt _
\b9_
\b7_
\b3 Network
Information Center, SRI International, Menlo Park,
California. February 1986.
[RFC974] Partridge, C., "Mail Routing and The Domain Sys-
tem." _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt _
\bR_
\be_
\bq_
\bu_
\be_
\bs_
\bt _
\bF_
\bo_
\br _
\bC_
\bo_
\bm_
\bm_
\be_
\bn_
\bt _
\b9_
\b7_
\b4 Network
Information Center, SRI International, Menlo Park,
California. February 1986.
[RFC1032] Stahl, M., "Domain Administrators Guide" _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt
_
\bR_
\be_
\bq_
\bu_
\be_
\bs_
\bt _
\bF_
\bo_
\br _
\bC_
\bo_
\bm_
\bm_
\be_
\bn_
\bt _
\b1_
\b0_
\b3_
\b2 Network Information
Center, SRI International, Menlo Park, California.
[RFC1033] Lottor, M., "Domain Administrators Guide" _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt
_
\bR_
\be_
\bq_
\bu_
\be_
\bs_
\bt _
\bF_
\bo_
\br _
\bC_
\bo_
\bm_
\bm_
\be_
\bn_
\bt _
\b1_
\b0_
\b3_
\b3 Network Information
Center, SRI International, Menlo Park, California.
[RFC1034] Mockapetris, P., "Domain Names - Concept and
Facilities." _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt _
\bR_
\be_
\bq_
\bu_
\be_
\bs_
\bt _
\bF_
\bo_
\br _
\bC_
\bo_
\bm_
\bm_
\be_
\bn_
\bt _
\b1_
\b0_
\b3_
\b4
Network Information Center, SRI International,
Menlo Park, California. November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation
and Specification." _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt _
\bR_
\be_
\bq_
\bu_
\be_
\bs_
\bt _
\bF_
\bo_
\br _
\bC_
\bo_
\bm_
\bm_
\be_
\bn_
\bt
_
\b1_
\b0_
\b3_
\b5 Network Information Center, SRI Interna-
tional, Menlo Park, California. November 1987.
[Terry] Terry, D. B., Painter, M., Riggle, D. W., and
Zhou, S., _
\bT_
\bh_
\be _
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt _
\bN_
\ba_
\bm_
\be _
\bD_
\bo_
\bm_
\ba_
\bi_
\bn
_
\bS_
\be_
\br_
\bv_
\be_
\br. Proceedings USENIX Summer Conference,
Salt Lake City, Utah. June 1984, pages 23-31.
[Zhou] Zhou, S., _
\bT_
\bh_
\be _
\bD_
\be_
\bs_
\bi_
\bg_
\bn _
\ba_
\bn_
\bd _
\bI_
\bm_
\bp_
\bl_
\be_
\bm_
\be_
\bn_
\bt_
\ba_
\bt_
\bi_
\bo_
\bn _
\bo_
\bf _
\bt_
\bh_
\be
_
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt _
\bN_
\ba_
\bm_
\be _
\bD_
\bo_
\bm_
\ba_
\bi_
\bn (_
\bB_
\bI_
\bN_
\bD) _
\bS_
\be_
\br_
\bv_
\be_
\br_
\bs.
UCB/CSD 84/177. University of California, Berke-
ley, Computer Science Division. May 1984.
projects / unix-history / blob