SBS2008, Win 7 & 8 clients. DNS seems to work normally for internal machines, at least I've no reason to suspect it is not working. But name resolution for Internet hosts is very unreliable. Web sites are often not found or don't render correctly because name resolution needed for rendering parts of the page fails.
When I've run GRC.COM's DNSBENCH.EXE it usually reports the SBS as having the lowest reliability of any of the nameservers. That list includes the 2 forwarders I use, which score 100% reliable. So it's not the forwarders that are failing; it's the DNS server. I can verify that on the clients by temporarily setting their DNS servers to the public DNS servers. Then, Internet name resolution is fast and reliable.
Here is a representative section of a DNS server debug log, taken when attempting to browse bing.com:
5/26/2013 11:30:24 AM 0978 PACKET 0000000002722AF0 UDP Snd 75.75.75.75 ca8f Q [0001 D NOERROR] AAAA (9)microsoft(9)webtrends(6)akadns(3)net(0) 5/26/2013 11:30:24 AM 0AA8 PACKET 0000000002F576B0 UDP Rcv 75.75.75.75 ca8f R Q [8081 DR NOERROR] AAAA (9)microsoft(9)webtrends(6)akadns(3)net(0) 5/26/2013 11:30:24 AM 0AA8 PACKET 0000000002DA00C0 UDP Snd 192.168.1.22 b1d9 R Q [8081 DR NOERROR] AAAA (1)m(9)webtrends(3)com(0) 5/26/2013 11:30:25 AM 0978 PACKET 0000000003F08590 UDP Snd 192.168.1.22 90f4 R Q [8081 DR NOERROR] A (5)login(4)live(3)com(0) 5/26/2013 11:30:25 AM 0978 PACKET 00000000026EB790 UDP Snd 192.168.1.22 644f R Q [8281 DR SERVFAIL] A (3)api(4)bing(3)com(0) 5/26/2013 11:30:25 AM 0978 PACKET 0000000003FFC0B0 UDP Snd 192.168.1.22 6cbe R Q [8281 DR SERVFAIL] A (3)www(4)bing(3)com(0) 5/26/2013 11:30:25 AM 0978 PACKET 0000000003A79280 UDP Snd 192.168.1.22 0bd7 R Q [8281 DR SERVFAIL] A (3)www(8)facebook(3)com(0) 5/26/2013 11:30:25 AM 0978 PACKET 0000000002BAC5A0 UDP Snd 192.168.1.22 35d4 R Q [8081 DR NOERROR] A (3)ssl(4)bing(3)com(0) 5/26/2013 11:30:25 AM 0978 PACKET 0000000002D5D920 UDP Snd 192.168.1.22 a823 R Q [8281 DR SERVFAIL] A (6)static(2)ak(5)fbcdn(3)net(0) 5/26/2013 11:30:25 AM 0AA8 PACKET 000000000454E2E0 UDP Rcv 192.168.1.22 cf12 Q [0001 D NOERROR] A (3)www(4)bing(3)com(0) 5/26/2013 11:30:25 AM 0AA8 PACKET 00000000046B7540 UDP Snd 75.75.76.76 afa5 Q [0001 D NOERROR] A (3)www(4)bing(3)com(0) 5/26/2013 11:30:25 AM 0AA0 PACKET 0000000006F79B50 UDP Rcv 192.168.1.22 719c Q [0001 D NOERROR] A (3)api(4)bing(3)com(0) 5/26/2013 11:30:25 AM 0AA0 PACKET 0000000003913860 UDP Snd 75.75.76.76 9bb2 Q [0001 D NOERROR] A (3)api(4)bing(3)com(0) 5/26/2013 11:30:25 AM 0AA0 PACKET 0000000003B7A090 UDP Rcv 192.168.1.22 6f8d Q [0001 D NOERROR] A (3)www(8)facebook(3)com(0) 5/26/2013 11:30:25 AM 0AA0 PACKET 0000000003E59ED0 UDP Snd 75.75.76.76 5e4a Q [0001 D NOERROR] A (3)www(8)facebook(3)com(0) 5/26/2013 11:30:25 AM 0AA8 PACKET 0000000002666330 UDP Rcv 192.168.1.22 97c5 Q [0001 D NOERROR] A (6)static(2)ak(5)fbcdn(3)net(0) 5/26/2013 11:30:25 AM 0AA8 PACKET 00000000040CBDD0 UDP Snd 75.75.76.76 0626 Q [0001 D NOERROR] A (6)static(2)ak(5)fbcdn(3)net(0) 5/26/2013 11:30:26 AM 0AA8 PACKET 0000000002D5D920 UDP Rcv 192.168.1.22 97c5 Q [0001 D NOERROR] A (6)static(2)ak(5)fbcdn(3)net(0)
Restarting the server or DNS service, or clearing the DNS server cache doesn't make any difference. EDNS is disabled (which did improve matters). Internet connectivity is generally good:
Ping statistics for 4.2.2.3:
Packets: Sent = 40, Received = 40, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 259ms, Average = 34ms
Subsequent queries tend to succeed, but by then it's too late for the client, which has already cached the bad result returned previously. If I do IPCONFIG /FLUSHDNS on the client and try again, it generally succeeds.
Any ideas?