Configuring the Resolver

The resolver is configured in the /etc/resolv.conf file. The resolver is not a separate and distinct process; it is a library of routines called by network processes. The resolv.conf file is read when a process using the resolver starts, and is cached for the life of that process. If the configuration file is not found, the resolver attempts to connect to the named server running on the local host. While this may work, I don't recommend it. By allowing the resolver configuration to default, you give up control over your system and become vulnerable to variations in the techniques used by different systems to determine the default configuration. For these reasons, the resolver configuration file should be created on every system running BIND.

The Resolver Configuration File

The configuration file clearly documents the resolver configuration. It allows you to identify up to three name servers, two of which provide backup if the first server doesn't respond. It defines the default domain and various other processing options. The resolv.conf file is a critical part of configuring name service.

resolv.conf is a simple, human-readable file. There are system-specific variations in the commands used in the file, but the entries supported by most systems are:

• nameserver address
• The nameserver entries identify, by IP address, the servers that the resolver is to query for domain information. The name servers are queried in the order that they appear in the file. If no response is received from a server, the next server in the list is tried until the maximum number of servers are tried.[83] If no nameserver entries are contained in the resolv.conf file or if no resolv.conf file exists, all queries are sent to the local host. However, if there is a resolv.conf file and it contains nameserver entries, the local host is not queried unless an entry points to it. Specify the local host with its official IP address or with 0.0.0.0, not with the loopback address. The official address avoids problems seen on some versions of Unix when the loopback address is used. A resolver-only configuration never contains a nameserver entry that points to the local host.

  [83]Three is the maximum number of servers tried by most BIND implementations.

• domain name
• The domain entry defines the default domain name. The resolver appends the default domain name to any hostname that does not contain a dot.[84] It then uses the expanded hostname in the query it sends to the name server. For example, if the hostname crab (which does not contain a dot) is received by the resolver, the default domain name is appended to crab to construct the query. If the value for name in the domain entry is wrotethetutorial.com, the resolver queries for crab.wrotethetutorial.com. If the environment variable LOCALDOMAIN is set, it overrides the domain entry, and the value of LOCALDOMAIN is used to expand the hostname.

  [84]This is the most common way that default domain names are used, but this is configurable.

• search domain
• The search entry defines a series of domains that is searched when a hostname does not contain a dot. Assume the entry search essex.wrotethetutorial.com butler.wrotethetutorial.com. A query for the hostname tutorial is first tried as tutorial.essex.wrotethetutorial.com. If that fails to provide a successful match, the resolver queries for tutorial.butler.wrotethetutorial.com. If that query fails, no other attempts are made to resolve the hostname. Use either a search statement or a domain statement. (The search command is preferred.) Never use both in the same configuration. If the environment variable LOCALDOMAIN is set, it overrides the search entry.
• sortlist network[/netmask] ...
• Addresses from the networks listed on the sortlist command are preferred over other addresses. If the resolver receives multiple addresses in response to a query about a multi-homed host or a router, it reorders the addresses so that an address from a network listed in the sortlist statement is placed in front of the other addresses. Normally addresses are returned to the application by the resolver in the order in which they are received.

  The sortlist command is rarely used because it interferes with the servers' ability to reorder addresses for load balancing and other purposes. The primary exception to this is that sometimes sortlist is configured to prefer addresses on a shared network over other addresses. Using this configuration, if the computer running the resolver is connected to network 172.16.0.0/16 and one of the addresses returned in a multiple address response is from that network, the address from 172.16.0.0 is placed in front of the other addresses.

• options option
• The options entry is used to select optional settings for the resolver. There are several possible options:[85]

  [85]This list shows the options on Linux systems that run BIND 8. The Solaris version of BIND 8 does not provide the rotate, no-check-names, or inet6 options.

  • debug
  • Turns on debugging, which prints debugging messages to standard output. debug works only if the resolver was compiled with the -DDEBUG option, and most weren't.
  • ndots:n
  • Sets the number of dots in a hostname used to determine whether or not the search list is applied before sending the query to the name server. The default is 1. Therefore a hostname with one dot does not have a domain appended before it is sent to the name server. If options ndots:2 is specified, a hostname with one dot does have the search list domain added before the query is sent out, but a hostname with two or more dots does not have a domain added.

    ndots may be useful for you if some component of your domain could be confused with a top-level domain and your users consistently truncate hostnames at that domain. In that case, the queries would first be sent to the root servers for resolution in the top-level domain before eventually getting back to your local server. It is very bad form to bother the root servers over nothing. Use ndots to force the resolver to extend the troublesome hostnames with your local domain name so that they will be resolved before reaching the root servers.

  • timeout:n
  • Sets the initial query timeout for the resolver. By default, the timeout is 5 seconds for the first query to every server. Under the Solaris 8 version of BIND, the syntax of this option is retrans:n.
  • attempts:n
  • Defines the number of times the resolver will retry a query. The default value is 2, which means the resolver will retry a query two times with every server in its server list before returning an error to the application. Under the Solaris 8 version of BIND, the syntax of this option is retry:n, and the default is 4.
  • rotate
  • Turns on round-robin selection of name servers. Normally, the resolver sends the query to the first server in the name server list, sending it to another server only if the first server does not respond. The rotate option tells the resolver to share the name server workload evenly among all of the servers.
  • no-check-names
  • Disables checking of domain names for compliance with RFC 952, DOD Internet Host Table Specification. By default, domain names that contain an underscore (_), non-ASCII characters, or ASCII control characters are considered to be in error. Use this option if you must work with hostnames that contain an underscore.
  • inet6
  • Causes the resolver to query for IPv6 addresses. The version of the Internet Protocol (IP) used in today's Internet is IPv4. IPv4 uses 32-bit addresses. IPv6 expands those to 128-bit addresses.

The most common resolv.conf configuration defines the local domain name as the search list, the local host as the first name server, and one or two backup name servers. An example of this configuration is:

# Domain name resolver configuration file # search wrotethetutorial.com # try yourself first nameserver 172.16.12.2 # try crab next nameserver 172.16.12.1 # finally try ora nameserver 172.16.1.2

The example is based on our imaginary network, so the default domain name is wrotethetutorial.com. The configuration is for rodent, and it specifies itself as the first name server. The backup servers are crab and ora. The configuration does not contain a sort list or any options, as these are infrequently used. This is an example of an average resolver configuration.

A resolver-only configuration

The resolver-only configuration is very simple. It is identical to the average configuration except that it does not contain a nameserver entry for the local system. A sample resolv.conf file for a resolver-only system is shown here:

# Domain name resolver configuration file # search wrotethetutorial.com # try crab nameserver 172.16.12.1 # next try ora nameserver 172.16.1.2

The configuration tells the resolver to pass all queries to crab; if that fails, try ora. Queries are never resolved locally. This simple resolv.conf file is all that is required for a resolver-only configuration.