What is a Name Server?

A name server is a computer server that hosts a network service for providing responses to queries against a directory service. It maps a human-recognizable identifier to a systeminternal, often numeric, identification or addressing component. This service is performed by the server according to a network service protocol. Different types of Name Servers TCP/IP networking may rely on different schemes to convert names into addresses. The simplest way is a host table stored in /etc/hosts. This is useful only for small LANs that are run by one single administrator and otherwise have no IP traffic with the outside world. Alternatively, the Berkeley Internet Name Domain service (BIND) for resolving hostnames to IP addresses can be used. Configuring BIND can be complex, but once it is done, changes can be made very easily in the network topology. On Linux name service is provided through a program called named. At startup, it loads a set of master files into its internal cache and waits for queries from remote or local user processes. There are different ways to set up BIND, and not all require running a name server on every host. 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. The central routines are gethostbyname and gethostbyaddr, which look up all IP addresses associated with a host name, and vice versa. They may be configured to simply look up the information in hosts, to query a number of DNS name servers, or to use the hosts' database of Network Information Service (NIS). 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 Version 2 of the GNU standard library, glibc, uses /etc/nsswitch.conf. The host.conf File The /etc/host.conf tells the older Linux standard library resolver functions which services to use, and in what order. Options in host.conf must appear on separate lines. The following options are available: /* This may be omitted */ order This option determines the order in which the resolving services are tried. Valid options are bind for querying the name server, hosts for lookups in /etc/hosts, and nis for NIS lookups. Any or all of them may be specified. The order in which they appear on the line determines the order in which the respective services are tried.

multi multi takes on or off as options. This determines if a host in /etc/hosts is allowed to have several IP addresses, which is usually referred to as being "multi-homed." The default is off. This flag has no effect on DNS or NIS queries. nospoof As we'll explain in the section "Reverse Lookups", DNS allows you to find the hostname belonging to an IP address by using the in-addr.arpa domain. Attempts by name servers to supply a false hostname are called spoofing. To guard against this, the resolver can be configured to check whether the original IP address is in fact associated with the obtained hostname. If not, the name is rejected and an error is returned. This behavior is turned on by setting nospoof on. alert This option takes on or off as arguments. If it is turned on, any spoof attempts will cause the resolver to log a message to the syslog facility. trim This option takes an argument specifying a domain name that will be removed from hostnames before lookup. This is useful for hosts entries, for which we might only want to specify hostnames without a local domain. If we specify our local domain name here, it will be removed from a lookup of a host with the local domain name appended, thus allowing the lookup in /etc/hosts to succeed. The domain name you add must end with the (.) character (e.g., :linux.org.au.) if trim is to work correctly. Sample host.conf File # /etc/host.conf # We have named running, but no NIS (yet) order bind, hosts # Allow multiple addrs multi on # Guard against spoof attempts nospoof on Resolver environment variables The settings from host.conf may be overridden using a number of environment variables: RESOLV_HOST_CONF This variable specifies a file to be read instead of /etc/host.conf. RESOLV_SERV_ORDER This variable overrides the order option given in host.conf. Services are given as hosts, bind, and nis.

