name resolution algorithms [was Re: CVS update: samba/source/libsmb]

Gerald (Jerry) Carter jerry at samba.org
Thu Jun 26 04:10:49 GMT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26 Jun 2003, Andrew Bartlett wrote:

> > > I was thinking about 'nice' ways to solve this.  It looks like we really
> > > do have a completely different name resolution system for ADS - so why
> > > not have "ads" as the resolve type - that we now pass as a parameter?
> > > 
> > > This should mean we never have lookups for netbios domain names in DNS.
> > 
> > No.  Correctly configure the 'name resolve order' and you should not see
> > netbios lookups via DNS.  At this stage, 'name resolve order' is basically
> > for netbios only.  Just set "name resolve order = wins bcast".  Done.
> > No need for another value to confuse things.  It works fine as it is.
> > Just needs docs.
> 
> Except that the current default is "name resolve order = lmhosts wins
> host bcast" which I think it quite useful.
> 
> I see the 'host' name resolve type for <00> names (which will often have
> a one-to-one mapping to netbios names) to be quite useful.  

No.  only type 0x20.  And if you don't want netbios name going to DNS, 
then you shouldn't have hosts in there in the first place.

> What I'm worried about is the lookups for _tcp._ldap.DOMAIN, which would
> ocour when looking for an ADS DC, but which *will not* find the
> answer.   

Why not.  Has the admin screwed up?

> Naturally, this won't occur if the domain is validly in WINS,
> but this doesn't always happen.  

You make no sense here.  If the DOMAIN#1c record is not in WINS
a large network based on netbios names will not operate.

> Currently, if I understand this correctly, we will do a DNS lookup
> (which we know will fail) *before* we broadcast.  Why do that lookup
> (which is not a normal 'hosts' lookup) at all?

what?  If you are working in "security = ads" the we'll lookup 
the SRV RR _ldap._tcp.domain in DNS.  If it's not there then you really
have a broken DNS.  But nevertheless we will drop back to looking up the
DOMAIN#1c name in lmhosts wins (also DNS in the default case this case) 
and finally broadcast.

Think for second.  If I'm a large organization, I have to be using either 
DNS or WINS.  If neither is working I'm already in trouble.  Broadcast 
should only be used in small cases (small offices that don't really care 
anyways).  So in the default case, DNS should never be not for the 
DOMAIN#1c record.  

Fix your servers first.  You've got bigger problems than Samba at this 
point.

> This is a very special case of lookup, why not deal with it as such?

dude, you're overly complicating the code making special cases here and 
there.  We now have **one** way to call to get a DC list.  The code is 
much cleaner, much more robust to failures, and much faster in the event 
of dead servers.

Have you run the code and looked at the log file?  

The code works.  It can still be tweaked some which I'll probably get
around to, but I accomplished what I intended.  It is fine under 
default circumstances where the admin has a half way working network.
I'll come back to it, but now I have bigger fish to fry in the 3.0 code.

If you want to fix something, go ahead.  But if you mess up the simplicity 
and consistency of get_dc_list(), I will revert the changes..  






cheers, jerry
 ----------------------------------------------------------------------
 Hewlett-Packard            ------------------------- http://www.hp.com
 SAMBA Team                 ---------------------- http://www.samba.org
 GnuPG Key                  ---- http://www.plainjoe.org/gpg_public.asc
 "You can never go home again, Oatman, but I guess you can shop there."  
                            --John Cusack - "Grosse Point Blank" (1997)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE++nJJIR7qMdg1EfYRAiYmAJ9Ix2JN9/jVGYA3FESCiNDH+yerogCfU0E4
aaG900hAQhCkx/a9qeI737k=
=dAOP
-----END PGP SIGNATURE-----




More information about the samba-technical mailing list