0

I have the most strange DNS Resulution problem ever encountered. And by strange I mean that I can only confirm this issue on two hosts in our network (my workstation Win7 and a management dns server Win2008R2) and it is only present if until I restart the DNS Client.

There are two networks in our company. The management network where all of the servers, routers and switches are located and the production network where all of the employees PCs are located. There is one DC and another management server that also acts as a secondary DNS server.

This problem started a year ago on my PC and during the past year SOMETIMES I am unable to resolve single label names from my PC. My PC is located in the production network.

What is most strange in this situation is that when I power on my PC everything is ok. Then after a while this problem shows up, and if i restart the DNS client the problem is gone for a while (that is I can resolve again) but after 15-30mins it shows up again.

2 months ago this problem occurred on the secondary dns server that i mentioned before. How can a server that is ITS OWN DNS SERVER unable to resolve the names?! If i restart the DNS Client the problem is gone for a while. I really don't know why is this occurring and it is starting to drive me nuts. None of the other admins have reported anything similar on their PC's.

nslookup is also working correctly. It is as something is interfering with the DNS client. Any advice will be appreciated.

----
This is an example of how this looks in reality:
NOTE: "Apollo" is a cisco router with interfaces in both networks, it does not have netbios thus the only way to find its name is via dns.

C:\>ping apollo
Ping request could not find host apollo. Please check the name and try again.

C:\>ping apollo.corp.local
Ping request could not find host apollo. Please check the name and try again.

C:\>net stop dnscache && net start dnscache
C:\>ping apollo

Pinging apollo.corp.local [192.168.5.1] with 32 bytes of data:
Reply from 192.168.5.1: bytes=32 time<1ms TTL=255

C:\>ipconfig /all
Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : corp.local
   Description . . . . . . . . . . . : Intel(R) PRO/100 VE Network Connection
   Physical Address. . . . . . . . . : 00-1D-92-0D-D5-01
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::ec96:c947:de50:b3f5%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.5.103(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, November 25, 2013 9:10:43 43
   Lease Expires . . . . . . . . . . : Tuesday, November 26, 2013 9:10:45 45
   Default Gateway . . . . . . . . . : 192.168.5.1
   DHCP Server . . . . . . . . . . . : 192.168.5.7
   DHCPv6 IAID . . . . . . . . . . . : 234888594
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-2C-C9-07-00-1D-92-0D-D5-01
   DNS Servers . . . . . . . . . . . : 192.168.5.7
                                       10.10.0.21
                                       8.8.8.8

   NetBIOS over Tcpip. . . . . . . . : Enabled
1
  • 2
    If this is in an AD environment, your DCs should be the only DNS servers that your clients use. 8.8.8.8 shouldn't be there.
    – MDMarra
    Nov 25, 2013 at 13:11

1 Answer 1

5
> DNS Servers . . . . . . . . . . . : 192.168.5.7
                                       10.10.0.21
                                       8.8.8.8

Your tertiary DNS server is one of Google's. Why are you configuring this on the clients instead of configuring a forwarder on your internal DNS servers?

When the problem occurs, the machine is probably trying to query Google for an internal address (and not getting a response, obviously). It doesn't explain why it's only happening for a couple of machines, but I'd look at changing this to begin with.

3
  • Makes sense. I'll try to remove this entry in our DHCP. However this also doen't explain why after I restart the DNS client the problem is solved for a while?! :S
    – Spirit
    Nov 25, 2013 at 13:16
  • 2
    Because it has failed over to the tertiary resolver and after restarting the client it is using the primary resolver. Pretty straightforward.
    – MDMarra
    Nov 25, 2013 at 13:44
  • That did it for me, thanks guys :) NOTE: It was really strange since the DHCP itself was configured to give the tertiary dns to all of the company workstations. I wonder why just the two mentioned hosts (my PC and that DNS server) had the resolving problem, and the rest of the hosts were working fine.
    – Spirit
    Nov 29, 2013 at 9:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .