Review of Mitigating DNS DoS Attacks

Review of Mitigating DNS DoS Attacks Tak-Lon Wu I433/I590 Research paper Computer Science Dept. Indiana University Bloomington, IN 47405 taklwu@indiana.edu 1. Introduction Abstract The Domain Name system (DNS) has become a ubiquitous part of modern internet infrastructure that maps numeric IP address to human-readable names. In the recent years, denial of service (DoS) attacks on DNS has a trend to be more serious problems. These attack is mainly related the hierarchical namespace architecture, which is hard to avoid as this architecture are widely deployment in multi-level approach. Therefore, researchers tend to solve this problem by changing its structure, configuring the original setting and enhancing the availability by augmenting its low-level DNS resolver. Such researches significantly improve the reliability and availability against that DoS attack. However, as the numerous solutions it has, there does not exist a standard way to achieve this problem. This paper gives a brief overview of DNS service, and review numerous recent researches tend to solve the DoS attack on DNS service. Internet has been widely used for almost 15 years. People are becoming abuse about internet and a part of daily life. One of the important components of internet is DNS service, which mainly converts the location information (IP address) to meaningful words. This service has become a ubiquitous part of daily computing such as connection information from a credit card machines to a bank s database, airport checking process

and other important daily life computing. As the more relies of this human-friendly service, it will be a disaster when this service is unable to function. Imaging numerous banks database or airport scheduling systems was unable to reach for 4 hours, this world probably will be mess up. [7,8,9] indicates a few denial of service (DoS) attack when a partial DNS service broken down. Especially, the case of [7] made the software kingdom, Microsoft.com, was unreachable for a day. DoS attack on DNS service become an unavoidable attack due to the publication of DNS service. Therefore, a large number of researches turn up in order to handle this problem. This paper is structured as follow. Section 2 review the background of a DNS generally operates and indicates a few DoS attacks. Section 3 illustrates the modern solution against DoS attacks. Section 4 focuses on the Mitigaing DNS DoS Attack [1]. And finally, section 5 and 6 gives briefly discussion and conclusion. 2. Background Review Domain name system (DNS) is now relied through the Internet Infrastructure, without the its support, the Internet will properly unable to function. Therefore, ensure this important service is running as the predicted situation becomes an essential issue. In this section, we introduce the hierarchical namespace structure of DNS, then indicate the common DoS attacks base on this structure, and finally give two examples of how researchers and companies face to these attacks. 2.1 DNS structure Root edu com gov mil org net uk cn... jp indiana... mit Microsoft Amazon. cs informatics chemistry Figure 1 DNS hierarchical namespace structure The basic idea of this naming service is to convert an IP address to a meaningful string such as 129.79.1.1 to www.indiana.edu. This string is processed from right to

left and use periods as separator, which first analyzes.edu, then Indiana.edu, and finally www.indiana.edu. Such process operates based on the hierarchical namespace structure as shown in Figure 1. The DNS hierarchy can be visualized as a tree, where each nodes in the tree corresponds to a domain, and the leaves in the tree correspond to the hosts being named (e.g. indiana.edu, Microsoft.com, etc.). A domain is also known as zones such as.edu,.com, and.net construct a zones within Root node, and Indiana.edu, mit.edu and others (*.edu) belong to the zone of edu. On the top of the tree represents as the Root name server, which is the core of this hierarchical namespace. It initially only has few machines, which was 13 at first, to hold the information related the second level. But now, it might be duplicated in order to support redundancy. The second level maintains by a group of Top Level domain (TLD) servers, which mainly handle the IP location of where a name-server of Microsoft.com or indiana.edu is. Third level and other levels are commonly known as authoritative servers which are hold by Universities or companies. The servers within this hierarchical service closely communicate to each other in order to support name translation. Figure 2 an example of a DNS query Figure 2 shows the method that a user asks a DNS resolver (local name-server) to obtain a related IP address. There are numerous local name-servers (properly at third level or a more descendant level) to serve the DNS requests from local users. These local name-servers take the responsibility to obtain answers (positive and negative) to local users. Here, once a successful (positive) request is done, these servers will cache the response and give a time to live (TTL) value for each response. Once these TTL expire, such caches will no longer exist in Memory and need to run the whole process again in order to obtain a new cache.

