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

I'm in an enterprise environment that has 2 Windows 2008 R2 domain controllers running in native 2008 R2 mode. On these DCs, the DNS service is installed and all Windows (XP,7) clients (~2,000) are pointing to them in a primary/secondary configuration. Each DC is using root hints to recursively forward DNS queries however we have also seen the below behavior when using the ISP's DNS servers as forwarders as well.

What we're seeing is that every week or so, a user will call in with a problem that they cannot get to a certain outside domain when browsing the Internet. The domain seems to vary. We attempt to resolve this domain on DC1 and it will not resolve. We switch over to the DC2 and it works correctly.

To fix the problem, we can always clear the server cache on DC1, attempt to resolve the domain and it works again. This process happens about once a week.

Does anyone have an idea on where I could start troubleshooting?

8/23/2013 UPDATE:

This just happened again. Here's the problem from the DNS debug log. The A record being queried was www.immunize.org. The domain and local DNS zone is hosp.uhhg.org.

8/23/2013 3:40:18 PM 0AF4 PACKET  0000000002531DD0 UDP Rcv 172.17.10.211   0042   Q [0001   D   NOERROR] A      (8)immunize(3)org(4)hosp(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  0000000002531DD0 UDP Snd 172.17.10.211   0042 R Q [8385 A DR NXDOMAIN] A      (8)immunize(3)org(4)hosp(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  0000000004E31D70 UDP Rcv 172.17.10.211   0043   Q [0001   D   NOERROR] AAAA   (8)immunize(3)org(4)hosp(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  0000000004E31D70 UDP Snd 172.17.10.211   0043 R Q [8385 A DR NXDOMAIN] AAAA   (8)immunize(3)org(4)hosp(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  0000000003233AE0 UDP Rcv 172.17.10.211   0044   Q [0001   D   NOERROR] A      (8)immunize(3)org(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  0000000003233AE0 UDP Snd 172.17.10.211   0044 R Q [8385 A DR NXDOMAIN] A      (8)immunize(3)org(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  0000000005FF34F0 UDP Rcv 172.17.10.211   0045   Q [0001   D   NOERROR] AAAA   (8)immunize(3)org(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  0000000005FF34F0 UDP Snd 172.17.10.211   0045 R Q [8385 A DR NXDOMAIN] AAAA   (8)immunize(3)org(4)uhhg(3)org(0)
8/23/2013 3:40:18 PM 0AF4 PACKET  000000000474D030 UDP Rcv 172.17.10.211   0046   Q 

[0001   D   NOERROR] A      (8)immunize(3)org(0)
8/23/2013 3:34:40 PM 0AF0 PACKET  0000000003856710 UDP Rcv 192.26.92.30    5e5a R Q [0080       NOERROR] A      (2)ns(11)nameservers(3)net(0)
8/23/2013 3:34:40 PM 0AF0 PACKET  0000000005F7C640 UDP Snd 172.17.10.211   0016 R Q [8281   DR SERVFAIL] A      (3)www(8)immunize(3)org(0)
8/23/2013 3:34:40 PM 0AF0 PACKET  0000000005D491B0 UDP Rcv 172.17.10.211   0017   Q [0001   D   NOERROR] AAAA   (3)www(8)immunize(3)org(0)
8/23/2013 3:34:40 PM 0AF0 PACKET  0000000005D491B0 UDP Snd 172.17.10.211   0017 R Q [8281   DR SERVFAIL] AAAA   (3)www(8)immunize(3)org(0)

There were no error recorded in the DNS Server event log and this happened on both of the DCs. The cached domain showed up and had two NS records; ns14a.nameservers.net and ns14b.nameservers.net but no other records. I tried just removing the cached domain and that made no difference.. I had to fully clear the cache to get it to work again. I noticed after it was working again, the immunize cached zone did not have the www A record as I expected.

share|improve this question
2  
Have you viewed the contents of the cache? I think you need to enable the advanced view in the MMC snap-in to do so. –  Simon Catlin May 2 '13 at 19:46
    
As always, the minute I reach out for help it's working well again. I didn't look at the cache but I will the next time this happens. It should happen this week. –  adbertram May 6 '13 at 13:35
    
This just popped up again. However, as soon as I heard about it I enabled debug logging and did some more investigation to hopefully get closer to finding the solution. –  adbertram Aug 23 '13 at 19:53

Your Answer

 
discard

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

Browse other questions tagged or ask your own question.