Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

6.1. DNS Basics

Although I
just said this chapter assumes familiarity with DNS,
let's clarify some important DNS terminology and
concepts with an example.

Suppose someone (myhost.someisp.com in Figure 6-1) is surfing the Web and wishes to view the
site http://www.dogpeople.org.
Suppose also that this person's machine is
configured to use the nameserver ns.someisp.com
for DNS
lookups. Since the name
"www.dogpeople.org" has no meaning
to the routers through which the web query and its responses will
pass, the user's web browser needs to learn the
Internet Protocol (IP) address associated with http://www.dogpeople.org before attempting
the web query.

Figure 6-1. A recursive DNS query

First, myhost asks ns
whether it knows the IP address. Since
ns.someisp.com isn't
authoritative for dogpeople.org and
hasn't recently communicated with any host that is,
it begins a query on the user's behalf. In DNS
parlance, making one or more queries in order to answer a previous
query is called recursion.

ns.someisp.com begins its recursive query by
asking a root nameserver for the IP address of a
host that's authoritative for the generic Top Level
Domain .org. (All Internet DNS servers use a
static "hints" file to identify the
13 or so official root nameservers. This list is maintained at
ftp://ftp.rs.internic.net/domain and is called
named.root.)
In our example,
ns asks E.ROOT-SERVERS.NET
(an actual root server whose IP address is currently 193.203.230.10),
who replies that DNS for .org is handled by
TLD1.ULTRADNS.NET, whose IP
address is 204.74.112.1.

ns next asks TLD1.ULTRADNS.NET for the name and IP address
of a name authority for the zone dogpeople.org. TLD1.ULTRADNS.NET replies that DNS for
dogpeople.org is served by
woofgange.dogpeople.org, whose IP
address is 55.100.55.100.

ns then asks woofgang
(using woofgang's IP address,
55.100.55.100) for the IP of www.dogpeople.org.
woofgang returns the answer (55.100.55.244),
which ns forwards back to
myhost.someisp.com. Finally,
myhost contacts 55.100.55.244 directly via HTTP
and performs the web query.

This is the most common type of name lookup. It and other single-host
type lookups are simply called queries;
DNS queries are handled on UDP port 53.

Not all DNS transactions involve single-host lookups, however.
Sometimes it is necessary to transfer entire name-domain (zone)
databases: this is called a zone transfer,
and it happens when you use the end-user command host
with
the -l flag and the command
dig with query-type set to
axfr. The output from such a request is a complete
list of all DNS records for the requested zone.

host and dig are normally
used for diagnostic purposes, however; zone transfers are meant to be
used by nameservers that are authoritative for the same domain to
stay in sync with each other (e.g., for
"master to slave"
updates). In fact, as we'll discuss shortly, a
master server should refuse zone-transfer requests from any host that
is not a known and allowed slave server. Zone transfers are handled
on TCP port 53.

The last general DNS concept we'll touch on here is
caching.
Nameservers cache all local zone files (i.e., their
hints file plus all zone information for which
they are authoritative), plus the results of all recursive queries
they've performed since their last
startupthat is, almost all of them. Each
resource record (RR)
has its own (or inherits its zone file's default)
time-to-live (TTL) setting. This value determines how long each RR
can be cached before being refreshed.

This, of course, is only a fraction of what one needs to learn to
fully understand and use BIND. But it's enough for
the purposes of discussing BIND security.