So much for the theory - let's go over what resolv.conf files look like on real hosts. Resolver configuration needs vary depending on whether or not a host runs a local name server, so we'll cover both cases: hosts with local name servers, and hosts with remote name servers.
We, as the administrators of movie.edu, have just been asked to configure a professor's new standalone workstation, which doesn't run a name server. Deciding which domain the workstation belongs in is easy - there's only movie.edu to choose from. However, she is working with researchers at Pixar on new shading algorithms, so perhaps it'd be wise to put pixar.com in her workstation's search list. The search directive:
search movie.edu pixar.com
will put her workstation in the movie.edu domain, and will search pixar.com for names not found in movie.edu.
The new workstation is on the 192.249.249.0 network, so the closest name servers are wormhole.movie.edu (192.249.249.1) and terminator.movie.edu (192.249.249.3). As a rule, you should configure hosts to use the closest name server available first. (The closest possible name server is a name server on the local host; the next closest is a name server on the same network or subnet.) In this case, both name servers are equally close, but we know that wormhole is bigger (it's a faster host, with more capacity). So the first nameserver directive in resolv.conf should be:
nameserver 192.249.249.1
Since this particular professor is known to get awfully vocal when she has problems with her computer, we'll also add terminator.movie.edu (192.249.249.3) as a backup name server. That way, if wormhole is down for any reason, the professor's workstation can still get name service (assuming terminator and the rest of the network are up).
The resolv.conf file ends up looking like this:
search movie.edu pixar.com nameserver 192.249.249.1 nameserver 192.249.249.3
Next, we have to configure the university mail hub, postmanrings2x, to use domain name service. postmanrings2x is shared by all groups in the movie.edu domain. We've recently configured a name server on the host to help cut down the load on the other name servers, so we should make sure the resolver queries the name server on the local host first.
The simplest resolver configuration for this case is no configuration at all: don't create a resolv.conf file, and let the resolver default to using the local name server. The hostname should be set to the full domain name of the host, so the resolver can determine the local domain.
If we decide we need a backup name server - a prudent decision - we can use resolv.conf. Whether or not we configure a backup name server depends largely on the reliability of the local name server. A good implementation of the DNS named will keep running for longer than some operating systems, so there may be no need for a backup. If the local name server has a history of problems, though - say it hangs occasionally and stops responding to queries - it's prudent to add a backup name server.
To add a backup name server, just list the local name server first in resolv.conf (at the host's IP address or the zero address, 0.0.0.0 - either will do), then one or two backup name servers. Remember not to use the loopback address unless you know your system's TCP/IP stack doesn't have the problem we mentioned earlier.
Since we'd rather be safe than sorry, we're going to add two backup name servers. postmanrings2x is on the 192.249.249.0 network, too, so terminator and wormhole are the closest name servers to it (besides its own). We'll reverse the order in which they're tried from the previous resolver-only example, to help balance the load between the two. The resolv.conf file ends up looking like this:
domain movie.edu nameserver 0.0.0.0 nameserver 192.249.249.3 nameserver 192.249.249.1