DNS resolving to external IP when looking up local name

I have been wracking my brain with this for days.  I recently had to rebuild my DC from scratch.. I got everything back up, domain set back up, all computers reconnected to domain, etc.  However I noticed that all of the logons were taking forever, and that no one could RDP into our Terminal Server, even though I reset all of the privileges back up.

I have double and quadruple checked all of the tcpip settings on all of the servers and switches, and firewall, and clients, and etc to make sure they are all only set up for local IP for the DNS server which is also the DC and DHCP server.

When pinging the DNS server by name, it resolves eventually but comes back with a random external IP address.  When I do a nslookup, it brings up the correct IP and name at first, but also still brings up an non-authoritative external IP address.  I tried to set up WINS on my server, but it will not start for whatever reason. Just says that the "network path was not found".

Also, there is no LMHosts file on the server other than the sample one.. I cannot remember if that is common or not...

The only entry in the HOSTS file is just the local host address of 127.0.0.1 and then 192.168.1.10 for the DC

DC\DNS is Server 2003 R2 with SP2, same for the Terminal Server.

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\Administrator.DC1>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : dc1
   Primary Dns Suffix  . . . . . . . : bfp.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : bfp.com

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : HP NC7782 Gigabit Server Adapter
   Physical Address. . . . . . . . . : 00-17-A4-45-35-6D
   DHCP Enabled. . . . . . . . . . . : No
   IP Address. . . . . . . . . . . . : 192.168.1.10
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.10
   Primary WINS Server . . . . . . . : 192.168.1.10

C:\Users\administrator>nslookup dc1
Server:  bfpdom1
Address:  192.168.1.10

Non-authoritative answer:
Name:    dc1.bfp.com
Address:  74.117.222.18

This is what I get when pinging the server from a client machine

Pinging dc1.bfp.com [74.117.222.18] with 32 bytes of data:
Reply from 74.117.222.18: bytes=32 time=27ms TTL=53
Reply from 74.117.222.18: bytes=32 time=27ms TTL=53
Reply from 74.117.222.18: bytes=32 time=27ms TTL=53
Reply from 74.117.222.18: bytes=32 time=27ms TTL=53

Ping statistics for 74.117.222.18:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 27ms, Maximum = 27ms, Average = 27ms
Brendon GaigeIT DirectorAsked:
Who is Participating?
 
Talbot2Commented:
Your problem really is that your DC1 is not authoritive for bfp.com.    What you REALLY need to do is rename your internal domain to something like bfp.local .
The true authority for the domain bfp.com is:
   Domain Name: BFP.COM
   Registrar: DIRECTNIC, LTD
   Whois Server: whois.directnic.com
   Referral URL: http://www.directnic.com
   Name Server: NS0.DIRECTNIC.COM
   Name Server: NS1.DIRECTNIC.COM
