Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

5.2. How DNS Works

DNS
organizes names in a domain hierarchy. A
domain is a collection of sites that are related
in some sensebecause they form a proper network (e.g., all
machines on a campus), because they all belong to a certain
organization (e.g., the U.S. government), or because
they're simply geographically close. For instance,
universities are commonly grouped in the edu domain, with each university or college
using a separate subdomain, below which their
s are subsumed. Groucho Marx University the groucho.edu domain, while the LAN of the
mathematics department is assigned maths.groucho.edu. Hosts on the departmental
network would have this domain name tacked onto their name, so
erdos would be known as erdos.maths.groucho.edu, which would be the
FQDN (see Section 4.1.2 in Chapter 4).

Figure 5-1 shows a
section of the namespace. The entry at the root of this tree, which
is denoted by a single dot, is quite appropriately called the
root domain and encompasses
all other domains. To indicate that a name is a FQDN, rather than
a name relative to some (implicit) local domain, it is sometimes
written with a trailing dot. This dot signifies that the
name's last component is the root domain. Depending
on its location in the name hierarchy, a domain may be called
top-level, second-level, or third-level. More levels of subdivision
occur, but they are rare. Table 5-1 lists several
top-level domains that you may see frequently.

Figure 5-1. A part of the domain namespace

Historically, the first four
of these were assigned to the U.S., but changes in policy have meant
that these domains, named global Top-Level Domains (gTLD), are now
considered global in nature. Recent negotiations to broaden the range
of gTLDs resulted in the last three additions. However, these new
options have so far proven to be quite unpopular.

Outside
the U.S., each country generally uses a top-level domain of its own
named after the two-letter country code defined in ISO-3166. Finland,
for instance, uses the fi domain;
fr is used by France, de by Germany, and aq by Antarctica. Below this top-level domain,
each country's NIC is free to organize names in
whatever way they want. Australia has second-level domains similar to
the international top-level domains, named com.au and edu.au. Other countries, such as Germany,
don't use this extra level, but have slightly long
names that refer directly to the organizations running a particular
domain. It's not uncommon to see names such as
Of course, these national domains
do not necessarily mean that a below that domain is actually
located in that country; it means only that the has been
registered with that country's NIC. A Swedish
manufacturer might have a branch in Australia and still have all its
s registered with the se
top-level domain.

This practice has become more popular in
recent years, with countries such as Tuvalu (tv) and Togo (to) selling TLDs to enterprising agents who
resell domain names such as go.to or
watch.tv.

Organizing the namespace in a hierarchy of
domain names nicely solves the problem of name uniqueness; with DNS,
a name has to be unique only within its domain to give it a name
different from all other s worldwide. Furthermore, fully
qualified names are easy to remember. Taken by themselves, these are
already very good reasons to split up a large domain into several
subdomains.

DNS does even
more for you than this. It also allows you to delegate authority over
a subdomain to its administrators. For example, the maintainers at
the Groucho Computing Center might create a subdomain for each
department; we already encountered the math and physics subdomains
above. When they find the network at the physics department too large
and chaotic to manage from outside (after all, physicists are known
to be an unruly bunch), they may simply pass control of the physics.groucho.edu domain to the
administrators of this network. These administrators are free to use
whatever names they like and assign them IP addresses from their
network in whatever fashion they desire, without outside
interference.

To this end, the namespace is split up
into zones, each rooted at a domain. Note the subtle difference
between a zone and a domain: the domain groucho.edu encompasses all s at Groucho
Marx University, while the zone groucho.edu includes only the s that are
managed by the Computing Center directlythose at the
mathematics department, for example. The s at the physics
department belong to a different zone, namely physics.groucho.edu. In Figure 5-1, the start of a zone is marked by a small
circle to the right of the domain name.

5.2.1. Name Lookups with DNS

At first glance, all this domain and zone
fuss seems to make name resolution an awfully complicated business.
After all, if no central authority controls what names are assigned
to which s, how is a humble application supposed to know?

Now comes the really ingenious part about DNS. If you want to find
the IP address of erdos, for
example, DNS says, "Go ask the people who manage it,
and they will tell you."