In our case, a local user asks the IP of www.cs.indiana.edu. Note that we assume no such cache in the local server, which means it has to obtain a new result to the user. First, the resolver follow the order: first Root server (Root level), then.com TLD server, and then Indiana.edu name-server, and finally cs.indiana.edu name-server. As can been seen, the operation follows the DNS hierarchy that each level s server stand as an important role. However, the more high level of this model (especially Root and TLD level), the fewer servers serve the requests. As a result, attackers focus on this special architecture and tend to deny this important internet infrastructure. The following section will briefly describe how a Denial of service (Dos) attack achieves underlying the DNS model. 2.2 DoS Attacks on DNS Denial of service (DoS) or Distributed Denial of service DDoS is one of common computer system attacks which main purpose makes a machine, service, system or other essential components of a computer system to be unavailable. In fact, DNS service is facing with DoS attack every day. One of the reasons is that DNS acts as a public service to serve all the internet users. Also, due to the hierarchical model which has fewer servers to deal with the requests on a higher level, attacker aims to deny legal user to obtain a DNS result from the higher level service (Root and TLD). The assets might vary from the attackers, but normally, a DoS attack. The method of such attack is obviously general and easy to understand. Having the characteristic of fewer servers on the higher level, attackers just need to overload those servers and cause other local name-servers unable to function as the target servers are too slow to answer the requests. Once this situation achieved, the whole target zones (e.g. Microsoft.com, Indiana.edu) are unable to reach as users cannot obtain a correct DNS response. Over the past ten years, there are numerous cases suffering from this DoS attack. According to the [7], in 2001, the Microsoft.com s (including MSN.com and other related sub-zones) network was unreachable due to the DNS attack. The duration was almost a day, and the engineers of Microsoft took a four-hour check to investigate the problem. At that moment, the company even contacted to FBI. And finally, they found out the reason might due to the changing a new router configuration, which opened the holes of the firewall to the long-term attackers. Note that the case of Microsoft does not only blame the attackers, but also related to the misconfiguration of the router and lack of backup DNS mirrors when the main service failed. In addition, another significant fault was all the DNS servers were on the same Network at that time. [8] and [9] also aware the DNS administrators that DoS on DNS service are now focusing on the root and TLD server, not only a DNS resolver. There was no DoS attack to the root server in 1990s [8]. However, as information technology grows rapidly and computer knowledge becomes a more common sense to people, such attacks cannot be avoided. Therefore, a large number of researches tend to come up with this unavoidable problem. Next section will gives some examples related to DoS attack on DNS.

3. DoS on DNS Research As DoS attacks on DNS are unavoidable, there are a huge amount of researches try to mitigate this problem. Such researches can be classified as three kinds of solution: redesigns the DNS architecture, changes the original configuration with new mechanism, and adds new mechanism to the original structure. In this section, we will briefly introduce these three scenarios, and Section 4 will mainly give a detail example the third method. 3.1 Re-designs the DNS architecture The mechanism proposed by T.Deegan et. al. [2] is one of the representative methods to re-design the DNS hierarchical architecture. T.Deegan et. al. [2] does not only mention how to enhance the availability against DoS attack, but also suppose the new design is reliable and can achieve a high performance. The idea of this mechanism is simple, which try to replace all the authoritative servers (including Root, TLD, and third level) with a single centralize database. This database is served by a small number of well-provisioned and well-placed servers. Obviously, comparing to the original DNS service, this method is trying to reduce the multiple communications between a resolver and the higher level name-servers. According to T.Deegan et. al. [2], there are several reasons to changes the architecture. First the Lookup latency, as the original DNS takes several steps to obtain the final result, each step has a interact delay. Once a heavy lookup comes in, the delays will increase as there are few high-level name-servers could answer the queries. Second is the administrative complexity. Although the multiple level administrative policies give the DNS services autonomy, it increases the lack of communication between different zones administrator, thus resulting delegation errors. The last but not least, the vulnerability of DoS, which act as a special case of point one. The default implementation of DNS service suggests that a zone should be served with more than 2 name-servers Figure 3 [2] (a) original DNS architecture (b) a centralize database DNS architecture

