Name resolution

Edit online

The process of obtaining an Internet address from a host name is known as name resolution and is done by the gethostbyname subroutine.

The process of translating an Internet address into a host name is known as reverse name resolution and is done by the gethostbyaddr subroutine. These routines are essentially accessors into a library of name translation routines known as resolvers.

Resolver routines on hosts running TCP/IP normally attempt to resolve names using the following sources:

  1. BIND/DNS (named)
  2. Network Information Service (NIS)
  3. Local /etc/hosts file

When NIS+ is installed, lookup preferences are set using the irs.conf file. For more information, see Network Information Services (NIS and NIS+) Guide.

To resolve a name in a domain network, the resolver routine first queries the domain name server database, which might be local if the host is a domain name server or on a foreign host. Name servers translate domain names into Internet addresses. The group of names for which a name server is responsible is its zone of authority. If the resolver routine is using a remote name server, the routine uses the domain name protocol (DOMAIN) to query for the mapping. To resolve a name in a flat network, the resolver routine checks for an entry in the local /etc/hosts file. When NIS or NIS+ is used, the /etc/hosts file on the master server is checked.

By default, resolver routines attempt to resolve names using the above resources. BIND/DNS is tried first. If the /etc/resolv.conf file does not exist or if BIND/DNS could not find the name, NIS is queried if it is running. NIS is authoritative over the local /etc/hosts, so the search ends here if it is running. If NIS is not running, then the local /etc/hosts file is searched. If none of these services can find the name, then the resolver routines return with HOST_NOT_FOUND. If all of the services are unavailable, then the resolver routines return with SERVICE_UNAVAILABLE.

The default order described above can be overwritten by creating the /etc/irs.conf configuration file and specifying the desired order. Also, both the default and /etc/irs.conf orderings can be overwritten with the environment variable, NSORDER. If either the /etc/irs.conf file or NSORDER environment variable are defined, then at least one value must be specified along with the option.

To specify host ordering with the /etc/irs.conf file:

hosts value [ continue ]

The order is specified with each method indicated on a line by itself. The value is one of the listed methods and the continue keyword indicates that another resolver method follows on the next line.

To specify host ordering with the NSORDER environment variable:

NSORDER=value,value,value

The order is specified on one line with values separated by commas. White spaces are permitted between the commas and the equal sign.

For example, if the local network is organized as a flat network, then only the /etc/hosts file is needed. Given this example, the /etc/irs.conf file contains the following line:

hosts local

Alternatively, the NSORDER environment variable can be set as:

NSORDER=local

If the local network is a domain network using a name server for name resolution and an /etc/hosts file for backup, then both services should be specified. Given this example, the /etc/irs.conf file contains the following lines:

hosts dns continue
hosts local

The NSORDER environment variable is set as:

NSORDER=bind,local
Note: The values listed must be in lowercase.

When following any defined or default resolver ordering, the search algorithm continues from one resolver to the next only if:

  • The current service is not running, therefore, it is unavailable.
  • The current service cannot find the name and is not authoritative.

If the /etc/resolv.conf file does not exist, then BIND/DNS is considered not set up or running, and therefore it is not available. If the getdomainname and yp_bind subroutines fail, then the NIS service is considered not set up or running, and therefore it is not available. If the /etc/hosts file could not be opened, then a local search is impossible, and therefore the file and service are unavailable.

When a service is listed as authoritative, it means that this service is the expert of its successors and has all pertinent names and addresses. Resolver routines do not try successor services, because successors might contain only a subset of the information in the authoritative service. Name resolution ends at service listed as authoritative, even if it does not find the name (in which case, the resolver routine returns HOST_NOT_FOUND). If an authoritative service is not available, then the next service specified is queried.

An authoritative source is specified with the string =auth directly behind a value. The entire word, authoritative can be typed in, but only the auth string is used. For example, if the NSORDER environment variable contains the following:

hosts = nis=auth,dns,local

The search ends after the NIS query (if NIS is running), regardless of whether the name was found. If NIS is not running, then the next source is queried, which is DNS.

TCP/IP name servers use caching to reduce the cost of searching for names of hosts on remote networks. Instead of searching for a host name each time a request is made, a name server first looks at its cache to see if the host name has been resolved recently. Because domain and host names do change, each item remains in the cache for a limited length of time specified by the time-to-live (TTL) value of the record. In this way, name servers can specify how long they expect their responses to be considered authoritative.