Only certain commands will resolve hostnames

[Kevin Darcy]

"dig" and "nslookup" are strictly DNS lookup tools and don't (except on
HP-UX, grrrr) consult the regular system config files to determine what
nameservices (e.g. DNS, /etc/hosts, NIS, NetInfo, etc.) to use. So the fact
that "dig bird.mydom.abc" and "nslookup bird" worked and the various
ping/telnet/ftp commands didn't, implies that you don't have your system set
up to use DNS. Your system is probably only configured to look for hostnames
in /etc/hosts. Apparently neither "bird" nor "bird.mydomain.abc" are in your
/etc/hosts file. On Linux, I think nameservices are configured in
/etc/nsswitch.conf.

As for the difference between "dig" and "nslookup", dig doesn't implement the
"search" functionality. So if you give dig a name like "bird" it will assume
you're trying to resolve a name in the root zone. nslookup, on the other
hand, will append your default domain to it. It would appear that your
default domain is "mydomain.abc", so the name which nslookup actually looks
up is "bird.mydomain.abc" and obvious that lookup works. Note that the
"search" behavior of nslookup is viewed by many (myself included) as more of
a bug than a feature, since it complicates the task of troubleshooting
DNS problems, which is what nslookup and dig were actually designed for.


- Kevin

Scott Rainaldo wrote:

> I am testing a DNS setup on a closed intranet, and have been seeing some
> strange behavior.  Some commands will resolve the hostnames of machines on
> the network correctly and others will not.  The nameserver is at
> 192.168.1.1 and is running Linux (Mandrake 7.2).  Can anyone explain this?
> The following is a listing of commands and whether they were able to
> resolve the hostname.
>
> dig bird:    no
> dig bird.mydom.abc:      yes
> nslookup bird:   yes
> ping bird:   no
> ping bird.mydom.abc:   no
> telnet bird:   no
> telnet bird.mydom.abc:   no
> ftp bird:   no
> ftp bird.mydom.abc:  no