against unavailability. However, there are many low-level zones operated with only 2 name-servers due to the cost of hardware. As a result, it is easily suffered from a DNS DoS attack. Figure 3(b) illustrates the basic idea of this centralize mechanism. They replace the all upper level name-servers (server side) expect the resolver with a large-scale, closely connected authoritative servers; meanwhile, the client side user do the same as the original DNS service. As large-scale distributed system, Grid computing and Clouding computing are widely used to achieve high performance, availability and reliability services. This single centralize database mechanism likely share the same advantages with such services. The main problem with this database is properly the same as a large-scale distributed database, which need to keep consistent between different nodes. Once this re-centralized mechanism achieved, the multi-level DoS against DNS can be solved. Moreover, it also can set rules to mitigate other attack as it is a centralized service. 3.2 Change the original configuration DoS attack on DNS always tends to deny the Root and TLD name-servers with the scenario that there are no such caches in memory. The reason that a DNS resolver does not have such record is always due to the short TTL time [3]. According to the original DNS designer, Mockapetris, indicated that The administrator defines TTL values for each resource record [RR] as part of the zone definition; a low TTL is desirable in that it minimizes periods of transient inconsistency, while a high TTL minimizes traffic and allows caching to mask periods of server unavailability due to network or host problems. After the first draft of [3], V.Pappas et. al. [4] proposed a method to enhance the DNS resilience with a reasonable TTL modification. The original DNS service aims to use short TTL values to provide an accurate answer. Such TTLs would not be longer than few hours, and it might cause a frequently refresh of the related record. Here, too frequent refresh of such record will probably cause Denial of Service. Therefore, V.Pappas et. al. [4] supposes to use longer TTLs to provide a more reliable DNS service. In practice, all the RRs that belong to a zone are available from a set of DNS server called authoritative name-servers for such zone. All this authoritative name-servers are identified by a Name-server (NS) record, which is a string. Such NS record need an A-record (IP address) to contact an authoritative nameserver (zone), and the set of this record are name as infrastructure resource records (IRR) [4]. This IRR is stored in cache after a query search the related zone for once. For example, one searches www.indiana.edu, then that resolver will store the IRR of Indiana.edu. And the second time when some others ask the same zone or subzone (e.g. www.cs.indiana.edu ) will not send a request to the root server for asking where the.edu and indiana.edu located. In other word, it can directly connect to the target name-server and reduces traffic to the root server. Some TLD name-servers, which directly below the Root level name-server, have IRRs with relatively TTL values. This mechanism is due to the few number of Root server need to be protected. However, many zones below TLD level have a short TTL for such IRRs. During the DoS attack, the re-

quests that send to the root or TLD service are potentially causing a time-out. At that time, user cannot get any information from the DNS resolver. But, if the resolver has a longer TTL of IRRs, some of these requests might able to answer as there is such related information. This idea is simple, however, once the TTL of IRRs increase, it might cause an indefinitely memory problem. Therefore, defining how long a IRR is kept and how to solve the memory problem are important. V.Pappas et. al. [4] introduces three critical ideas: TTL refresh, TTL Renewal and Long TTL. First, TTL refresh means when subzones of a zone need to be asked, and if there is a cache of the IRRs, the resolver refreshes the TTL (detetmine by the new request) after the request finishes. This refresh keeps popular IRRs alive in the cache. As an IRR might expire before TTL refresh, TTL Renewal can renew the IRR before that IRR ready to expire. A certain credit c which defines the number of times a IRR could be renewed after it has expired. There different way to increase the credit c, but this credit mainly decreases by one when each time the IRR expires. And the last suggestion is long TTL, it could be thought as the combination of TTL refresh and TTL Renewal. However, once the IP address of that authoritative name-server has changed, this TTL is useless. But due to the IRR represent the high-level name-server, they seldom change the IP address. 3.3 Add new mechanism to the original structure DNS service is now widely used by internet users; it also stands as a symbol modern naming system. Numerous researches tend to keep this infrastructure and add new mechanisms to face the common DoS attack. One of the researches is proposed by K. Park et. al. [5], a CoDNS which improves the performance and reliability against DoS attack via a Cooperative queries Lookup. First, it has to identify two parts of server, a server-side and client-side. A serverside server means the high-level server (Root, TLD), a client-side server means the local Figure 4 a basic example of CoDNS

