| Now that we've defined the hierarchy, let's look at how we determine the information we're searching for. For example, let's assume we need to locate the IP address of our earlier example, www.sun.com. Figure 16.3 provides an overview of the steps that we'll follow to do this. Figure 16.3. Determining an IP address. 
Now let's look at the different machine types that the figure refers to. Name Servers Name servers are the server portions of DNS. They are responsible for storing the domain information and handing it out to any clients who request it. For example, in our earlier explanation about DNS, we talked about determining the IP address of the machine we wanted to connect into. This would have been provided by one of the name servers for the domain. They are an important part of DNS because if a server for a particular domain fails, then after a certain amount of time everyone's queries to that domain will fail. For this reason, at least two name servers must be used to store the domain's data; in fact, the IP addresses of the two name servers acting for you need to be provided when a domain is registered. These are referred to as the "master" and "slave" server, although many people still tend to use their old names of "primary" and "secondary." Master and Slave Servers Master servers hold the configuration files for the domains (or more correctly, the "zones," as we'll see later). Whenever changes are made to the files they are made on this system. Slave servers contain copies of the files, which are automatically downloaded from the master on a regular basis, depending on the settings contained in the master configuration files. It's also interesting to note that while one is a master and the other a slave, external connections cannot tell the difference. They simply know that they have received an answer to their query. Caching Servers All name servers cache data to a certain degree, but caching name servers only cache data (they don't hold any configuration files for the domain). These types of servers are often used to provide additional resources if the main name servers become heavily loaded. Root Servers These are "special" name servers and are very important to DNS. They are used to tie all the name servers in the locally managed domains together to form the Internet. Let's see how. Suppose we want to look up "somemachine.somedomain.com." We query our name server, but it doesn't know the answer so it passes the query to one of the root servers (we've just seen this happen in Figure 16.3). From there, the query passes to a name server responsible for the top-level domain that the query relates to, in this case ".com." If this server cannot provide the answer, the query is passed to the one responsible for the domain ("somedomain.com"). This process continues until a response is returned. To be able to do this, each name server must know how to contact one of the root servers. This information is freely available and is supplied as part of the configuration files when the system is built, as we'll see later. We can see from this that the root name servers are even more important than the "standard" domain name servers, in that if the root servers fail, eventually all DNS would stop working. To overcome this potential problem, a number of these servers are scattered around the world. Resolvers These are the client portions of DNSthe parts responsible for making the queries to the name servers (commonly known as "host name resolving" or "host name lookups"). They are built into the operating system and so are transparent to the users. The only real options related to resolvers are whether to enable or disable them. We do this by editing the name service switch file, /etc/nsswitch.conf, which we'll cover later when the systems are configured (it's also explained in more detail in Chapter 12, "Naming Services and NIS"). /etc/resolv.conf When the resolver starts up, it tries to determine the domain name of the system from a number of different places, which are listed below (again, these are explained further in Chapter 12, "Naming Services and NIS": The system variable LOCALDOMAIN (if set) The "domain" entry in /etc/resolv.conf The domain setting used for NIS/NIS+ if they are enabled (the value of "domainname") The local hosts file if it contains a fully qualified domain name
The most common way of doing this is to create the configuration file named /etc/resolv.conf. This file contains the configuration settings for the resolver, such as the default domain name and the IP addresses of the name servers it will use. We have created this in previous chapters and we'll use it here with every machine configured for DNS. This makes it easy to see what values we've set without searching in different places to find them and also means we can simply copy the file from machine to machine as required. Forward and Reverse Lookups We saw in Figure 16.3 the steps involved in resolving the host name www.sun.com (that is, finding its IP address). These steps are known as "forward lookups" and are the most common type of lookup carried out. They are generally used when a user wants to connect to a machine (for example, by entering a URL into a Web browser). Reverse lookups go the other waywe know the IP address but need to determine the domain name. These types of requests are usually carried out by the system itself. For example, Web and ftp servers often use them to try and obtain the name of the connecting system, to output the information to a human-readable log file. In fact, many systems will terminate the connection if they cannot perform a valid reverse lookup and determine the host name of the machine connecting in. A gTLD named ".arpa" is actually used for reverse lookups. The domain itself was part of the "original" Internet. It builds up a tree exactly in the same way as the other gTLDs, but this one is ordered by IP address, rather than domain name, as shown in Figure 16.4. Figure 16.4. The in-addr.arpa reverse domain. 
When we create our DNS server later we'll see how to define entries that will allow both forward and reverse lookups to be performed on our systems. | 
