Book Image

DNS in Action

By : CP Books a.s.
Book Image

DNS in Action

By: CP Books a.s.

Overview of this book

The Domain Name System is one of the foundations of the internet. It is the system that allows the translation of human-readable domain names into machines-readable IP addresses and the reverse translation of IP addresses into domain names. This book describes the basic DNS protocol and its extensions; DNS delegation and registration, including for reverse domains; using DNS servers in networks that are not connected to the internet; and using DNS servers on firewall machines. Many detailed examples are used throughout the book to show perform various configuration and administration tasks.
Table of Contents (16 chapters)
DNS in Action
Credits
About the Authors
Preface
Country Codes and RIRs
Index

1.8 Resolvers


A resolver is a component of the system dealing with the translation of an IP address. A resolver is a client; it is not a particular program. It is a set of library functions that are linked with application programs requiring services such as Telnet, FTP, browsers, and so on. For example, if Telnet needs to translate the name of a computer to its IP address, it calls the particular library functions.

The client (in this case, the aforementioned Telnet) calls the library functions (gethostbyname), which will formulate the query, and send it to the name server.

Time limitations must also be considered. It is possible that a resolver does not receive an answer to its first query, while the next one with the same content is answered correctly (while the server is waiting for the first query, it manages to obtain the answer for the second query from another name server, so the first query was not answered, because the response of its name server took too long). From the user’s point of view, it seems that the translation was not managed on the first try, but was completed by processing it again. The use of the UDP protocol causes a similar effect. Note that it can also happen that the server did not receive the request for the translation at all, because the network is overloaded, and the UDP datagram has been lost somewhere along the way.

1.8.1 Resolver Configuration in UNIX

The configuration file for a resolver in the UNIX operating system is /etc/resolv/conf. It usually contains two types of lines (the second command can be repeated several times):

domain the name of the local domain
nameserver IP address of name server

If the user inserted the name without a dot at the end, the resolver will add the domain name from the domain command after the inserted name, and will try to transfer it to the name server for translation. If the translation is not performed (a negative answer has been received from the name server), the resolver will try to translate the actual name without the suffix from the domain command.

Some resolvers enable the search command. This command allows us to specify more names of local domains.

The IP address of a name server that the resolver should contact is specified by the nameserver command. It is recommended to use more nameserver commands for times when some name server is not available.

Note

The IP address of a name server always has to be stated in the configuration file of the resolver, not the domain name of the name server!

When configuring the resolver and name server on the same machine, the nameserver command can be directed to a local name server 127.0.0.1 (but this is not necessary).

Other parameters of the resolver (for example, the maximum number of nameserver commands) can be set in the configuration file of the operating system kernel. This file is often called /usr/include/resolv.h. Afterwards, of course, a new compilation of the kernel operating system must follow.

Generally, it is also possible to configure all computers without the use of DNS. Then all requests for address translations are performed locally with the help of the /etc/hosts file (in Windows %System_Root%/System32/Drivers/etc/hosts). It is possible to combine both methods (the most typical variant); however, we need to be careful about the content of the database /etc/hosts. Usually it is also possible to set the order in which the databases are supposed to be browsed. Usually one /etc/hosts file is browsed and afterwards the DNS.

1.8.2 Resolver Configuration in Windows

There is an interesting situation in Windows 2000 and higher. Here we still have the previously mentioned DNS Client service. It is an implementation of a caching resolver. This service is started implicitly. It is strictly recommended in the documentation not to stop this service. However, according to my tests, Windows acts like a station with a stub resolver after stopping this service.

The content of a resolver cache can even be written out by a ipconfig /displayDNS command or deleted by ipconfig /flushDNS command.

The content of a %System Root%/System32/Drivers/etc/hosts file whose content is not changed by the ipconfig /flushDNS command is also a part of the cache resolver. The cache resolver can be parameterized by the insertion or change of keys in the Windows register folder HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Dnscache/Parameters, for example, by a NegativeCacheTime key, where you can specify a time period within which negative answers kept in the cache resolver can be changed.

