Unix client resolving differently

[Stolen]

from the man pages for resolv.conf:

                         ndots:n   Sets a floor threshold for the
                                   number   of  dots  which  must
                                   appear  in  a  name  given  to
                                   res_query() (see resolver(3N))
                                   before  an  initial   absolute
                                   (as-is)  query  is  performed.
                                   The default for n is 1.  Thus,
                                   if  there  are  any  dots in a
                                   name, the name is tried  first
                                   as an absolute name before any
                                   search-list domain  names  are
                                   appended to it.

Cinense, Mark wrote:

>Thanks, options seemed to work.  Could you please tell me where you got that
>from.  I have not seen that before.
>
>Mark
>
> -----Original Message-----
>From: 	Stolen [mailto:stolen at thecave.net] 
>Sent:	Tuesday, November 19, 2002 6:20 AM
>To:	Cinense, Mark
>Cc:	comp-protocols-dns-bind at isc.org
>Subject:	Re: Unix client resolving differently
>
>It might have to do with the fact that chivas.mp actually exists.  I 
>imagine the resolver in your unix box is looking up chivas.mp. first, 
>and then if it didn't exist would look up chivas.mp.sandia.gov.
>You might want to add the following into your resolv.conf:
>options ndots:2
>
>
>Cinense, Mark wrote:
>
>  
>
>>Simon,
>>
>> 
>>
>>    
>>
>>>First nslookup really sucks for DNS troubleshooting - learn dig.
>>>   
>>>
>>>      
>>>
>>	No problem using dig here...
>>
>>Windows DIG results:
>>
>>F:\>dig @ns3.sandia.gov ANY chivas.mp
>>
>>; <<>> DiG 9.2.1 <<>> @ns3.sandia.gov ANY chivas.mp
>>;; global options:  printcmd
>>;; Got answer:
>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
>>;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
>>
>>;; QUESTION SECTION:
>>;chivas.mp.                     IN      ANY
>>
>>;; ANSWER SECTION:
>>chivas.mp.              43200   IN      A       64.65.105.59
>>
>>;; AUTHORITY SECTION:
>>mp.                     43200   IN      NS      ns1.nic.mp.
>>mp.                     43200   IN      NS      ns2.nic.mp.
>>
>>;; Query time: 460 msec
>>;; SERVER: 134.253.181.25#53(ns3.sandia.gov)
>>;; WHEN: Tue Nov 19 05:59:35 2002
>>;; MSG SIZE  rcvd: 83
>>
>>
>>UNIX DIG results:
>>
>># dig @ns3.sandia.gov ANY chivas.mp
>>
>>; <<>> DiG 9.2.1 <<>> @ns3.sandia.gov ANY chivas.mp
>>;; global options:  printcmd
>>;; Got answer:
>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 415
>>;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
>>
>>;; QUESTION SECTION:
>>;chivas.mp.                     IN      ANY
>>
>>;; ANSWER SECTION:
>>chivas.mp.              43082   IN      A       64.65.105.59
>>
>>;; AUTHORITY SECTION:
>>mp.                     43082   IN      NS      ns1.nic.mp.
>>mp.                     43082   IN      NS      ns2.nic.mp.
>>
>>;; Query time: 12 msec
>>;; SERVER: 134.253.181.25#53(ns3.sandia.gov)
>>;; WHEN: Tue Nov 19 06:02:03 2002
>>;; MSG SIZE  rcvd: 83
>>
>>BTW, my resolv.conf does have a search entry for my domain.  I looked
>>further into this issue, and noticed that I was using a different nslookup
>>    
>>
>>from what came with bind 9, which is what I am running here at sandia.  I
>  
>
>>tried that one, and still no luck.  I have to use the fully qualified name,
>>and then it resolves correctly.  Our legato server is resolving by short
>>name, and not FQDN.  I don't know how they are doing that, but they are.
>>
>>
>>Mark
>>
>>
>>
>> 
>>
>>    
>>
>
>
>
>
>  
>