 In this set of slides, we will have a look into a real attack against the DNS infrastructure. The DNS infrastructure can be in itself a target of attacks, for example, a DDoS attack. DDoS attacks aim at hindering or stopping the functioning of a certain service. What would then be the effect of degrading the performance of DNS? The easy answer is that any application that has a dependency on DNS will suffer. Unfortunately, nowadays, this means a large portion of the Internet as we know it. To give some examples, the web, but also email, instant messaging, and the Internet electronic. DNS has a certain building resistance to attacks. First of all, DNS is highly distributed and redundant. Second, caching can get you a long way before a failure propagates. For example, assuming that a root server fails, it is likely that the local resolver has already cached the relevant IP addresses for some TLD servers, and the time to live for such a resource records is in the ordinary days for most zones. At another level of the resolution process, however, a failure can be not as much faster, ultimately resulting in failed queries. For example, the time to live for cnn.com is five minutes, which means that if all the authoritative name servers for cnn.com are down for more than five minutes, nobody would be able to resolve the name anymore. Caching is not the only consideration to be made, however. It is also a matter of number of queries. Considering that a root server might receive a number of queries per day in the order of billions, an attack to the root of the DNS is clearly a very serious business. In this lecture, we analyze the recent attacks on the DNS root servers. On the 3rd of November and the 1st of December 2015, most of the root servers experience what is suspected to be a DDoS attack. There is currently no agreement as if the event was a DDoS attack targeting the root of the DNS, or if the target was something else, but the net effect is that we have observed exceptional side effects at the root servers. So, in lack of more information, we refer here to this event as an attack. There were actually two separate events, one on November 30 and one on the 1st of December, but the modus operandi was the same. The root servers received an enormously high number of queries on IPv4 and UDP. Analysis of the traffic shows that all the queries were for only two domains. Researchers at VeriSign, who have analyzed the attack, report that 10 out of the 13 root servers received attack traffic. We have already mentioned that a root server might receive billions of queries per day. Let's have a look at how the root of the DNS is implemented. First of all, there is not a single root server, but 13 of them, named with letters from A to M. Each one of the root servers can answer recursive queries and knows how to reach the TLD authoritative servers. In practice, 13 servers is still a relatively small number for such a crucial service. Under the hood, for resilience and performance reason, most of the root servers are implemented using AnyCast. AnyCast is an addressing methodology that allows a receiving IP address to have several replicas. This means there will be several servers all with the same IP address online at the same time. Traffic to an AnyCast IP address will be routed to the closest replica, where typically we intend closest in a routing sense, but hopefully this is also consigned with a geographically close replica. AnyCast has the advantage of introducing redundancy in a service which is beneficial for resilience and performance. In case of the root servers, this means that hundreds of replicas are scattered all over the world. For example, Amsterdam hosts replicas for server E, F, I, J, K and L. Coming back to the attack, this is an example of how one of the root servers, the A-root, operated by Verisign, has seen the attack. In the picture to the left, we have the query volume in millions of queries per day. A-root registered total number of IPv4 UDP queries of $52.8 billion on November 30, 2015, against a general trend of around $3 to $6 billion per day. Verisign reports that for the duration of the attack, A-root registered a peak of $5.2 million queries per second. The attack is also clearly visible if we look at the number of IPv4 addresses contacting the servers on the right. This number spikes to $1.8 billion against a few million sources during a normal day. Verisign reports that about 895 million different source IP were involved in the attack for the two root server they manage, A and J. Finally, let's have a look at another characteristic of the attack. Most of the queries were regular, well-formed queries. This graph reports the response code for the query received by A-root. Most of the queries during the attack receive a non-error code, meaning that the queries were completed with success. The analysis of the query returns code shows that A and J-root succeeded in handling the attack, despite higher query load. Let's now have a look on how the other root servers reacted. This picture shows the percentage of unanswered queries for each of the root servers over IPv4 and IPv6 separately. Have a look at the y-axis. Each dot on the plot represents a time slot of 10 minutes. The picture has been generated by the DNS-mon server's RIPE using props generated by the RIPE Atlas platform. A green dot indicates that the server is reacting normally. An orange of red dot indicates that the server is not able to handle all the query it receives. In the plot, we can clearly see two red zones related to the two attacks. The picture shows that the root server reacted differently to the attack. For example, not all the root servers after query loss during the attack, as we already knew that was the case for A and J, for example. However, some root servers were badly affected, as for example B, C, G and H, and to a somehow less-degree E, F, I and K. Besides analyzing the event, VeriSign researchers also provide some example of how such an attack can be mitigated in practice. Other approaches to mitigate attacks against the DNS or misuse of the DNS are possible, but we will look at them in the next video. For the specifics of this attack, the following two mitigation strategies have been put in place at A and J root. First, response rate limiting. Response rate limiting is a mechanism recently embedded in DNS software that allows a server to slow down the rate to which it answers to queries that arrive in iVolume. In the case of the November-December events, response rate limiting was able to drop 60% of the attack response traffic. Response rate limiting has the advantage that it might already be deployed at the DNS server, as indeed it was the case for this event. So it is an automatic mitigation mechanism. The disadvantage is that response rate limiting only acts based on the rate of request. It does not distinguish between attack or normal traffic. Therefore, part of the attack traffic is unaffected. The second mitigation mechanism was filtering. To filter, you need to be able to create a rule to distinguish between malicious and normal requests. In the case of this attack, this was possible, and filtering was a very effective mitigation strategy. The disadvantage, however, is that it needed manual intervention, both for analyzing the traffic and defining a filter, as well as for deploying the filter.