Unable to ping domain.local, but can ping server.domain.local

Question

I have a single windows 2008 server running active directory, group policy, and DNS. DHCP is running from the firewall (this is because there are multiple branch locations, and each location has its own firewall supplying DHCP. But, for this problem, the server and workstation are at the same location).

On an XP workstation, if I try to visit \\domain.local or ping domain.local, the workstation can't find it. A ping returns Ping request could not find host domain.local.

If I try to visit \\server or \\server.domain.local or ping server or server.domain.local, I'm able to connect normally.

If I ping or visit domain.local on the server, I'm able to connect normally.

A-Records are in place in the DNS service for server, domain.local, and server.domain.local. A reverse lookup zone also is enabled and PTR records are in place.

If I wait 20-30 minutes, I am eventually able to ping and visit domain.local--but, when attempting to ping, it takes 30 second to return an IP address.

I am also unable to join a new workstation to the domain during this wait period. If I try, the error message returned is "network path not found".

Is there something I'm missing?

Solution 1

It sounds like your clients aren't using your DCs for DNS. This is a requirement for things to function properly unless you've gone through very specific steps to offload name resolution to other servers.

Your Windows clients should point to your DC(s) and only your DC(s) for name resolution.

Solution 2

Try the following in a command prompt:

nslookup domain.local

What is the output?

Try a reverse lookup as well:

nslookup {ip}

What about:

nbtstat -a domain.local

If you try to connect to \\domain.local are you prompted for a Username or Password? Try connecting to potential shares on domain.local.

For example:

\\domain.local\ADMIN$

\\domain.local\C$

Are you prompted for a Username or Password when connecting to these shares? Are there even any shares on your domain controller? Maybe there are but have you allowed access to them? When attempting to connect to your domain controller (\\domain.local) it is quite possible (and makes sense) that your domain controller doesn't have any shares. Can other systems access those shares on \\domain.local?

Its important to understand that \\server.domain.local is completely different then \\domain.local. Those are 2 different servers you are connecting to (assuming \\server has a different A record than \\domain.local).

Just because you cant ping domain.local doesn't mean you are having connectivity issues. ICMP echo request/reply (depending on the environment) can either be on of off on the domain controller (hence you getting a reply or not). In my environment, I don't get a reply when I ping my DC.

Are other systems on your network experiencing similar issues with the server taking 30 secs to respond with an IP? There are a variety of potential culprits, but if the the issue is isolated to one system/subnet/etc., check the following:

Are you having issues connecting to other systems? Is there some kind of 3rd party firewall in place? (Zone alarm?) Check the event log on the DC... anything?

Give us as much information as you can, test from different systems to isolate the problem. Once you can determine there are shares, other systems can access them, etc etc etc. than we can determine what the potential root issue is.

Comments

[mdpc]

What about WINS?

[Force Flow]

WINS is not installed. Is it even needed for anything newer than a Windows 2000 environment?

[mdpc]

Interesting, I still see it running here eventhough we are XP, Win 7, Server 2003/8 site.

[Force Flow]

Just for the heck of it, I enabled WINS, but it didn't seem to have any effect on DNS resolution.

[mdpc]

(The thought was some type of caching or the update of the browser cache issues).

[Force Flow]

domain.local and server.domain.local are for the same server and IP address. There is no delay in pinging other workstations. There is no delay in pinging server.domain.local or the IP. There are no firewalls in place on the workstations and server other than the windows firewall. Disabling the firewall on the server does not allow workstations to ping or visit domain.local

[Force Flow]

nslookup domain.local and nslookup 10.10.0.2 both bring up this: server: server.domain.local Address: 10.10.0.2; server: domain.local Address: 10.10.0.2. Attempting to access any share on \\domain.local results in the "not accessible" error message. \\server.domain.local works fine.

[Blake]

And you can access those shares through \\server.domain.local\C$, ADMIN$, etc.?

[Force Flow]

ok, here's an interesting twist. On a workstation for the first 20 minutes or so after a reboot, \\domain.local is unavailable and not pingable, but \\server.domain.local is available and pingable. After about 20 minutes, \\server.domain.local is unavailable and not pingable, but \\domain.local is available and pingable. To answer your question about shares, NETLOGON, SYSVOL, and $ADMIN are available on whichever one I can connect to.

[Blake]

This is a very weird issue indeed. I wonder if having 2 A records in there is causing this disturbance. Remove the A record for server.domain.local and just leave the domain.local one. Either have one or the other and retest!

[Force Flow]

I removed the two records. After about 15 minutes, both re-appeared in the DNS server. I'm able to ping and visit server.domain.local, but not domain.local. After about 15-20 minutes after that, I was able to access both server.domain.local and domain.local. However, upon rebooting, domain.local became unavailable again.

[Robin Gill]

Time to fire up wireshark and determine whether the problem is with the server or clients.

[Force Flow]

I didn't see anything amiss with wireshark, though I'm not an expert in that arena. I saw the DNS request and response and ICMP requests and responses. There was no delay shown either on the client side or server side even though the cmd window on the client showed a 30 second delay between when I entered the ping command and when it started displaying the ping responses.

[Force Flow]

On the workstation, when the cmd window is waiting for the ping request, wireshark stops collecting/displaying packets. As soon as the first ping response appears in the cmd window, wireshark plays catch-up and displays all the packets that weren't displayed when the cmd window was waiting on the ping request

[Blake]

Use another system in your environment and determine if this is affecting the whole network or is isolated to that one machine. These are very weird issues you are having... and since they are consistently intermittent, this means tracking down the issue is going to be lots of fun for you :)

[Force Flow]

It's happening on more than one machine.

[Blake]

Hmm, well if it was me I'd fire up Wireshark and do a ping -t domain.local and watch the traffic (server.domain.local too). It would be nice if you could get a capture of first it not working than of it working all in the same capture. Id also try a few \\domain.local ,etc. and see what the packets look like. Shoot, this is weird enough save the capture as a .pcap and host it up somewhere. Id be interested in looking at the traffic!

[Blake]

Also, is there any indication in the Event Log on the DC of any potential issues?

[Force Flow]

No errors or warnings on the DC.

[MDMarra]

But do they use the DC as the only DNS server? If you only have 1 DC, you should only have 1 entry in the list.

[Force Flow]

There is a second entry for OpenDNS for when the DC is unavailable for whatever reason (reboot, connectivity loss, etc).

[MDMarra]

That can have some unintended consequences.

[Force Flow]

Like what? Is this particular situation a typical result of this configuration? If so, it's rather odd considering all other DNS lookups (both LAN and Internet) function normally. The problem is only with the FQDN.