Association between DNS systems and DDOS attacks

Association between DNS systems and DDOS attacks

Since last year, DDOS attacks have risen to a new height. The iconic attack is a large-scale DDOS attack targeting the International Anti-Spam alliance and cloudflare, with the traffic reaching 120 GB at a time, of course, the subsequent DDOS attacks far exceed 120 GB, but this attack is indeed historic.

Now let's look back at these attacks and we know that their attack sources are caused by reflection attacks such as DNS and NTP. But why are DNS and NTP services so powerful? How can attackers make such a huge volume of traffic? How does a common DNS service become a large-scale attack when we use it on our daily network?

Now let's give the final answer in advance, and then explain:

1. DNS uses simple UDP packets for communication between the client and the server;

2. DNS is a pure natural traffic amplifier that returns a large response packet through a very small request;

3. The Internet is flooded with a large number of open DNS servers, which can accept requests from any client without being rejected;

4. network abuse may cause the issuance of packets with forged source IP addresses in many places.

These four problems finally combined to form the current DNS System Pattern and make the DNS system an important source of DDOS attacks. A normal DNS request may send only 64 bytes of traffic, but it may receive more than this number of responses. In some specific scenarios, this traffic can be increased by more than 50 times. Based on this ratio, if a botnet sends DNS requests at the same time, it is very easy to generate G/s traffic. If DNSSEC is used, the traffic will be larger.

The problem is that, in essence, these traffic and other traffic are both seemingly normal traffic, so a simple filtering mechanism will not work for this, we need to find deeper solutions to solve this problem that has plagued the Internet for a long time.

In the discussion of this issue, one of them mentioned that if you implement the network according to BCP38, you can prevent the fake IP address from sending DNS requests, this prevents reflection amplification attacks by using DNS. Of course, this topic has been longer than BCP38 itself, and BCP38 has been a document for 13 years, however, this still fails to change the endless source IP spoofing attacks in the past 13 years. Therefore, we should not report too much expectation for these attacks in the next several months or even a few years.

Another discussion is that the parser should implement the response rate limiting (RRL) and silently discard repeated requests that exceed the threshold value, which is indeed quite efficient for authoritative DNS, however, for Recursive parser groups, the effect is much worse, because once an attack is routed to each recursive server, the frequency detected after the attack is apportioned can not reach the detection threshold. However, implementing RRL on authoritative DNS is still a good choice.

In another discussion, shutting down these open recursive query servers, the open resolver project (http://openresolverproject.org) project is ready to do this, so that the maintainer of the open query server can check the configuration on its own, shut down the problematic queryserver, which is similar to the BCP38 reception level. Do not expect this method to be too useful. This is partly because a large number of recursive servers are neglected in management.

The line in which the DNS server receives a packet request to generate a packaging response has become an inherent attribute of DNS, especially for DNSSEC. We want to ensure the security of DNS resolution results, if you want to speed up, You must select the UDP protocol, combined with the ubiquitous recursive DNS query server, which leads to a larger response packet, eventually, this platform became an artifact of high-traffic attacks.

If we want to completely solve the problem of using DNS for large-scale attacks, we have little space to play. However, there is still a continuation of the view on whether DNS uses UDP.

 

In the original RFC1123, UDP and TCP are allowed as the DNS service protocol. The following section describes the Protocol:

 

"In the near future, the new DNS record type will exceed the limit of bytes, which is required for TCP-based DNS, therefore, the recursive parser and authoritative server must support the TCP mode to provide services as a backup solution for the current use of UDP, and TCP will be used in the future."

(Why is it 512bytes? This restriction comes from the ipv4 host requirement definition (RFC1122). All systems that support ipv4 must be able to receive at least 576 bytes, 20 bytes IP headers, 8 bytes UDP headers, and 40bytes ip options, this determines the maximum size of a single UDP packet is 512 bytes)

It is now possible to generate a larger packet in IPv4. The theoretical maximum is 65535 bytes, And the UDP packet size is 65507 bytes, however, such a large package will be split during transmission. In this case, a typical firewall rule can block the subsequent package, which may cause it to fail to reach the client, this is because many firewalls are based on UDP and TCP port addresses. Because these fragmented packages do not contain UDP or TCP headers, the firewall is in a dilemma. Are they allowed or not? In this situation, the firewall may eventually compromise and then make some attacks succeed. Or discard all the parts? Considering these two factors, the traditional DNS approach is to limit the UDP response packet size to 512 bytes, and when the packet size exceeds bytes, TCP is always enabled as a backup measure.

However, the client may not know that the DNS response package size will exceed 512 bytes, so to notify the client to use TCP to receive the entire DNS response, the DNS parser sends a response with the "truncated" bit set to the customer.

We have been sticking to this channel for many years. In most cases, DNS uses UDP for communication and only enables TCP communication in rare cases. This method was not so good when we considered adding a security certificate mechanism for DNS resolution. With the addition of DNSSEC, few response packages can be up to bytes, the mechanism of switching from UDP to client through TCP resend will inevitably lead to a delay in resolution.

As written in RFC5966:

Because the DNS core prototype has been set, the DNS extension mechanism has also been proposed (EDNS0 RFC2671). This mechanism can be used to indicate that the client can receive packets larger than bytes, A package sent from an EDNS0-compatible client to a compatible server can be the package size specified by the client buffer size without sharding.

EDNS0 allows UDP-based response packets to have a larger size. In this case, TCP has been widely used as a secret of martial arts and is only used for domain transfer. If you do not want to enable domain transfer, it seems that TCP has no effect at all.

In RFC1123, the necessary host conditions are described as follows:

The DNS parser and the secondary server must support UDP and can send query requests over TCP.

However, TCP-based DNS not only supports large DNS responses, but if we review the prerequisites for large-scale DNS reflection attacks, the universal UDP large packet response, and the lack of implemented BCP38, attackers can use source IP address spoofing to attack the target.

TCP will not cause this problem. If attackers initiate a TCP request by forging the source IP address, at most the target IP address will receive a small packet (40 bytes ), only the SYN and ACK tags are included. The target system will be discarded because there is no established connection to the status. Depending on the local configuration, the target IP address may send a tcp reset packet to the other end to indicate that the state is not established, or it is only discarded silently, so that the traffic amplification of DNS attacks will not be effectively solved.

If the DNS system has caused the entire Internet to face such a huge problem, should we stop using the large UDP response packet supported by EDNS0, and then use TCP to transmit large requests?

Let's take a look at RFC5966:

Most DNS service providers support TCP and the default software configuration also supports TCP. The main audience of this document is those...

Here we need to see the question: how can we quantify the coverage of DNS support for TCP requests and responses? What is the "majority" here?

 

Tests show that most DNS systems can respond to TCP packets. That is to say, it is feasible to use TCP to reply to large packets and organize DNS to send large packets using UDP, some DNS systems that do not support TCP either fail to request the first Server due to the configuration of the master-slave DNS, or request the next Server due to some other problems, that is, some of the DNS servers that handle TCP problems actually exist.

If you are a DNS System Administrator, we suggest:

1. Try not to maintain some small open DNS services, which should be done by network operators;

2. authoritative DNS must limit the request frequency. If bind is used, you can use the RRL feature provided by bind to limit the frequency. If it is PDNS, you can use firewall rules to limit the frequency;

3. perform a full check on the DNS system and configure the DNS system to prevent some low-level errors. Only through a variety of efforts can we gradually reduce the impact of DDOS attacks