named (pronounced name-dee)
provides DNS on most Unix machines. It is a server program
originally developed for BSD to provide name service to clients, and
possibly to other name servers. BIND Version 4 was around for some
time and appeared in most Linux distributions. The new release,
Version 8, has been introduced in most Linux distributions, and is a
big change from previous versions.[1]
It has many new features, such as support for DNS dynamic updates, DNS
change notifications, much improved performance, and a new
configuration file syntax. Please check the documentation contained
in the source distribution for details.
This section requires some understanding of the way DNS works. If the
following discussion is all Greek to you, you may want to reread the
section Section 6.2."
named is usually
started at system boot time and runs until the machine goes down
again. Implementations of BIND prior to Version 8 take their
information from a configuration file called
/etc/named.boot and various files that map domain
names to addresses. The latter are called zone
files. Versions of BIND from Version 8 onwards use
/etc/named.conf in place of
/etc/named.boot.
To run named at the prompt, enter:
named will come up and read the named.boot
file and any zone files specified therein. It writes its process ID to
/var/run/named.pid in ASCII, downloads any zone files
from primary servers, if necessary, and starts listening on port 53 for DNS
queries.
The
BIND configuration file prior to Version 8 was very simple in
structure. BIND Version 8 has a very different configuration file
syntax to deal with many of the new features introduced. The name of
the configuration file changed from
/etc/named.boot, in older versions of BIND, to
/etc/named.conf in BIND Version 8. We'll focus
on configuring the older version because it is probably what most
distributions are still using, but we'll present an equivalent
named.conf to illustrate the differences, and
we'll talk about how to convert the old format into the new one.
The named.boot file is generally small and contains
little but pointers to master files containing zone information and
pointers to other name servers. Comments in the boot file start with the
(#) or (;) characters and extend to the next newline. Before we discuss
the format of named.boot in more detail, we will take a
look at the sample file for vlager
given in Example 6-8.
Example 6-8. The named.boot File for vlager
;
; /etc/named.boot file for vlager.vbrew.com
;
directory /var/named
;
; domain file
;-----------------
cache . named.ca
primary vbrew.com named.hosts
primary 0.0.127.in-addr.arpa named.local
primary 16.172.in-addr.arpa named.rev |
Let's look at each statement individually. The
directory keyword tells
named that all filenames referred to later in this file,
zone files for example, are located in the /var/named
directory. This saves a little typing.
The primary keyword shown in
this example loads information into named. This
information is taken from the master files specified as the last of
the parameters. These files represent DNS resource records, which we
will look at next.
In this example, we configured named as the primary
name server for three domains, as indicated by the three primary statements. The first of these
statements instructs named to act as a primary
server for vbrew.com, taking
the zone data from the file named.hosts.
The cache keyword is very special and
should be present on virtually all machines running a name server. It
instructs named to enable its cache and to load
the root name server hints from the cache file specified
(named.ca in our example). We will come back to the name
server hints in the following list.
Here's a list of the most important options you can use in
named.boot :
- directory
This
option specifies a directory in which zone files reside. Names of
files in other options may be given relative to this
directory. Several directories may be specified by repeatedly using
directory. The Linux file
system standard suggests this should be
/var/named.
- primary
This option takes a domain name and filename as an argument, declaring the local
server authoritative for the named domain. As a primary server,
named loads the zone information from the given master file.
There will always be at least one primary
entry in every boot file used for reverse mapping of network
127.0.0.0, which is the local
loopback network.
- secondary
This
statement takes a domain name, an address list, and a filename as an
argument. It declares the local server a secondary master server for
the specified domain.
A secondary server holds authoritative data on the domain, too, but it
doesn't gather it from files; instead, it tries to download it from
the primary server. The IP address of at least one primary server thus
must be given to named in the address list. The
local server contacts each of them in turn until it successfully
transfers the zone database, which is then stored in the backup file
given as the third argument. If none of the primary servers responds,
the zone data is retrieved from the backup file instead.
named then attempts to refresh the zone data at
regular intervals. This process is explained later in connection with
the SOA resource record type.
- cache
This option
takes a domain name and filename as arguments. This file contains
the root server hints, which is a list of records pointing to the root
name servers. Only NS and A records will be recognized. The
domain should be the root domain name, a
simple period (.).
This information is absolutely crucial to named; if
the cache statement does not
occur in the boot file, named will not develop a
local cache at all. This situation/lack of development will severely
degrade performance and increase network load if the next server
queried is not on the local net. Moreover, named
will not be able to reach any root name servers, and thus won't
resolve any addresses except those it is authoritative for. An
exception from this rule involves forwarding servers (see the
forwarders option that
follows).
- forwarders
This
statement takes a whitespace-separated list of addresses as an
argument. The IP addresses in this list specify a list of name
servers that named may query if it fails to resolve
a query from its local cache. They are tried in order until one of
them responds to the query. Typically, you would use the name server of
your network provider or another well-known server as a forwarder.
- slave
This
statement makes the name server a slave
server. It never performs recursive queries itself, but only forwards
them to servers specified in the forwarders statement.
There are two options that we will not describe here:
sortlist and
domain. Two other directives may also be
used inside these database files:
$INCLUDE and
$ORIGIN. Since they are rarely
needed, we will not describe them here, either.
BIND Version 8 introduced a range of new features, and with these came
a new configuration file syntax. The named.boot,
with its simple single line statements, was replaced by the
named.conf file, with a syntax like that of
gated and resembling C source syntax.
The new syntax is more complex, but fortunately a tool has been
provided that automates conversion from the old syntax to the new
syntax. In the BIND 8 source package, a
perl program called
named-bootconf.pl is provided that will read your
existing named.boot file from
stdin and convert it into the equivalent
named.conf format on
stdout. To use it, you must have the
perl interpreter installed.
You should use the script somewhat like this:
# cd /etc
# named-bootconf.pl <named.boot >named.conf |
The script then produces a
named.conf that looks
like that shown in
Example 6-9. We've cleaned out a few of
the helpful comments the script includes to help show the almost
direct relationship between the old and the new syntax.
Example 6-9. The BIND 8 equivalent named.conf File for vlager
//
// /etc/named.boot file for vlager.vbrew.com
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "vbrew.com" {
type master;
file "named.hosts";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "16.172.in-addr.arpa" {
type master;
file "named.rev";
}; |
If you take a close look, you will see that each of the one-line statements in
named.boot has been converted into a C-like statement
enclosed within { } characters in the
named.conf file.
The comments, which in the named.boot file were
indicated by a semicolon (;), are now indicated by two
forward slashes ( // ).
The directory statement has been
translated into an options paragraph
with a directory clause.
The cache and
primary statements have been converted
into zone paragraphs with
type clauses of
hint and
master, respectively.
The zone files do not need to be modified in any way; their syntax remains
unchanged.
The new configuration syntax allows for many new options that we
haven't covered here. If you'd like information on the new options,
the best source of information is the documentation supplied with the
BIND Version 8 source package.
Master
files included with named, like
named.hosts, always have a domain associated with
them, which is called the origin. This is the
domain name specified with the cache and primary options. Within a master file, you
are allowed to specify domain and host names relative to this
domain. A name given in a configuration file is considered
absolute if it ends in a single dot, otherwise it
is considered relative to the origin. The origin by itself may be
referred to using (@).
The
data contained in a master file is split up in resource
records (RRs). RRs are the smallest units of information
available through DNS. Each resource record has a type. A records, for
instance, map a hostname to an IP address, and a CNAME record
associates an alias for a host with its official hostname. To see an
example, look at Example 6-11, which shows the
named.hosts master file for the Virtual Brewery.
Resource record representations in master files share a
common format:
[domain] [ttl] [class] type rdata |
Fields are separated by spaces or tabs. An entry may be continued across
several lines if an opening brace occurs before the first newline and the
last field is followed by a closing brace. Anything between a semicolon and
a newline is ignored. A description of the format terms follows:
- domain
This term is the domain name to which the entry applies. If no domain name is
given, the RR is assumed to apply to the domain of the previous RR.
- ttl
In order to force resolvers to discard information after a certain time, each
RR is associated a time to live (ttl ). The
ttl field specifies the time in seconds that the
information is valid after it has been retrieved from the server. It is a
decimal number with at most eight digits.
If no ttl value is given, the field value defaults to that of the
minimum field of the preceding SOA record.
- class
This is an address class, like IN for IP addresses or HS for objects in the
Hesiod class. For TCP/IP networking, you have to specify IN.
If no class field is given, the class of the preceding RR is assumed.
- type
This describes the type of the RR. The most common types are A, SOA, PTR,
and NS. The following sections describe the various types of RRs.
- rdata
This holds the data associated with the RR. The format of this field
depends on the type of RR. In the following discussion, it will be
described for each RR separately.
The following is partial list of RRs to be used in DNS master files. There
are a couple more of them that we will not explain; they are experimental
and of little use, generally.
- SOA
This RR describes a zone of authority (SOA means “Start of Authority”).
It signals that the records following the SOA RR contain authoritative
information for the domain. Every master file included by a
primary statement must contain an SOA
record for this zone. The resource data contains the following fields:
- origin
This field is the canonical hostname of the primary name server for this domain.
It is usually given as an absolute name.
- contact
This field is the email address of the person responsible for maintaining the
domain, with the "@" sign replaced
by a dot. For instance, if the responsible person at the Virtual Brewery
were janet, this field would
contain janet.vbrew.com.
- serial
This field is the version number of the zone file, expressed as a single decimal
number. Whenever data is changed in the zone file, this number should be
incremented. A common convention is to use a number that reflects the date
of the last update, with a version number appended to it to cover the case
of multiple updates occurring on a single day, e.g., 2000012600 being update 00
that occurred on January 26, 2000.
The serial number is used by secondary name servers to recognize zone
information changes. To stay up to date, secondary servers request the
primary server's SOA record at certain intervals and compare the
serial number to that of the cached SOA record. If the number has
changed, the secondary servers transfer the whole zone database from
the primary server.
- refresh
This field specifies the interval in seconds that the secondary servers should wait
between checking the SOA record of the primary server. Again, this is a
decimal number with at most eight digits.
Generally, the network topology doesn't change too often, so this number
should specify an interval of roughly a day for larger networks, and even
more for smaller ones.
- retry
This number determines the intervals at which a secondary server should retry
contacting the primary server if a request or a zone refresh fails. It must
not be too low, or a temporary failure of the server or a network problem
could cause the secondary server to waste network resources. One hour, or
perhaps one-half hour, might be a good choice.
- expire
This field specifies the time in seconds after which a secondary server should
finally discard all zone data if it hasn't been able to contact the primary
server. You should normally set this field to at least a week (604,800 seconds), but
increasing it to a month or more is also reasonable.
- minimum
This field is the default ttl value for resource records that
do not explicitly contain one. The ttl value specifies
the maximum amount of time other name servers may keep the RR in their cache. This time applies only to normal lookups, and has nothing to do with the time after
which a secondary server should try to update the zone information.
If the topology of your network does not change frequently, a week or even
more is probably a good choice. If single RRs change more frequently, you could
still assign them smaller ttls individually. If your network changes frequently, you may want to set
minimum to one day (86,400 seconds).
- A
This record associates an IP address with a hostname. The resource data field
contains the address in dotted quad notation.
For each hostname, there must be only one A record. The hostname used in
this A record is considered the official or canonical
hostname. All other hostnames are aliases and must be mapped onto the
canonical hostname using a CNAME record. If the canonical name of
our host were vlager, we'd have
an A record that associated that hostname with its IP address. Since we may
also want another name associated with that address, say
news, we'd create a
CNAME record that associates this alternate name with the canonical name.
We'll talk more about CNAME records shortly.
- NS
NS records are used to specify a zone's primary server and all its secondary
servers. An NS record points to a master name server of the given zone, with
the resource data field containing the hostname of the name server.
You will meet NS records in two situations: The first situation is when you delegate
authority to a subordinate zone; the second is within the master zone database
of the subordinate zone itself. The sets of servers specified in both the
parent and delegated zones should match.
The NS record specifies the name of the primary and secondary name
servers for a zone. These names must be resolved to an address so they
can be used. Sometimes the servers belong to the domain they are
serving, which causes a “chicken and egg” problem; we
can't resolve the address until the name server is reachable, but we
can't reach the name server until we resolve its address. To solve
this dilemma, we can configure special A records directly into the
name server of the parent zone. The A records allow the name servers
of the parent domain to resolve the IP address of the delegated
zone name servers. These records are commonly called glue
records because they provide the “glue” that
binds a delegated zone to its parent.
- CNAME
This record associates an alias with a host's canonical
hostname. It provides an alternate name by which
users can refer to the host whose canonical name is supplied as a
parameter. The canonical hostname is the one the master file provides
an A record for; aliases are simply linked to that name by a CNAME
record, but don't have any other records of their own.
- PTR
This type of record is used to associate names in the
in-addr.arpa domain with hostnames.
It is used for reverse mapping of IP addresses to hostnames. The hostname
given must be the canonical hostname.
- MX
This RR announces a mail exchanger for a domain.
Mail exchangers are discussed in
Section 17.4.1.” The syntax of an MX record is:
[domain] [ttl] [class] MX preference host |
host names the mail exchanger for
domain. Every mail exchanger has an integer
preference associated with it. A mail transport
agent that wants to deliver mail to domain
tries all hosts who have an MX record for this domain until it succeeds.
The one with the lowest preference value is tried first, then the others, in
order of increasing preference value.
- HINFO
This record provides information on the system's hardware and software.
Its syntax is:
[domain] [ttl] [class] HINFO hardware software |
The hardware field identifies the hardware used by
this host. Special conventions are used to specify this. A list of valid
“machine names” is given in the Assigned Numbers RFC (RFC-1700).
If the field contains any blanks, it must be enclosed in double quotes. The
software field names the operating system software
used by the system. Again, a valid name from the Assigned Numbers RFC should
be chosen.
An HINFO record to describe an Intel-based Linux machine
should look something like:
tao 36500 IN HINFO IBM-PC LINUX2.2 |
and HINFO records for Linux running on Motorola 68000-based
machines might look like:
cevad 36500 IN HINFO ATARI-104ST LINUX2.0
jedd 36500 IN HINFO AMIGA-3000 LINUX2.0 |
There is a special type of named configuration
that we'll talk about before we explain how to build a full name
server configuration. It is called a
caching-only configuration. It doesn't really
serve a domain, but acts as a relay for all DNS queries produced on
your host. The advantage of this scheme is that it builds up a cache
so only the first query for a particular host is actually sent to the
name servers on the Internet. Any repeated request will be answered
directly from the cache in your local name server. This may not seem
useful yet, but it will when you are dialing in to the Internet, as
described in Chapter 7 and Chapter 8.
A named.boot file for a caching-only server looks like
this:
; named.boot file for caching-only server
directory /var/named
primary 0.0.127.in-addr.arpa named.local ; localhost network
cache . named.ca ; root servers |
In addition to this named.boot file, you must set
up the named.ca file with a valid list of root
name servers. You could copy and use Example 6-10 for this purpose. No other
files are needed for a caching-only server configuration.
Example 6-10,
Example 6-11,
Example 6-12, and
Example 6-13 give sample files for a name
server at the brewery, located on
vlager. Due to the nature of the
network discussed (a single LAN), the example is pretty straightforward.
The named.ca cache file shown in
Example 6-10 shows sample hint records for
a root name server. A typical cache file usually describes about a dozen name servers. You can obtain the current list of name servers for the root
domain using the nslookup tool described in the next
section.[2]
Example 6-10. The named.ca File
;
; /var/named/named.ca Cache file for the brewery.
; We're not on the Internet, so we don't need
; any root servers. To activate these
; records, remove the semicolons.
;
;. 3600000 IN NS A.ROOT-SERVERS.NET.
;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
;. 3600000 NS B.ROOT-SERVERS.NET.
;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
;. 3600000 NS C.ROOT-SERVERS.NET.
;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;. 3600000 NS D.ROOT-SERVERS.NET.
;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;. 3600000 NS E.ROOT-SERVERS.NET.
;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;. 3600000 NS F.ROOT-SERVERS.NET.
;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
;. 3600000 NS G.ROOT-SERVERS.NET.
;G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;. 3600000 NS H.ROOT-SERVERS.NET.
;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
;. 3600000 NS I.ROOT-SERVERS.NET.
;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;. 3600000 NS J.ROOT-SERVERS.NET.
;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10
;. 3600000 NS K.ROOT-SERVERS.NET.
;K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
;. 3600000 NS L.ROOT-SERVERS.NET.
;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12
;. 3600000 NS M.ROOT-SERVERS.NET.
;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
; |
Example 6-11. The named.hosts File
;
; /var/named/named.hosts Local hosts at the brewery
; Origin is vbrew.com
;
@ IN SOA vlager.vbrew.com. janet.vbrew.com. (
2000012601 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
;
; local mail is distributed on vlager
IN MX 10 vlager
;
; loopback address
localhost. IN A 127.0.0.1
;
; Virtual Brewery Ethernet
vlager IN A 172.16.1.1
vlager-if1 IN CNAME vlager
; vlager is also news server
news IN CNAME vlager
vstout IN A 172.16.1.2
vale IN A 172.16.1.3
;
; Virtual Winery Ethernet
vlager-if2 IN A 172.16.2.1
vbardolino IN A 172.16.2.2
vchianti IN A 172.16.2.3
vbeaujolais IN A 172.16.2.4
;
; Virtual Spirits (subsidiary) Ethernet
vbourbon IN A 172.16.3.1
vbourbon-if1 IN CNAME vbourbon |
Example 6-12. The named.local File
;
; /var/named/named.local Reverse mapping of 127.0.0
; Origin is 0.0.127.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
1 ; serial
360000 ; refresh: 100 hrs
3600 ; retry: one hour
3600000 ; expire: 42 days
360000 ; minimum: 100 hrs
)
IN NS vlager.vbrew.com.
1 IN PTR localhost. |
Example 6-13. The named.rev File
;
; /var/named/named.rev Reverse mapping of our IP addresses
; Origin is 16.172.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. joe.vbrew.com. (
16 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
; brewery
1.1 IN PTR vlager.vbrew.com.
2.1 IN PTR vstout.vbrew.com.
3.1 IN PTR vale.vbrew.com.
; winery
1.2 IN PTR vlager-if2.vbrew.com.
2.2 IN PTR vbardolino.vbrew.com.
3.2 IN PTR vchianti.vbrew.com.
4.2 IN PTR vbeaujolais.vbrew.com. |
nslookup is a great tool for checking the operation
of your name server setup. It can be used both interactively with
prompts and as a single command with immediate output. In the latter
case, you simply invoke it as:
nslookup queries the name server specified in
resolv.conf for hostname.
(If this file names more than one server, nslookup chooses
one at random.)
The interactive mode, however, is much more exciting. Besides looking up
individual hosts, you may query for any type of DNS record and transfer
the entire zone information for a domain.
When invoked without an argument, nslookup displays the name
server it uses and enters interactive mode. At the > prompt,
you may type any domain name you want to query. By default, it asks
for class A records, those containing the IP address relating to the
domain name.
You can look for record types by issuing:
in which type is one of the resource record names described
earlier, or ANY.
You might have the following nslookup session:
$ nslookup
Default Server: tao.linux.org.au
Address: 203.41.101.121
> metalab.unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
Name: metalab.unc.edu
Address: 152.2.254.81
> |
The output first displays the DNS server being queried, and then the result
of the query.
If you try to query for a name that has no IP address associated with it,
but other records were found in the DNS database, nslookup
returns with an error message saying
“No type A records found.” However, you can
make it query for records other than type A by issuing the
set type command. To get the SOA record of
unc.edu, you would issue:
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
*** No address (A) records available for unc.edu
> set type=SOA
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
unc.edu
origin = ns.unc.edu
mail addr = host-reg.ns.unc.edu
serial = 1998111011
refresh = 14400 (4H)
retry = 3600 (1H)
expire = 1209600 (2W)
minimum ttl = 86400 (1D)
unc.edu name server = ns2.unc.edu
unc.edu name server = ncnoc.ncren.net
unc.edu name server = ns.unc.edu
ns2.unc.edu internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1
ns.unc.edu internet address = 152.2.21.1 |
In a similar fashion, you can query for MX records:
> set type=MX
> unc.edu
Server: tao.linux.org.au
Address: 203.41.101.121
unc.edu preference = 0, mail exchanger = conga.oit.unc.edu
unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu
unc.edu name server = ns.unc.edu
unc.edu name server = ns2.unc.edu
unc.edu name server = ncnoc.ncren.net
conga.oit.unc.edu internet address = 152.2.22.21
imsety.oit.unc.edu internet address = 152.2.21.99
ns.unc.edu internet address = 152.2.21.1
ns2.unc.edu internet address = 152.2.253.100
ncnoc.ncren.net internet address = 192.101.21.1
ncnoc.ncren.net internet address = 128.109.193.1 |
Using a type of ANY returns all resource records associated with a given name.
A practical application of nslookup, besides debugging, is
to obtain the current list of root name servers. You can obtain this list by querying
for all NS records associated with the root domain:
> set type=NS
> .
Server: tao.linux.org.au
Address: 203.41.101.121
Non-authoritative answer:
(root) name server = A.ROOT-SERVERS.NET
(root) name server = H.ROOT-SERVERS.NET
(root) name server = B.ROOT-SERVERS.NET
(root) name server = C.ROOT-SERVERS.NET
(root) name server = D.ROOT-SERVERS.NET
(root) name server = E.ROOT-SERVERS.NET
(root) name server = I.ROOT-SERVERS.NET
(root) name server = F.ROOT-SERVERS.NET
(root) name server = G.ROOT-SERVERS.NET
(root) name server = J.ROOT-SERVERS.NET
(root) name server = K.ROOT-SERVERS.NET
(root) name server = L.ROOT-SERVERS.NET
(root) name server = M.ROOT-SERVERS.NET
Authoritative answers can be found from:
A.ROOT-SERVERS.NET internet address = 198.41.0.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
B.ROOT-SERVERS.NET internet address = 128.9.0.107
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
I.ROOT-SERVERS.NET internet address = 192.36.148.17
F.ROOT-SERVERS.NET internet address = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
J.ROOT-SERVERS.NET internet address = 198.41.0.10
K.ROOT-SERVERS.NET internet address = 193.0.14.129
L.ROOT-SERVERS.NET internet address = 198.32.64.12
M.ROOT-SERVERS.NET internet address = 202.12.27.33 |
To see the complete set of available commands, use the help
command in nslookup.
There are a few tools that can help you with your tasks as a BIND
administrator. We will briefly describe two of them here. Please refer to
the documentation that comes with these tools for more information on how
to use them.
hostcvt helps you
with your initial BIND configuration by converting your
/etc/hosts file into master files for
named. It generates both the forward (A) and
reverse mapping (PTR) entries, and takes care of aliases. Of course,
it won't do the whole job for you, as you may still want to tune the
timeout values in the SOA record, for example, or add MX
records. Still, it may help you save a few
aspirins. hostcvt is part of the BIND source, but
can also be found as a standalone package on a few Linux FTP servers.
After setting up your name server,
you may want to test your configuration. Some good tools
that make this job much simpler: the first is called
dnswalk, which is a Perl-based package. The second
is called nslint. They both walk your DNS database
looking for common mistakes and verify that the information they find
is consistent. Two other useful tools are host and
dig, which are general purpose DNS database query
tools. You can use these tools to manually inspect and diagnose DNS
database entries.
These tools are likely to be available in prepackaged form.
dnswalk and nslint are available
in source from https://www.visi.com/~barr/dnswalk/ and
ftp://ftp.ee.lbl.gov/nslint.tar.Z. The
host and dig source codes can be
found at ftp://ftp.nikhef.nl/pub/network/ and
ftp://ftp.is.co.za/networking/ip/dns/dig/.
