Resolver Setup


Now that your caching nameserver is working, it's time to tackle the other half of DNS: the resolver. As seen in Chapter 1, when a name lookup is required, a resolver performs the steps necessary to resolve the query. The details of the resolution will be taken care of by a nameserver, but your host OS needs a way to talk to the nameserver.

The OS resolver is not part of DNS, but it does use DNS for resolving hostnames. However, it also uses other sources. Chief among the other sources is the local /etc/hosts file and NIS (formerly known as YP). If the resolver configuration indicates that DNS should be used for hostname resolution, a local recursive DNS server is contacted and it performs the actual resolution described in Chapter 1. The OS resolver merely sends the initial query, say for the A record of www.amazon.com, to the local DNS server. The caching nameserver we set up just now is just such a local and recursive DNS server. The relationship between the resolver, DNS, and other name services is shown in Figure 2.1.

Under UNIX, the OS resolver is part of the standard C library. Newer versions of this library do not need any configuration if a nameserver is available locally. Older versions, on the other hand, do require it. If the nameserver is not available locally, you will need it, so we will set it up.

Figure 2.1. The relationship between the resolver, DNS, and other name services.

graphics/02fig01.gif

The UNIX resolver is configured in one, or sometimes two, files. All UNIX systems share this file: /etc/resolv.conf. Vendor variations exist in the contents allowed in this file. I will not go into the differences each vendor allows and the extensions they have made here. For more information, see the OS man page for this file, which is often called resolver(5) rather than resolv.conf(5).

/etc/resolv.conf

If the OS resolver is to use DNS, it consults /etc/resolv.conf to find out how to communicate with DNS, as well as some other necessary specifics.

Nameserver

You can define as many as three nameservers in the file. You do it by entering lines such as the following:

 nameserver 127.0.0.1 nameserver 192.168.0.1 

In this code, I defined two nameservers. The first one is 127.0.0.1, which is the local host on which we now have a working nameserver. The second one is 192.168.0.1, which is the IP number of a DNS server internal to the network to which my computer is attached. If the first nameserver fails for some reason, the second one will be tried. The timeout for a query to be seen as failed is quite long, though, so if it fails, you will notice long pauses as the resolver waits for the timeout to occur.

Domain

You also can define a domain within which your resolver will look for hostnames unless you specify an FQDN, with the trailing dot, as in the following example:

 domain linpro.no

This specifies that, when I type telnet cat, the resolver will append linpro.no to the name and try to resolve cat.linpro.no. This is handy because having to type the whole name every time would be tedious. An interesting side effect in all but the newest of resolvers is that when I type telnet math.uio.no, the resolver tries to look up math.uio.no.linpro.no, and when that fails, it tries math.uio.no. Fortunately, the first query will fail quickly, and the delay will in most cases be imperceptible. Had I typed telnet math.uio.no. with the trailing dot, the resolver would have known it was an FQDN and would have looked up math.uio.no at once, without trying to append the specified domain first. Not all applications are tolerant of the trailing dot, though, so it can't always be specified.

The newest resolvers will not append the domain name if a dot is in the name given it to look up. However, this behavior is configurable. See the man page for more information.

Search

Newer resolvers support another directive as well search. In the search directive, you can list the domains in which you want your resolver to search, as in the following:

 search linpro.no uio.no ifi.uio.no

This specifies that the three domains linpro.no, uio.no, and ifi.uio.no are to be appended to the given name in turn until the lookup succeeds. When ssh gram is executed, the resolver first looks for gram.linpro.no, which does not exist; then gram.uio.no, which does not exist, either; and finally gram.ifi.uio.no, which will succeed because it does exist.

How many domains, totaling how many characters, you specify varies some; check the man page.

Search and domain are mutually exclusive, so if both are found, the last one will prevail.

Other Things

Some vendors have extended /etc/resolv.conf to configure more aspects of resolving than just DNS. SGIs IRIX enables you to specify the order in which name services such as DNS, NIS (formerly YP), and the /etc/hosts file are queried. This too is discussed in the man page.

Other Files

Quite a few UNIX systems use an additional file to configure the resolver. Whereas /etc/resolv.conf enables you to set up DNS resolution, you also might need to specify that DNS is to be queried at all. Some OSes, including older AIX, take the mere presence of a /etc/resolv.conf file as an indicator that DNS is to be queried. In contrast, Solaris, Linux, and most new versions of UNIX do not. They require additional configuration to query DNS.

/etc/nsswitch.conf

Several UNIX systems, including Solaris, Linux, and so on, use /etc/nsswitch.conf to configure which name services the resolver should use. If your system has a man page for this file, it should use it. If you look in it, you will find a line starting with hosts:. This specifies which services will be queried for hostnames. Most UNIX systems support dns, nis, and files for /etc/hosts. They also might support other name services such as nisplus.

Most times you will want just files and dns in some order that suits you. The following is one possibility:

 hosts:  files dns

The previous code enables me to override DNS by entering things in /etc/hosts. This can be helpful when I do development work and want to connect to development servers instead of production servers without changing the code, or configuration files, on which I'm working.

/etc/host.conf

On some versions of some OSes, the /etc/host.conf file specifies the resolution service order. If so, a single line similar to the following will specify the same order as shown in the previous nsswitch.conf file:

 order hosts,bind

This code specifies that the /etc/hosts file comes first, and then BIND and DNS.

And So On…

Some UNIX systems, especially older versions, use other files to specify name service order. On newer resolvers, the resolv.conf file doesn't even need to be present because, when nsswitch.conf specifies DNS and no resolv.conf exists, 127.0.0.1 is queried. On some UNIX systems, though, the presence of a resolv.conf file is required because DNS won't be queried without it.

As time passes, more and more UNIX systems are switching to resolv.conf and nsswitch.conf. Luckily, this makes the system administrator's task easier, eliminating the need to remember how the various UNIX systems differ.

In any case, after the resolv.conf file and possibly one other file has been set up, any network software on your computer, such as telnet, ssh, and Netscape, should be capable of using domain names from DNS. Try it.

Client Resolver

After you know your name daemon works and that it can resolve hostnames for the host on which it runs, it is time to configure all the clients who are going to use the nameserver. You must configure the resolver on each of them as well, just as you set it up on the server, configuring /etc/resolv.conf and any other files as needed. Windows, Macintosh, and other OSes will also be able to use your BIND-based name daemon without problems. Configuration methods vary even more wildly than on UNIX, though.



The Concise Guide to DNS and BIND
The Concise Guide to DNS and BIND
ISBN: 0789722739
EAN: 2147483647
Year: 1999
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net