Mitigating DNS DoS Attacks H. Ballani and P.Francis

1. Mitigating DNS DoS AttacksH. Ballani and P.Francis Presented for CSCE 715 class by Ahmad Almadhor On Nov. 4th 2010

2. outline • Background: DNS and resolvers • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

3. What is DNS? Resolver? • DNS : • hierarchical naming system built on a distributed database for computers, services, or any resource connected to the Internet or a private network. • translates human-friendly computer hostnames into IP addresses.(phone book) • Ex.: the domain name www.example.com translates to the addresses 192.0.32.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). • Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains and so on for sub-domains. • DNS resolver: • determines the appropriate domain name servers responsible for the domain name in question by a sequence of queries starting with the right-most (top-level). • Caching is a technique to solve DNS overhead problem Source: Wikipedia Almadhor 715

4. Resolver process illustration Source: Wikipedia Almadhor 715

5. Almadhor 715

6. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

7. Introduction • Recently, many DoS attacks on DNS to prevent client from resolving resource records from an under attack zone. • Many proposals suggesting new architecture for the naming system in the internet to decentralize data distribution. • The authors think that no need to have a new architecture. • So, just a new technique built on the current framework would allow availability in resources. • Resolvers use caching to improve performance (reduce overhead) by using TTL “time to live” then discard them. • The new proposal is to modify resolvers operation: • data from cache memory is stored to a new memory “Stale Cache” after TTL expired. • So when an authoritative name server is not available, stale cache can be used to answer queries • Problems: • Obsolete data in stale cache will be showed small (<0.5%) • DNS semantics violation but is not adversely impact the fundamentals of DNS Almadhor 715

8. Resource: techrepublic.com Almadhor 715

9. DNS poisoning attack • DNS cache poisoning (sometimes referred to as cache pollution) is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching nameserver. • The impact is all web traffic, email, and other important network data can be redirected to systems under the attacker's control. • Solutions: • Apply a patch from the vendor • Restrict access • Filter traffic at network perimeters • Run a local DNS cache • Disable recursion Source: US-CERT. Almadhor 715

10. Source: www.ipa.go.jp Almadhor 715

11. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

12. DNS resolvers today and flooding attacks • Resolvers: • Get queries, map them to a matching resource record, get responses (not necessary answer the query), cache answers with TTL (either positives or negatives). • Check the cache for matching, if yes return a response; otherwise: • Determine the closest zone, if it’s cached then traverse it down. • if not go to TLD and traverse it down. • Failure scenario when a name server is not available fig 1. • Attacks: • Flooding (e.g. by requests) name servers of a zone to disrupt the resolution process and its sub-zones. • Denying the service between servers and clients. Almadhor 715

13. Almadhor 715

14. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

15. Resolvers adjustments and the new cache • Resolvers have a new job: • Storing cache data with expired TTL into the stale cache. • when the authoritative name servers are unavailable during the process of resolution as in fig 1, a resolver only now has a right to check the stale cache to find the queried record figure 2. • Resolvers can do resolution process and stale cache lookup concurrently. • Stale cache cleaning: • When a normal response from resolution process is received, it’ll be cached; besides the corresponding record in the stale cache will be removed. So, the new record will be in the stale cache after TTL expires (even negative responses). • This cleaning procedure helps keeping the stale cache updated with latest authoritative info. • Stale cache storage space requires small amount, even with a month’s worth of stale records. Almadhor 715

16. Almadhor 715

17. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

18. Evaluation • Collected DNS traffic from CS dept. @ Cornell network link to the internet (using the network border router not at the resolvers), queries responses from cache were not observed. • Roughly 1300 hosts during 65 days • There were 84,580,513 DNS queries and 53,848,115 DNS responses for a total of 4,478,731 unique names • Packets were anonymized for privacy purposes. • The simulation was trace-based and controlled by two parameters: • Stale cache size: X= 1 to 30 in days • Attack duration: 3,6,12 and 24 hours • Took the 7 days trace data into the stale cache and simulated an attack lasted for 3 hours. So, it was flexible to adjust the stale cache size and the attack period. Almadhor 715