There are only two semi-workarounds to your problem.   In the REAL nameservers for BFP (the true, authoritive ones mentioned above, add your DC1 and respective internal IP address to the public DNS records on the nameservers above.   Or, add a record to HOSTS on your client computers to make dc1.bfp.com resolve to your internal IP address.  Even though you have that zone loaded into your DC1, it still knows that it isn't the authoritative answer because of the above.   Incidentally, the 74.117.222.18 you mentioned is one of the IP addressses for the authoritave nameservers above.
The correct solution would be to rename your internal domain, as I mentioned it isn't that hard to do, and it really is the "correct" network setup.    Believe me, I've set a couple up in the 90's the wrong way before I knew better.   It is a much bigger pain to work the workarounds.

 
0
 
Brendon GaigeIT DirectorAuthor Commented:
I could really use some input on this ASAP... Anything new would be helpful...
0
 
Brendon GaigeIT DirectorAuthor Commented:
But why would this issue have only popped up now when this is the exact same domain name we used previously, I just reset everything up from scratch, but with same information.  What all would entail in renaming the domain?  I have already spent hours upon hours reestablishing client pcs with the current domain and restoring their profiles... I really do not want to have to do all of that over again...
0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
Brendon GaigeIT DirectorAuthor Commented:
Also, I guess I am confused as our DNS and DC is setup as internal only.  It should not be setup as a public domain...
0
 
Talbot2Commented:
I feel your pain about not wanting to do it over again.   I pondered the same thing when I was replying to your message.  The only thing I can think of is that before, maybe your DC didn't have internet access or maybe it didn't try to look up DNS.  Do you have DNS forwarders set in DNS Server on your DC now?  Maybe you didn't before.
0
 
Talbot2Commented:
Is your domain really setup as BFP.COM or was that an example you used?
0
 
Brendon GaigeIT DirectorAuthor Commented:
Yes that is what it is setup as.  It took me over 20 hours to do it before... I really am not in the mood to do it again... (Was onsite non-stop for over 50 hours).  I dont remember if it had the forwarders set up or not before hand, but most clients had the server dns as well as an external dns setup in their tcpip settings.  However, it all worked fine at that time. However, the company that managed my company before me did a half-arsed job on pretty much everything, and I was trying to set things up correctly this time.
0
 
Talbot2Commented:
0
 
Talbot2Commented:
>>Yes that is what it is setup as.  It took me over 20 hours to do it before...
I  know what you're saying, but the problem is that bcp.com is a real domain on the internet and it isn't your company.   When things are setup correctly (as you're trying to do), it just ain't going to work without some workarounds.   Do you have a zone in your DNS server - not just the domain stuff, but a real zone setup for bcp.com.   If you do not, you're going to have to manually (I think) add that zone yourself and make sure your server entries get set up.    This is not hard to do and should go pretty quickly.    Go to the DNS server on your DC and look under "forward lookup zones".  You should see bcp.com in there.   It needs to be primary and your SOA record should be set to the the IP address of DC1.
 
0
 
Talbot2Commented:
The more I think of it... I'm betting you have the zone already in your DNS server, but the SOA is set to the real server.   That might be the key to your problem.   It has to come down to one or maybe 2 things different from what they WERE.
0
 
Brendon GaigeIT DirectorAuthor Commented:
Ok, I changed the information for the SOA record from dc1.bfp.com to the local IP of 192.168.1.10.  And yes I had the zone set up initially, but all of it has been setup with the name, not the IP... should I change them all to the IP?  It wont let me change all of them though since it needs the NetBios name for record doesnt it?  Or will just the IP in the location you specified be enough?
0
 
Brendon GaigeIT DirectorAuthor Commented:
The name server is also set up correctly as dc1.bfp.com and 192.168.1.10
0
 
Talbot2Commented:
The IP in the SOA is big.   If that's wrong, then it (the DNS server) wants to get info from other places.   If you use names in your DNS instead of IP addresses, then it is going to try to look up those names elsewhere (going back to the SOA to find where that elsewhere is)  Does that make sense?   If you define the IP as THAT server, then it knows, "the buck stops here".  
When you say, "should I change them all to the IP", what specifically are you talking about?
0
 
Talbot2Commented:
If you want to do some DNS resolution testing, don't forget to run IPCONFIG /FLUSHDNS to clear the resolver cache.  If you don't it may used cached entries and not what you just changed - it WILL cause you do go insane.
0
 
Talbot2Commented:
If you're going to have dc1.bfp.com in your DNS server, be sure to have an explicit HOST (A) record to define what that is.   It SHOULD already be in there, but if it is not, add it manually with the correct IP address.  
0
 
Brendon GaigeIT DirectorAuthor Commented:
Disregard my previous question as it was a bonehead one... Also, now when these DNS setting propagate through the network, should it then allow the clients to see the server through the netbios name?  Or will I still have to add it to every client's hosts file?
0
 
Brendon GaigeIT DirectorAuthor Commented:
I already have the Host A file with the correct IP and name in the forward lookup zones.
0
 
Brendon GaigeIT DirectorAuthor Commented:
Ok, I changed the SOA to the actual IP address earlier... but it reset itself using the FQDN (dc1.bfp.com)...
0
 
Brendon GaigeIT DirectorAuthor Commented:
However I realized that I restarted the DNS server after I made the changes earlier, but I did not clear the cache and "update server data files" before doing so, would that have caused the issue with it reverting back to name instead of IP?
0
 
Talbot2Commented:
It doesn't really propagate, per se.  What happens is - the clients will do a DNS request to that server to get the IP address for the host that they're looking for.   What people get confused with propgagation is actually cached DNS entries.   DNS server zones have a TTL entry (time to live) and that's a suggested time to the client on how long to cache the information before referring back to the server to get a fresh lookup on that record.  Since most DNS hosts don't change that often, you can often see TTL values of hours or days.  So, unless you do an IPCONFIG /FLUSHDNS, those clients will still have cached lookup answers until they reach that timeout.  Generally speaking, if your people start on Monday, things will be fine.   You've just got to flush on your client computer to get the old values out manually so you can see if it works right or not.
0
 
Brendon GaigeIT DirectorAuthor Commented:
Ok, even when I do all of that, it still reverts back to name instead of IP.
0
 
Brendon GaigeIT DirectorAuthor Commented:
I did a flush on a client computer that does not have the information for the DNS server in the HOSTS file, and after a flush and register, it still pinged the external ip when resolving for dc1.
0
 
Talbot2Commented:
Do you have a host (A) record set up for DC1 in that DNS server?  If you do, then the FQDN is okay.   In that case a ping to dc1.bcp.com SHOULD resolve to your server.
0
 
Talbot2Commented:
The client computer you mention...  Is DC1 the ONLY DNS server is has defined?
 
0
 
Brendon GaigeIT DirectorAuthor Commented:
Ok, also let me clarify, there are two zones setup in my forward look up.  One is BFPDOM1 which is the netbios name for our domain, and it has the SOA, Name Server, and Host (A) files in it, this one has the SOA that keeps reverting back to the name instead of the IP.

Then there is another zone called lan.bfp.com that only has SOA and Name Server files in it, but it also resets back to the name instead of the IP.
0
 
Brendon GaigeIT DirectorAuthor Commented:
Talbot2:

The client computer you mention...  Is DC1 the ONLY DNS server is has defined?

Yes, it is.
0
 
Talbot2Commented:
I've never seen a netbios name listed in DNS.   What I would expect to see under forward lookup zones in your DNS server is one zone, called bcp.local.  
I think your lan.bfp.com is acually incorrect (and this would be technically a subdomain).
try pinging dc1.lan.bfp.com and see what you get.  
0
 
Brendon GaigeIT DirectorAuthor Commented:
Ok, I jsut refreshed the status on the forward zone, and one of the client computers just showed up under the Host (A) type.
0
 
Brendon GaigeIT DirectorAuthor Commented:
I deleted the lan.bfp.com zone, and created a new one with just bfp.com, and that is where the client showed up on.

Now more of them are showing up, looks like that was part of the problem...
0
 
Talbot2Commented:
Cool, now make sure that DC1 is in there as a host, even if you have to add it manually.    Then your SOA for that zone can be dc1.bcp.com.   I think you're on the right path now.
0
 
Brendon GaigeIT DirectorAuthor Commented:
Ok, yes, just tested on client computer that did NOT have it already set in HOSTS file, and it resolved the server properly... Also, I can get farther into remote accessing our Terminal Server now, however that is another can of worms trying to figure out why it says the user doesnt have the proper access rights, when they are a member of the RDP group... But I will open a new question for that if you want to try and earn some more points :).
0
 
Talbot2Commented:
Sure.   I have some ideas already.
0
 
Talbot2Commented:
I think this user mean to accept this question and not close it.
 
0
 
Talbot2Commented:

I think this user mean to accept this question and not close it.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.