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

5.1. The Resolver Library

The term resolver
refers not to a special application, but to the resolver library.
This is a collection of functions that can be found in the standard C
library and are invoked by a wide range of networking applications.
The central routines are gethostbyname(2) and
gethostbyaddr(2), which look up all IP addresses
associated with a hostname, and vice versa. They may be configured to
simply look up the information in hosts, or to
query a number of DNS nameservers.

The resolver functions read
configuration files when they are invoked. From these configuration
files, they determine what databases to query, in which order, and
other details relevant to how you've configured your
environment. The older Linux standard library, libc, used
/etc/host.conf as its master configuration file,
but since Version 2 of the GNU standard library, glibc, uses
/etc/nsswitch.conf.

5.1.1. The nsswitch.conf File

The nsswitch.conf file
allows the system administrator to configure a wide variety of
different databases. We'll limit our discussion to
options that relate to host and network IP address resolution. You
can easily find more information about the other features by reading
the GNU standard library documentation.

Options in
nsswitch.conf must appear on separate lines.
Fields may be separated by whitespace (spaces or tabs). A hash sign
(#) introduces a comment that extends to the next
newline. Each line describes a particular service; hostname
resolution is one of these. The first field in each line is the name
of the database, ending with a colon. The database name associated
with host address resolution is hosts. A related
database is networks, which is used for resolution
of network names into network addresses. The remainder of each line
stores options that determine the way lookups for that database are
performed.

The following options are available:

dns

Use the DNS service
to resolve the address. This makes sense only for host address
resolution, not network address resolution. This mechanism uses the
fs file that we'll describe
later in the chapter.

files

Search a local file for the host or network name and its
corresponding address. This option uses the traditional
/etc/hosts and
/etc/networks files.

The order in which the services to be queried are listed determines
the order in which they are queried when attempting to resolve a
name. The query-order list is in the service description in the
/etc/nsswitch.conf file. The services are
queried from left to right and by default searching stops when a
resolution is
successful.

A simple example of host and network database specification that
would mimic our configuration using the older libc standard library
is shown in Example 5-1.

Example 5-1. Sample nsswitch.conf file

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# Information about this file is available in the `libc6-doc' package.
hosts:          dns files
networks:       files

This example causes the system to look up hosts first in the DNS and,
if that can't find them, the
/etc/hosts file. Network name lookups would be
attempted using only the /etc/networks file.

You are able to control the lookup
behavior more precisely using "action
items" that describe what action to take given the
result of the previous lookup attempt. Action items appear between
service specifications and are enclosed within square brackets,
[ ]. The general syntax of the
action statement is:

[ [!] status = action ... ]

There are two possible actions:

return

Controls returns to the program that
attempted the name resolution. If a lookup attempt was successful,
the resolver will return with the details; otherwise, it will return
a zero result.

continue

The resolver will move on to the next service in the list and use it
to attempt resolution.

The optional (!) character specifies that the status value should be
inverted before testing; that is, it means
"not."

The available status values on which we can act are as follows:

success

The requested entry was found without error. The default action for
this status is return.

notfound

There was no error in the lookup, but the target host or network
could not be found. The default action for this status is
continue.

unavail

The service queried was unavailable. This could mean that the
hosts or networks file was
unreadable for the files service or that a
nameserver or NIS server did not respond for the
dns or nis services. The
default action for this status is continue.

tryagain

This status means that the
service is temporarily unavailable. For the
files service, this would usually indicate that
the relevant file was locked by some process. For other services, it
may mean the server was temporarily unable to accept connections. The
default action for this status is continue.

A simple example of how you might use this mechanism is shown in
Example 5-2.

Example 5-2. Sample nsswitch.conf file using an action statement

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# Information about this file is available in the `libc6-doc' package.
hosts:          dns [!UNAVAIL=return] files
networks:       files

This example attempts host resolution
using DNS. If the return status is anything other than unavailable,
the resolver returns whatever it has found. If, and only if, the DNS
lookup attempt returns an unavailable status, the resolver attempts
to use the local /etc/hosts. This means that we
should use the hosts file only if our nameserver
is unavailable for some reason.

5.1.2. Configuring Nameserver Lookups Using resolv.conf

When
configuring the resolver library to use the DNS name service for host
lookups, you also have to tell it which nameservers to use. There is
a separate file for this called resolv.conf. If
this file does not exist or is empty, the resolver assumes the
nameserver is on your local host.

To run a nameserver on your local host,
you have to set it up separately, as will be explained in the
following section, "How DNS Works."
If you are on a local network and have the opportunity to use an
existing nameserver, this should always be preferred. If you use a
dialup IP connection to the Internet, you would normally specify the
nameserver of your service provider in the
resolv.conf file.

The
most important option in resolv.conf is
nameserver, which gives the IP address of a
nameserver to use. If you specify several nameservers by giving the
nameserver option several times, they are tried in
the order given. You should therefore put the most reliable server
first. The current implementation allows you to have up to three
nameserver statements in
resolv.conf. If no nameserver
option is given, the resolver attempts to connect to the nameserver
on the local host.

Two other options,
domain and search, let you use
shortcut names for hosts in your local domain. Usually, when just
contacting another host in your local domain, you
don't want to type in the fully qualified hostname,
but use a name such as gauss on the
command line and have the resolver tack on the mathematics.groucho.edu part.

This
is just the domain statement's
purpose. It lets you specify a default domain name to be appended
when DNS fails to look up a hostname. For instance, when given the
name gauss, the resolver first tries
to find gauss. in DNS and fails,
because there is no such top-level domain. When given mathematics.groucho.edu as a default domain,
the resolver repeats the query for gauss with the default domain appended, this
time succeeding.

That's just fine, you may think, but as soon you get
out of the math department's domain,
you're back to those fully qualified domain names.
Of course, you would also want to have shorthands like quark.physics for hosts in the physics
department's domain.

This is where
the search list comes in. A
search list can be specified using the search
option, which is a generalization of the domain
statement. Where the latter gives a single default domain, the former
specifies a whole list of them, each to be tried in turn until a
lookup succeeds. This list must be separated by blanks or tabs.

The search and
domain statements are mutually exclusive and may
not appear more than once. If neither option is given, the resolver
will try to guess the default domain from the local hostname using
the getdomainname(2) system call. If the local
hostname doesn't have a domain part, the root domain
is the default.

Assume you're at the Virtual Brewery and want to log
in to foot.groucho.edu. By a slip of
your fingers, you mistype foot as
foo, which doesn't
exist. GMU's nameserver will therefore tell you that
it knows no such host. Using older search methods, the resolver used
to keep trying the name with vbrew.com and com appended. The latter is problematic
because groucho.edu.com might
actually be a valid domain name. Their nameserver might then even
find foo in their domain, pointing
you to one of their hosts, which is not what you're
looking for.

For some applications, these bogus host
lookups can be a security problem. Therefore, you should usually
limit the domains on your search list to your local organization or
something comparable. At the mathematics department of Groucho Marx
University, the search list would commonly be set to maths.groucho.edu and groucho.edu.

If default domains sound confusing to you, consider this sample
resolv.conf file for the Virtual Brewery:

# /etc/resolv.conf
# Our domain
domain         vbrew.com
#
# We use vlager as central name server:
nameserver     172.16.1.1

When resolving the name vale, the
resolver looks up vale. and, failing
this, vale.vbrew.com.

5.1.3. Resolver Robustness

When running a LAN
inside a larger network, you definitely should use central
nameservers if they are available. The nameservers develop rich
caches that speed up repeat queries, since all queries are forwarded
to them. However, this scheme has a drawback: when a fire destroyed
the backbone cable at one author's university, no
more work was possible on his department's LAN
because the resolver could no longer reach any of the nameservers.
This situation caused difficulties with most network services, such
as X terminal logins and printing.

Although it is not very common for campus backbones to go down in
flames, one might want to take precautions against such cases.

One option is to set up a
local nameserver that resolves hostnames from your local domain and
forwards all queries for other hostnames to the main servers. Of
course, this is applicable only if you are running your own domain.

Alternatively, you can maintain a backup
host table for your domain or LAN in /etc/hosts.
This is very simple to do. You simply ensure that the resolver
library queries DNS first and the hosts file
next. In the /etc/nsswitch.conf file
you'd use hosts:
dns files to make the resolver
fall back to the hosts file if the central
nameserver is unreachable.