Strange DNS issue

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 5.16.85.3

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.
C:\nslookup
> www.domain-name.com
Server: other.otherdomain.com
Address: 10.1.1.200

Non-authoritative answer:
domain: domainname.com
Address: 5.16.85.3
Aliases: www.domain-name.com

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.

c:\nslookup
> www.domain-name.com
Server: domaindc1.domainname.com
Address: 127.1.0.19

Non-authoritative answer:
domain: domainname.com
Addresses: 127.1.0.21, 127.1.0.19, 127.1.0.18
Aliases: www.domain-name.com

Again the alias shows up. So I paid a visit to may friends at Central Ops a visit

DNS records
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 5.16.85.3 86400s (1.00:00:00)
domainname.com IN NS dns036.c.register.com 86400s (1.00:00:00)
domainname.com IN SOA
server: dns109.a.register.com
email: root.register.com
serial: 200007331
refresh: 10800
retry: 3600
expire: 604800
minimum ttl: 86400
86400s (1.00:00:00)
domainname.com IN NS dns109.a.register.com 86400s (1.00:00:00)
domain-name.com IN A 5.16.85.3 86400s (1.00:00:00)
domain-name.com IN MX
preference: 10
exchange: mail.domain-name.com
86400s (1.00:00:00)
domain-name.com IN SOA
server: domain-name.com
email: hostmaster.primary.net
serial: 1203777421
refresh: 10800
retry: 3600
expire: 604800
minimum ttl: 86400
86400s (1.00:00:00)
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)
3.85.16.5.in-addr.arpa IN PTR static-5.16.85.3.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).

The fix.
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.

Be safe.

James