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

2. outline 1.Background: DNS and resolvers 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 42Almadhor 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 Nov. 4Almadhor 7153 Source: Wikipedia

4. Nov. 44Almadhor 715 Resolver process illustration Source: Wikipedia

5. Nov. 45Almadhor 715

6. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 46Almadhor 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 Nov. 47Almadhor 715

8. Nov. 48Almadhor 715 Resource: techrepublic.com

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 Nov. 49Almadhor 715 Source: US-CERT.

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

11. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 411Almadhor 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. Nov. 412Almadhor 715

13. Nov. 413Almadhor 715

14. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 414Almadhor 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. Nov. 415Almadhor 715

16. Nov. 416Almadhor 715

17. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 417Almadhor 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. Nov. 418Almadhor 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? Nov. 419Almadhor 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 Nov. 420Almadhor 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 Nov. 421Almadhor 715

22. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 422Almadhor 715

23.  Three attacks: 1.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. 2.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 Nov. 423Almadhor 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. Nov. 424Almadhor 715

25. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 425Almadhor 715

26.  Memory requirements for the stale cache: 1.Number of clients 2.Query patterns 3.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!! Nov. 426Almadhor 715

27. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 427Almadhor 715

28. Pros 1.DNS robustness: resolvers surly can respond to queries; also this approach can be adopted by the resolver operators. 2.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) 3.Incremental deployment: any resolver can adopt this proposal easily and successfully. 4.Motivation for deployment: since it’s beneficial for the clients and resolver Nov. 428Almadhor 715

29. Cons Nov. 429Almadhor 715 ObjectionsDefenses Change DNS semanticsDoes not affect the fundamentals of DNS Inaccurate information being usedHappens only under two conditions: A- NS for a zone are inaccessible B- records are updated since last access by the resolver, so: 1-When the records are moved to a new address  nowadays the old address is still up to guide the misbehaving resolvers who keep cached info even after TTL expired. 2- records have been changed to balance client load  rare Poole et.al. showed that it’s <2% So, it’s a small price to pay for robustness Or use RCODE field in DNS header to inform the querying client that response is based on the stale cache Autonomy for zone operators: Moving it to resolver operators; so zone op will lose control on their sub-zone. Not affected since they didn’t modify DNS hierarchical resolution process, so resolvers still need to traverse the tree Attackers attempting to force the use of inaccurate info.: they may take advantage of stale cache It’s a concern but such attacks are not practical and the duration of a sub-zone to be alive is not too long Privacy concerns: storing records beyond their TTL- values. Stale cache does not provide an attacker about identities.

30. Nov. 430Almadhor 715 ObjectionsDefenses Resolution latency in the face of an attack: when a resolver query each NS at a zone and wait the query to timeout, that would increase the latency the lookup latency problem can be solved by using aggressive values for these timers DoS’ing the application servers: This approach does not reduce the vulnerability of name servers to DoS attacks. Also, intend to measure this for name servers on the Internet as part of the authors future work. Interaction with DNSSec The proposal does not have any harmful interactions with or implications for DNSSec

31. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 431Almadhor 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. Nov. 432Almadhor 715

33. outline 1.Background: DNS and resolvers. 2.Introduction 3.The basic idea:  DNS resolvers today  DNS flooding attacks  Resolver modification  Stale cache 4.Evaluation  Implementation  Performance under different attacks  Memory 5.Pros and Cons 6.Related work 7.Future work Nov. 433Almadhor 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. Nov. 434Almadhor 715

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