Figure 1.8: Configuration of a resolver in Windows XP

In older Windows versions, the configuration of a resolver was as simple as it was in UNIX. The difference was only in the fact that a text configuration file was not created by a text editor, but the values were inserted into a particular window. With Windows XP this particular configuration window of the resolver (Figure 1.8) contains a lot more information.

It is necessary to look at Windows XP and higher from a historical point of view. The LAN Manager System based on NetBIOS protocol was the predecessor of the Windows network. NetBIOS protocol also uses names of computers, which it needs to translate to network addresses in the network layer. When Windows uses TCP/IP as a network protocol, it needs to translate the names of computers to IP addresses and vice versa.

LAN Manager implemented its own system of names. Names with particular IP addresses were saved locally in a %SystemRoot%/System 32/Drivers/etc/lmhosts file. Later Windows implemented a DNS analogy, a database called WINS (Windows Internet Names Service).

The translation of names is an interesting problem in Windows. When a translation is not found either in an lmhosts file or on WINS server, it is then sent to a broadcast requesting whether the searched for computer is present on the LAN. Searching in DNS after the implementation of DNS into Windows has extended the entire mechanism. So programs in Windows 2000, which have LAN Manager system as a precursor search for the translation:

  1. 1. In the LAN Manager cache of a local computer (nbtstat -c command lists the cache). It is a cache of the NetBIOS protocol. Rows of the lmhosts file, having the #PRE string as a last parameter, are loaded into this cache when a computer starts. If the lmhosts file is changed, we can force reloading of these rows into a cache by the nbtstat -R command.

  2. 2. On WINS servers. By a broadcast or multicast on LAN.

  3. 3. In the lmhosts file.

  4. 4. In a resolver cache (even the content of hosts file is read into it).

  5. 5. On DNS servers.

And programs (for example, the ping command) that are Internet oriented search for the translation:

  1. 1. In the resolver cache (even the content of hosts file is read into it).

  2. 2. On DNS Servers.

  3. 3. On WINS servers.

  4. 4. By a broadcast or multicast packet of NetBIOS protocol.

  5. 5. In the lmhosts file.

So if you make a mistake in the name of the computer in the ping command, then in the record of a MS Network Monitor program or in the record of an Ethereal program (visit http://www.ethereal.com for additional information) you will also be able to see the packets of NetBIOS protocol and even the search conducted by a broadcast.

Now to the configuration of a resolver in Windows XP in Figure 1.8. First we will insert the IP addresses of name servers into the upper window (DNS server’s address, in order of use). It is not necessary to insert them if we get them during the start up of the computer, for example, from a DHCP server or during the establishment of a dial-up connection with the help of PPP protocol.

Furthermore, there are two options here:

  1. 1. Select Append primary and connection specific in DNS suffixes in the DNS tab (this option is not selected in Figure 1.8); the translation is performed as follows:

    • If the required name contains a dot, then the resolver tries to translate the name without adding a suffix.

    • If the name does not contain a dot, it tries to translate the inserted name after which it has added a dot and a domain name of a Windows domain (configured on Properties in the Computer Name tab).

    • It tries to translate the inserted name after which it has added a dot and a name of a chain in a field DNS suffix for this connection.

  2. 2. Click Append these DNS suffixes (in order); the translation is performed as follows:

    • If the required name contains a dot then the resolver tries to translate the name without adding a suffix.

    • It tries to add particular suffixes according to a list listed in the window below the mentioned option.

So if you make a mistake in the name of the computer and hit a nonexistent name xxx, then because you have selected a second option, the resolver will first try to translate the name xxx.bill.company.com and then a name xxx.sec.company.com. In both cases, it will generate a query to the name server 195.70.130.1 for each of these translations and then if you do not receive the answer in time, it will repeat the question to the server 195.70.130.10, and the whole cycle is repeated until the time limit is exceeded.