NetBios over TCP/IP
At the moment we have 2 separate domains on the same network. There isn't any trust relationship. DNS settings aren't linked, no stubzones what so ever.
The problem is that on domain "name1" there is a name resolution to a servername on the domain "name2" that resolves to a wrong ip-adres. I've been looking for the source of this ip resolution. There is no DNS setting, no host lmhost file. I flushed all possible caches, dns arp netbios, wins. But still a ping to the servername resolves to a wrong ip address.
When I execute a nbtstat -a servername I get Host not found. Nslookup also can't find the servername. When I select the "Disable NetBIOS over TCP/IP" in the WINS Tab of the network card properties it solves the faulty resolution, running a ping to the server I get "Ping request could not find host ...". When I reselect the Default setting "Use NETBIOS setting from the DHCP server....." The wrong server ip resolution reapperars.
So it must be Netbios over TCP/IP being the source of this resolution. How do I flush this Netbios over TCP/IP cache?
Would creating a DNS stubzone solve this issue?
The problem is that on domain "name1" there is a name resolution to a servername on the domain "name2" that resolves to a wrong ip-adres. I've been looking for the source of this ip resolution. There is no DNS setting, no host lmhost file. I flushed all possible caches, dns arp netbios, wins. But still a ping to the servername resolves to a wrong ip address.
When I execute a nbtstat -a servername I get Host not found. Nslookup also can't find the servername. When I select the "Disable NetBIOS over TCP/IP" in the WINS Tab of the network card properties it solves the faulty resolution, running a ping to the server I get "Ping request could not find host ...". When I reselect the Default setting "Use NETBIOS setting from the DHCP server....." The wrong server ip resolution reapperars.
So it must be Netbios over TCP/IP being the source of this resolution. How do I flush this Netbios over TCP/IP cache?
Would creating a DNS stubzone solve this issue?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The server with the wrong name resolution has 1 nic. What probably once happened is that with the very first boot it got an IP address from the dhcp server of the domain "coffee.msf". Later we changed it to a static ip address and linked it to the other domain "thee.msf".
I solved it for now by manually adding a primary dns zone of domain "coffee.msf" to the dns server of domain "thee.msf". I linked a GPO to "thee.msf" adding the dns suffix of "coffee.msf". It all resolves ok now, using dns instead of netbios. So everybody can start RDP from domain "thee.msf" to "coffee.msf" with the correct name resolution.
We are in a transition of going from domain "thee.msf" to "coffee.msf" so we aren't going to put any domain trusts or forward lookup zone in place.
The source of the old wrong netbios cache on "thee.msf" is still a mistery.
Thanks.
I solved it for now by manually adding a primary dns zone of domain "coffee.msf" to the dns server of domain "thee.msf". I linked a GPO to "thee.msf" adding the dns suffix of "coffee.msf". It all resolves ok now, using dns instead of netbios. So everybody can start RDP from domain "thee.msf" to "coffee.msf" with the correct name resolution.
We are in a transition of going from domain "thee.msf" to "coffee.msf" so we aren't going to put any domain trusts or forward lookup zone in place.
The source of the old wrong netbios cache on "thee.msf" is still a mistery.
Thanks.
Look on the server's LMHOST file. Much like DNS, there are three spots bad records can be.
One is the cache: Netbios or WINS cache (whatever you want to call it)
To clear the cache you go to the command prompt and type NBTSTAT -RR
The second is the LMHOST file: Like DNS that uses the host file, WINS and netbios translation uses the LMHOST File. So if that is configured, it could have a bad record.
The third location is the WINS database. Much like DNS, WINS holds its own database and that is populated by netbios broadcasts.
Since most people don't configure the LMHOST file, (and that has to be manually configured), my guess is that you are using WINS with a bad record in the WINS database for this server.
NBTSTAT -RR, (or was it NBTSTAT -rr) should correct your WINS database record.
DNS was modeled after WINS. So, the locations of records and many of the concepts are VERY similar.
Instead of DNS cache, you have WINS or Netbios cache.
Instead of a HOST file, you have a LMHOST file in the same location.
Instead of a DNS database of records, you have a WINS database of records.
Since DNS and WINS models are similar, you can follow the path of a DNS query and just relate that to WINS. Here's an article I wrote on the path of a DNS query.
https://www.experts-exchange.com/articles/Networking/Protocols/DNS/DNS-Troubleshooting-made-easy.html
One is the cache: Netbios or WINS cache (whatever you want to call it)
To clear the cache you go to the command prompt and type NBTSTAT -RR
The second is the LMHOST file: Like DNS that uses the host file, WINS and netbios translation uses the LMHOST File. So if that is configured, it could have a bad record.
The third location is the WINS database. Much like DNS, WINS holds its own database and that is populated by netbios broadcasts.
Since most people don't configure the LMHOST file, (and that has to be manually configured), my guess is that you are using WINS with a bad record in the WINS database for this server.
NBTSTAT -RR, (or was it NBTSTAT -rr) should correct your WINS database record.
DNS was modeled after WINS. So, the locations of records and many of the concepts are VERY similar.
Instead of DNS cache, you have WINS or Netbios cache.
Instead of a HOST file, you have a LMHOST file in the same location.
Instead of a DNS database of records, you have a WINS database of records.
Since DNS and WINS models are similar, you can follow the path of a DNS query and just relate that to WINS. Here's an article I wrote on the path of a DNS query.
https://www.experts-exchange.com/articles/Networking/Protocols/DNS/DNS-Troubleshooting-made-easy.html
ASKER
Nbtstat -R or nbtstat -RR they don't flush this caching issue. I'm looking for the magic flushing command that does flush this cache.