Link to home
Start Free TrialLog in
Avatar of wolf2008
wolf2008Flag for United States of America

asked on

DNS failure

We recently assisted a client with the relocation of their website.  The site moved from inside the domain to a hosted site; the website still has the same name as the local domain.
Updated global DNS settings and the world can navigate to the website.  Updated the local DNS A record by simply inserting the global IP where there used to be a private IP.  One can ping the website via URL or IP successfully from inside the LAN.  Performing an http connection test is successful, too.  However, no one inside the local LAN can navigate to the website.  Depending on which browser one chooses to use, the message is basically that the page cannot be found.  Chrome cannot find the website, for example.
I'm open for suggestions; thanks ahead to anyone who has a moment to respond.
Avatar of becraig
becraig
Flag of United States of America image

From one of the computers in the lan run the following command:


nslookup www.domain.com 


Look at the result and see if it actually resolves to an IP address
I would open DNS Manager from all servers, right click the server and Clear Cache.

Also, run an IPCONFIG /FLUSHDNS from the clients as well.
Also is the website the same as the server?

If so try adding www as a name to the DNS zone.

EG:

contoso.com
   - www <public IP of the new web server>

then hit www.contoso.com


If the domain is named contoso.com it'll look for the DC, and not the website.
Avatar of wolf2008

ASKER

Becraig,

Running this command returns a local IP.  Do you have suggestions from where you sit on how to correct that?
SOLUTION
Avatar of becraig
becraig
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Santosh Gupta
Santosh Gupta

Hi,

see the Kyle Abrahams comment.

1. Go to DNS server.
2. create a A record shown below.
Name: www
IP: your site IP

User generated image
Run  IPCONFIG /FLUSHDNS

and try.
Thanks for these suggestions.  
We have done these things already, as noted in my original post.  The A record has been updated; ipconfig /flushdns executed many times now.  That was my first and only intended step to take on the local LAN for this website move.  This is the only internal change I have made for other clients when moving a website.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi,

Run below command on DNS server.

nslookup www.domain.com 

if it not resolve to your public site IP then restart the

1. DNS server service then try.
2. if not then open your DNS console, right click on your domain name and clear cache.

then again try nslookup www.domain.com
You updated the old ip where the new one was, but was that for your domain, or was that for WWW?

If you don't have a WWW in your DNS can you add one and make that the public IP?  Then try to browse by www.website.com?
I think Santosh Gupta is on the right track.  Running ipconfig /flushdns and /registerdns does not flush the DNS server's cache.  You need to flush the old cached record on the DNS server so that it refreshes with the new information for your www.domain.com IP address.  This can be done either by restarting the DNS server service or by opening the DNS management console, manually checking the cache and deleting the old record that points to the internal IP address.
Thanks for all of the responses.  

We definitely have an A record pointing to the proper IP address of the website.  The A record is for www.

We have flushed the DNS.  We have scoured the DNS for any conflicting entries.  We have restarted the service and rebooted the server.

If I ping the URL and succeed, does this NOT show that DNS is proper?
If I ping the URL and succeed, does this NOT show that DNS is proper?

So, while pinging are you able to get public IP.
Santosh,

Yes.  That is the fact.
hi,

Try to access http://yoursitepublicIP

if you are still unable to access then need to see the router/firewall logs.
Download this tool:
http://www.microsoft.com/en-us/download/details.aspx?id=17148

It will be invaluable in the long run.

once you have it installed run

portqry -n www.domain.com -e 80

then
portqry -n xxx.xx.xx.x - 80

Where xx.xx above represents the public ip.

Let me know the results
I suspect that the website is redirecting requests from www.domain.com to domain.com, and this is what's causing the problem. You can test this by browsing to www.domain.com from outside the LAN. Does the URL in the browser change to domain.com when the site's main page appears? If so, it's being redirected.

The only way to fix this is to remove the redirect from the site so that it will accept requests for www.domain.com. Since the internal and external domains have the same name, users inside the LAN will hit a domain controller when they try to browse to domain.com, because Active Directory uses blank host records in the domain's DNS zone to designate domain controllers. You shouldn't attempt to get around this by creating another blank host record and giving it the public IP of the website; internal users will only reach the site some of the time anyway, and you may cause Active Directory issues.
DrDave242,
We did exactly what you suggested to NOT do, and the issue has been resolved for nearly two weeks with no reports of any toxic byproducts.  My tech did two things, actually, which resulted in a resolution.  First, he deleted the A record that I had formerly only changed, and he recreated it using the exact same parameters, of course.  He also created a blank A record (no www or anything; so the record is for domain.com and not www.domain.com).  This is apparently our solution.  I'll let you know if/when things go awry.
I think that suggestion was the 4th comment on this thread to recreate the A record so internal DNS would know where to go:

Your Comment
by: becraigPosted on 2014-04-14 at 13:56:42ID: 39999936
Rank: Sage
It should have returned a value for Server:xx.xx.xx.xx
If that server is an internal DNS server, then you should update your DNS server to point to the public ip address:
Create a new A record for www in zone domain.com pointing to the public ip address that should fix it...

Creating a blank A record for domain.com would not be the source of your solution if you initial issue was accurate resolution of www.domain.com.

I surmise something else internally might have been amiss with DNS and it is cleaned up now, inclusive of the creation of a new A record.
Actually 2nd suggestion, but who's keeping track?  ;-)
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
After a bit more research, I can tell you why it's working (assuming it still is): a feature of modern web browsers called client retry (or browser retry). When I started reading about it, I realized I'd read about it before but later forgot the information. It's not very well documented, apparently, but it works like this:

Note: This example assumes that nothing is cached on the client beforehand.

1.

The DNS client on your machine sends a host query for domain.com to your internal DNS server.

2.

The server responds with a list of all host records (and CNAME records, if they exist) matching the query. In your case, the response will contain the IP addresses of each of your DCs and the IP address of your web server, since you've created that blank host record. (Looking at previous queries for the same information would allow you to determine the order in which the addresses will be presented, due to the way round-robin DNS works, but we're not really concerned with that.)

3.

The DNS client gives this data to the web browser. So far, this is normal. Steps 4, 5, and 6 are where client retry comes in.

4.

The web browser attempts to connect to each address in the list until a successful connection is made.

5.

Assuming a connection is made, the browser displays the requested page as it normally would, but it also caches the address associated with the successful connection. This cache is separate from both the DNS client cache and the browser's cache of previously opened pages..

6.

Future connections from the same browser to the same FQDN will use the cached address.Because client retry isn't well documented, I don't know how long the address remains cached on the client, though it's safe to assume it's eventually purged. (Maybe the browser uses the TTL value of the corresponding host record - who can say?) When that happens, the next connection attempt starts over at step 1. (Well...not necessarily, since the DNS client may still have the address cached as well.)

I can think of one potential problem: if IIS ever gets installed on one of your DCs for whatever reason, and that DC's address is presented to the web browser before the address of the web server, that client won't be able to reach the web server. It'll connect to IIS on the DC, assume that's where you were trying to go, and cache the DC's address for future connections. That's obviously not ideal.

If you want to read more about client retry, you can find some (unofficial) information here and here...and probably in other places as well.