nmbd uses only first IP address even when more are returned by DNS

[Christopher R. Hertel]

On Fri, Oct 17, 2003 at 06:02:21PM +0200, bernd.casimir at daimlerchrysler.com wrote:
> 
> On Thu, Oct 16, 2003 crh wrote:
> > On Thu, Oct 16, 2003 at 09:19:47AM +0200, bernd casimir wrote:
> > > Hi,
> > > to get rid of the inconsistency problems between WINS and DNS we
> modified
> > > the SAMBA nmbd
> > > to use DNS as the only source to respond to WINS name queries
> > > (WINS-to-DNS-Proxy).
> >
> > Oh, that's ugly.
> 
> That's necessary for security and operating stability reasons:
> 
> WINS was designed for small networks to provide a selfregistering
> nameservice.
> For large networks normally you don't want that any client can add its name
> - especially if this name already exists in DNS with a different meaning.

Then you're defining a different type of service.  That's okay, just keep 
in mind that it isn't an NBNS (because you're right, it had different 
design goals) and it's not DNS (because the DNS works with DNS names, not 
NetBIOS names).

> For the same security reason you should disable uncontrolled D-DNS updates.
> In our environment only DHCP servers are allowed to update DNS.
> Therefore all DHCP clients are registered with their name in DNS - even if
> they cannot update WINS or DNS in a secure way directly.
> And this is the only chance to detect conflicts and react in the correct
> way.

...but there's an inherent problem.  There is no (standard) mechanism (of
which I'm aware) for setting the NetBIOS base name via DHCP.  In contrast,
there is a way to set the DNS hostname via DHCP.  In many cases, the
NetBIOS name will be hard-coded in the config.  If the DNS name matches
and is also in the config (and if your DynDNS server accepts this) then
you're okay.  If you are assigning DNS hostnames to the DHCP clients, then
the likelyhood of a mismatch (the NetBIOS basename not matching the DNS
hostname) goes up.

> For example our IP address management system (Lucent QIP) protects static
> DNS entries so no DHCP client can overwrite a DNS entry by accident. A suffix
> will be added to the DHCP client name so all DNS entries are unique and you
> have a chance to search for conflicting names.

We use QiP as well.  That bit about adding the suffix... well, again
you're dealing with DNS names, and you're also talking about
server-assigned names.

> Our Windows-NT environment was running fine without WINS - we configured
> "use DNS for NETBIOS name resolution" and were able to abandon WINS.
> The drawback to have no browselist anymore was very small as a browselist
> doesn't make sense if you have several thousands of servers and printers.

If it's divided into multiple workgroups it shouldn't be a problem.  In
any case, keep in mind that without WINS the only NetBIOS service you can
reliably access is SMB filesharing.  All others (eg., as you mentioned,
the Browse Service) are unfindable across router boundaries.

Hmmm...  well, there are some other services that use the machine name as 
a base name, and I suppose you could find them (as long as the client 
knows to add the correct suffix after the base name has been resolved by 
the DNS).

> Unfortunately meanwhile we have to use WINS again for
> - W2K or XP clients which want to change passwords in a NT domain
> or
> - NT clients where the users have been migrated to Active Directory
> 
> But for these purposes only Domain Controllers are necessary to be resolved
> by WINS.
> That's the reason for a WINS-to-DNS-proxy...

...but it's still a special-purpose kludge.

> Another problem is that XP clients send out WINS and DNS queries at the
> same time
> and use the answer which comes back first.
> This can lead to very ugly race condition problems which are very hard to
> debug
> if there are inconsistencies between WINS and DNS.

That's a bug in XP behavior.  :)

> > > To be able to respond to domain controller queries we added some lines
> of
> > > code that adds
> > > "-PDC" to the DNS query when a client requests a name with type "1B"
> and "
> > > -DC" if it is type "1C".
> >
> > Are these modified versions of the names?  I assume that the name
> > <workgroup>-PDC is added to the DNS to identify the PDC, is that what
> > you're doing?
> 
> Exactly.

Again, that's a very special purpose solution.  I don't see any reason 
that a general purpose tool such as Samba should support it.

There are also two problems with it.  First, the <1B> name represents the 
Domain Master Browser service, not the PDC.  The PDC registers a <1C> 
group name.  Now, as it happens, in the Windows world the PDC and the DMB 
must be the same machine.

