This article is meant to help companies that own a DNS resolver and want to make sure their service is the best.
Response time can be divided into many portions, but usually the one companies are most interested in is the final response time seen by the end user. This is the portion that covers most delays and is closer to the end user perception.
There is many ways to divide the time measurement, but personally I find the following bigger divisions to make the most sense for response time.
1- Time it takes the end user device to send an UDP query
2- Time it takes the DNS resolver configured on the user device to find out the response. This section can be subdivided into many more which is mostly important for the companies owning the DNS resolver.
2.1- Time it takes to do the DNS recursion, resolve a DNS response to the end user query and hand the response to the OS where the DNS application runs.
2.2 – Time it takes the OS to take the response packet from the network queue and finally send it through the network interface.
3 – Time it takes the response packet to reach the end user device.
Companies that own the DNS resolvers have no idea how long it took for their DNS server response to reach the end user, but would usually focus on handing the DNS response packet to the network queue as soon as possible and will monitor these measurements as part of their KPI.
The easiest KPI to look at is the response time from the application to the network interface. Most DNS software will be able to provide means of looking at the response time, but this usually is only up to the transmission queue of the OS.
When needed to find out if some popular domains are slower because of the DNS server load, hardware bottleneck or an external cause it makes sense to perform measurements as a client on the same server; or at the end user side of the network if it is possible that the network is congested. A simple bash script like the one below that runs every few minutes could be enough information to give an idea of what might be going on.
#!/bin/bash
# get the parameters into variables
DOMAIN=$1
CMPTIME=$2
# make sure the parameter is considered an integer
CMP=$(expr "$CMPTIME" '*' 1)
# dns query command (requires dig to be installed)
command="dig ${DOMAIN} @localhost"
# capture response time
RESTIME=$($command | grep "Query time"| grep -Eo '[0-9]+')
# make sure the parameter is considered an integer
RESTIME2=$( expr "$RESTIME" '*' 1)
# echo an output only if response time is over the configured threshold from the second parameter
[ "$RESTIME2" -gt "$CMP" ] && echo "slow response of $RESTIME2 at `date` on `hostname`"This script will let you know if the response was slow or not given two parameters: domain name to be resolved and the threshold in milliseconds. The example above will query the domain “test.example.com” and print a message if the response took over 8 milliseconds.
#> bash testresptime.sh test.example.com 8
For regular tests a crontab line may be setup on the server, for example as below:
*/10 * * * * bash <path_to_script>/testresptime.sh test.example.com 8 >> /var/log/example.com_resptime.log
In this way it will run every 10 minutes and add a line to the log file example.com_resptime.log whenever the response is slow for later review.
It is very important to take into account that by running this request the DNS server will be queried periodically for the given domain name and thus it is most probable for the response to be already in the server cache which can translate into faster queries depending on how frequently the test is executed.
if preferred, when the response time is not slow very frequently instead of a log line an email might be more convenient. Given that the mail server is correctly configured on a rhel compatible server the last line of the script may be swapped by:
[ “$RESTIME2” -gt “$CMP” ] && mail “Slow Response Time of $RESTIME2 on `hostname`” > /dev/null “your.email@emaildomain.com”
Luis Castro's Blogs 