This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
When troubleshooting application performance issues, network analysts might overlook name servers. Windows Internet Name Service (WINS), Lightweight Directory Access Protocol (LDAP), and Domain Name Service are the most common name servers in the corporate environment. Performance problems associated with name servers include overloaded servers, packet loss, and misconfigured clients.
Network analysts typically test name servers using ping to confirm a server is up and the network isn’t slow, or use Nslookup-type utilities to prove a DNS server is resolving names to IP addresses. There also are tools that perform a UDP or TCP port check for response time measurements, but they won’t actually perform a DNS lookup.
In this video, I focus on methods for troubleshooting DNS performance and demonstrate three free tools: The DNS Benchmark tool from Gibson Research Corporation, Google’s namebench utility, and DNS Jumper from Sordum.
Protocol or packet analysis is the most accurate and through method, but it involves quite a bit of work and isn't really scalable. First, you need to set up your analyzer to capture only DNS traffic (TCP or UDP), then you need to generate some DNS lookups. The simplest way to do this is to go to any news or social media site. Last, you need to review your trace and calculate your results. If you are comfortable with Wireshark, you could add a response time column and export as CSV, but then you need to use another application to calculate and report the results.
When testing DNS server performance, it's important to keep in mind what your goal is. All the tools I demonstrate here test from the first person perspective or the “end-user experience.” If you need to measure DNS performance from another angle, that is a different story altogether.
As I mention in the video, it's important to understand a tool's nuances in order to know what results are worth paying attention to and which to ignore. It's equally important to intentionally cause an error to see what the tool reports. In this case, I simply added a host to the DNS server list that is not a DNS server.