Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
What about WINS? –  mdpc Aug 7 '12 at 18:57
    
WINS is not installed. Is it even needed for anything newer than a Windows 2000 environment? –  Force Flow Aug 7 '12 at 19:38
    
Interesting, I still see it running here eventhough we are XP, Win 7, Server 2003/8 site. –  mdpc Aug 7 '12 at 20:55
    
Just for the heck of it, I enabled WINS, but it didn't seem to have any effect on DNS resolution. –  Force Flow Aug 8 '12 at 14:32
    
(The thought was some type of caching or the update of the browser cache issues). –  mdpc Aug 8 '12 at 16:13

2 Answers 2

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.

share|improve this answer
    
They use the DC as the primary DNS server. –  Force Flow Nov 14 '12 at 16:30
    
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. –  MDMarra Nov 14 '12 at 16:34
    
There is a second entry for OpenDNS for when the DC is unavailable for whatever reason (reboot, connectivity loss, etc). –  Force Flow Nov 14 '12 at 17:36
    
That can have some unintended consequences. –  MDMarra Nov 14 '12 at 17:37
    
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. –  Force Flow Nov 14 '12 at 18:35

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.

share|improve this answer
    
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 Aug 7 '12 at 19:32
    
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. –  Force Flow Aug 7 '12 at 19:36
    
And you can access those shares through \\server.domain.local\C$, ADMIN$, etc.? –  Blake Aug 7 '12 at 19:45
    
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. –  Force Flow Aug 7 '12 at 19:49
    
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! –  Blake Aug 7 '12 at 19:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.