DNS resolver. As a DoS attack always make a local DNS resolver timeout from the serverside servers, a local DNS resolver will meet a situation that is unable to answer the queries. K. Park et. al. [5] suggest to keep the server side sever, but having a small change to the client-side server. They build a trusted, closed and fast peer network with several local DNS resolver to construct a Content Distributed Network (CDN). CDN is widely used by video media such as CNN.com and youtube.com., and the benefit of this approach to DNS will share the ideas of availability and high performance. In other word, content of a DNS record will separate through this small network. Once one of these peers is experiencing a problem, it starts up the CoDNS mechanism to forward the name lookup to its entire neighbor until a response returns. The main problem of this idea is building such trust-connected environment increase the system complexity. That means it has to include a trust mechanism to this peer network, and must rely on each peer. Otherwise, if one of the peers is compromised, the trust connection will dissolve. According to the implementation, this CoDNS is started as a background service. Once an event of local DNS resolver is slow which a certain period of waiting with a normal query, this CoDNS service will immediately operate and send a forward lookup to its peer. The remote lookup queries return dynamically, and the duration depends on the response time of its peers. Before sending the first remote query, there is an initial delay and this delay is adjusted based on the health state of a related DNS resolver. Once if the past 32 query are all resolved without using any forwarding lookup, it set as an initially delay of 200ms. This value is chosen as twice of a normal DNS query delay which does not exceed 100ms generally. And if the peer query win more than 50% of the last 60 request, the delay of forward set to 0ms, which means it immediately forward the query to its peer. This approach could enhance the single resolver of the traditional DNS client-side, and the experiment shows the ability to mitigate the unavailability during the DoS attack. Figure 4 shows the architecture of this mechanism. 4. Mitigating of DNS DoS attack According to the previous section, we see that a DNS flooding attacks certainly causes a DoS attack making a DNS service unable to serve the normal function. Focusing on the rule that does not change the infrastructure, this section will describe a detail research to conquer the DoS attack. This method assumes a situation happened only during a DoS attack, and it will only function when such situation occurs. Such assumption make the original DNS service keep the general operation, and create a crisis mechanism to deal with the attack. Figure 5 shows a Traversal fails which always occurs in DoS attack. Such scenario has been discussed in the previous section. Once again, this fails causes by the short TTL in cache, and needs to retry the whole process to obtain an appropriate result. As the network traffic increases, the more timeout will eventually break down the DNS service. Based on this problem, H. Ballani and P. Francis [1] try to use a stale cache to improve the availability when such Traversal fails (DoS) occurs. A stale cache is a group of cached, expired records which a Local DNS resolver has evicted in cache and is ready to expunge.

Figure 6 shows an example of this mechanism. With the familiar idea as V.Pappas et. al. [4], it stores the IRR of a zone in order to reach a cached subzone when the TLD server cannot be connected. This stale cache is an individual component new to the DNS structure, and it is easy to approach. As can been seen, the process in Figure 6, step 4 is the Figure 5 a Traversal fails in general DNS time that the DNS resolver cannot communicate to the TLD name-server (probably a DoS attack). Therefore, it tries to scan the stale cache if a cache hit could be found. In our case, the stale cache has the result of the name-server (NS) of Indiana.edu, and fortunately the NS of Indiana.edu does not change. Note that if stale cache does not evict such record or the NS of Indiana.edu has changed, this mechanism is still unhelpful. But according to the paper [1], the latter case has a small possibility to happen. Therefore, with former case, it conducts some important issue: when this stale cache update, how long it evict a record, and how it can be store within the resolver. First of all, this cache is updated when the normal cache get a result from the high-level name-server. This result is either positive or negative, e.g. a domain no longer exists. It ensures the record store in the stale cache is up to date. Second, it is hard to Figure 6 an example of Stale cache hits

determine the TTL of a stale cache due to the thousand of zones has a different population. But they provide an evaluation that the longer TTL as a stale cache stores, the higher cache hits it is served. And it seems like 14-day stale cache (with 79.6% of queries can be answered) is a bottleneck to this mechanism, as the more days stale cache only have a few percentage increases. And finally, a 30 days stale record uses < 313 MB with almost 2,700,000 cache record. The statistic indicates that this mechanism does not use much memory to store the record; therefore they suggest using memory for storing the stale cache as today s strong hardware support. 4.1 Pros The advantage of using this mechanism obviously is the availability. The main purpose of this method is to answer the query during a high-level name-server is attacked. It assumes previous queries has recorded in the stale cache, and a DoS flooding attack appears, this modification ensures that a resolver can respond for that zone as that zone s authoritative name-servers are unavailable during DoS attack. It enhances the DNS robustness with a lightweight change. In addition, the other beauties of this mechanism are that it does not change the original DNS structure, and only functions when a query is failed with a traversal fail. These two conditions do not involve any overhead to the DNS resolver, even if the caching behavior has been modified. 4.2 Cons Meanwhile, there is a significant minor point of this mechanism. It is certainly a big trouble to the service, which the using the previous cache as answer to internet user. If a zone or such stale record has change its IP address or currently unreachable to public during this mechanism is running, it probably will answer the user with an incorrect result. At that time, user still needs to resend the query and suffers from the DoS attack. Therefore, the using of stale cache is a Double-edged sword. But, other researches mentioned in [1] prove that the name-to-ip mappings tend to be stable with less than 2% of changing the IP address more than once a week, that means such scenario happen with a small probability. In addition, once the attackers learn this mechanism, they might keep track the record and figure out which zone might not be cache in the stale cache. After they know such situation, a DoS attack is still vulnerable to this system. In sum, this mechanism has a main benefit of its simple idea which just utilizes the previous caches to provide available service during a DoS attack, however, once the attacker learn the concept of this mechanism, it will easily conquer the new modification. Also, as it does not change the DNS architecture, it shares the disadvantages of the original DNS such as high latency when a new query asked during the DoS attack. That means vulnerability still exists, but a different scenario. 5. Discussion Obviously, the current DoS attack on DNS is due to the hierarchical architecture. So, the method that changes the current DNS structure could significantly solve this

