No, I am right. I have done this on many servers that sit on the perimeter. There is ZERO reason to have NetBIOS enabled on an outside NIC, unless you are using a nested domain (a domain housed inside another domain) where you want to have replication of WINS info between multiple domains. It seems to me that it would be hard to pass judgement on an opinion where you are not familiar with the topic. NetBIOS is simply a core protocol heavily used in MS (SMB as well) systems, and was the foundation for NetBEUI (a very small, very fast broadcast-based protocol). When MS decided to ditch the effort on NetBEUI (I saw this mostly around '97-'98, but probably sooner with their gradual push into DNS and TCP/IP) and go into TCP/IP, they really pushed WINS as a solution for name and resource resolution. NetBIOS handles RPC information, such as using remote consoles for user and system management on remote systems, and should NEVER be left bound to a controller that is not used for this purpose. When you remove the ability for an OS to "listen" for commands, you are closing a potentially large hole. So what I do is just unbind NetBIOS over TCP/IP from the external NIC, and I also remove "File and Printer Sharing" along with "Client for MS Networks" if possible. This will keep the OS from using that NIC for most authentication purposes. Basically, you are stripping that NIC down to core functionality which is equivalent to a *nix/BSD system, and they have been working on networks for years, right?

Okay well it looks like Netbios isn't terribly necessary. This description makes it sound like it's left from Dos networking days where the computer names had to be really short. Of course there wasn't any mention there about the net MSG stuff. So this will disable the messenger functionality altogether. Is there a way I can just trust a few computer names (not necessarily in my network or workgroup? I would trust IP addresses, but my friends and I are all on DHCP.
Cheers,
Christian