Note also that the <1C> names are a special case group names in WINS.  
<1C> names are actually handled per the RFCs, which is unusual given that
WINS normally (incorrectly) sends back 255.255.255.255 in response to a
group name query--Samba does the same because we have to.  Anyway, in
response to a <1C> query a WINS server sends back a list of IP addresses,
one per Domain Controller for the given NT Domain.  As a further fudge on
top of all of this mess, the first IP address returned in that list is the 
PDC IP.  That is one of the *correct* ways to find the PDC for an NT 
Domain.

If your DNS hack does not return the PDC IP as the first list entry, then 
you *may* have trouble.  I'm not sure how often we use this little fudge 
in Samba.

Another way to find the PDC is to use the "Primary Domain Controller 
Location Protocol", which is outlined here:

  ftp://ftp.microsoft.com/developr/drg/CIFS/cifsbrow.txt

See Appendix B.  There is probably a newer RPC-based variant as well.

> > > Unfortunately nmbd uses only the first IP address of the DNS response -
> > > even when several domain controllers are reported by DNS.
> >
> > The code was probably written to deal with WINS queries, in which case
> > the first IP returned in response to a <1C> query will be the IP of the
> > PDC.
> 
> OK, but if the PDC is down it would be better for the clients to
> have some other IP addresses available where they can try to contact a BDC.

To perform a domain logon or such, yes.  If you just want any DC then any 
of the IPs will do.  If the first one doesn't work, then use the second, 
and so on.

Again, what version of Samba are you running?

> > > Do you think this can be modified in a later version of samba?
> >
> > Why would we want to do that?
> 
> I think nmbd should return all IP addresses which are available - for
> redundancy purposes

You mean, if it does a DNS lookup to find a <1C> name?  Hmmm...  I'll have 
to think about the implications.

I'll have to see what happens if the lookup is done against a WINS server.  
If this kind of kludge is going to work, then the response should be as 
close to the real thing as possible.  In theory, when Samba is attempting 
to perform an operation against a DC any DC in the NT Domain should work, 
but we need to ensure that the PDC IP is at the top of the list as WINS 
does.

> > Is the memory leak in your code or ours?  Which version of Samba?
> 
> I don't know.
> I think there is no easy way to detect the root cause of a memory leak...
> We are using version 2.2.1a at the moment.

The reason we produce new releases is because we improve things.  
Sometimes there are bugs that need fixing, other times we add or improve
features.  The most recent version of the 2.2.x chain is 2.2.8a.

> > > PS: If you are interested in the modifications for a WINS-to-DNS-Proxy
> > > I can post the diffs...
> >
> > I am deeply opposed to the idea of nailing the NetBIOS namespace to the
> > DNS namespace.  The NetBIOS namespace is separate, and has the following
> > characteristics:
> >
> >   - It is flat.  There is no hierarchy, as there is in the DNS world.
> >   - It is localized.  Under NBT, the NetBIOS namespace is defined by the
> >     local IP broacast domain or by the share NBNS (WINS server) or by the
> >     union of the two.  Your NetBIOS namespace is distinct from mine.  The
> >     DNS namespace, in contrast, is meant to be global (which is why there
> >     is a hierarchical structure).
> 
> Therefore I added a smb.conf parameter called "dns fqdn = xyz.test.com" to
> define where this flat namespace should be linked to the hierarchical DNS
> world.

Again, that's a localized solution (and really should be handled by the
DNS name resolution subsystem on the host).

> >   - DNS names map to IP addresses.  NetBIOS names map to applications or
> >     services.  The NBT layer provides the IP address at which the name
> >     can be found, but the *meaning* of the NetBIOS name is quite different
> >     from the meaning of the NetBIOS name.
> 
> As mentioned before - the only application we need is to find PDCs and DCs.
> All other applications should be looked up in DNS.

...and really, as I mentioned before, this problem is the result of trying 
to graft one namespace onto another.  It just becomes one kludge on top of 
another.

> This is also a safe way to control what is resolvable by WINS so you have a
> chance to get rid of it completely when all clients have been migrated to
> AD.

Migrating to Active Directory isn't really the core of the issue.  As long 
as you have NT4, Win9x, WinME, and XP-Home systems around you'll be 
dealing with NBT and the NT Domain architecture (which are intertwined).