In fact, DNS is a giant distributed
database. It is implemented by so-called nameservers that supply
information on a given domain or set of domains. For each zone there
are at least two, or at most a few, nameservers that hold all
authoritative information on s in that zone. To obtain the IP
address of erdos, all you have to do
is contact the nameserver for the groucho.edu zone, which will then return the
desired data.

Easier
said than done, you might think. So how do I know how to reach the
nameserver at Groucho Marx University? In case your computer
isn't equipped with an address-resolving oracle, DNS
provides for this, too. When your application wants to look up
information on erdos, it contacts a
local nameserver, which conducts a so-called iterative query for it.
It starts off by sending a query to a nameserver for the root domain,
asking for the address of erdos.maths.groucho.edu. The root nameserver
recognizes that this name does not belong to its zone of authority,
but rather to one below the edu
domain. Thus, it tells you to contact an edu zone nameserver for more information and
encloses a list of all edu nameservers along with their addresses.
Your local nameserver will then go on and query one of those
for instance, a.isi.edu. In a manner
similar to the root nameserver, a.isi.edu knows that the groucho.edu people run a zone of their own and
points you to their servers. The local nameserver will then present
its query for erdos to one of these,
which will finally recognize the name as belonging to its zone and
return the corresponding IP address.

This looks like a lot of traffic for looking up a measly IP address,
but it's miniscule considering the speed of
networking today. There's still room for improvement
with this scheme, however.

To improve response time during future queries, the nameserver stores
the information obtained in its local cache. So the next time anyone
on your local network wants to look up the address of a in the
groucho.edu domain, your nameserver
will go directly to the groucho.edu
nameserver.[1]

[1] If information weren't
cached, DNS would be as inefficient as any other method because each
query would involve the root name servers.

Of course,
the nameserver will not keep this information forever; it will
discard it after some time. The expiration interval is called the
time to
live (ttl). Each datum in the DNS database is
assigned such a ttl by administrators of the responsible
zone.

5.2.2. Types of Nameservers

Nameservers that hold all
information on s within a zone are called
authoritative for this zone. Any query for a
within this zone will end up at one of these nameservers.

Authoritative servers must be fairly
well synchronized. Thus, the zone's network
administrator must make one the primary server,
which loads its zone information from datafiles, and make the others
secondary servers, which transfer the zone data
from the primary server at regular intervals.

Having several nameservers distributes workload; it also provides
backup. When one nameserver machine fails in a benign way, such as
crashing or losing its network connection, all queries fall back to
the other servers. Of course, this scheme doesn't
protect you from server malfunctions that produce wrong replies to
all DNS requests, such as from software bugs in the server program
itself.

You can also run a nameserver that is not
authoritative for any domain.[2] This is useful since the nameserver will still be able to
conduct DNS queries for the applications running on the local network
and cache the information. Hence, it is called a
caching-only server.

[2] Well, almost. A
nameserver has to provide at least name service for local and
reverse lookups of 127.0.0.1.

5.2.3. The DNS Database

We have
seen that DNS not only deals with IP addresses of s, but also
exchanges information on nameservers. DNS databases may have, in
fact, many different types of entries.

A single piece of information from the
DNS database is called a resource
record (RR). Each record has a type associated
with it describing the sort of data it represents, and a class
specifying the type of network it applies to. The latter accommodates
the needs of different addressing schemes, including IP addresses
(the IN class), Hesiod addresses (used by MIT's
Kerberos system), and a few more. The prototypical resource record
type is the A record, which associates a fully qualified domain name
with an IP address.

A may be known by more than one name.
For example you might have a server that provides both FTP and World
Wide Web servers, which you give two names: Example 5-3 shows a part of the
domain database that is loaded into the nameservers for the physics.groucho.edu zone.

Example 5-3. An excerpt from a BIND zone file for the physics department