19. Implementation • They used extreme scenarios (more than realistic flooding attacks) to test the stale info. • Fig 3 shows 1-day stale cache answers 68% queries in 3hr attack, and the fraction increases by the days. However, it diminishes after 14 days as shown in previous studies that the popularity of DNS names follows a zipf distr. • From fig 3, the fraction of queries answered increases with attack duration. Why? Almadhor 715

20. Resolver cache has valid info., so no need to use the stale cache. • Now, Note: the trace did not include network’s resolvers, so this underestimated the actual fraction of successful answered queries in presence of stale cache. • Since stale cache has records with expired TTL, then accuracy problem arises. • To test the accuracy of the responses, they compared the simulation result with real resolution responses from the NS. Fig 4 Almadhor 715

21. In fig 5, is a comparison between the responses for A-queries(records) and NS-queries(records) using only the stale cache (no resolver cache) under 3 hr attack. • Notice that NS has much less responses that A. Why? • NS has longer TTL, so they are still in the resolver cache, or not used in the past. • However, the accuracy fraction is surprisingly high for both (>99.5%). Fig 5 Almadhor 715

22. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

23. Three attacks: • Queries for NS-records corresponding to TLDs are failed. • Such queries are successful with the stale cache because they were captured during the trace and hence will be in the cache or stale cache. • A client is not able to access TLD name serves(second-level ”a.com”). • Fig 6, the queries answered increased but stable later because longer TTL Almadhor 715

24. 3. Similar to the previous attack; so third-level ”b.a.com” name servers are not accessible. • Focused on queries are not cached by the network’s resolvers. • Both A and NS records for names are accessed by clients with higher fraction of queries answered fig 7. Why? • Lower TTL –values. Almadhor 715

25. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

26. Memory requirements for the stale cache: • Number of clients • Query patterns • Resolver may use some rules for stale cache eviction algorithms (i.e. Least Recently Used) • In their simulation, they used: 1 to 30 days stale cache, 1300 hosts and query response rate 25 DNS packets/second; hence they used <313 MB only!! Almadhor 715

27. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

28. Pros • DNS robustness: resolvers surly can respond to queries; also this approach can be adopted by the resolver operators. • Simplicity: • No change in the protocol operation neither infrastructure. • No extra load on DNS • Does not impact the patency of query resolution (it’s used only when a query resolution fails) • Incremental deployment: any resolver can adopt this proposal easily and successfully. • Motivation for deployment: since it’s beneficial for the clients and resolver Almadhor 715

29. Cons Almadhor 715

30. Almadhor 715

31. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Related work • Future work Almadhor 715

32. Related work • R. Cox, A. Muthitacharoen, and R. T. Morris, “Serving DNS using a Peer-to-Peer Lookup Service,” in Proc. Of IPTPS, 2002, M. Handley and A. Greenhalgh, “The Case for Pushing DNS,” in Proc. of Hotnets-IV, 2005. • those papers and many others are proposing a new naming system architecture and others to multicast the global DNS to specialized servers. • 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. • This paper suggests to make DNS TTL-values higher for infrastructure records which is similar but it is harder for operators to update records. • K. Park, V. Pai, L. Peterson, and Z. Wang, “CoDNS: Improving DNS Performance and Reliability via Cooperative Lookups,” in Proc. of USENIX OSDI, 2004. • It is introduced cooperating DNS resolvers within the a zone to avoid DoS. Almadhor 715

33. outline • Background: DNS and resolvers. • Introduction • The basic idea: • DNS resolvers today • DNS flooding attacks • Resolver modification • Stale cache • Evaluation • Implementation • Performance under different attacks • Memory • Pros and Cons • Relatedwork • Future work Almadhor 715

34. Future work • Extensive work on DNS records accuracy at the stale cache which has been one big opposition on this work. • Combining this approach “stale cache” with others such as Co-operating DNS resolvers proposal and studying their performance together. • Studying further on cost concerns when it is deployed on current systems. Almadhor 715

35. Questions! Source: http://blog.contentmanagementconnection.com Almadhor 715