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

[bernd.casimir at daimlerchrysler.com]

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.
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.
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.

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.

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...

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.

> > 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.

> > 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.

> > 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

> > Over 30.000 productive clients are running very fine with this
solution.
> > The only drawback is that there must be a memory leak in nmbd as the
used
> > memory
> > increases from hour to hour and we have to restart nmbd every night...
>
> 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.

> > 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.

>   - 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.
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.

> 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.
In our solution the clients are forced to have the same name what is our
purpose.

> .... 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.

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.

> 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.

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

Bernd