Troubleshooting DNS

DNS Response Time

Background:

The DNS (Domain Name System), which has been defined in detail in the RFC 1034 and RFC 1035, is key to the good performance of TCP/IP networks. It works in a hierarchical way. This means that if one of the DNS servers is misconfigured or compromised, the entire network, which relies on it, is also impacted. Although the DNS protocol is quite simple, it generates a significant number of issues: configuration issues, which affect the performance of the network as well as security issues, which jeopardize the network integrity. The purpose of this section is to cover the main configuration issues you may encounter with DNS when it comes to network performance.

Hypothesis:

You noticed a general slowdown for a specific host, zone, or the entire LAN. You didn’t find the issue with the previous methods. Maybe this problem has nothing to do with the business applications or your network equipment.

Diagnosis:

The DNS server(s) need to have a very high availability to resolve all the names into IP addresses that are necessary for the applications on the network to function. An overloaded DNS server will take some time to respond to a name request and will slow down all applications, that have no DNS data in their cache. An analysis of the DNS flows on the network will reveal some malfunctions like:

Latency Issues

If we can observe that the mean time between the client request is significantly higher than the average (on a LAN it should remain close to 1 ms), we may face three kinds of issue:

• The client is not requesting the correct DNS server (DHCP misconfiguration, for example). You can check this out in the interface by looking at the Server IP fields;
• It means that the DNS server has an issue with regards to the caching of DNS names. The cache system makes it possible to resolve a name without requesting the DNS server, which has authority for the DNS zone, the IP address corresponding to the name. Hence, if the response time is high, first the application will be slow from the user’s point of view and secondly, it will include an unnecessary consumption of bandwidth. This bandwidth will be wasted both on the LAN and on the Internet link (if we make the hypothesis that the authority server sits on the Internet). If we consider the case of a fairly large organization, the bandwidth used by the DNS traffic will not be negligible and will represent an additional charge;
• The DNS server may have system issues. If the server is overloaded, it cannot hold all the requests, and delay (or drop) some, which leads to a general slowdown of the network perfomances.

You can easily cast a glance at these issues: go in the Analysis -> DNS Messages menu, and fill the form with appropriate values (especially the Requester Zone), to verify that the requests are correctly answered, and in an acceptable timing.

Traffic Issue

If we establish the top hosts making DNS requests, it will be possible to pinpoint misconfigured clients that are not keeping the DNS server responses in a local cache. This approach makes it possible to distinguish between an issue coming from the user’s workstation and one coming from the general function of the network. Please note that hosts making a very high volume of DNS requests may correspond to a malicious behaviour. For example, some malwares try to establish connections to Internet by resolving domain names and sometimes, the DNS protocol is used in cover channels to escape information.

DNS Errors Issue

We can also ask for the top hosts receiving the most DNS error messages (non-existing hosts, etc.). This will also shine a light on misconfigured stations, generating an unnecessary traffic and lowering the overall network performance.

DNS Internal Misconfiguration

To do this, we need to identify the AXFR and IXFR transactions’ autorithy server. If these updates occur too often (and therefore, generate unnecessary traffic), we can conclude that there is an issue. If the bandwidth used is too large, it means that our DNS server requests a full zone transfer (AXFR) when an iterative transfer (IXFR) would have been more adequate. If this is the case, then the network administrator can take some easy steps to improve his network’s performance.