host versus nslookup

Kevin Darcy kcd at chrysler.com
Wed Oct 12 22:09:41 UTC 2011


On 10/12/2011 5:46 PM, Sten Carlsen wrote:
>
>
> On 12/10/11 22:33, Fajar A. Nugraha wrote:
>> On Thu, Oct 13, 2011 at 3:23 AM, Sten Carlsen<stenc at s-carlsen.dk>  wrote:
>>>> Use dig.
>>>>
>>>> Always use dig.
>>> I don't quite agree, for debugging bind, use dig - for debugging lookup
>>> issues on some machine, host will behave more like any normal program, using
>>> resolv.conf and what else and can point to some issues dig will not
>>> discover. E.g. normal SW using something else than DNS, because of some
>>> setup. Dig will never catch this.
>> If you're concern about what address programs gets when they resolve
>> host names, then getent is a better choice as it also respects
>> nsswitch.conf and hosts file.
> I just tried to make the point that dig is NOT always the perfect 
> tool, it depends what you want to know. Using dig tells you about DNS, 
> host and getent and even nslookup tells you more about the behaviour 
> of your system.
As far as I know, only HP-UX has hacked nslookup to look at /etc/hosts. 
And I don't think it even looks at the "switch" file or other naming 
sources (e.g. Yellow Plague). HP-UX's nslookup "enhancement" is a 
one-off, I believe.

On most platforms, the only way that nslookup is "closer" to the OS 
name-resolution mechanism than dig is that nslookup will do 
suffix-searching, whereas dig will not. But even then, I think nslookup 
uses its own version of the resolver library to do that, so if one is 
trying to troubleshoot a problem with the OS'es suffix-searching 
behavior using nslookup, one might be comparing apples to grapefruit 
(or, since we're talking about nslookup here, perhaps I should say 
uglyfruit).

                                                                         
                                                                         
                                             - Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20111012/990d7786/attachment.html>


More information about the bind-users mailing list