On Wednesday 28 January 2009, Jean-Louis Martineau wrote:
>What do you get if you run:
>  /usr/bin/smbclient '//not.a.host.name/notashare' -U nosuchuser -N -Tx
>/dev/null
>
>Maybe your DNS is slow to return that 'not.a.host.name' is not a valid
>hostname
>Check your DNS configuration.
>
>Jean-Louis
Humm:
[root@coyote media]# /usr/bin/smbclient '//not.a.host.name/notashare' -U 
nosuchuser -N -Tx /dev/null
timeout connecting to 208.69.32.132:445
timeout connecting to 208.69.32.132:139
Error connecting to 208.69.32.132 (Operation already in progress)
Connection to not.a.host.name failed (Error NT_STATUS_ACCESS_DENIED)

These addresses above are not quite exactly the dns servers being used here.
208.67.222.222
208.67.220.220
Those are from opendns (I got sick of verizons <85% uptime for theirs) and the 
opendns servers are typically 50%  faster than verizon's, with so far 100% 
uptimes.

All dns queries from this box goto the gateway machine, an old x86 box with 3 
nics it it, running dd-wrt.  On this same page of its display, I have 3 other 
dhcp/dns related items checked, which are:

Use DNSMasq for DHCP
Use DNSMasq for DNS
DHCP-Authoritative

They might have an effect, particularly the middle one.  I turned it off, and 
the delay is still the same, but the message is slightly different:

[root@coyote ~]# /usr/bin/smbclient '//not.a.host.name/notashare' -U 
nosuchuser -N -Tx /dev/null
Connection to not.a.host.name failed (Error NT_STATUS_BAD_NETWORK_NAME)

Next, I'll turn off the last one...  And that takes me back to the original 
message:
[root@coyote ~]# /usr/bin/smbclient '//not.a.host.name/notashare' -U 
nosuchuser -N -Tx /dev/null
timeout connecting to 208.69.32.132:445
timeout connecting to 208.69.32.132:139
Error connecting to 208.69.32.132 (Operation already in progress)
Connection to not.a.host.name failed (Error NT_STATUS_ACCESS_DENIED)

dnsmasq is running on this box also, with these apparently default arguments 
according to htop:

/usr/sbin/dnsmasq -s coyote.den

And that doesn't look right, it should be router.coyote.den I'd think, but NDI 
what to do to fix that.  Acc the manpage, there should be an = after the -s, 
and a FQDN address, but all it shows is the domain name, and looking at the 
starter script in init.d/dnsmasq it looks as if they do not use the = sign 
either.

FWIW The delay is also just about an even 40 seconds.

Here, all boxes use the router as the second choice if the requested name is 
not in the /etc/hosts file.  The router, dd-wrt, if it doesn't have it in its 
cache, forwards it to opendns.org's servers.  And except for this, response 
is essentially instant over a 1.5/256 adsl circuit.

It is probably here, this lag also occurred several times before I switched to 
opendns.org's dns servers, which was a week ago early yesterday morning, 

Bind(named) is not running on the local net, all machines are set to hit the 
router for names not in their hosts file.

On the dd-wrt screen, there is a place to set a 'WINS' address, currently 
zeroed out, I assume that is for a WIN Server, aka something that samba might 
need?  But its (samba) is working just fine here.  After a lot of wrangling I 
did manage to convince the rest of the network here that this machine was the 
samba master.  So I set that to point at this machine, but it didn't help.  
Cleared again.

Call me stumped|stupid I guess.

What else can I fiddle with?  Something in smb.conf maybe?  It seems to me 
that there should be something there to restrict the search to local, but I 
don't seem to find that.  And I'd consider having samba go out on the net 
looking for name resolution to be a security hole, a big one at that.

Thanks, Jean-Louis.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Vail's Second Axiom:
        The amount of work to be done increases in proportion to the
        amount of work already completed.