20.5 Objective 5: Set Up and
Configure Basic DNS Services
The Domain Name Service (DNS) is the
distributed database of name-to-IP-address translations.
Technically, it isn't necessary to use host and domain names
such as www.lpi.org, because it's the actual IP address that the computer requires
to establish communications. DNS was created to allow the use
of more convenient global domain names instead. For example,
when a user enters a DNS name as part of a URL in a browser,
the name portion is sent to a DNS server to be resolved into
an IP address. Once the address is found, it is used to
rewrite the URL and directly fetch the web page.
|
You must be familiar with the concept
of name resolution on the Internet using DNS.
|
The server daemon that implements DNS is
named, the name daemon
, which is part of the Berkeley Internet Name Daemon package
(BIND). It is named's job to
respond to requests from the resolver and return an IP
address.
20.5.1 The resolver
The code that
resolves names to IP addresses using DNS for client programs
is implemented in system libraries collectively called the
resolver. The resolver uses one of several
means to determine an IP address from a hostname or domain
name:
- Static local files
-
The local file /etc/hosts can
contain name-to-address mapping for a few systems on a
network. However, for large enterprises, using static local
files to manage IP address resolution is problematic due to
the frequent changes required in the data. Updating all of
the client systems would be impractical. This resolution
method is sometimes referred to as the files method.
- Network Information Service
(NIS)
-
Some private
networks use a shared information service that can include
address resolution. This is NIS, or a later version of it
called NIS+, and is referred to as the nis method
of resolution. Both services are beyond the scope of the
LPIC Level 1 exams.
- Domain Name Service
(DNS)
-
Because addresses
and domains on the public Internet change frequently and are
so numerous, static local files can't handle resolution far
outside the enterprise. As already mentioned, DNS is a
distributed database. That is, small portions of the DNS are
managed by local authorities that are responsible only for
their particular slice of the system. As you'd expect, using
DNS for name resolution is called the dns method.
In most cases, /etc/hosts will be used
for name resolution of the local host and perhaps a few other
nearby systems. DNS, perhaps together with NIS in enterprise
environments, will handle everything else.
/etc/hosts and the other files used to
configure the resolver are described in Section
19.2 but here's a quick recap:
- /etc/hosts
-
This file lists statically defined
name-to-address translations.
- /etc/nsswitch.conf (or
/etc/host.conf on older Linux systems)
-
The "name service switch" file
(nsswitch.conf ) defines the order of name server
methods to be used in succession by the resolver (it can
also control other things such as passwords, but those don't
apply here). Typically, this single entry is used to control
name resolution: hosts: files dns
This entry instructs the resolver to resolve
names using /etc/hosts first, and if a match isn't
found, to make a DNS query.
- /etc/resolv.conf
-
This file lists
the IP addresses of name servers: nameserver 127.0.0.1
nameserver 192.168.1.5
nameserver 192.168.250.2
|
Be sure that you understand how
/etc/nsswitch controls the resolution order, that
/etc/resolv.conf identifies DNS servers by
address, and that /etc/hosts is for local,
statically resolved addresses. Also remember that older
versions of Linux used /etc/host.conf to
configure the resolution order instead of
/etc/nsswitch.conf. |
When the resolver determines that a DNS query
is required, it sends a request containing a domain name to
one of the DNS servers listed in /etc/resolv.conf. The
DNS server uses its own records to find the domain or may
resort to escalating to other DNS servers if the information
isn't readily available. When a result is found by the DNS
servers, the IP address corresponding to the requested name is
returned to the originating client.
20.5.1.1 Domain registration
Domain names are
assigned through a registration process with one of the domain
name registrars available on the Internet (http://www.internic.net/regist.html).
Originally, a single authority managed domain names. As
commercial uses for domain names spread, additional entities
sought the ability to charge for the service of domain
registration, and today there are a number of qualified
registrars (a search for "domain registrar" on one of the
popular search engines will yield a daunting list). Once a
domain name is registered, it is listed in a worldwide
database along with contact information for the owners or
their agents. The name servers that contain DNS information
for the domain can go along with this record.
Most registrants offer a domain name search
service, so you can test desired domain names for
availability. If the domain name you're seeking is available,
you can provide payment information to a registrant and
purchase rights to use the name, usually for one or two years.
20.5.1.2 Using named as a local
caching-only name server
named is often configured to serve DNS
requests even when it does not have local information for a
domain. Instead, it is used for its caching ability. When a
client program requests an address resolution from the local
named
, the daemon first checks its local
cache. If it doesn't find the domain there, it goes to other
DNS servers as usual. If the cache does contain the domain, it
is returned immediately to the client from the cache, which
speeds the resolution process.
Some Linux distributions come with a
caching-only named
configuration pre-installed. If this isn't the case for you,
simply follow the brief instructions in section 3 of the
DNS HOWTO available from http://www.linuxdoc.org/ (or in your
/usr/doc/HOWTO directory). Part of the configuration
includes setting your local system as the default DNS server
in /etc/resolv.conf : nameserver 127.0.0.1
You can test the configuration using the
nslookup utility: # nslookup
Default Server: localhost
Address: 127.0.0.1
> lpi.org
Server: localhost
Address: 127.0.0.1
Name: lpi.org
Address: 209.167.177.93
> lpi.org
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: lpi.org
Address: 209.167.177.93
> exit
In this example, nslookup
attaches to the default server localhost
(127.0.0.1). In the first query for lpi.org,
the local named must find the
address from external DNS servers. However, the result is
found in the cache on the second try, as indicated by the
Non-authoritative answer response. If this behavior
isn't seen, there may be a problem with the named configuration in
/etc/named.conf.
Some debugging information can be found in
/var/log/messages. For example, the highlighted line in
this short excerpt shows an error in the configuration file:
smp named[216]: starting. named
smp named[216]: cache zone "" (IN) loaded (serial 0)
smp named[216]: Zone "0.0.127.in-addr.arpa"
(file named.local): No default TTL
set using SOA minimum instead
smp named[216]: master zone "0.0.127.in-addr.arpa"
(IN) loaded (serial 1997022700)
smp named[216]: /etc/named.conf:18: can't redefine
channel 'default_syslog'
smp named[216]: listening on [127.0.0.1].53 (lo)
smp named[216]: listening on [192.168.1.30].53 (eth0)
smp named[216]: listening on [172.16.132.1].53 (vmnet1)
smp named[216]: Forwarding source address is [0.0.0.0].1855
smp named[216]: Ready to answer queries.
Note that configuration of a caching-only
name server is beyond the scope of the LPIC Level 1 exams but
is a useful exercise in understanding the configuration of
named.
20.5.1.3 DNS query utilities
A few tools exist to verify the operation of
DNS name resolution. Here's a brief synopsis of nslookup and host, both specifically mentioned in
this Objective. The host
utility does not offer interactive mode but uses a syntax
similar to nslookup.
Syntaxnslookup host [dnsserver]
Description
Look up
host, optionally specifying a particular
dnsserver. nslookup can
be used in either interactive or noninteractive modes. If
host is provided on the command line, noninteractive
mode is used. In interactive mode, a number of commands are
available to control nslookup
(the ls command to nslookup is used in the example). See
the manpage for more details.
Noninteractive example
In this example, nslookup provides immediate results
because host, in this case oreillynet.com, is
provided on the command line: # nslookup oreillynet.com 192.168.1.2
Server: ns1.mydomain.com
Address: 192.168.1.2
Non-authoritative answer:
Name: oreillynet.com
Address: 208.201.239.36
Interactive example
Here, nslookup
is used interactively with DNS server 192.168.1.2 to
find records from yourdomain.com : # nslookup
Default Server: localhost
Address: 127.0.0.1
> server 192.168.1.2
Default Server: ns1.mydomain.com
Address: 192.168.1.2
> ls -a yourdomain.com
[ns1.mydomain.com]
$ORIGIN yourdomain.com.
ipass 2D IN CNAME snoopy
smtp 2D IN CNAME charlie
mail 2D IN CNAME charlie
pop 2D IN CNAME lucy
yourdomain 2D IN CNAME charlie
ww2 2D IN CNAME linus
www 2D IN CNAME sally
> exit
Syntaxhost [options] host [dnsserver]
Description
Look up
host, optionally specifying a particular
dnsserver.
Frequently used options
- -d
-
Enable debugging, showing network
transactions in detail.
- -v
-
Use verbose mode. Results are displayed in
the official domain master file format.
Example# host -v oreillynet.com
Trying null domain
rcode = 0 (Success), ancount=1
The following answer is not authoritative:
oreillynet.com 1991 IN A 208.201.239.36
For authoritative answers, see:
oreillynet.com 167591 IN NS NS1.SONIC.NET
oreillynet.com 167591 IN NS NS.SONGLINE.COM
Additional information:
NS1.SONIC.NET 167591 IN A 208.201.224.11
NS.SONGLINE.COM 167591 IN A 208.201.239.31
|
Detailed knowledge of nslookup and host are not required, but you
must be familiar with their purpose and basic operation.
|
Additional utilities, such as dig and dnsquery, also can help you with DNS
queries, though they are not mentioned in this exam Objective.
20.5.1.4 BIND Version 4 versus
Version 8 configuration files
It's likely that a Linux administrator will
maintain or install systems running BIND v4.x as well as the
newer v8.x. This LPI Objective requires an understanding of
the differences between the configuration files for these two
BIND versions. Under BIND v4, the configuration file was
called /etc/named.boot. Example
20-5 shows a trivial BIND v4 configuration file.
Example 20-5. BIND v4
named.boot File directory /var/named
cache . root.hints
primary 0.0.127.IN-ADDR.ARPA 127.0.0.zone
primary localhost localhost.zone
In BIND v8, the configuration file was
renamed /etc/named.conf. Example
20-6 shows the equivalent configuration in the BIND v8
format.
Example 20-6. BIND v8
named.conf File // generated by named-bootconf.pl
options {
directory "/var/named";
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "127.0.0.zone";
};
zone "localhost" {
type master;
file "localhost.zone";
};};
As you can see, the information contained in
the files is largely the same, but the v8 format contains a
more formal structure. For those upgrading to Version 8, the
Perl script named-bootconf.pl is included in the v8
package to upgrade named.boot to named.conf.
|
You should be generally familiar with
the structural differences between the configuration
files for BIND v4 and v8. However, detailed named configuration is beyond
the scope of the LPIC Level 1 exams.
|
|