problem. However, whenever a new system approaches, numerous problems will follow. Also, with changing a human abuse service, it takes time to get used to a new mechanism even though such service is perfectly designed. One significant advantage of T.Deegan et. al. [2] s project is that they only change the server-side architecture, the setting of that layer of are always maintained by a group professional administrators. Normal user or DNS resolver does not need to worried about how they change the behind infrastructure. Meanwhile, such mechanism will cause a lack of autonomy and increase the complexity. The second approach [4] tends to use the characteristic of current DNS service by changing the TTL values of the IRRs record. Such mechanism is good and easily achieve. The only problem is certainly related to the extended memory size, even if current system can accepted such increase, it still need to reduce the memory size in order to provide a DNS-like process. Third, CoDNS [5] suppose to use a CDN-like mechanism to provide a trust, lightweight, high performance, and better availability service. However, having a trust environment is hard to determine by simple policies although it does not concentrate much on the paper. Finally, the stale cache resolver [1] apparently has a similar idea to CoDNS [5]. They share the same idea that only changes the resolver in order to fight against the DoS attack, and it is important that they do not change the original structure. But the only difference is the latter involves resolvers cooperating together to achieve a more reliable service, meanwhile, the former use the local storage to insure themselves against DoS on DNS. 6. Conclusion This paper presents a clear review of the DNS hierarchical architecture. The hierarchical architecture with fewer name-servers causes significant DoS attacks commonly occur underlying this infrastructure. Therefore, different researches such as redesigning a new architecture to DNS service, applying small configuration of current DNS service, and adding a mechanism based on the current DNS structure are widely discussed in order to protect this indispensable service. And till now, no one can dominate this field due to the daily, important usage to internet deeply influences internet user can only rely on this public and old fashion mechanism. However, this mechanism might still use for several years and even more than 5 years until someone eventually make a brand new, a more safe and more efficient naming service. In sum, all the above methods we have shown can mitigate the DoS attack on DNS service. Even though there are more solutions to the current DNS infrastructure, it is better to investigate new mechanisms to replace this service, as this service is widespread known and frequently attacker by attackers. Reliability, availability cannot be trusted with this sense. Such new mechanisms either change the server-side or clientside will be still valuable. Moreover, the idea of CoDNS [5] and H. Ballani et. al. seems can be combined together. With the reliable CDN peer network supported by CoDNS and the lightweight implementation provided with stale cache, it might able to construct a more reliable and reachable service.

References [1] H. Ballani, and P.Francis, Mitigating DNS DoS Attacks, Proceedings of the 15th ACM conference on Computer and Communications Security (CCS), pp. 189-198, 2008. [2] T. Deegan, J. Crowcroft, and A. Warfield, The Main Name System: An Exercise in Centralized Computing, SIGCOMM Comput. Commun. Rev., vol. 35, no. 5, 2005. [3] V. Pappas, B. Zhang, E. Osterweil, D. Massey, and L. Zhang, Improving DNS Service Availability by Using Long TTLs, draft-pappas-dnsop-long-ttl-02, June 2006. [4] V. Pappas, D. Massey, and L. Zhang, Enhancing DNS Resilience against Denial of Service Attacks, in Proc. of Conference on Dependable Systems and Networks (DSN), 2007. [5] K. Park, V. Pai, L. Peterson, and Z. Wang, CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups, in Proc. of USENIX OSDI, 2004. [6] L. Peterson, and B. Davie, Computer Network : A System Approach, 4 th ed. Elsevier Inc : San Francisco, 2007, pp 657-665 [7] Microsoft DDoS Attack, NetworkWorld, Jan 2001, http://www.networkworld.com/news/2001/0125mshacked.html. [8] Root Server DDoS Attack, RIPE Mail Archive, Nov 2002, https://www.ripe.net/ripe/maillists/archives/eof-list/2002/msg00009.html. [9] Blue Security Kicked While It's Down, Washington Post, May 2005, http://voices.washingtonpost.com/securityfix/2006/05/blue_security_surrender s_but_s.html