How does traceroute resolve names?

Question

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 192.168.235.41
traceroute to 192.168.235.41 (192.168.235.41), 64 hops max, 52 byte packets
 1  selenium-rc (192.168.235.41)  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 192.168.235.41
traceroute to 192.168.235.41 (192.168.235.41), 64 hops max, 52 byte packets
 1  minint-q4e8i52.mycorp.net (192.168.235.41)  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?

Answer 1

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

192.168.235.41 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.

Answer 2

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

Your system can look up the IP address 192.168.235.41 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.

Answer 3

My guess: invoking traceroute 192.168.235.41 caused a DNS request to go out to find the name that goes with IP address 192.168.235.41. traceroute -n 192.168.235.41 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 192.168.235.41. By the time traceroute sends out and receives packets from 192.168.235.41, 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.