[Pkg-samba-maint] Bug#459972: winbind: want to limit libnss_wins checks to WINS (no broadcasting)

[Steve Langasek]

On Thu, Jan 10, 2008 at 12:54:59PM -0500, Matt Swift wrote:
> test 1 (conditions A B)

>   corax% ping <unknown>
> 
>   DNS query for <unknown>.swift.private fails
>   assume that a WINS lookup fails
>   NBNS broadcast from Corax for <unknown> (3 packets)
> 
>   comment: Samba SHOULDN'T broadcast when "name resolve order" doesn't
>   contain "bcast" (condition B).

Yep, we agree this is a bug.

> test 2 (A B C D)

>   corax% nmblookup -U localhost -R <unknown>

>   fails, i.e., no network traffic, no broadcast

>   comment: Samba SHOULD broadcast when "name resolve order" contains
>   "bcast" (conditions B and D).  Comment below on test 4 may apply as
>   well.

I don't agree.  nmblookup -U has precise semantics, which are "query the
server at this IP".  -R additionally tells it "query it as a WINS server".
Neither of these requests will ever generate external network traffic with
any server, Windows, Samba or otherwise.

nmblookup is not a general-purpose resolver, it's a tool for interacting
with the NMB protocol.  Its behavior is designed to facilitate working with
NMB, not for giving end-users a one-click way to resolve names.

> test 3 (A B C D)

>   plankton% ping <unknown>

>   DNS query for <unknown>.swift.private fails
>   NBNS query to Corax for <unknown> fails
>   NBNS broadcast from Plankton for <unknown> (3 packets)

>   comment: Samba SHOULD broadcast when "name resolve order" contains
>   "bcast" (conditions B and D) -- but maybe Samba is smart enough to
>   refrain from broadcasting after a failed query from a WinXP client
>   that we know is going to fall back on doing a broadcast itself?

Er, if plankton is the WinXP client, it's that client's responsibility to do
a broadcast query for the name if it's a hybrid node and if the WINS server
doesn't know the name.  Samba as WINS server is not going to (should not) do
broadcast queries on behalf of clients for names it doesn't know about.
(For one thing, it's the common case that the client and WINS server will
not be in the same broadcast domain!)

> test 4 (A B C D)

>   plankton% nblookup <unknown>

>   NBNS query to Corax for <unknown> fails

>   comment: same as for test 3, but regarding the question is Samba
>   smart enough, etc., in this case, the assumption that Plankton will
>   fall back on a broadcast is wrong because the WINS query was made
>   with a diagnostic tool (nblookup) not the normal WinXP name
>   resolution procedure.

Yes, Windows won't fall back to a broadcast; but it's still not the WINS
server's responsibility to do a broadcast in that case.  That's not how the
protocol works.

So we still have the same one bug here - nss_wins behaves in a manner
inconsistent with smbclient and samba wrt the "name resolve order" option.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org