> > Using DNS names to locate NetBIOS services is, at best, a kludge.  Yeah,
> > it works, but it was never part of the original design of the NBT layer.
> > It works because 99% of the systems out there keep the DNS host name
> > consistent with the NetBIOS machine name.
> 
> Normally it makes sense to have the same NetBIOS machine name and DNS host
> name.

Yes, sure it does.  It's just not a requirement since both namespaces are 
separate.

Where I work, I once did a dump of our DNS (about 50K entries, as I
recall) and found six other hosts with the same hostname as my box.  
That's okay in a DNS environment because they were in separate subdomains.  
If we wanted to be in the same NetBIOS namespace, however, some of us 
would have had to change our NetBIOS basename.

> In our solution the clients are forced to have the same name what is our
> purpose.

Which is okay, but it's not a requirement of either protocol, nor is it
really "required" by any CIFS implementation (of which I'm aware).  
Windows boxes will try to encourage this.  The upshot, however, is that 
enforcement falls on your shoulders.

> > .... and there's the problem you're facing.  There are two or three base
> > names used by SMB systems to create all of the (several) NetBIOS names
> > they typically register.  The three most common base names are:
> > - The host name
> > - The workgroup name
> > - The logged-on user name
> >
> > The NT Domain names are built using the workgroup name, which is
> > (generally) not the same as the host name.  That in mind, you have to
> > assign several DNS names (CNAMES?) per IP address to fudge NetBIOS name
> > service behavior out of the DNS.  Ick.
> 
> Yes - and I can controll with this CNAMEs which clients will contact
> which BDC so every client will ask the nearest BDC first.
> These clients use different DNS domains to resolve WINS queries and
> you can link the PDC to another DNS domain so you can combine
> the hierarchical advantages of DNS with the flat WINS environment.
> 
> With WINS or nmbd this is managed randomly - even if the DC is far away
> and only reachable over a slow WAN link.

Not entirely randomly.  The PDC IP is always the first in the list, and 
the rest are in order of the last time they were registered or refreshed.

Of course, that doesn't help you at all.  :)

All of the problems you are facing, and all of the hoops you are jumping
through to try to bypass those problems, are reasons why Microsoft
redesigned SMB filesharing in Windows2000 (NT5).  By their nature, the NT 
Domain system, the Browse Service, and the flat namespace simply do not 
scale.

The reason I'm arguing with you (and I do hope you are taking it in the 
constructive, positive way I intend) is that you are really, truly running 
against the wind here.  Bending the NetBIOS namespace and your own DNS 
services to meet your needs is great, and it works for you.  It is not a 
general-purpose solution, however, so bending Samba itself does not really 
make sense.

I can look into the functions you are talking about.  In most cases, WINS 
only returns--and Samba only uses--*one* IP address in response to a 
query.  As described above, the <1C> name is a special (MS-kludged) case.

I think, however, that the best bet is probably to write your own function 
for the specific case you're interested in.  That's why we provide source, 
after all.

> Another advantage is that we can remove load from the PDC if a client needs
> only a normal DC. Remember that you can have only one PDC emulator for
> the whole AD environment and you don't want that all clients worldwide
> try to contact the PDC first which is default WINS behaviour.

Well, the default for WINS is that it returns the PDC IP address first in 
the list.

Yes, there are situations in which we could contact any DC in the list to 
get the results we need.  If we always use the first DC in the list, then 
we'll always be going to the PDC.

This is the crux of it, of course.  The problem is that there are other 
cases in which we *may* be looking for the PDC, in which case we do want 
the first in the list.  I'll have to see if we are really doing this, or 
if it's safe to write a function to return a random IP from a list.  
Perhaps the second IP, in this case.

> > No, I think we've already gone too far down the road of kludging things
> > to work with DNS.  Windows2000 introduced SMB without the NBT layer, 
> > and it is appropriate to use the DNS for name resolution in that space.
> > For NBT transport, using DNS lookups really should be the last resort,
> > not the first.
> 
> If you want to use W2K or XP clients with a NT-DC you have to use WINS.
> A DNS only solution is not working!
> The same for legacy clients (NT) which want to be part of AD.
> 
> Therefore we can use a DNS-only environment only when the last legacy
> client has been migrated. And this can last several years.

Right.  Because the legacy clients are using a different namespace, which 
has different servers.

> I only want to have a controllable name resolution system - no
> self-administered nightmare...

I hate to say this, but I really could (given some time) write a 
completely non-dynamic WINS server.  I could, you know.  :)

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org