Have you noticed that names and IP addresses that you put into /etc/hosts are correctly resolved by your browser - but not found when looked-up using host or dig? There's a simple explanation - and there are some solutions, too!

Programs like host, dig or nslookup will always call DNS servers directly. This can be very frustrating if you want to check a name that you've added to /etc/hosts - it will never be found.

To make things worse: the documentation says that either /etc/host.conf or /etc/nsswitch.conf will be used to determine if the hosts file is called before or after the DNS system is searched... but, if you use a Fedora-derived distribution of Linux you will find both of those files. They both say that the system resolver will search /etc/hosts first and DNS later - but removing the reference to the DNS system does not stop host, dig or nslookup from ignoring /etc/hosts and returning results from DNS servers.

What's going on?

It turns out that the name daemon, named, is strictly replying to DNS queries. It will search its own zone files and, if it can't find what you're looking for, it will ask other DNS servers - but it ignores completely the local files that play a role in the resolution of name and ip information.

Utilities like host, dig and nslookup are strictly designed to query the DNS system. They too ignore all the other files in your system that are involved in name resolution.

All the other software in your computer, though, will always resolve names using some local library software called the resolver. In reality there are different libraries that a program can use to resolve names and IP addresses - but there are some standard library functions, written in C, that are commonly used; these are the main functions that are called "the resolver."

Depending on the platform/distribution you are using and the software you have installed, a given resolver may not look for /etc/host.conf or /etc/nsswitch.conf. Or, it might use one or the other before checking the directives in /etc/resolv.conf.

Note that the resolver software is running on each individual system - workstation or server. Each system has its own local configuration files that resolver libraries are supposed to reference. Most importantly: The resolver, when trying to resolve names and IP's for you, will generate DNS requests to query the DNS system. It will never reply to a DNS request.

If you have a small local network you might not want to install the name daemon. You can still resolve host names on your workstations without local DNS. To do this, make a small /etc/hosts file and copy it to each of your workstations. Make sure that /etc/host.conf and/or /etc/nsswitch.conf are set correctly to search the hosts file before sending a DNS query. This way, your local machine names will be found in the hosts file and external names will be found through external DNS servers. Once you've got everything organized, you can verify that the names are being resolved correctly using the

$ getent hosts [name]

command. Getent is a utility that will call the standard local resolver functions to resolve the requested [name].

Internal DNS Views

Here's a problem that comes-up quite often in the software development world:

• You are developing intranet software for a customer.
• They have an intranet in their office and they have their own DNS system.
• You are targeting a server with a local host name on the customers' intranet.
• You want to test your software on your local development server and you want to use the same host name that your customer will be using.

The solution, of course, is to configure your systems to get your development server IP in return for the customers' host name - in effect: a local view for an external name. There are two ways to do this:

• Put the name into the local /etc/hosts file for each internal workstation that should use the local IP address or
• Add an appropriate zone to your DNS server. This is the only way for your DNS server to respond to the requests for the desired host name.

Unfortunately, the second option will result in your DNS server trying to reply to all requests for that domain on your network. If your customer is using the same domain name for their internal servers as for their external servers - you won't be able to access any of their external servers without having to manually duplicate the necessary host/ip information in your local zone file.

There is a new feature, as of version 9 of BIND, that improves this situation slightly: Views in BIND v9+ allow your DNS server to respond differently to clients calling from different networks. With BIND v9+ you could, for example, put your programming staff on a different subnet within your office. You could then create a view in BIND, let's call it the programmers' view, for that subnet. It would include a zone file for your customers' domain so that the programmers would be directed to their development server when they use that domain. The other views in your DNS configuration would not include that zone file - so everybody else would be directed to the customers' domain.

0% of 0 voters found this FAQ useful,  I found this FAQ   useful   not useful