N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be
f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
_
\bR_
\be_
\bl_
\be_
\ba_
\bs_
\be _
\b4_
\b._
\b9
_
\bR_
\be_
\bl_
\be_
\ba_
\bs_
\be_
\bs _
\bf_
\br_
\bo_
\bm _
\b4_
\b._
\b9
Digital Equipment Corporation
Network Systems Laboratory
_
\bR_
\be_
\bl_
\be_
\ba_
\bs_
\be_
\bs _
\bt_
\bh_
\br_
\bo_
\bu_
\bg_
\bh _
\b4_
\b._
\b8_
\b._
\b3
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Sciences
1
\b1.
\b. I
\bIn
\bnt
\btr
\bro
\bod
\bdu
\buc
\bct
\bti
\bio
\bon
\bn
The Berkeley Internet Name Domain (BIND) implements
an Internet name server for the UNIX operating system.
The BIND consists of a server (or ``daemon'') and a
_
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br library. 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 integrated
into BSD (4.3 and later releases) network programs for
use in storing and retrieving host names and address.
* The author was an employee of Digital Equipment Corpo-
ration'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.
UNIX is a Trademark of AT&T Bell Laboratories
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b2 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
The system administrator can configure the system to use
BIND as a replacement to the older host table lookup of
information in the network hosts file _
\b/_
\be_
\bt_
\bc_
\b/_
\bh_
\bo_
\bs_
\bt_
\bs. The
default configuration for BSD uses BIND.
2
\b2.
\b. B
\bBu
\bui
\bil
\bld
\bdi
\bin
\bng
\bg A
\bA S
\bSy
\bys
\bst
\bte
\bem
\bm w
\bwi
\bit
\bth
\bh a
\ba N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br
BIND is composed 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 _
\b/_
\bl_
\bi_
\bb_
\b/_
\bl_
\bi_
\bb_
\bc_
\b._
\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
given network port. The standard port for UDP and TCP is
specified in _
\b/_
\be_
\bt_
\bc_
\b/_
\bs_
\be_
\br_
\bv_
\bi_
\bc_
\be_
\bs.
2
\b2.
\b.1
\b1.
\b. R
\bRe
\bes
\bso
\bol
\blv
\bve
\ber
\br R
\bRo
\bou
\but
\bti
\bin
\bne
\bes
\bs i
\bin
\bn l
\bli
\bib
\bbc
\bc
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. Newer BSD
systems include both name server and host table func-
tionality with preference given to the name server if
there is one or if there is a _
\b/_
\be_
\bt_
\bc_
\b/_
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\b._
\bc_
\bo_
\bn_
\bf file.
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 contains functions that build query
packets and exchange them with name servers.
Before building the 4.3BSD C library, set the
variable _
\bH_
\bO_
\bS_
\bT_
\bL_
\bO_
\bO_
\bK_
\bU_
\bP equal to _
\bn_
\ba_
\bm_
\be_
\bd in
_
\b/_
\bu_
\bs_
\br_
\b/_
\bs_
\br_
\bc_
\b/_
\bl_
\bi_
\bb_
\b/_
\bl_
\bi_
\bb_
\bc_
\b/_
\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
If your operating system isn't VAX 4.3BSD, it is
probably the case that your vendor has included
_
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br support in the supplied C Library. You
VAX is a Trademark of Digital Equipment Corporation
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b3
should consult your vendor's documentation to find out
what has to be done to enable _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br support. Note
that your vendor's _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br may be out of date with
respect to the one shipped with BIND, and that you
might want to build BIND's resolver library and
install it, and its include files, into your system's
compile/link path so that your own network applica-
tions will be able to use the newer features.
2
\b2.
\b.2
\b2.
\b. T
\bTh
\bhe
\be N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bvi
\bic
\bce
\be
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 RFC1034, RFC1035 and RFC974. These docu-
ments can be found in _
\b/_
\bu_
\bs_
\br_
\b/_
\bs_
\br_
\bc_
\b/_
\be_
\bt_
\bc_
\b/_
\bn_
\ba_
\bm_
\be_
\bd_
\b/_
\bd_
\bo_
\bc in 4.3BSD
or _
\bf_
\bt_
\bped from f
\bft
\btp
\bp.
\b.r
\brs
\bs.
\b.i
\bin
\bnt
\bte
\ber
\brn
\bni
\bic
\bc.
\b.n
\bne
\bet
\bt. It is also recom-
mended 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-
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 coop-
erate. But this does not work well for large networks
where machines cross organizational boundaries.
With the name server, the network can be broken
into a hierarchy of domains. The name space is orga-
nized as a tree according to organizational or admin-
istrative 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 sev-
eral 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 adminis-
trative boundaries. An example of a host address for
a host at the University of California, Berkeley would
_
\bm_
\bo_
\bn_
\be_
\bt.
\b._
\bB_
\be_
\br_
\bk_
\be_
\bl_
\be_
\by.
\b._
\bE_
\bD_
\bU
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-4
\b4 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
The top level domain for educational organizations is
EDU; Berkeley is a subdomain of EDU and monet is the
2
\b2.
\b.3
\b3.
\b. A
\bAb
\bbo
\bou
\but
\bt H
\bHe
\bes
\bsi
\bio
\bod
\bd,
\b, a
\ban
\bnd
\bd H
\bHS
\bS-
\b-c
\bcl
\bla
\bas
\bss
\bs R
\bRe
\bes
\bso
\bou
\bur
\brc
\bce
\be R
\bRe
\bec
\bco
\bor
\brd
\bds
\bs
Hesiod, developed by MIT Project Athena, is an
information service built upon BIND. Its intent is
similar to that of Sun's NIS: to furnish information
about users, groups, network-accessible file systems,
printcaps, and mail service throughout an installa-
tion. Aside from its use of BIND rather than separate
server code another important difference between Hes-
iod and NIS is that Hesiod is not intended to deal
with passwords and authentication, but only with data
that are not security sensitive. Hesiod servers can
be implemented by adding resource records to BIND
servers; or they can be implemented as separate
servers separately administered.
To learn about and obtain Hesiod make an anony-
mous FTP connection to host ATHENA-DIST.MIT.EDU and
retrieve the compressed tar file p
\bpu
\bub
\bb/
\b/h
\bhe
\bes
\bsi
\bio
\bod
\bd.
\b.t
\bta
\bar
\br.
\b.Z
\bZ.
You will not need the named and resolver library por-
tions of the distribution because their functionality
has already been integrated into BIND 4.9. To learn
how Hesiod functions as part of the Athena computing
environment obtain the paper p
\bpu
\bub
\bb/
\b/u
\bus
\bse
\ben
\bni
\bix
\bx/
\b/a
\bat
\bth
\bhe
\ben
\bna
\ba-
\b-
c
\bch
\bha
\ban
\bng
\bge
\bes
\bs.
\b.P
\bPS
\bS from the above FTP server host. There is
also a tar file of sample Hesiod resource files.
Whether one should use Hesiod class is open to
question, since the same services can probably be pro-
vided with class IN, type TXT and type CNAME records.
In either case, the code and documents for Hesiod will
suggest how to set up and use the service.
Note that while BIND includes support for _
\bH_
\bS-
class queries, the zone transfer logic for non-_
\bI_
\bN-
class zones is still experimental.
2
\b2.
\b.4
\b4.
\b. A
\bAb
\bbo
\bou
\but
\bt `
\b``
\b`s
\bse
\bec
\bcu
\bur
\bre
\be z
\bzo
\bon
\bne
\bes
\bs'
\b''
\b'
Secure zones implement named security on a zone
by zone basis. It is designed to use a permission
list of networks or hosts which may obtain particular
information from the zone.
In order to use zone security, named must be com-
piled with SECURE_ZONES defined and you must have at
least one secure_zone TXT RR. Unless a secure_zone
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-5
\b5
record exists for a given zone, no restrictions will
be applied to the data in that zone. The format of
the secure_zone TXT RR is:
secure_zone addr-class TXT string
The addr-class may be either HS or IN. The syn-
tax for the TXT string is either "network
address:netmask" or "host IP address:H".
"network address:netmask" allows queries from an
entire network. If the netmask is omitted, named will
use the default netmask for the network address speci-
"host IP address:H" allows queries from a host.
The "H" after the ":" is required to differentiate
the host address from a network address. Multiple
secure_zone TXT RRs are allowed in the same zone file.
For example, you can set up a zone to only answer
hesiod requests from the masked class B network
130.215.0.0 and from host 128.23.10.56 by adding the
secure_zone HS TXT "130.215.0.0:255.255.0.0"
secure_zone HS TXT "128.23.10.56:H"
This feature can be used to restrict access to a
Hesiod password map or to seperate internal and exter-
nal internet address resolution on a firewall machine
without needing to run a seperate named for internal
and external address resolution.
3
\b3.
\b. T
\bTy
\byp
\bpe
\bes
\bs o
\bof
\bf Z
\bZo
\bon
\bne
\bes
\bs
A ``zone'' is a point of delegation in the DNS tree.
It contains all names from a certain point ``downward''
except those which are delegated to other servers. A
``delegation point'' has one or more _
\bN_
\bS records in the
``parent zone'', which should be matched by equivalent _
\bN_
\bS
records at the root of the ``delegated zone'' (i.e., the
``@'' name in the zone file).
Understanding the difference between a ``zone'' and
a ``domain'' is crucial to the proper operation of a name
server. As an example, consider the DEC.COM _
\bd_
\bo_
\bm_
\ba_
\bi_
\bn,
which includes names such as POBOX1.PA.DEC.COM and QUAB-
BIN.CRL.DEC.COM even though the DEC.COM _
\bz_
\bo_
\bn_
\be includes
only _
\bd_
\be_
\bl_
\be_
\bg_
\ba_
\bt_
\bi_
\bo_
\bn_
\bs for the PA.DEC.COM and CRL.DEC.COM
zones. A zone can map exactly to a single domain, but
could also include only part of a domain (the rest of
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-6
\b6 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
which could be delegated to other name servers). Techni-
cally speaking, every name in the DNS tree is a
``domain'', even if it is ``terminal'', that is, has no
``subdomains''. Technically speaking, every subdomain is
a domain and every domain except the root is also a sub-
domain. The terminology is not intuitive and you would
do well to read RFC's 1033, 1034, and 1035 to gain a com-
plete understanding of this difficult and subtle topic.
Though BIND is a _
\bD_
\bo_
\bm_
\ba_
\bi_
\bn Name Server, it deals pri-
marily in terms of _
\bz_
\bo_
\bn_
\be_
\bs. The _
\bp_
\br_
\bi_
\bm_
\ba_
\br_
\by and _
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by dec-
larations in the _
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\bb_
\bo_
\bo_
\bt file specify _
\bz_
\bo_
\bn_
\be_
\bs, not
_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn_
\bs. When you ask someone if they are willing to be
a secondary server for your ``domain'', you are actually
asking for secondary service for some collection of
Each zone will have one ``primary'' server, which
loads the zone contents from some local file which is
edited by humans or perhaps generated mechanically from
some other local file which is edited by humans. Then
there will be some number of ``secondary'' servers, which
load the zone contents using the IP/DNS protocol (that
is, the secondary servers will contact the primary and
fetch the zone using IP/TCP). This set of servers (the
primary and all of the secondaries) should be listed in
the _
\bN_
\bS records in the parent zone, which will constitute
a ``delegation''. This set of servers must also be
listed in the zone file itself, usually under the ``@''
name which is a magic cookie that means the ``top level''
or ``root'' of current $ORIGIN. You can list servers in
the zone's top-level ``@'' _
\bN_
\bS records that are not in the
parent's _
\bN_
\bS delegation, but you cannot list servers in
the parent's delegation that are not present in the
zone's ``@''. (This latter condition is one form of what
is called a ``lame delegation''.)
4
\b4.
\b. T
\bTy
\byp
\bpe
\bes
\bs o
\bof
\bf S
\bSe
\ber
\brv
\bve
\ber
\brs
\bs
Servers do not really have ``types''. A server can
be a primary for some zones and a secondary for others,
or it can be only a primary, or only a secondary, or it
can serve no zones and just answer queries via its
``cache''. Previous versions of this document referred
to servers as ``master'' and ``slave'' but we now feel
that those distinctions -- and the assignment of a
``type'' to a name server -- are not useful.
4
\b4.
\b.1
\b1.
\b. C
\bCa
\bac
\bch
\bhi
\bin
\bng
\bg O
\bOn
\bnl
\bly
\by S
\bSe
\ber
\brv
\bve
\ber
\br
All servers are caching servers. This means that
the server caches the information that it receives for
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-7
\b7
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 _
\bT_
\bT_
\bL (``Time To Live'') field which
is maintained for all resource records.
4
\b4.
\b.2
\b2.
\b. R
\bRe
\bem
\bmo
\bot
\bte
\be S
\bSe
\ber
\brv
\bve
\ber
\br
A Remote Server is an option given to people who
would like to use a name server from 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 with-
out 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. This kind
of host is technically not a ``server'', since it has
no cache and does not answer queries. A host which
has an _
\b/_
\be_
\bt_
\bc_
\b/_
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\b._
\bc_
\bo_
\bn_
\bf file listing only remote
hosts, and which does not run a name server of its
own, is sometimes called a Remote Server but more
often it is called simply a DNS Client.
4
\b4.
\b.3
\b3.
\b. S
\bSl
\bla
\bav
\bve
\be S
\bSe
\ber
\brv
\bve
\ber
\br
A Slave Server is a server that always forwards
queries it cannot satisfy from its cache, 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 given site to be interacting with the rest of the
Internet servers. A typical scenario 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
other nameservers to resolve the query before return-
ing the answer. An added benefit of using the for-
warding feature is that the central machine develops a
much more complete cache of information that all the
workstations can take advantage of. The use of Slave
mode and forwarding is discussed further under the
description of the named bootfile commands.
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-8
\b8 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
Note that a Slave Server still needs a _
\bc_
\ba_
\bc_
\bh_
\be
directive in its bootfile, since it will otherwise not
be able to locate the root servers. There is no pro-
hibition against declaring a server to be a _
\bs_
\bl_
\ba_
\bv_
\be even
though it has _
\bp_
\br_
\bi_
\bm_
\ba_
\br_
\by and/or _
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by zones as well;
the effect will still be that anything in the local
server's cache or zones will be answered, and anything
else will be forwarded using the _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs list.
5
\b5.
\b. S
\bSe
\bet
\btt
\bti
\bin
\bng
\bg u
\bup
\bp Y
\bYo
\bou
\bur
\br O
\bOw
\bwn
\bn D
\bDo
\bom
\bma
\bai
\bin
\bn
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 the _
\bI_
\bn_
\bt_
\be_
\br_
\bn_
\be_
\bt
and _
\bB_
\bI_
\bT_
\bN_
\bE_
\bT) should register with only one network.
The contacts are as follows:
5
\b5.
\b.1
\b1.
\b. I
\bIn
\bnt
\bte
\ber
\brn
\bne
\bet
\bt
Sites on the Internet who need information on
setting up a domain should contact the registrar for
their network, which is one of the following:
MILnet HOSTMASTER@NIC.
\b.DDN.
\b.MIL
other HOSTMASTER@RS.
\b.INTERNIC.
\b.NET
You may also want to be placed on the BIND mailing
list, which is a mail group for people on the Internet
who run BIND. The group discusses future design deci-
sions, operational problems, and other related topic.
The address to request being placed on this mailing
_
\bb_
\bi_
\bn_
\bd_
\b-_
\br_
\be_
\bq_
\bu_
\be_
\bs_
\bt_
\b@_
\bu_
\bu_
\bn_
\be_
\bt.
\b._
\bu_
\bu.
\b._
\bn_
\be_
\bt
5
\b5.
\b.2
\b2.
\b. B
\bBI
\bIT
\bTN
\bNE
\bET
\bT
If you are on the BITNET and need to set up a
domain, contact INFO@BITNIC.
5
\b5.
\b.3
\b3.
\b. S
\bSu
\bub
\bbd
\bdo
\bom
\bma
\bai
\bin
\bns
\bs o
\bof
\bf E
\bEx
\bxi
\bis
\bst
\bti
\bin
\bng
\bg D
\bDo
\bom
\bma
\bai
\bin
\bns
\bs
If you want a subdomain of some existing domain,
you should find the contact point for the parent
domain rather than asking one of the above top-level
registrars. There should be a convention that r
\bre
\beg
\bgi
\bis
\bs-
\b-
t
\btr
\bra
\bar
\br@_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn or h
\bho
\bos
\bst
\btm
\bma
\bas
\bst
\bte
\ber
\br@_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn for any given domain
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-9
\b9
will always be an alias for that domain's registrar
(somewhat analogous to p
\bpo
\bos
\bst
\btm
\bma
\bas
\bst
\bte
\ber
\br), but there is no
such convention. Try it as a last resort, but first
you should examine the _
\bS_
\bO_
\bA record for the domain and
send mail to the ``responsible person'' shown therein.
6
\b6.
\b. F
\bFi
\bil
\ble
\bes
\bs
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.
6
\b6.
\b.1
\b1.
\b. B
\bBo
\boo
\bot
\bt F
\bFi
\bil
\ble
\be
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 _
\b/_
\be_
\bt_
\bc_
\b/_
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\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.
6
\b6.
\b.1
\b1.
\b.1
\b1.
\b. D
\bDo
\bom
\bma
\bai
\bin
\bn
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.
\b._
\bE_
\bd_
\bu
Older name servers use this information when they
receive a query for a name without a ``.
\b.'' that is
not known. Newer designs assume that the resolver
library will append its own idea of a ``default
domain'' to any unqualified names. Though the name
server can still be compiled with support for the
_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn directive in the boot file, the default is
to leave it out and we strenuously recommend
against its use. If you use this feature, clients
outside your local domain which send you requests
about unqualified names will have the implicit
qualification of your domain rather than theirs.
The proper place for this function is on the
client, in their /
\b/e
\bet
\btc
\bc/
\b/r
\bre
\bes
\bso
\bol
\blv
\bv.
\b.c
\bco
\bon
\bnf
\bf (or equivalent)
file. Use of the _
\bd_
\bo_
\bm_
\ba_
\bi_
\bn directive in your boot
file is strongly discouraged.
6
\b6.
\b.1
\b1.
\b.2
\b2.
\b. D
\bDi
\bir
\bre
\bec
\bct
\bto
\bor
\bry
\by
The _
\bd_
\bi_
\br_
\be_
\bc_
\bt_
\bo_
\br_
\by directive specifies the direc-
tory in which the nameserver should run, allowing
the other file names in the boot file to use
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b10
\b0 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
relative path names. There can be only one _
\bd_
\bi_
\br_
\be_
\bc_
\b-
_
\bt_
\bo_
\br_
\by directive and it should be given before any
other directives that specify file names.
_
\bd_
\bi_
\br_
\be_
\bc_
\bt_
\bo_
\br_
\by _
\b/_
\bv_
\ba_
\br_
\b/_
\bn_
\ba_
\bm_
\be_
\bd
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 /var/named 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
named to run in a location that is reasonable to
dump core if it feels the urge.
6
\b6.
\b.1
\b1.
\b.3
\b3.
\b. P
\bPr
\bri
\bim
\bma
\bar
\bry
\by S
\bSe
\ber
\brv
\bvi
\bic
\bce
\be
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.
\b._
\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
6
\b6.
\b.1
\b1.
\b.4
\b4.
\b. S
\bSe
\bec
\bco
\bon
\bnd
\bda
\bar
\bry
\by S
\bSe
\ber
\brv
\bvi
\bic
\bce
\be
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.
\b._
\bE_
\bd_
\bu _
\b1_
\b2_
\b8.
\b._
\b3_
\b2.
\b._
\b0.
\b._
\b1_
\b0 _
\b1_
\b2_
\b8.
\b._
\b3_
\b2.
\b._
\b0.
\b._
\b4 _
\bu_
\bc_
\bb_
\bh_
\bo_
\bs_
\bt_
\bs_
\b._
\bb_
\ba_
\bk
The first field specifies that the server is a sec-
ondary master server for the zone stated in the
second field. The two network addresses specify
the name servers which have data for the zone.
Note that at least one of these will be a _
\bp_
\br_
\bi_
\bm_
\ba_
\br_
\by,
and, unless you are using some protocol other than
IP/DNS for your zone transfer mechanism, the others
will all be other _
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by servers. Having your
secondary server pull data from other secondary
servers is usually unwise, since you can add delay
to the propagation of zone updates if your net-
work's connectivity varies in pathological but com-
mon ways. The intended use for multiple addresses
on a _
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by declaration is when the _
\bp_
\br_
\bi_
\bm_
\ba_
\br_
\by
server has multiple network interfaces and
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b11
\b1
therefore multiple host addresses. The secondary
server gets its data across the network from one of
the listed servers. The server addresses are tried
in the order listed. 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 is
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. Note that listing your
server as a _
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by server does not neccessarily
make it one -- the parent zone must _
\bd_
\be_
\bl_
\be_
\bg_
\ba_
\bt_
\be
authority to your server as well as the primary and
the other secondaries, or you will be transferring
a zone over for no reason; no other server will
have a reason to query you for that zone unless the
parent zone lists you as a server for the zone.
6
\b6.
\b.1
\b1.
\b.5
\b5.
\b. C
\bCa
\bac
\bch
\bhi
\bin
\bng
\bg S
\bSe
\ber
\brv
\bve
\ber
\br
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, including ``caching only''
servers, should have a line as follows in the boot
file to prime the name servers cache:
_
\bc_
\ba_
\bc_
\bh_
\be .
\b. _
\br_
\bo_
\bo_
\bt.
\b._
\bc_
\ba_
\bc_
\bh_
\be
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 be used until a root
query is actually answered by one of the name
servers in your cache file, at which time that
answer will be used until it times out and your
cache file will be ignored.
Do not put anything into your _
\bc_
\ba_
\bc_
\bh_
\be files
other than root server information.
6
\b6.
\b.1
\b1.
\b.6
\b6.
\b. F
\bFo
\bor
\brw
\bwa
\bar
\brd
\bde
\ber
\brs
\bs
Any server can make use of _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs. A _
\bf_
\bo_
\br_
\b-
_
\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_
\br_
\bd_
\be_
\br_
\bs
command specifies forwarders by internet address as
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b12
\b2 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
_
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs _
\b1_
\b2_
\b8.
\b._
\b3_
\b2.
\b._
\b0.
\b._
\b1_
\b0 _
\b1_
\b2_
\b8.
\b._
\b3_
\b2.
\b._
\b0.
\b._
\b4
There are two main reasons for wanting to do so.
First, some systems may not have full network
access and may be prevented from sending any IP
packets into the rest of the Internet and therefore
must rely on a forwarder which does have access to
the full net. The second reason is that the for-
warder sees a union of all queries as they pass
through his server and therefore it 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.
The effect of ``forwarders'' is to prepend
some fixed addresses to the list of name servers to
be tried for every query. Normally that list is
made up only of higher-authority servers discovered
via _
\bN_
\bS record lookups for the relevant domain. If
the forwarders do not answer, then unless the _
\bs_
\bl_
\ba_
\bv_
\be
directive was given, the appropriate servers for
the domains will be queried directly.
6
\b6.
\b.1
\b1.
\b.7
\b7.
\b. S
\bSl
\bla
\bav
\bve
\be S
\bSe
\ber
\brv
\bve
\ber
\brs
\bs
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 for-
warders until an answer is found or the list of
forwarders is exhausted. The server will not try
to contact any remote name server other than those
named in the _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs list.
So while _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs adds to the end of the
``server list'' for each query, _
\bs_
\bl_
\ba_
\bv_
\be causes the
``server list'' to contain _
\bo_
\bn_
\bl_
\by those addresses
listed in the _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs declarations. Careless
use of the _
\bs_
\bl_
\ba_
\bv_
\be directive can cause really horri-
ble forwarding loops, since you could end up for-
warding queries only to some set of hosts which are
also slaves, and one or several of them could be
forwarding queries back to you.
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b13
\b3
Use of the _
\bs_
\bl_
\ba_
\bv_
\be directive should be consid-
6
\b6.
\b.1
\b1.
\b.8
\b8.
\b. Z
\bZo
\bon
\bne
\be T
\bTr
\bra
\ban
\bns
\bsf
\bfe
\ber
\br R
\bRe
\bes
\bst
\btr
\bri
\bic
\bct
\bti
\bio
\bon
\bns
\bs
It may be the case that your organization does
not wish to give complete lists of your hosts to
anyone on the Internet who can reach your name
servers. While it is still possible for people to
``iterate'' through your address range, looking for
_
\bP_
\bT_
\bR records, and build a list of your hosts the
``slow'' way, it is still considered reasonable to
restrict your export of zones via the zone transfer
protocol. To limit the list of neighbors who can
transfer zones from your server, use the
_
\bx_
\bf_
\br_
\bn_
\be_
\bt_
\bs
directive. This directive has the same syntax as
_
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs except that you can list network numbers
in addition to host addresses. For example, you
could add the directive _
\bx_
\bf_
\br_
\bn_
\be_
\bt_
\bs _
\b1_
\b6_
\b._
\b0_
\b._
\b0_
\b._
\b0 if you
wanted to permit only hosts on Class A network num-
ber 16 to transfer zones from your server. This is
not nearly granular enough, and a future version of
BIND will permit such access-control to be speci-
fied on a per-zone basis rather than the current
The _
\bx_
\bf_
\br_
\bn_
\be_
\bt_
\bs directive may also be given as
_
\bt_
\bc_
\bp_
\bl_
\bi_
\bs_
\bt for compatibility with interim releases of
Note that _
\bx_
\bf_
\br_
\bn_
\be_
\bt_
\bs support is a compile-time
option which your vendor may not have enabled when
they built your operating system.
6
\b6.
\b.1
\b1.
\b.9
\b9.
\b. S
\bSo
\bor
\brt
\bti
\bin
\bng
\bg A
\bAd
\bdd
\bdr
\bre
\bes
\bss
\bse
\bes
\bs
If there are multiple addresses available for
a name server which BIND wants to contact, BIND
will try the ones it believes are ``closest''
first. ``Closeness'' is defined in terms of simi-
larity-of-address; that is, if one address is on
the same _
\bs_
\bu_
\bb_
\bn_
\be_
\bt as some interface of the local
host, then that address will be tried first. Fail-
ing that, an address which is on the same _
\bn_
\be_
\bt_
\bw_
\bo_
\br_
\bk
will be tried first. Failing that, they will be
tried in a more-or-less random order unless the
_
\bs_
\bo_
\br_
\bt_
\bl_
\bi_
\bs_
\bt directive was given in the _
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\bb_
\bo_
\bo_
\bt
file. _
\bs_
\bo_
\br_
\bt_
\bl_
\bi_
\bs_
\bt has a syntax similar to _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs
and _
\bx_
\bf_
\br_
\bn_
\be_
\bt_
\bs; you give it a list of networks and it
uses these to ``prefer'' some remote name server
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b14
\b4 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
addresses over others. If you are on a Class C net
which has a Class B net between you and the rest of
the Internet, you could try to improve the name
server's luck in getting answers by listing the
Class B network's number in a _
\bs_
\bo_
\br_
\bt_
\bl_
\bi_
\bs_
\bt directive.
This should have the effect of trying ``closer''
servers before the more ``distant'' ones. Note
that this behaviour is new in BIND 4.9.
The other and older effect of the _
\bs_
\bo_
\br_
\bt_
\bl_
\bi_
\bs_
\bt
directive is to cause BIND to sort the _
\bA records in
any response it generates, so as to put those which
appear on the _
\bs_
\bo_
\br_
\bt_
\bl_
\bi_
\bs_
\bt earlier than those which do
not. This is not as helpful as you might think,
since many clients will reorder the _
\bA records
either at random or using LIFO.
In actual practice, noone uses this directive
since it hardwires information which changes
rapidly; a network which is ``close'' today may be
``distant'' next month. Since BIND builds up a
cache of the remote name servers' response times,
it will quickly converge on ``reasonable''
behaviour, which isn't the same as ``optimal'' but
it's close enough. Future directions for BIND
include choosing addresses based on local interface
metrics (on hosts which have more than one) and
perhaps on routing table information. We do not
intend to solve the generalized ``multi-homed
host'' problem, but we should be able to do a lit-
tle better than we're doing now. Likewise, we hope
to see a higher-level resolver library that sorts
responses using topology information that only
exists on the client's host.
6
\b6.
\b.1
\b1.
\b.1
\b10
\b0.
\b. B
\bBo
\bog
\bgu
\bus
\bs N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\brs
\bs
It happens occasionally that some remote name
server goes ``bad''. You can tell your name server
to refuse to listen to or ask questions of certain
other name servers by listing them in a _
\bb_
\bo_
\bg_
\bu_
\bs_
\bn_
\bs
directive in your _
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\bb_
\bo_
\bo_
\bt file. Its syntax is
the same as _
\bf_
\bo_
\br_
\bw_
\ba_
\br_
\bd_
\be_
\br_
\bs -- you just give it a list
of dotted-quad Internet addresses.
Note that _
\bb_
\bo_
\bg_
\bu_
\bs_
\bn_
\bs support is a compile-time
option which your vendor may not have enabled when
they built your operating system.
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b15
\b5
6
\b6.
\b.1
\b1.
\b.1
\b11
\b1.
\b. S
\bSe
\beg
\bgm
\bme
\ben
\bnt
\bte
\bed
\bd B
\bBo
\boo
\bot
\bt F
\bFi
\bil
\ble
\bes
\bs
If you are secondary for a lot of zones, you
may find it convenient to split your _
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\bb_
\bo_
\bo_
\bt
file into a static portion which hardly ever
changes (directives such as _
\bd_
\bi_
\br_
\be_
\bc_
\bt_
\bo_
\br_
\by, _
\bs_
\bo_
\br_
\bt_
\bl_
\bi_
\bs_
\bt,
_
\bx_
\bf_
\br_
\bn_
\be_
\bt_
\bs and _
\bc_
\ba_
\bc_
\bh_
\be could go here), and dynamic por-
tions that change frequently (all of your _
\bp_
\br_
\bi_
\bm_
\ba_
\br_
\by
directives might go in one file, and all of your
_
\bs_
\be_
\bc_
\bo_
\bn_
\bd_
\ba_
\br_
\by directives might go in another file --
and either or both of these might be fetched auto-
matically from some neighbor so that they can
change your list of secondary zones without requir-
ing your active intervention). You can accomplish
this via the _
\bi_
\bn_
\bc_
\bl_
\bu_
\bd_
\be directive, which takes just a
single file name as its argument. No quotes are
needed around the file name. The file name will be
evaluated after the name server has changed its
working directory to that specified in the _
\bd_
\bi_
\br_
\be_
\bc_
\b-
_
\bt_
\bo_
\br_
\by directive, so you can use relative pathnames
if your system supports them.
6
\b6.
\b.2
\b2.
\b. R
\bRe
\bes
\bso
\bol
\blv
\bve
\ber
\br C
\bCo
\bon
\bnf
\bfi
\big
\bgu
\bur
\bra
\bat
\bti
\bio
\bon
\bn
The resolver will try to contact a nameserver on
the localhost if it cannot find its configuration
file. You should install the configuration file on
every host anyway, since you can list the local host's
address if the localhost runs a nameserver, and there
is no other recommended way to specify a system-level
default domain. Note that if you wish to list the
local host in your resolver configuration file, you
should probably use its primary Internet address
rather than a localhost alias such as 127.0.0.1 or
0.0.0.0. This is due to a bug in the handling of con-
nected SOCK_DGRAM sockets in some versions of the BSD
networking code. If you must use an address-alias,
you should prefer 0.0.0.0 (or simply ``0'') over
127.0.0.1, though be warned that depending on the vin-
tage of your BSD-derived networking code, both of them
are capable of failing in their own ways.
The configuration file's name is
_
\b/_
\be_
\bt_
\bc_
\b/_
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\b._
\bc_
\bo_
\bn_
\bf. This file designates the name
servers on the network that should be sent queries.
It is considered reasonable to create this file even
if you run a local server, since its contents will be
cached by each client of the resolver library when the
client makes its first call to a resolver routine. If
you run a name server locally, list it in your
_
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\b._
\bc_
\bo_
\bn_
\bf file.
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b16
\b6 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
The _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\b._
\bc_
\bo_
\bn_
\bf file contains directives, one per
line, of the following forms:
domain _
\bl_
\bo_
\bc_
\ba_
\bl_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn
search _
\bs_
\be_
\ba_
\br_
\bc_
\bh_
\b-_
\bl_
\bi_
\bs_
\bt
nameserver _
\bs_
\be_
\br_
\bv_
\be_
\br_
\b-_
\ba_
\bd_
\bd_
\br_
\be_
\bs_
\bs
sortlist _
\bs_
\bo_
\br_
\bt_
\b-_
\bl_
\bi_
\bs_
\bt
The _
\bd_
\bo_
\bm_
\ba_
\bi_
\bn and _
\bs_
\be_
\ba_
\br_
\bc_
\bh directives should be given
exactly once. If the _
\bs_
\be_
\ba_
\br_
\bc_
\bh directive is given, the
first item in the given _
\bs_
\be_
\ba_
\br_
\bc_
\bh_
\b-_
\bl_
\bi_
\bs_
\bt will override any
previously-specified _
\bl_
\bo_
\bc_
\ba_
\bl_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn. The _
\bn_
\ba_
\bm_
\be_
\bs_
\be_
\br_
\bv_
\be_
\br
directive may be given up to three times; additional
_
\bn_
\ba_
\bm_
\be_
\bs_
\be_
\br_
\bv_
\be_
\br directives will be ignored. Comments may
be given by starting a line with a ``;
\b;'' or ``#
\b#'';
note that comments were not permitted in versions of
the resolver earlier than the one included with BIND
4.9 -- so if your vendor's resolver supports comments,
you know they are really on the ball.
The _
\bl_
\bo_
\bc_
\ba_
\bl_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn will be appended to any query-
name that does not contain a ``.
\b.''. _
\bl_
\bo_
\bc_
\ba_
\bl_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn can
be overridden on a per-process basis by setting the
LOCALDOMAIN environment variable. Note that _
\bl_
\bo_
\bc_
\ba_
\bl_
\b-
_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn processing can be disabled by setting an option
The _
\bs_
\be_
\ba_
\br_
\bc_
\bh_
\b-_
\bl_
\bi_
\bs_
\bt is a list of domains which are
tried, in order, as qualifying domains for query-names
which do not contain a ``.
\b.''. Note that _
\bs_
\be_
\ba_
\br_
\bc_
\bh_
\b-_
\bl_
\bi_
\bs_
\bt
processing can be disabled by setting an option in the
The _
\bs_
\be_
\br_
\bv_
\be_
\br_
\b-_
\ba_
\bd_
\bd_
\br_
\be_
\bs_
\bs's are aggregated and then used
as the default destination of queries generated
through the resolver. This is, in other words, the
way you tell the resolver which name servers it should
use. It is possible for a given client application to
override this list, and this is often done inside the
name server (which is itself a _
\br_
\be_
\bs_
\bo_
\bl_
\bv_
\be_
\br client) and in
test programs such as _
\bn_
\bs_
\bl_
\bo_
\bo_
\bk_
\bu_
\bp.
The _
\bs_
\bo_
\br_
\bt_
\b-_
\bl_
\bi_
\bs_
\bt is a list of IP address, netmask
pairs. Addresses returned by gethostbyname are sorted
tp the order specifed by this list. Any addresses
that do not match the address netmask pair will
returned after those that do. The netmask is optional
and the natural netmask will be used if not specified.
Finally, if the environment variable HOSTALIASES
is set, it is taken to contain the name of a file
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b17
\b7
which in turn contains resolver-level aliases. These
aliases are applied only to names which do not contain
any ``.
\b.'' characters, and they are applied to query-
names before the query is generated. Note that the
resolver options governing the operation of _
\bl_
\bo_
\bc_
\ba_
\bl_
\b-
_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn and _
\bs_
\be_
\ba_
\br_
\bc_
\bh_
\b-_
\bl_
\bi_
\bs_
\bt do not apply to HOSTALIASES.
6
\b6.
\b.3
\b3.
\b. C
\bCa
\bac
\bch
\bhe
\be I
\bIn
\bni
\bit
\bti
\bia
\bal
\bli
\biz
\bza
\bat
\bti
\bio
\bon
\bn
6
\b6.
\b.3
\b3.
\b.1
\b1.
\b. r
\bro
\boo
\bot
\bt.
\b.c
\bca
\bac
\bch
\bhe
\be
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.
6
\b6.
\b.3
\b3.
\b.2
\b2.
\b. n
\bna
\bam
\bme
\bed
\bd.
\b.l
\blo
\boc
\bca
\bal
\bl
This file specifies the _
\bP_
\bT_
\bR record for the
local loopback interface, better known as _
\bl_
\bo_
\bc_
\ba_
\bl_
\b-
_
\bh_
\bo_
\bs_
\bt, whose network address is 127.0.0.1. The
location of this file is specified in the boot
file. It is vitally important to the proper opera-
tion of every name server that the 127.0.0.1
address have a _
\bP_
\bT_
\bR record pointing back to the name
``l
\blo
\boc
\bca
\bal
\blh
\bho
\bos
\bst
\bt.
\b._
\bm_
\by_
\b._
\bd_
\bo_
\bm_
\b._
\ba_
\bi_
\bn''. The name of this _
\bP_
\bT_
\bR
record is always ``1
\b1.
\b.0
\b0.
\b.0
\b0.
\b.1
\b12
\b27
\b7.
\b.I
\bIN
\bN-
\b-A
\bAD
\bDD
\bDR
\bR.
\b.A
\bAR
\bRP
\bPA
\bA''. This
is neccessary if you want your users to be able to
use hostname-authentication (_
\bh_
\bo_
\bs_
\bt_
\bs_
\b._
\be_
\bq_
\bu_
\bi_
\bv or
_
\b~_
\b/_
\b._
\br_
\bh_
\bo_
\bs_
\bt_
\bs) on the name ``l
\blo
\boc
\bca
\bal
\blh
\bho
\bos
\bst
\bt''. As implied
by this _
\bP_
\bT_
\bR record, there should be an _
\bA record in
your domain specifying that ``l
\blo
\boc
\bca
\bal
\bl-
\b-
h
\bho
\bos
\bst
\bt.
\b._
\bm_
\by_
\b._
\bd_
\bo_
\bm_
\b._
\ba_
\bi_
\bn'' has the Internet address
6
\b6.
\b.4
\b4.
\b. D
\bDo
\bom
\bma
\bai
\bin
\bn D
\bDa
\bat
\bta
\ba F
\bFi
\bil
\ble
\bes
\bs
There are two standard files for specifying the
data for a domain. These are _
\bh_
\bo_
\bs_
\bt_
\bs and _
\bh_
\bo_
\bs_
\bt_
\b._
\br_
\be_
\bv.
These files use the Standard Resource Record Format
covered later in this paper. Note that the file names
are arbitrary; many network administrators prefer to
name their zone files after the domains they contain,
especially in the average case which is where a given
server is primary and/or secondary for many different
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b18
\b8 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
6
\b6.
\b.4
\b4.
\b.1
\b1.
\b. h
\bho
\bos
\bst
\bts
\bs
This file contains all the data about the
machines in this zone. The location of this file
is specified in the boot file.
6
\b6.
\b.4
\b4.
\b.2
\b2.
\b. h
\bho
\bos
\bst
\bts
\bs.
\b.r
\bre
\bev
\bv
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 speci-
fied 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 natu-
ral grouping of hosts in a network.
6
\b6.
\b.5
\b5.
\b. S
\bSt
\bta
\ban
\bnd
\bda
\bar
\brd
\bd R
\bRe
\bes
\bso
\bou
\bur
\brc
\bce
\be R
\bRe
\bec
\bco
\bor
\brd
\bd F
\bFo
\bor
\brm
\bma
\bat
\bt
The records in the name server data files are
called resource records. The Standard Resource Record
Format (RR) is specified in RFC1035. The following is
a general description of these records:
_
\b{_
\bn_
\ba_
\bm_
\be_
\b} _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\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 all
RR's other than the first in a file, 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; currently, only one class
is supported: _
\bI_
\bN for internet addresses and other
internet information. Limited support is included for
the _
\bH_
\bS class, which is for MIT/Athena ``Hesiod''
information. 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
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-1
\b19
\b9
T
\bTh
\bhe
\be f
\bfo
\bol
\bll
\blo
\bow
\bwi
\bin
\bng
\bg c
\bch
\bha
\bar
\bra
\bac
\bct
\bte
\ber
\brs
\bs h
\bha
\bav
\bve
\be s
\bsp
\bpe
\bec
\bci
\bia
\bal
\bl m
\bme
\bea
\ban
\bni
\bin
\bng
\bgs
\bs:
\b:
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.
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.
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 rec-
ognized within parentheses.
Semicolon starts a comment; the remainder of the
An asterisk signifies wildcarding. Note that
this is just another data character whose special
meaning comes about only during internal name
server search operations. Wildcarding is only
meaningful for some RR types (notably _
\bM_
\bX), and
then only in the name field -- not in the data
Anywhere a name appears -- either in the name
field or in some data field defined to contain names
-- the current origin will be appended if the name
does not end in a ``.
\b.''. 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 the domain for which you are creating
the data file, end the name with a ``.
\b.''.
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b20
\b0 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
6
\b6.
\b.5
\b5.
\b.1
\b1.
\b. $
\b$I
\bIN
\bNC
\bCL
\bLU
\bUD
\bDE
\bE
An include line begins with $INCLUDE, starting
in column 1, and is followed by a file name, and,
optionally, by a new temporary $ORIGIN to be used
while reading this file. This feature is particu-
larly useful for separating different types of data
into multiple files. An example would be:
$INCLUDE /usr/local/adm/named/data/mail-exchangers
The line would be interpreted as a request to load
the file _
\b/_
\bu_
\bs_
\br_
\b/_
\bn_
\ba_
\bm_
\be_
\bd_
\b/_
\bd_
\ba_
\bt_
\ba_
\b/_
\bm_
\ba_
\bi_
\bl_
\b-_
\be_
\bx_
\bc_
\bh_
\ba_
\bn_
\bg_
\be_
\br_
\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 primary zone to be orga-
nized in separate files. Not even the ``temporary
$ORIGIN'' feature described above is sufficient to
cause your data to branch out into some other zone
-- zone boundaries can only be introduced in the
6
\b6.
\b.5
\b5.
\b.2
\b2.
\b. `
\b``
\b`$
\b$O
\bOR
\bRI
\bIG
\bGI
\bIN
\bN'
\b''
\b'
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 seems like it
could be useful for putting more then one zone into
a data file, but that's not how it works. The name
server fundamentally requires that a given zone map
entirely to some specific file. You should there-
fore be very careful to use $ORIGIN only once at
the top of a file, or, within a file, to change to
a ``lower'' domain in the zone -- never to some
6
\b6.
\b.5
\b5.
\b.3
\b3.
\b. S
\bSO
\bOA
\bA -
\b- S
\bSt
\bta
\bar
\brt
\bt O
\bOf
\bf A
\bAu
\but
\bth
\bho
\bor
\bri
\bit
\bty
\by
_
\bn_
\ba_
\bm_
\be _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\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.
\b.Berkeley.
\b.Edu.
\b. kjd.
\b.ucbvax.
\b.Berkeley.
\b.Edu.
\b. (
The _
\bS_
\bt_
\ba_
\br_
\bt _
\bo_
\bf _
\bA_
\bu_
\bt_
\bh_
\bo_
\br_
\bi_
\bt_
\by_
\b, _
\bS_
\bO_
\bA_
\b, 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
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b21
\b1
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. Older
servers permitted the use of a phantom ``.'' in
this and other numbers in a zone file; the meaning
of n.m was ``n000m'' rather than the more intuitive
``n*1000+m'' (such that 1.234 translated to 1000234
rather than to 1234). This feature has been depre-
cated due to its obscurity, unpredictability, and
lack of neccessity. Note that using a ``YYYYM-
MDDNN'' notation you can still make 100 changes per
day until the year 4294. You should choose a nota-
tion that works for you. If you're a clever _
\bp_
\be_
\br_
\bl
programmer you could even use _
\bR_
\bC_
\bS version numbers
to help generate your zone serial numbers. The
refresh indicates how often, in seconds, the sec-
ondary name servers are to check with the primary
name server to see if an update is needed. The
retry indicates how long, in seconds, a secondary
server should wait before retrying a failed zone
transfer. 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
which do not specify one in the zone file. It is
also an enforced minimum on Time To Live if it is
specified on an RR. There should only be one _
\bS_
\bO_
\bA
6
\b6.
\b.5
\b5.
\b.4
\b4.
\b. N
\bNS
\bS -
\b- N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br
_
\b{_
\bn_
\ba_
\bm_
\be_
\b} _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\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.
\b.Berkeley.
\b.Edu.
\b.
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 name server for the domain, and every
domain should have at least two nameservers.
6
\b6.
\b.5
\b5.
\b.5
\b5.
\b. A
\bA -
\b- A
\bAd
\bdd
\bdr
\bre
\bes
\bss
\bs
_
\b{_
\bn_
\ba_
\bm_
\be_
\b} _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bA _
\ba_
\bd_
\bd_
\br_
\be_
\bs_
\bs
ucbarpa IN A 128.
\b.32.
\b.0.
\b.4
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
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b22
\b2 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
should be one _
\bA record for each address of the
6
\b6.
\b.5
\b5.
\b.6
\b6.
\b. H
\bHI
\bIN
\bNF
\bFO
\bO -
\b- H
\bHo
\bos
\bst
\bt I
\bIn
\bnf
\bfo
\bor
\brm
\bma
\bat
\bti
\bio
\bon
\bn
_
\b{_
\bn_
\ba_
\bm_
\be_
\b} _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bH_
\bI_
\bN_
\bF_
\bO _
\bH_
\ba_
\br_
\bd_
\bw_
\ba_
\br_
\be _
\bO_
\bS
_
\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
operating system that are running at the listed
host. If you want to include a space in the
machine name you must quote the name. There could
be one _
\bH_
\bI_
\bN_
\bF_
\bO record for each host, though for secu-
rity reasons most domains don't have any _
\bH_
\bI_
\bN_
\bF_
\bO
records at all. No application depends on them.
6
\b6.
\b.5
\b5.
\b.7
\b7.
\b. W
\bWK
\bKS
\bS -
\b- W
\bWe
\bel
\bll
\bl K
\bKn
\bno
\bow
\bwn
\bn S
\bSe
\ber
\brv
\bvi
\bic
\bce
\bes
\bs
_
\b{_
\bn_
\ba_
\bm_
\be_
\b} _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\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.
\b.32.
\b.0.
\b.10 UDP who route timed domain
IN WKS 128.
\b.32.
\b.0.
\b.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 _
\b/_
\be_
\bt_
\bc_
\b/_
\bs_
\be_
\br_
\bv_
\bi_
\bc_
\be_
\bs_
\b. There should be only
one _
\bW_
\bK_
\bS record per protocol per address. Note that
RFC 1123 says of _
\bW_
\bK_
\bS records:
2.2 Using Domain Name Service
An application SHOULD NOT rely on the ability to locate a WKS
record containing an accurate listing of all services at a
particular host address, since the WKS RR type is not often used
by Internet sites. To confirm that a service is present, simply
5.2.12 WKS Use in MX Processing: RFC-974, p. 5
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b23
\b3
RFC-974 [SMTP:3] recommended that the domain system be queried
for WKS ("Well-Known Service") records, to verify that each
proposed mail target does support SMTP. Later experience has
shown that WKS is not widely supported, so the WKS step in MX
processing SHOULD NOT be used.
6.1.3.6 Status of RR Types
The TXT and WKS RR types have not been widely used by
Internet sites; as a result, an application cannot rely
on the the existence of a TXT or WKS RR in most
6
\b6.
\b.5
\b5.
\b.8
\b8.
\b. C
\bCN
\bNA
\bAM
\bME
\bE -
\b- C
\bCa
\ban
\bno
\bon
\bni
\bic
\bca
\bal
\bl N
\bNa
\bam
\bme
\be
_
\ba_
\bl_
\bi_
\ba_
\bs_
\be_
\bs _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bC_
\bN_
\bA_
\bM_
\bE _
\bC_
\ba_
\bn_
\bo_
\bn_
\bi_
\bc_
\ba_
\bl _
\bn_
\ba_
\bm_
\be
The _
\bC_
\ba_
\bn_
\bo_
\bn_
\bi_
\bc_
\ba_
\bl _
\bN_
\ba_
\bm_
\be resource record, _
\bC_
\bN_
\bA_
\bM_
\bE, speci-
fies an alias or nickname for the official, or
canonical, host name. This record should be the
only one associated with the alias name. All other
resource records should be associated with the
canonical name, not with the nickname. Any
resource records that include a domain name as
their value (e.g., NS or MX) _
\bm_
\bu_
\bs_
\bt list the canoni-
cal name, not the nickname.
Nicknames are also useful when a host changes
its name. In that case, it is usually a good idea
to have a _
\bC_
\bN_
\bA_
\bM_
\bE record so that people still using
the old name will get to the right place.
6
\b6.
\b.5
\b5.
\b.9
\b9.
\b. P
\bPT
\bTR
\bR -
\b- D
\bDo
\bom
\bma
\bai
\bin
\bn N
\bNa
\bam
\bme
\be P
\bPo
\boi
\bin
\bnt
\bte
\ber
\br
_
\bn_
\ba_
\bm_
\be _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bP_
\bT_
\bR _
\br_
\be_
\ba_
\bl _
\bn_
\ba_
\bm_
\be
7.0 IN PTR monet.
\b.Berkeley.
\b.Edu.
\b.
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_
\b-_
\bA_
\bD_
\bD_
\bR.
\b._
\bA_
\bR_
\bP_
\bA domain. This line is from the example
_
\bh_
\bo_
\bs_
\bt_
\bs_
\b._
\br_
\be_
\bv file. _
\bP_
\bT_
\bR records are needed by the
_
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\bb_
\by_
\ba_
\bd_
\bd_
\br function. Note the trailing ``.
\b.''
which prevents BIND from appending the current
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b24
\b4 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
6
\b6.
\b.5
\b5.
\b.1
\b10
\b0.
\b. M
\bMX
\bX -
\b- M
\bMa
\bai
\bil
\bl E
\bEx
\bxc
\bch
\bha
\ban
\bng
\bge
\ber
\br
_
\bn_
\ba_
\bm_
\be _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\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_
\bx_
\bc_
\bh_
\ba_
\bn_
\bg_
\be_
\br
Munnari.
\b.OZ.
\b.AU.
\b. IN MX 0 Seismo.
\b.CSS.
\b.GOV.
\b.
*.
\b.IL.
\b. IN MX 0 RELAY.
\b.CS.
\b.NET.
\b.
_
\bM_
\ba_
\bi_
\bl _
\be_
\bX_
\bc_
\bh_
\ba_
\bn_
\bg_
\be_
\br records, _
\bM_
\bX, are used to specify a
list of hosts which are configured to receive mail
sent to this domain name. Every name which
receives mail should have an _
\bM_
\bX since if one is not
found at the time mail is being delivered, an _
\bM_
\bX
will be ``imputed'' with a cost of 0 and a destina-
tion of the host itself. If you want a host to
receive its own mail, you should create an _
\bM_
\bX for
your host's name, pointing at your host's name. It
is better to have this be explicit than to let it
be imputed by remote mailers. In the first exam-
ple, above, Seismo.
\b.CSS.
\b.GOV.
\b. is a mail gateway that
knows how to deliver mail to Munnari.
\b.OZ.
\b.AU.
\b.. 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. Note that lower numbers indicate higher
precedence, and that mailers are supposed to ran-
domize same-valued _
\bM_
\bX hosts so as to distribute the
load evenly if the costs are equal. See RFC 974
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
of RELAY.CS.NET. Wildcard _
\bM_
\bX records are not very
useful in practice, though, since once a mail mes-
sage gets to the gateway for a given domain it
still has to be routed _
\bw_
\bi_
\bt_
\bh_
\bi_
\bn that domain and it is
not currently possible to have an apparently-
different set of _
\bM_
\bX records inside and outside of a
domain. If you won't be needing any Mail Exchang-
ers inside your domain, go ahead and use a wild-
card. If you want to use both wildcard ``top-
level'' and specific ``interior'' _
\bM_
\bX records, note
that each specific record will have to ``end with''
a complete recitation of the same data that is car-
ried in the top-level record. This is because the
specific _
\bM_
\bX records will take precedence over the
top-level wildcard records, and must be able to
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b25
\b5
perform the top-level's if a given interior domain
is to be able to receive mail from outside the
gateway. Wildcard _
\bM_
\bX records are very subtle and
you should be careful with them.
6
\b6.
\b.5
\b5.
\b.1
\b11
\b1.
\b. T
\bTX
\bXT
\bT -
\b- T
\bTe
\bex
\bxt
\bt
_
\bn_
\ba_
\bm_
\be _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bT_
\bX_
\bT _
\bs_
\bt_
\br_
\bi_
\bn_
\bg
Munnari.
\b.OZ.
\b.AU.
\b. IN TXT "foo"
A _
\bT_
\bX_
\bT record contains free-form textual data. The
syntax of the text depends on the domain where it
is found; several systems use _
\bT_
\bX_
\bT records to encode
the local user database (_
\b/_
\be_
\bt_
\bc_
\b/_
\bp_
\ba_
\bs_
\bs_
\bw_
\bd) and other
administrative data. MIT Hesiod is one such sys-
tem, which, though it uses an addr-class of _
\bH_
\bS
rather than _
\bI_
\bN, implements its database with _
\bT_
\bX_
\bT
6
\b6.
\b.5
\b5.
\b.1
\b12
\b2.
\b. R
\bRP
\bP -
\b- R
\bRe
\bes
\bsp
\bpo
\bon
\bns
\bsi
\bib
\bbl
\ble
\be P
\bPe
\ber
\brs
\bso
\bon
\bn
_
\bo_
\bw_
\bn_
\be_
\br _
\b{_
\bt_
\bt_
\bl_
\b} _
\ba_
\bd_
\bd_
\br_
\b-_
\bc_
\bl_
\ba_
\bs_
\bs _
\bR_
\bP _
\bm_
\bb_
\bo_
\bx_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn_
\b-_
\bn_
\ba_
\bm_
\be _
\bT_
\bX_
\bT_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn_
\b-_
\bn_
\ba_
\bm_
\be
franklin IN RP ben.franklin.berkeley.edu. sysadmins.berkeley.edu.
The Responsible Person record, _
\bR_
\bP, identifies
the name or group name of the responsible person
for a host. Often it is desirable to be able to
identify the responsible entity for a particular
host. When that host is down or malfunctioning,
you would want to contact those parties who might
be able to repair the host.
The first field, _
\bm_
\bb_
\bo_
\bx_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn_
\b-_
\bn_
\ba_
\bm_
\be, is a domain
name that specifies the mailbox for the responsible
person. Its format in master files uses the DNS
convention for mailbox encoding, identical to that
used for the _
\bP_
\be_
\br_
\bs_
\bo_
\bn_
\b-_
\bi_
\bn_
\b-_
\bc_
\bh_
\ba_
\br_
\bg_
\be mailbox field in the
SOA record. In the example above, the mbox domain
name shows the encoding for
``<
\b<b
\bbe
\ben
\bn@
\b@f
\bfr
\bra
\ban
\bnk
\bkl
\bli
\bin
\bn.
\b.b
\bbe
\ber
\brk
\bke
\bel
\ble
\bey
\by.
\b.e
\bed
\bdu
\bu>
\b>''. The root domain
name (just ``.
\b.'') may be specified to indicate that
The second field, _
\bT_
\bX_
\bT_
\b-_
\bd_
\bo_
\bm_
\ba_
\bi_
\bn_
\b-_
\bn_
\ba_
\bm_
\be, is a domain
name for which _
\bT_
\bX_
\bT records exist. A subsequent
query can be performed to retrieve the associated
_
\bT_
\bX_
\bT resource records at _
\bT_
\bX_
\bT domain name. This pro-
vides a level of indirection so that the entity can
be referred to from multiple places in the DNS.
The root domain name (just ``.
\b.'') may be specified
for TXT domain name to indicate that no associated
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b26
\b6 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
_
\bT_
\bX_
\bT RR exists. In the example above, ``s
\bsy
\bys
\bsa
\bad
\bd-
\b-
m
\bmi
\bin
\bns
\bs.
\b.b
\bbe
\ber
\brk
\bke
\bel
\ble
\bey
\by.
\b.e
\bed
\bdu
\bu.
\b.'' is the name of a TXT record
that might contain some text with names and phone
The format of the _
\bR_
\bP record is class-
insensitive. Multiple _
\bR_
\bP records at a single name
may be present in the database, though they should
The _
\bR_
\bP record is still experimental; not all
name servers implement or recognize it.
6
\b6.
\b.6
\b6.
\b. D
\bDi
\bis
\bsc
\bcu
\bus
\bss
\bsi
\bio
\bon
\bn a
\bab
\bbo
\bou
\but
\bt t
\bth
\bhe
\be T
\bTT
\bTL
\bL
The Time To Live assigned to the records and to
the zone via the Minimum field in the SOA record is
very important. High values will lead to lower BIND
network traffic and faster response time. Lower values
will tend to generate lots of requests but will allow
faster propagation of changes.
Only changes and deletions from the zone are
affected by the TTLs. Additions propagate according
to the Refresh value in the SOA.
Experience has shown that sites use default TTLs
for their zones varying from around 0.5 day to around
7 days. You may wish to consider boosting the default
TTL shown in former versions of this guide from one
day (86400 seconds) to three days (259200 seconds).
This will drastically reduce the number of requests
made to your name servers.
If you need fast propagation of changes and dele-
tions, it might be wise to reduce the Minimum field a
few days before the change, then do the modification
itself and augment the TTL to its former value.
If you know that your zone is pretty stable (you
mainly add new records without changing regularly old
ones) then you may even wish to consider a TTL higher
Note that in any case, it makes no sense to have
records with a TTL below the SOA Refresh delay, as
Delay is the time required for secondaries to get a
copy of the newly modified zone.
6
\b6.
\b.7
\b7.
\b. S
\bSa
\bam
\bmp
\bpl
\ble
\be F
\bFi
\bil
\ble
\bes
\bs
The following section contains sample files for
the name server. This covers example boot files for
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b27
\b7
the different types of servers and example domain data
6
\b6.
\b.7
\b7.
\b.1
\b1.
\b. B
\bBo
\boo
\bot
\bt F
\bFi
\bil
\ble
\bes
\bs
6
\b6.
\b.7
\b7.
\b.1
\b1.
\b.1
\b1.
\b. P
\bPr
\bri
\bim
\bma
\bar
\bry
\by S
\bSe
\ber
\brv
\bve
\ber
\br
; Boot file for Primary Name Server
; type domain source file or host
directory /usr/local/adm/named
primary Berkeley.
\b.Edu ucbhosts
primary 32.
\b.128.
\b.in-addr.
\b.arpa ucbhosts.
\b.rev
primary 0.
\b.0.
\b.127.
\b.in-addr.
\b.arpa named.
\b.local
6
\b6.
\b.7
\b7.
\b.1
\b1.
\b.2
\b2.
\b. S
\bSe
\bec
\bco
\bon
\bnd
\bda
\bar
\bry
\by S
\bSe
\ber
\brv
\bve
\ber
\br
; Boot file for Secondary Name Server
; type domain source file or host
directory /usr/local/adm/named
secondary Berkeley.
\b.Edu 128.
\b.32.
\b.0.
\b.4 128.
\b.32.
\b.0.
\b.10 ucbhosts.bak
secondary 32.
\b.128.
\b.in-addr.
\b.arpa 128.
\b.32.
\b.0.
\b.4 128.
\b.32.
\b.0.
\b.10 ucbhosts.rev.bak
primary 0.
\b.0.
\b.127.
\b.in-addr.
\b.arpa named.
\b.local
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b28
\b8 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
6
\b6.
\b.7
\b7.
\b.1
\b1.
\b.3
\b3.
\b. C
\bCa
\bac
\bch
\bhi
\bin
\bng
\bg O
\bOn
\bnl
\bly
\by S
\bSe
\ber
\brv
\bve
\ber
\br
; Boot file for Caching Only Name Server
; type domain source file or host
directory /usr/local/adm/named
primary 0.
\b.0.
\b.127.
\b.in-addr.
\b.arpa named.
\b.local
6
\b6.
\b.7
\b7.
\b.2
\b2.
\b. R
\bRe
\bem
\bmo
\bot
\bte
\be S
\bSe
\ber
\brv
\bve
\ber
\br /
\b/ D
\bDN
\bNS
\bS C
\bCl
\bli
\bie
\ben
\bnt
\bt
6
\b6.
\b.7
\b7.
\b.2
\b2.
\b.1
\b1.
\b. /
\b/e
\bet
\btc
\bc/
\b/r
\bre
\bes
\bso
\bol
\blv
\bv.
\b.c
\bco
\bon
\bnf
\bf
nameserver 128.
\b.32.
\b.0.
\b.4
nameserver 128.
\b.32.
\b.0.
\b.10
sortlist 130.155.160.0/255.255.240.0 130.155.0.0
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-2
\b29
\b9
6
\b6.
\b.7
\b7.
\b.3
\b3.
\b. r
\bro
\boo
\bot
\bt.
\b.c
\bca
\bac
\bch
\bhe
\be
; Initial cache data for root domain servers.
; This data was current as of April 15, 1993. The official and current
; version is always available from via anonymous FTP from RS.INTERNIC.NET
; as /domain/named.cache.
; Thanks to Long-Morrow@CS.Yale.EDU for providing this update.
.
\b. 99999999 IN NS NS.
\b.NIC.
\b.DDN.
\b.MIL.
\b.
99999999 IN NS NS.
\b.NASA.
\b.GOV.
\b.
99999999 IN NS KAVA.
\b.NISC.
\b.SRI.
\b.COM.
\b.
99999999 IN NS TERP.
\b.UMD.
\b.EDU.
\b.
99999999 IN NS AOS.
\b.ARL.
\b.ARMY.
\b.MIL.
\b.
99999999 IN NS C.
\b.NYSER.
\b.NET.
\b.
99999999 IN NS NIC.
\b.NORDU.
\b.NET.
\b.
99999999 IN NS NS.
\b.INTERNIC.
\b.NET.
\b.
; Prep the cache (hotwire the addresses).
\b.
NS.
\b.NIC.
\b.DDN.
\b.MIL.
\b. 99999999 IN A 192.
\b.112.
\b.36.
\b.4
NS.
\b.NASA.
\b.GOV.
\b. 99999999 IN A 128.
\b.102.
\b.16.
\b.10
NS.
\b.NASA.
\b.GOV.
\b. 99999999 IN A 192.
\b.52.
\b.195.
\b.10
KAVA.
\b.NISC.
\b.SRI.
\b.COM.
\b. 99999999 IN A 192.
\b.33.
\b.33.
\b.24
AOS.
\b.ARL.
\b.ARMY.
\b.MIL.
\b. 99999999 IN A 128.
\b.63.
\b.4.
\b.82
AOS.
\b.ARL.
\b.ARMY.
\b.MIL.
\b. 99999999 IN A 192.
\b.5.
\b.25.
\b.82
C.
\b.NYSER.
\b.NET.
\b. 99999999 IN A 192.
\b.33.
\b.4.
\b.12
TERP.
\b.UMD.
\b.EDU.
\b. 99999999 IN A 128.
\b.8.
\b.10.
\b.90
NIC.
\b.NORDU.
\b.NET.
\b. 99999999 IN A 192.
\b.36.
\b.148.
\b.17
NS.
\b.INTERNIC.
\b.NET.
\b. 99999999 IN A 198.
\b.41.
\b.0.
\b.4
6
\b6.
\b.7
\b7.
\b.4
\b4.
\b. n
\bna
\bam
\bme
\bed
\bd.
\b.l
\blo
\boc
\bca
\bal
\bl
@ IN SOA ucbvax.
\b.Berkeley.
\b.Edu. kjd.
\b.ucbvax.
\b.Berkeley.
\b.Edu.
\b. (
IN NS ucbvax.
\b.Berkeley.
\b.Edu.
\b. ; pedantic
1 IN PTR localhost.
\b.Berkeley.
\b.Edu.
\b.
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b30
\b0 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
6
\b6.
\b.7
\b7.
\b.5
\b5.
\b. H
\bHo
\bos
\bst
\bts
\bs
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b31
\b1
; @(#)ucb-hosts 1.2 (berkeley) 88/02/05
@ IN SOA ucbvax.
\b.Berkeley.
\b.Edu.
\b. kjd.
\b.monet.
\b.Berkeley.
\b.Edu.
\b. (
IN NS ucbarpa.
\b.Berkeley.
\b.Edu.
\b.
IN NS ucbvax.
\b.Berkeley.
\b.Edu.
\b.
; note that 127.1 is the same as 127.0.0.1; see inet(3n)
ucbarpa IN A 128.
\b.32.
\b.4
ernie IN A 128.
\b.32.
\b.6
monet IN A 128.
\b.32.
\b.7
IN A 128.
\b.32.
\b.130.
\b.6
ucbvax IN A 10.
\b.2.
\b.0.
\b.78
; 128.32.10 means 128.32.0.10; see inet(3n)
; HINFO and WKS are widely unused,
; but we'll show them as examples.
IN WKS 128.32.0.10 TCP ( echo telnet
toybox IN A 128.
\b.32.
\b.131.
\b.119
toybox IN MX 0 monet.Berkeley.Edu.
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b32
\b2 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
6
\b6.
\b.7
\b7.
\b.6
\b6.
\b. h
\bho
\bos
\bst
\bt.
\b.r
\bre
\bev
\bv
; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05
@ IN SOA ucbvax.
\b.Berkeley.
\b.Edu.
\b. kjd.
\b.monet.
\b.Berkeley.
\b.Edu.
\b. (
IN NS ucbarpa.
\b.Berkeley.
\b.Edu.
\b.
IN NS ucbvax.
\b.Berkeley.
\b.Edu.
\b.
0.
\b.0 IN PTR Berkeley-net.
\b.Berkeley.
\b.EDU.
\b.
IN A 255.
\b.255.
\b.255.
\b.0
0.
\b.130 IN PTR csdiv-net.
\b.Berkeley.
\b.EDU.
\b.
4.
\b.0 IN PTR ucbarpa.
\b.Berkeley.
\b.Edu.
\b.
6.
\b.0 IN PTR ernie.
\b.Berkeley.
\b.Edu.
\b.
7.
\b.0 IN PTR monet.
\b.Berkeley.
\b.Edu.
\b.
10.
\b.0 IN PTR ucbvax.
\b.Berkeley.
\b.Edu.
\b.
6.
\b.130 IN PTR monet.
\b.Berkeley.
\b.Edu.
\b.
7
\b7.
\b. D
\bDo
\bom
\bma
\bai
\bin
\bn M
\bMa
\ban
\bna
\bag
\bge
\bem
\bme
\ben
\bnt
\bt
This section contains information for starting, con-
trolling and debugging _
\bn_
\ba_
\bm_
\be_
\bd.
7
\b7.
\b.1
\b1.
\b. /
\b/e
\bet
\btc
\bc/
\b/r
\brc
\bc.
\b.l
\blo
\boc
\bca
\bal
\bl
The hostname should be set to the full domain
style name in _
\b/_
\be_
\bt_
\bc_
\b/_
\br_
\bc_
\b._
\bl_
\bo_
\bc_
\ba_
\bl using _
\bh_
\bo_
\bs_
\bt_
\bn_
\ba_
\bm_
\be_
\b(_
\b1_
\b). The
following entry should be added to _
\b/_
\be_
\bt_
\bc_
\b/_
\br_
\bc_
\b._
\bl_
\bo_
\bc_
\ba_
\bl to
start up _
\bn_
\ba_
\bm_
\be_
\bd at system boot time:
_
\bi_
\bf _
\b[ _
\b-_
\bf _
\b/_
\be_
\bt_
\bc_
\b/_
\bn_
\ba_
\bm_
\be_
\bd _
\b]_
\b; _
\bt_
\bh_
\be_
\bn
_
\b/_
\be_
\bt_
\bc_
\b/_
\bn_
\ba_
\bm_
\be_
\bd [options] _
\b& _
\be_
\bc_
\bh_
\bo _
\b-_
\bn _
\b' _
\bn_
\ba_
\bm_
\be_
\bd_
\b' _
\b>_
\b/_
\bd_
\be_
\bv_
\b/_
\bc_
\bo_
\bn_
\bs_
\bo_
\bl_
\be
This usually directly follows the lines that start
_
\bs_
\by_
\bs_
\bl_
\bo_
\bg_
\bd. D
\bDo
\bo N
\bNo
\bot
\bt 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 the cache.
7
\b7.
\b.2
\b2.
\b. /
\b/e
\bet
\btc
\bc/
\b/n
\bna
\bam
\bme
\bed
\bd.
\b.p
\bpi
\bid
\bd
When _
\bn_
\ba_
\bm_
\be_
\bd is successfully started up it writes
its process id into the file _
\b/_
\be_
\bt_
\bc_
\b/_
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\bp_
\bi_
\bd. This is
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b33
\b3
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.
7
\b7.
\b.3
\b3.
\b. /
\b/e
\bet
\btc
\bc/
\b/h
\bho
\bos
\bst
\bts
\bs
The _
\bg_
\be_
\bt_
\bh_
\bo_
\bs_
\bt_
\bb_
\by_
\bn_
\ba_
\bm_
\be_
\b(_
\b) 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 _
\b/_
\be_
\bt_
\bc_
\b/_
\bh_
\bo_
\bs_
\bt_
\bs to resolve an
address. This option was added to allow _
\bi_
\bf_
\bc_
\bo_
\bn_
\bf_
\bi_
\bg_
\b(_
\b8_
\bC_
\b)
to configure the machines local interfaces and to
enable a system manager to access the network while
the system is in single user mode. It is advisable to
put the local machines interface addresses and a cou-
ple of machine names and address in _
\b/_
\be_
\bt_
\bc_
\b/_
\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
_
\b/_
\be_
\bt_
\bc_
\b/_
\bh_
\bo_
\bs_
\bt_
\bs has not changed. See _
\bh_
\bo_
\bs_
\bt_
\bs_
\b(_
\b5_
\b) for more
information. Since the process of reading _
\b/_
\be_
\bt_
\bc_
\b/_
\bh_
\bo_
\bs_
\bt_
\bs
is slow, it is not advisable to use this option when
the system is in multi user mode.
7
\b7.
\b.4
\b4.
\b. S
\bSi
\big
\bgn
\bna
\bal
\bls
\bs
There are several signals that can be sent to the
_
\bn_
\ba_
\bm_
\be_
\bd process to have it do tasks without restarting
7
\b7.
\b.4
\b4.
\b.1
\b1.
\b. R
\bRe
\bel
\blo
\boa
\bad
\bd
SIGHUP - Causes _
\bn_
\ba_
\bm_
\be_
\bd to read _
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\bb_
\bo_
\bo_
\bt and
reload the database. This is useful when you have
made a change to a ``primary'' data file and you
want _
\bn_
\ba_
\bm_
\be_
\bd's internal database to reflect the
change. If you build BIND with the FORCED_RELOAD
option, then SIGHUP also has the effect of schedul-
ing all ``secondary'' zones for serial-number
checks, which could lead to zone transfers ahead of
the usual schedule. Normally serial-number com-
pares are done only at the intervals specified in
7
\b7.
\b.4
\b4.
\b.2
\b2.
\b. D
\bDe
\beb
\bbu
\bug
\bgg
\bgi
\bin
\bng
\bg
When _
\bn_
\ba_
\bm_
\be_
\bd is running incorrectly, look first
in _
\b/_
\bv_
\ba_
\br_
\b/_
\bl_
\bo_
\bg_
\b/_
\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
what is happening. Unless you run it with the
``-d'' option, _
\bn_
\ba_
\bm_
\be_
\bd has very little to say on its
standard output or standard error. Everything
_
\bn_
\ba_
\bm_
\be_
\bd has to say, it says to _
\bs_
\by_
\bs_
\bl_
\bo_
\bg.
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b34
\b4 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
SIGINT - Dumps the current data base and cache
to _
\b/_
\bv_
\ba_
\br_
\b/_
\bt_
\bm_
\bp_
\b/_
\bn_
\ba_
\bm_
\be_
\bd_
\b__
\bd_
\bu_
\bm_
\bp_
\b._
\bd_
\bb This should give you an
indication to whether the data base was loaded cor-
rectly. 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_
\bo_
\bt_
\be_
\b: the following two signals only work when
_
\bn_
\ba_
\bm_
\be_
\bd is built with _
\bD_
\bE_
\bB_
\bU_
\bG defined.
SIGUSR1 - Turns on debugging. Each following
USR1 increments the debug level. The output goes
to _
\b/_
\bv_
\ba_
\br_
\b/_
\bt_
\bm_
\bp_
\b/_
\bn_
\ba_
\bm_
\be_
\bd_
\b._
\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 _
\b/_
\bl_
\bi_
\bb_
\b/_
\bl_
\bi_
\bb_
\bc_
\b._
\ba.
SIGWINCH - Toggles tracing of all incoming
queries if _
\bn_
\ba_
\bm_
\be_
\bd has been compiled with _
\bQ_
\bR_
\bY_
\bL_
\bO_
\bG
defined. The trace is sent to syslog, and is huge,
but it is very useful for tracking down problems.
To run with tracing of all queries specify the _
\b-_
\bq
flag on the command line. If you routinely log
queries you will probably want to analyze the
results using the dnsstats stats script in the con-
A
\bAC
\bCK
\bKN
\bNO
\bOW
\bWL
\bLE
\bED
\bDG
\bGE
\bEM
\bME
\bEN
\bNT
\bTS
\bS
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
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b35
\b5
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 Corpo-
Update for the 4.9 release: the alpha-test group was
extremely helpful in furnishing improvements, finding and
repairing bugs, and being patient. I would like to express
special thanks to Brian Reid for funding this work. Robert
Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Par-
tan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat
Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis,
Christophe Wolfhugel, and a cast of dozens all helped out
above and beyond the call of duty. Special thanks to Phil
Almquist, who got the project started and contributed a lot
of the code and fixed several of the worst bugs. [
\b[ _
\bP_
\ba_
\bu_
\bl
_
\bV_
\bi_
\bx_
\bi_
\be_
\b, _
\bD_
\bE_
\bC_
\bW_
\bR_
\bL _
\ba_
\bn_
\bd _
\bD_
\bE_
\bC_
\bN_
\bS_
\bL_
\b, _
\bA_
\bp_
\br_
\bi_
\bl _
\b'_
\b9_
\b3 ]
\b].
S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b36
\b6 N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD
R
\bRE
\bEF
\bFE
\bER
\bRE
\bEN
\bNC
\bCE
\bES
\bS
[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_
\b. _
\bA_
\b._
\bC_
\b._
\bM_
\b. _
\b2_
\b5_
\b,
[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
[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 Cen-
ter, 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 Cen-
ter, 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.
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names
and Other Types." _
\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_
\b1_
\b0_
\b1 Network Information Center, SRI Interna-
tional, Menlo Park, California. April 1989.
[RFC1123] R. Braden, Editor, "Requirements for Internet
Hosts -- Application and Support" _
\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_
\b1_
\b2_
\b3 Network Information Center, SRI
International, Menlo Park, California. October
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and Mock-
apetris, P., "New DNS RR Definitions" _
\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_
\b1_
\b8_
\b3 Network Information
N
\bNa
\bam
\bme
\be S
\bSe
\ber
\brv
\bve
\ber
\br O
\bOp
\bpe
\ber
\bra
\bat
\bti
\bio
\bon
\bns
\bs G
\bGu
\bui
\bid
\bde
\be f
\bfo
\bor
\br B
\bBI
\bIN
\bND
\bD S
\bSM
\bMM
\bM:
\b:1
\b10
\b0-
\b-3
\b37
\b7
Center, SRI International, Menlo Park, California.
[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_
\b. 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 _
\b(_
\bB_
\bI_
\bN_
\bD_
\b) _
\bS_
\be_
\br_
\bv_
\be_
\br_
\bs_
\b.
UCB/CSD 84/177. University of California, Berke-
ley, Computer Science Division. May 1984.
Mockapetris, P., Dunlap, K, _
\bD_
\be_
\bv_
\be_
\bl_
\bo_
\bp_
\bm_
\be_
\bn_
\bt _
\bo_
\bf _
\bt_
\bh_
\be
_
\bD_
\bo_
\bm_
\ba_
\bi_
\bn _
\bN_
\ba_
\bm_
\be _
\bS_
\by_
\bs_
\bt_
\be_
\bm ACM Computer Communications
Review 18, 4:123-133. Proceedings ACM SIGCOMM '88
[Liu] Liu, C., Albitz, P., _
\bD_
\bN_
\bS _
\ba_
\bn_
\bd _
\bB_
\bI_
\bN_
\bD O'Reilly & Asso-
ciates, Sebastopol, CA, 502 pages, ISBN
projects / unix-history / blob