Solving complex DNS performance issues in enterprise networks

DNS performance issues in modern networks

The Domain Name System (DNS) is key networking application for proper functioning of modern day networks. Issues related to DNS failures and performance can hierarchically impact hundreds of commercial applications as every other application replies on it. If one of the DNS servers is misconfigured or compromised, each of the network components that relies on it also gets impacted. Although the DNS protocol is quite simple, it can lead to a significant number of network performance issues, particularly configuration issues that affect network performance, as well as security issues that jeopardize network integrity.

Network performance issues due to incorrectly configured DNS

DNS servers require very high availability to resolve all the names into IP addresses that are necessary for the proper functioning of applications on the network. An overloaded DNS server will take some time to respond to a DNS name resolution 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 DNS performance issues such as:

1) High DNS resolution latency

If you observe that the mean time between the client request—which is trying to resolve a DNS domain name (Eg: www.bing.com) into an IP address—is significantly higher than average (i.e., on a LAN it should remain lesser than 1 ms), it means that the DNS server has an issue with regards to the caching of DNS names. The DNS cache system makes it possible to resolve a name without a new request to the DNS server, which has authority for the DNS zone, for 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. 

2) Hosts generating high/bad query volumes

If we determine the top hosts making DNS requests, it will be possible to pinpoint misconfigured clients 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 functioning of the network.  Please note that hosts making a very high volume of DNS requests may correspond to a malicious behavior; for example, some malware tries to establish connections to the Internet by resolving domain names and sometimes the DNS protocol is used in cover channels to exfiltrate information.

3) Hosts generating high error volumes

DNS administrator can also look at the b (i.e., non-existing hosts, etc.). This will also shine a light on misconfigured workstations—generating an unnecessary traffic and lowering the overall network performance.

4) Updates between primary and secondary DNS servers

By analyzing traffic coming from the DNS server, we can also verify that the updates between primary and secondary DNS servers correspond to our request. To do this, we need to identify the full zone transfer (AXFR) and iterative transfer (IXFR) transactions towards its Authority server. If these updates occur too often—and therefore generate an unnecessary volume of traffic—we can conclude that there is an issue. If the bandwidth used is too high, 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 network performance.

5) DNS DDoS attacks

DNS amplification and flood are very common DNS attacks targeted towards commercial DNS servers and can immediately cripple the DNS servers. Botnets and hackers initiate large volumes of DNS requests to huge domains requiring DNS servers to open connections and un-necessarily resolve huge DNS domain trees. resulting in overload and rejecting legitimate requests form genuine users. Volume of DNS connections over a time and #users can give indicative examples of whether a DNS server is under a attack. Further investigation can reveal the source of the attack usually from public internet botnets and malicious servers.