I had a customer recently changed ISPs at their main office and suddenly they were unable to connect to their hosted web site. The rest of the world was able to connect to the website but their internal users were getting redirected to the internal pages on their domain contollers - specifically the default web page on an IIS implementation.
To test the process out I connected to their web site - http://www.domain-name.com and I was presented with the beautiful web site that had been crafted for them.
Then I connected into their network and logged on to a server in their environment and tried the same the process of connecting to the web site. This time I was indeed presented with the IIS default page.
The customer thought that they were having problems connecting to the Internet, but I was able to disprove this by being connected remotely to their networks and by being able to connect to other sites on the Internet.
The problem was limited to the customers web site and no other sites.
So first step was to determine where the customers network was directing traffic.
ping www.domain-name.com from my physical location answered back to the actual address 220.127.116.11
Internally to the customer ping www.domain-name.com answered back with the IP address of one of the domain controllers 127.1.0.21, 127.1.0.19, 127.1.0.18.
Next tool to use was NSLookup
Here is this the output I received at my physical location.
This looks fairly normal other than the last line, but I will get back to that in a minute.
So do the same process at the client site.
Addresses: 127.1.0.21, 127.1.0.19, 127.1.0.18
Again the alias shows up. So I paid a visit to may friends at Central Ops a visit
name class type data time to live
www.domain-name.com IN CNAME domainname.com 86400s (1.00:00:00)
domainname.com IN NS dns030.b.register.com 86400s (1.00:00:00)
domainname.com IN NS dns010.d.register.com 86400s (1.00:00:00)
domainname.com IN A 18.104.22.168 86400s (1.00:00:00)
domainname.com IN NS dns036.c.register.com 86400s (1.00:00:00)
domainname.com IN SOA
minimum ttl: 86400
domainname.com IN NS dns109.a.register.com 86400s (1.00:00:00)
domain-name.com IN A 22.214.171.124 86400s (1.00:00:00)
domain-name.com IN MX
domain-name.com IN SOA
minimum ttl: 86400
domain-name.com IN NS dns2.primary.net 86400s (1.00:00:00)
domain-name.com IN NS dns1.primary.net 86400s (1.00:00:00)
126.96.36.199.in-addr.arpa IN PTR static-188.8.131.52.primarynetwork.com 86400s (1.00:00:00)
The key here CNAME -what this is telling us is that www.domain-name.com is redirecting to domainname.com for resolution. This works fine out on the Internet but not at the clients office because their internal domain is .... domainname.com.
Here is how this process works on the Internet.
Internet user requests a connection to http://www.domain-name.com and his/her domain name server requests more information from the root dns servers. The root dns server then redirects the request to the specific server that handles .com domains which in turn forwards the request to the server that handles domain-name.com. The server that handles domain-name.com then provides back the alias for www.domain-name.com as domainname.com and the process starts again to request domainname.com. This works because the local dns server has to go out and request this information because it did not know it before. (i.e. its local cache does not contain the information.
Same process occurs at the client site until the alias of domainname.com is given. The local server has a zone record for the domain domainname.com and considers itself an authoritative responder for the domain (which it legitimately is for the internal network).
To fix this in the clients office network I added a small zone for www.domain-name.com to the dns servers and pointed its parent/root record to the IP address of the server.
Client PCs were then able to connect to the hosted web site.
Customer was happy and I had an interesting story.