; Authoritative Information on physics.groucho.edu.
$TTL 3D
@  IN  SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. {
2004010200       ; serial no
8H              ; refresh
2H              ; retry
4W              ; expire
1D               ; default ttl
}
;
; Name servers
IN    NS       niels
IN    NS       gauss.maths.groucho.edu.
gauss.maths.groucho.edu. IN A 149.76.4.23
;
; Theoretical Physics (subnet 12)
niels         IN    A        149.76.12.1
IN    A        149.76.1.12
nameserver    IN    CNAME    niels
otto          IN    A        149.76.12.2
quark         IN    A        149.76.12.4
down          IN    A        149.76.12.5
iowa          IN    AAAA     2001:30fa::3
strange       IN    A        149.76.12.6
...
; Collider Lab. (subnet 14)
boson         IN    A        149.76.14.1
muon          IN    A        149.76.14.7
bogon         IN    A        149.76.14.12
...

Apart from
the A and CNAME records, you can see a special record at the top of
the file, stretching several lines. This is the SOA resource record
signaling the Start of
Authority, which holds general information on
the zone that the server is authoritative for. The SOA record
comprises, for instance, the default time to live for all records.

Note that
all names in the sample file that do not end with a dot should be
interpreted relative to the physics.groucho.edu domain. The special name
(@) used in the SOA record refers to the domain
name by itself.

We have seen earlier that the
nameservers for the groucho.edu
domain somehow have to know about the physics zone so that they can point queries to
their nameservers. This is usually achieved by a pair of records: the
NS record that gives the server's FQDN, and an A
record that associates an address with that name. Since these records
are what holds the namespace together, they are frequently called
glue records. They are the
only instances of records in which a parent zone actually holds
information on s in the subordinate zone. The glue records
pointing to the nameservers for physics.groucho.edu are shown in Example 5-4.

Example 5-4. An excerpt from a zone file for GMU

; Zone data for the groucho.edu zone.
....
;
; Glue records for the physics.groucho.edu zone
physics        IN     NS        niels.physics.groucho.edu.
IN     NS        gauss.maths.groucho.edu.
niels.physics  IN     A         149.76.12.1
gauss.maths    IN     A         149.76.4.23
...

5.2.4. The BIND named.conf File

The
primary configuration file of BIND is
/etc/named.conf. This style of configuration
file has been in use by BIND since Version 8 replaced the old
named.boot file.

The syntax is somewhat complex and supports a wide range of
functions, but is fairly straightforward when configured to provide
basic functionality. Example 5-5 shows a simple
configuration file for the vbrew
domain.

Example 5-5. The BIND named.conf file for vlager

