While writing a script, I wanted to reference a machine by the computer name that I gave it (e.g. "selenium-rc"). I could not ping it using "selenium-rc", so I tried the following commands to see if the name was recognized.

> traceroute
traceroute to (, 64 hops max, 52 byte packets
 1  selenium-rc (  0.545 ms  0.241 ms  0.124 ms

Ok, traceroute "found" the name. How? Next ...

> traceroute selenium-rc
traceroute: unknown host selenium-rc

Hmm ... the lookup mechanism here must be different because the host is unkown. I'm assuming this is using a system name resolution process whereas the first example was using a process specific to traceroute. Correct?

Then when I came back a bit later ...

> traceroute
traceroute to (, 64 hops max, 52 byte packets
 1  minint-q4e8i52.mycorp.net (  0.509 ms  0.206 ms  0.136 ms

Ok, different result. The "selenium-rc" name did not change on the machine itself, but the traceroute name resolution process must include some sort of priority and now gives a presumably more authoritative result assigned by another system/service on the network. (Unfortunately, I'm assuming it's a dynamic name that I do not control, and thus it would not be useful in a script.)

Can someone explain the results?


Generally, in Linux, and Unix, traceroute and ping would both use a call to gethostbyname() to lookup the name of a system. gethostbyname() in turn uses the system configuration files to determine the order in which to query the naming databases, ie: /etc/hosts, and DNS.

In Linux, the default action is (or maybe used to be) to query DNS first, and then /etc/hosts. This can be changed or updated by setting the desired order in /etc/host.conf.

To search /etc/hosts before DNS, set the following order in /etc/host.conf:

order hosts,bind

In Solaris, this same order is controlled via the /etc/nsswitch.conf file, in the entry for the hosts database.

hosts: files dns

Sets the search order to look in /etc/hosts before searching DNS.

Traceroute and ping would both use these methods to search all the configured naming databases. the host and nslookup commands both use only DNS, so they won't necessarily duplicate the seemingly inconsistent results you're seeing.

Solaris has a lookup tool, getent, which can be used to identify hosts or addresses in the same way that traceroute and ping do - by following the configured set of naming databases to search.

getent hosts <hostname>

would search through whatever databases are listed for hosts, in /etc/nsswitch.conf.

So. In your case, to acheive consistent results, add the following to /etc/hosts selenium-rc

And, make sure /etc/host.conf has:

order hosts,bind

Or, make sure that /etc/nsswitch.conf has:

hosts: files dns

Once that's done, you should see more consistent results with both ping, and traceroute, as well as other commands, like ssh, telnet, curl, wget, etc.

  • When I queried the DNS server listed in the resolv.conf file with the dig utility, I found both entries. I guess traceroute preferred the fully qualified one. – Keith Bentrup Sep 29 '11 at 16:01

Looks like you have reverse lookup set up properly, but not forward.

Your system can look up the IP address and recognize that it's selenium-rc, but when it tries to look up selenium-rc it fails.

I recommend you check /etc/hosts and /etc/resolv.conf; the behavior of the getaddrinfo system call is dictated by the latter and references the former.


My guess: invoking traceroute caused a DNS request to go out to find the name that goes with IP address traceroute -n is the way to start traceroute without it doing DNS lookups on each IP address it finds. The DNS server took longer to respond than the DNS system wanted to wait, so at first traceroute did not give a hostname for By the time traceroute sends out and receives packets from, your DNS server has responded, so traceroute can give a hostname for it.

So, I'd say "DNS server issues", with a very convenient timing that made you suspicious of other things. Think "Murphy's Law" here. When you came back a bit later, you get a different name for the same IP address, which also makes me think maybe someone was messing with the DNS server config during the time you were doing your traceroutes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.