My struggling with NSLOOKUP and DNS, covered in other posts, relates back to a problem with our Sophos WS1000 web appliance. I'm now after some help with this source problem.
At the moment our main Internet connection is provided by the CC. All staff go directly through this, whereas students first go through the WS1000. Around 2-3 weeks ago, but possibly longer*, the Internet for students started performing oddly e.g. in a class of 30 some could open pages, and half often not at all.
After some troubleshooting it was identified that the WS1000 was part of the problem, as redirecting the Internet to go directly to the CC connection resolved the performance issue. After a week or so of toing and front with Sophos Support it was identified that NSLOOKUP on the WS1000 is very slow, often taking several seconds to resolve a single address. Sophos Support said the problem is with our DNS, hence for us to resolve.
The problem is that to get our CC Internet connection to work we have to go through a proxy, which is of course bypassing the internal DNS anyway, therefore isn't testing it. To try and get my head around where the problem lies I have used a command line programme called Dig (from BIND BIND | Internet Systems Consortium ) to carry out a timed NSLOOKUP from my PC, and the speed appears to be very quick (milliseconds). I also pointed the WS1000 gateway at a secondary connection we have on-site (a simple BT connection) and it was still problematic using our DNS server. I then switched it to Google DNS, and it was fine.
I'm now stuck as to what to test further to try and resolve where the problem is. Sophos are saying it's us, yet it isn't clear whether our DNS is definitely at fault (Dig suggests not).
Anyone have any ideas?
*Teachers were a bit slow in reporting this, so I'm wondering if it dates back to Christmas. Over the Christmas holidays our old physical DNS servers were shutdown and replaced by a virtual server. I'm not sure whether this is related. Also none of our student PCs (coincidentally all those affected) are appearing in reverse lookup, albeit the DHCP lease was set to 8 days. Today I changed this to 1 day.
Last edited by Gongalong; 3rd February 2012 at 01:59 PM.
To test the DNS server on your WS1000 (your description implies that you may have one), you should run dig, pointed directly at the WS1000 address as DNS server (e.g. dig www.bbc.co.uk @10.97.90.2), but supply different DNS names to look up each time. Not only that, but you really need to be sure that noone else in the school has looked up those addresses through the WS1000. This is because, if the WS1000 is a fully-recursive resolver, it will cache successful lookup results locally for the duration of the time-to-live which the owner of that DNS name has chosen - and this is often set up to seven days ahead.
What I'm really saying is that using dig against the WS1000 may produce spurious results.
However I think that the clue to your problem may be in your footnote. It's quite possible that the WS1000 is doing a reverse lookup on client IP addresses when it receives an HTTP request. For example, it could be doing this so that you could partition the internet access which different PCs receive, based on a PC's name or domain. Clearly, not being able to resolve the reverse lookup could have deleterious effects. Since this post is a few days old, maybe you've found that this is the solution already?
Ah, no the WS1000 doesn't have a DNS server. We're running one on a Win 2008 R2 server, which the WS1000 is using. I've been using Dig against our server.
I watched Sophos support though running NSLOOKUPs which were taking several seconds. As soon as they switched to Google DNS it took milliseconds. I can't understand why when I run an NSLOOKUP from my Windows client it seems to be fine, whereas the WS1000 is so slow.
Turns out this was caused by teaming being set to automatic on the DNS server (technically the host server, as the DNS server is a VM). Changing the team type to Network Fault Tolerance Only caused lookups to work. (Just in case anyone finds this via Google)