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 http://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/.
