Mitigating DNS DoS AttacksH. Ballani and P.Francis

Presented for CSCE 715 class

by Ahmad Almadhor

On Nov. 4th 2010

2Almadhor 715

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. 4

3Almadhor 715

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. 4

Source: Wikipedia

4Almadhor 715 Nov. 4

Resolver process illustration

Source: Wikipedia

5Almadhor 715 Nov. 4

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. 4 6Almadhor 715

7Almadhor 715

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. 4

8Almadhor 715 Nov. 4

Resource: techrepublic.com

9Almadhor 715

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. 4

Source: US-CERT.

10Almadhor 715 Nov. 4

Source: www.ipa.go.jp

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. 4 11Almadhor 715

12Almadhor 715

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. 4

13Almadhor 715 Nov. 4

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. 4 14Almadhor 715

15Almadhor 715

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. 4

16Almadhor 715 Nov. 4

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. 4 17Almadhor 715

18Almadhor 715

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. 4

19Almadhor 715

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. 4

20Almadhor 715

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. 4

21Almadhor 715

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. 4

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. 4 22Almadhor 715

23Almadhor 715

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. 4

24Almadhor 715

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. 4

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. 4 25Almadhor 715

26Almadhor 715

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. 4

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. 4 27Almadhor 715

28Almadhor 715

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. 4

29Almadhor 715

Cons

Nov. 4

Objections Defenses

Change DNS semantics Does not affect the fundamentals of DNS

Inaccurate information being used Happens only under two conditions: A- NS for a zone are inaccessibleB- 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 loadrare Poole et.al. showed that it’s <2%So, it’s a small price to pay for robustnessOr 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.

30Almadhor 715 Nov. 4

Objections Defenses

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 harmfulinteractions with or implications for DNSSec

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. 4 31Almadhor 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. 4Almadhor 715

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. 4 33Almadhor 715

34Almadhor 715

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. 4

35Almadhor 715 Nov. 4

Questions!

Source: http://blog.contentmanagementconnection.com