RESOLV_SPOOF_CHECK This variable determines the measures taken against spoofing. It is completely disabled by off. The values warn and warn off enable spoof checking by turning logging on and off, respectively. A value of * turns on spoof checks, but leaves the logging facility as defined in host.conf. RESOLV_MULTI This variable uses a value of on or off to override the multi options from host.conf. RESOLV_OVERRIDE_TRIM_DOMAINS This variable specifies a list of trim domains that override those given in host.conf. Trim domains were explained earlier when we discussed the trim keyword. RESOLV_ADD_TRIM_DOMAINS This variable specifies a list of trim domains that are added to those given in host.conf. The nsswitch.conf File Version 2 of the GNU standard library includes a more powerful and flexible replacement for the older host.conf mechanism. The concept of the name service has been extended to include a variety of different types of information. Configuration options for all of the different functions that query these databases have been brought back into a single configuration file; 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. 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 remainders of each line stores options that determine the way lookups for that database are performed. The following options are available: dns Use the Domain Name System (DNS) service to resolve the address. This makes sense only for host address resolution, not network address resolution. This mechanism uses the /etc/resolv.conf 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/network files. nis or nisplus Use the Network Information System (NIS) to resolve the host or network address. 3

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 is specified below: Sample nsswitch.conf File # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. hosts: dns files networks: files This example causes the system to look up hosts first in the Domain Name System, and the /etc/hosts file, if that can't find them. 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 attempt resolution using it. 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: 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 name server or NIS server did not respond for the dns or nis services. The default action for this status is continue. tryagain This status means 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. 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 the Domain Name Service system. 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 name server is unavailable for some reason. How DNS Works DNS organizes hostnames in a domain hierarchy. A domain is a collection of sites that are related in some sense because they form a proper network (e.g., all machines on a campus), and they all belong to a certain organization (e.g. Heritage Institute of Technology), and they are geographically close. For instance, universities are commonly grouped in the edu domain, with each university or college using a separate subdomain, below which their hosts are subsumed. Heritage Institute of Technology has the heritageit.edu domain, while the LAN of the CSE department may be assigned cse.heritageit.edu. Hosts on the departmental network would have this domain name tacked onto their hostname, so ssg might be known as ssg.maths.heritageit.edu. This is called the fully qualified domain name (FQDN), which uniquely identifies this host worldwide. Figure 1 (below) shows a section of the namespace. The entry at the root of this tree, which is denoted by a single dot, is quite appropriately called the root domain and encompasses all other domains. To indicate that a hostname is a fully qualified domain name, rather than 5

a name relative to some (implicit) local domain, it is sometimes written with a trailing dot. This dot signifies that the name's last component is the root domain.

.com

.edu

.net

.heritageit

.maths .cse

Figure 1 Depending on its location in the name hierarchy, a domain may be called top-level, secondlevel, or third-level. More levels of subdivision occur, but they are rare. This list details several top-level domains are seen frequently: Domain edu com org net mil gov uucp Description (Mostly U.S.) educational institutions like universities. Commercial organizations and companies. Non-commercial organizations. Private UUCP (UNIX-to-UNIX-COPY) networks are often in this domain. Gateways and other administrative hosts on a network. U.S. military institutions. Government institutions. Officially, all site names formerly used as UUCP names without domains have been moved to this domain.

Outside the U.S., each country generally uses a top-level domain of its own named after the two-letter country code defined in ISO-3166. India, for instance, uses the in domain; fr is used by France, de by Germany, and au by Australia. Below this top-level domain, each country's NIC is free to organize hostnames in whatever way they want. For instance, the domain used by the Indian Railways is indianrail.gov.in. Name Lookups with DNS In fact, DNS is a giant distributed database. It is implemented by so-called name servers that supply information on a given domain or set of domains. For each zone there are at least two, or at most a few, name servers that hold all authoritative information on hosts in that zone. To obtain the IP address of cse (of cse.heritageit.edu) it is required to contact the name server for the heritageit.edu zone, which in turn gives the desired data.

Now, how does my computer know how to reach the name server of the zone containing heritageit.edu? In case the computer is not equipped with an address-resolving system, DNS provides for this, too. When one wants to look up information on cse, it contacts a local name server, which conducts a so-called iterative query for it. The DNS Database A single piece of information from the DNS database is called a resource record (RR). Each record has a type associated with it describing the sort of data it represents, and a class specifying the type of network it applies to.

Running named named provides DNS on most Unix machines. named is usually started at system boot time and runs until the machine goes down again. To run named at the prompt, enter: # /usr/sbin/named named will come up and read the named.boot file and any zone files specified therein. It downloads any zone files from primary servers, if necessary, and starts listening on port 53 for DNS queries. Verifying the Name Server Setup nslookup is a great tool for checking the operation of your name server setup. It can be used both interactively with prompts and as a single command with immediate output. In the latter case, you simply invoke it as: # nslookup <hostname>