While TCP based applications consume a larger percentage of the internet's bandwidth, DNS queries/responses are typically sent over User DataGram Protocol (UDP). UDP is popular amongst many real time applications due to its simple nature and ability to minimize transmission delay. While UDP poses many benefits in its application, a specific feature plays a big role in the behavior of systems where it is applied. Retransmission is defined as a behavior in which a response/request is resent due to packet loss. UDP’s lack of delivery confirmation makes having retransmission policy a key tool in application success. Of course this policy can be modified to fit the efficiency needs of an application. Internet traffic is known to be unpredictable therefore policy will vary as needed. An optimal approach would be to determine retransmission interval figures based on prior data.
Here is a clear example of a resolver making a request to an inactive name server created for testing purposes
A standard query was made to ns1.ns1monitoring.com at (159.203.187.64) from the resolver (45.79.187.48). Since the server had been spun down, the resolver hadn’t received a response and a retransmit was issued to once again determine the address of ns1.ns1monitoring.com.
However, it is important to note that the destination is slightly different this time around. After not receiving a response, the resolver decided to retransmit to ns2.ns1monitoring.com to determine the address of the ns1.ns1monitoring.com.
ns2.ns1monitoring.com responds with the full information for both name servers on the network in a timely fashion. This shows just how helpful DNS retransmissions can be in a situation where latency is high and/or a server is unreachable.
Although retransmission holds great benefits, there are negative connotations that pursue in its implementation. An overly aggressive retransmission value has the potential to increase latency for the community as a whole. In contrast, a passive value may lead to excessively packet loss with a low rate of recovery. A typical Retransmit interval is between 2 - 5 seconds. The hot and cold behavior of UDP retransmission makes finding a neutral balance very important in its implementation. When it comes to DNS, retransmission may also have a strong effect in an ongoing Distributed Denial of Service attack (DDoS). These malicious attacks aim to render a victim's domain inaccessible by overwhelming it’s authoritative DNS server using a high amount of faulty traffic. Unfortunately this process can be assisted by taking advantage of the UDP retransmission policy. A high volume attack with many dropped packets may lead to a sharp increase in duplicate queries in quick a succession.
The following screen shot contains an example of how retransmission can affect an ongoing DDoS attack.
As you can see there is a broad list of source IP addresses. Many of these addresses appear more than once in the “Source” column and are attempting to reach the same destination. These duplicate queries increase the amount traffic during an attack exponentially in turn making the attack even more aggressive than it was to begin with.
Well configured authoritative servers understand that legitimate DNS clients do not send duplicate queries at a rapid rate even during significant packet loss. As a DDoS mitigation strategy, many DNS servers will drop duplicate queries coming from same IP to the same destination. All though this may not bring the attack to a complete halt, it serves as a trusted strategy to aid the mitigation process.
Retransmission is a crucial part of any TCP/UDP enabled application. It's implementation is vital to system health and should be configured cautiously. Although many modern day attacks have a variety of ways to inhibit the functionality of authoritative name servers. Dumping malicious traffic based on retransmission policies still remains a valid weapon in the fight against cybercrime.