// This is the primary configuration file for the BIND DNS server named.
//
options {
directory "/var/cache/bind";
allow-query { any; };
recursion no;        
zone "local" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "vbrew.com" {
type master;
allow-transfer { 10.10.0.5; 
172.16.90.4; 
1.2.3.4;
};
file "/etc/bind/db.vbrew.com";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.0";
};

If you take a close look, you will see that each of the statements is
written similar to a C-like statement with attributes enclosed within
{ } characters in the
named.conf file.

The comments, often indicated by a pound
character (#) in Linux, are indicated by two forward slashes (//)
instead.

One of the most important
options in this configuration file is zone. This
is how you tell BIND what it's supposed to know.
Beneath zone is another very important option,
allow-transfer. This option allows you to set the
IP addresses permitted to perform a zone transfer. It is important to
restrict this to authorized entities only because it contains a lot
of information that could be useful to potential attackers. In the
example configuration files, we've restricted zone
transfers to the three IP addresses listed.

In the option statement,
we've also disabled DNS recursion. This allows us to
separate the DNS server functionality from the DNS cache
functionality. For security reasons it's a good idea
to do this. There have been many papers written on this subject, with
one of the best explanations found at http://cr.yp.to/djbdns/separationl. If
you need recursive functionality, it is best to configure a
caching-only server on an IP address separate from your DNS server.
We'll discuss how to make a caching-only server with
BIND a little bit later.

If you've
decided that you can't live without recursion on the
same server, there are ways within the
named.conf to restrict recursion to specified
domains. By using the allow-recursion option in
place of the recursion no, you can specify a range
of IP addresses allowed to perform recursive queries.

You've probably noticed
that in this file we've included quite a few other
entries than just the vbrew.com
domain. These are present to be compliant with the specifications
established in RFC 1912, "Common DNS Operational and
Configuration Errors." This specification requests
that sites be authoritative for the local forward and reverse
zones, and for broadcast zones.

The BIND configuration supports many more options that we
haven't covered here. If you'd like
information all of the options, the best source of information is the
documentation supplied with the BIND Version 8 or 9 source
package.

5.2.5. The DNS Database Files

Master
files included with named, zone files, 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 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 RRs, the smallest units of information available through
DNS. Each RR has a type. A records, for instance, map a name to
an IP address, and a CNAME record associates an alias for a with
its official name. Examples appear later in the chapter when a
complete set of configuation and zone files are shown.

RR 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, such as 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. 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 name of the primary nameserver 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 nameservers 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 time to
live value for resource records that do not explicitly contain one.
The ttl value specifies the maximum amount of time other nameservers
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 name. The resource data field contains the address in dotted
quad notation.

For each name, there must be
only one A record. The name used in this A record is considered
the canonical name. All other names are
aliases and must be mapped onto the canonical name using a CNAME
record. If the canonical name of our were vlager, we'd have an A record
that associated that name 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.

AAAA

This record is exactly the same as the A record, but is used
exclusively for IPv6 addresses.

NS

NS records
are used to specify a zone's primary server and all
its secondary servers. An NS record points to a master nameserver of
the given zone, with the resource data field containing the name
of the nameserver.

You will meet NS records in two
situations: the first 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 nameservers
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
nameserver is reachable, but we can't reach the
nameserver until we resolve its address. To solve this dilemma, we
can configure special A records directly into the nameserver of the
parent zone. The A records allow the nameservers of the parent domain
to resolve the IP address of the delegated zone nameservers. These
records are commonly called glue records because they provide the
"glue" that binds a delegated zone
to its parent. Refer to the "DNS
Database" section earlier for an explanation of how
this works.

CNAME

This record associates an alias with a
's canonical name. It provides an alternate
name by which users can refer to the whose canonical name is
supplied as a parameter. The canonical name 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 names. It is used
for reverse mapping of IP addresses to names. The name given
must be the canonical name.

MX

This
RR announces a mail
exchanger for a domain. Mail exchangers are
discussed in Chapter 11,
Section 11.5. The syntax
of an MX record is

[domain] [ttl] [class] MX preference 

names the MX for
domain. Every MX has an integer
preference associated with it. A mail
transport agent that wants to deliver mail to
domain tries all s that have an MX
record for this domain until it succeeds. The one with the lowest
preference value is tried first, and 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 . Special conventions are
used to specify this. 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.
However, for security reasons, it's not a great idea
to have this information publicly available, as it provides
potentially valuable information to attackers. It's
very uncommon to see it used lately, but some administrators like to
use it to provide spurious or humorous information about their s.

Example HINFO records to describe machines look
something like:

tao  36500  IN  HINFO  SEGA-DREAMCAST  LINUX2.6
cevad 36500 IN  HINFO  ATARI-104ST LINUX2.0
jedd  36500 IN  HINFO  TIMEX-SINCLAIR  LINUX2.6

5.2.6. Caching-Only named Configuration

There is a special type of
named configuration that we'll
talk about before we explain how to build a full nameserver
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 . The
advantage of this scheme is that it builds up a cache so that only
the first query for a particular is actually sent to the
nameservers on the Internet. Any repeated request will be answered
directly from the cache in your local nameserver.
It's also important to note here that a cache server
should not be run from the same IP address as the DNS server.

A named.conf file for a caching-only server
looks like this:

// Define networks to allow queries from.
acl allowednets { 192.168.99.0/24; 192.168.44.0/24; };
options {
directory "/etc/bind";           // Working directory
allow-query { allowednets; };
};
// Root server hints
zone "." { type hint; 
file "root.hint"; };
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
file "local.rev";
notify no;
};

In addition to this
named.conf file, you must set up the
root.hint file with a valid list of root
nameservers. You could copy and use Example 6.10 for this purpose,
or, better yet, you could use a BIND tool called
dig to get the most current version of this
file. No other files are needed for a caching-only server
configuration. We'll discuss
dig in more detail later in this chapter, but
for now, to obtain the information to create the
root.hint file, you can use the following
command:

vbrew# dig at e.root-servers.net . ns

5.2.7. Writing the Master Files

Examples
Example 5-6, Example 5-7, Example 5-8, and Example 5-9 give sample
configuration and zone files for a nameserver at the brewery, located
on vlager. Due to the nature of the
network discussed (a single LAN), the example is pretty
straightforward.

The root.hint cache file shown in Example 5-6 shows sample hint records for a root
nameserver. A typical cache file usually describes about a dozen
nameservers. You can obtain the current list of nameservers for the
root domain using the dig tool as described
above.

Example 5-6. The root.hint file

; <<>> DiG 9.2.2 <<>> at e.root-servers.net . ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21972
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;at.                            IN      A
;; AUTHORITY SECTION:
;; Query time: 54 msec
;; SERVER: 206.13.28.12#53(206.13.28.12)
;; WHEN: Sat Jan 31 11:28:44 2004
;; MSG SIZE  rcvd: 83
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8039
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;e.root-servers.net.            IN      A
;; ANSWER SECTION:
e.root-servers.net.     566162  IN      A       192.203.230.10
;; AUTHORITY SECTION:
ROOT-SERVERS.net.       134198  IN      NS      a.ROOT-SERVERS.net.
ROOT-SERVERS.net.       134198  IN      NS      f.ROOT-SERVERS.net.
ROOT-SERVERS.net.       134198  IN      NS      j.ROOT-SERVERS.net.
ROOT-SERVERS.net.       134198  IN      NS      k.ROOT-SERVERS.net.
;; ADDITIONAL SECTION:
a.ROOT-SERVERS.net.     566162  IN      A       198.41.0.4
f.ROOT-SERVERS.net.     566162  IN      A       192.5.5.241
j.ROOT-SERVERS.net.     566162  IN      A       192.58.128.30
k.ROOT-SERVERS.net.     566162  IN      A       193.0.14.129
;; Query time: 12 msec
;; SERVER: 206.13.28.12#53(206.13.28.12)
;; WHEN: Sat Jan 31 11:28:44 2004
;; MSG SIZE  rcvd: 196
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61551
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUESTION SECTION:
;.                              IN      NS
;; ANSWER SECTION:
.                       479762  IN      NS      F.ROOT-SERVERS.NET.
.                       479762  IN      NS      B.ROOT-SERVERS.NET.
.                       479762  IN      NS      J.ROOT-SERVERS.NET.
.                       479762  IN      NS      K.ROOT-SERVERS.NET.
.                       479762  IN      NS      L.ROOT-SERVERS.NET.
.                       479762  IN      NS      M.ROOT-SERVERS.NET.
.                       479762  IN      NS      I.ROOT-SERVERS.NET.
.                       479762  IN      NS      E.ROOT-SERVERS.NET.
.                       479762  IN      NS      D.ROOT-SERVERS.NET.
.                       479762  IN      NS      A.ROOT-SERVERS.NET.
.                       479762  IN      NS      H.ROOT-SERVERS.NET.
.                       479762  IN      NS      C.ROOT-SERVERS.NET.
.                       479762  IN      NS      G.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
F.ROOT-SERVERS.NET.     566162  IN      A       192.5.5.241
B.ROOT-SERVERS.NET.     566162  IN      A       192.228.79.201
J.ROOT-SERVERS.NET.     566162  IN      A       192.58.128.30
K.ROOT-SERVERS.NET.     566162  IN      A       193.0.14.129
L.ROOT-SERVERS.NET.     566162  IN      A       198.32.64.12
M.ROOT-SERVERS.NET.     566162  IN      A       202.12.27.33
I.ROOT-SERVERS.NET.     566162  IN      A       192.36.148.17
E.ROOT-SERVERS.NET.     566162  IN      A       192.203.230.10
D.ROOT-SERVERS.NET.     566162  IN      A       128.8.10.90
A.ROOT-SERVERS.NET.     566162  IN      A       198.41.0.4
H.ROOT-SERVERS.NET.     566162  IN      A       128.63.2.53
C.ROOT-SERVERS.NET.     566162  IN      A       192.33.4.12
G.ROOT-SERVERS.NET.     566162  IN      A       192.112.36.4
;; Query time: 17 msec
;; SERVER: 206.13.28.12#53(206.13.28.12)
;; WHEN: Sat Jan 31 11:28:44 2004
;; MSG SIZE  rcvd: 436

Example 5-7. The vbrew.com zone file

;
;                        Hosts at the brewery
;                    /etc/bind/zone/vbrew.com
;                               Origin is vbrew.com
;
$TTL 3D
@                IN  SOA   vlager.vbrew.com. janet.vbrew.com. (
200401206       ; serial, date + todays serial #
8H              ; refresh, seconds
2H              ; retry, seconds
4W              ; expire, seconds
1D )            ; minimum, seconds                           
IN  NS    vlager.vbrew.com.
;
; local mail is distributed on vlager
IN  MX    10 vlager
;
; loopback address
local.       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 5-8. The loopback zone file

;
; /etc/bind/zone/127.0.0       Reverse mapping of 127.0.0
;                              Origin is 0.0.127.in-addr.arpa.
;
$TTL 3D
@             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   local.

Example 5-9. The vbrew reverse lookup file

;
;                     /etc/bind/zones/16.172.in-addr.arpa   
;                               Origin is 16.172.in-addr.arpa.
;
$TTL 3D
@             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.

5.2.8. Verifying the Nameserver Setup

dig
is the current nameserver query tool
of choice, replacing the commonly known
nslookup. It is flexible, fast, and can be used
to query almost anything from a DNS server. The syntax for
dig is very straightforward.

vbrew# dig nameserver name type

The command-line parameters are defined as follows:

nameserver

This is the name of the server that you
are querying. It can be entered as a name or as an IP address. If you
leave this blank, dig will use the DNS server
listed in the resolv.conf file.

name

This is the name of the DNS record that you want to look up.

type

This is the type of query you want to
execute. Common types are ANY, MX, and TXT. If left blank,
dig will default to looking for an A record.

So, using this, if we wanted to see which
servers handle mail for the Virtual Brewery, we would create the
following dig query:

vbrew# dig vlager.vbrew.com MX
; <<>> DiG 9.2.2 <<>> vlager.vbrew.com MX
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40590
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;vlager.vbrew.com.      IN      MX
;; AUTHORITY SECTION:
vbrew.com.         10794   IN      SOA     vlager.vbrew.com. vlager.vbrew.com. 2003080803 
10800 3600 604800 86400
;; Query time: 14 msec
;; SERVER: 192.168.28.12#53(192.168.28.12)
;; WHEN: Sun Feb  1 12:19:06 2004
;; MSG SIZE  rcvd: 104

Another
example of an interesting query type which can be useful is the BIND
version query. This is easily done with dig with
the following syntax:

vlager# dig @vlager.vbrew.com version.bind. CHAOS TXT
.
.
; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind.                  CH      TXT
;; ANSWER SECTION:
VERSION.BIND.           0       CH      TXT     "BIND 8.2.2-P5"
.
.

5.2.9. Using nslookup

nslookup
,
while now deprecated, is still a good tool for checking the operation
of your nameserver 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 name

nslookup queries the nameserver specified in
resolv.conf for
name. (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 s, 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 nameserver it uses and
enters interactive mode. At the prompt, you may type any domain name
that you want to query. By default, it asks for class A
recordsthose containing the IP address relating to the domain
name.

You can look for record types by issuing:

> set  type= type 

in which type is one of the RRs names
described earlier, or ANY.

For instance, 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 = -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 nameservers.
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.

5.2.10. Other Useful Tools

There
are a few other 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.

cvt


helps you with your initial BIND
configuration by converting your /etc/s 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 save you a few
aspirins. cvt is part of the BIND source,
but can also be found as a standalone package.

After setting up
your nameserver, 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 examine your
DNS database for common mistakes and verify that the information is
consistent. Two other useful tools are ,
which is a general purpose DNS database query tool. You can use this
tool to manually inspect and diagnose DNS database entries.

This tool is likely to be available in prepackaged form.
dnswalk and nslint are
available in source from http://www.visi.com/~barr/dnswalk/ and