DNS Resolvers Considered Harmful Kyle Schomp, Mark Allman, and - - PowerPoint PPT Presentation

▶
dns resolvers considered harmful
SMART_READER_LITE
LIVE PREVIEW

DNS Resolvers Considered Harmful Kyle Schomp, Mark Allman, and - - PowerPoint PPT Presentation

Mar 30, 2023 263 likes •620 views

DNS Resolvers Considered Harmful Kyle Schomp, Mark Allman, and Michael Rabinovich 2 DNS resolvers abstract complexity and offer the possibility of improved performance and better scalability . Why are they harmful? 3 Resolvers Are Vulnerable

slide-1
SLIDE 1

DNS Resolvers Considered Harmful

Kyle Schomp, Mark Allman, and Michael Rabinovich

slide-2
SLIDE 2

DNS resolvers abstract complexity and offer the possibility of improved performance and better scalability. Why are they harmful?

2

slide-3
SLIDE 3

Resolvers Are Vulnerable to Cache Injection

  • Kaminsky vulnerability discovered in 2008, 16% of resolvers

vulnerable to Kaminsky attack in 2012[1]

  • Preplay attack discovered in 2014, millions of wifi routers

acting as resolvers are vulnerable[1]

  • Shulman attack discovered in 2013, 79% of resolvers

vulnerable[2]

[1] Schomp, Kyle, Tom Callahan, Michael Rabinovich, and Mark Allman. "Assessing DNS Vulnerability to Record Injection." PAM (2014). [2] Herzberg, Amir and Haya Shulman. “Fragmentation Considered Poisonous, or: One-domain-to-rule-them- all.org.” CNS (2013).

3

slide-4
SLIDE 4

Resolvers Should Not Be Trusted

  • Resolvers rewrite responses for non-existent domains,

effects 24% of clients[1]

  • Others intentionally participate in hijacking domains (e.g.,

Paxfire in 2011[3])

  • Many countries use resolvers to enable censorship[4]
  • ...yet we give them access to sensitive user information

[4] Verkamp, John-Paul, and Minaxi Gupta. "Inferring mechanics of web censorship around the world." 2nd FOCI (2012). [3] Weaver, Nicholas, Christian Kreibich, and Vern

  • Paxson. "Redirecting DNS for ads and profit." FOCI

(2011).

4

slide-5
SLIDE 5

Resolvers Obscure Clients

  • Client-resolver location mismatch, 7.5-15% of clients suffer

reduced performance due to wrong CDN edge server[5]

  • Resolvers hide client population reducing the effectiveness of

DNS-based load balancing

[5] Huang, Cheng, Ivan Batanov, and Jin Li. "A practical solution to the client-LDNS mismatch problem." SIGCOMM (2012).

5

slide-6
SLIDE 6

[6] http://openresolverproject.org/

Resolvers Used In Amplification Attacks

  • 24 million open resolvers on the Internet today[6]
  • DNS amplification attacks are massive[7] and growing in

popularity[8]

[7] http://www.zdnet.com/the-largest-ddos-attack-didnt- break-the-internet-but-it-did-try-7000013225/ [8] NSFOCUS 2014 Mid-Year DDoS Threat Report. http://en.nsfocus.com/2014/SecurityReport_0922/190. html

6

slide-7
SLIDE 7

Existing Solutions

Solutions to some of these issues, e.g.,

○ Random transaction IDs and source ports mitigate guessing attacks such as Kaminsky ○ Closing open resolvers thwarts amplification attacks and preplay ○ EDNS-client-subnet (ECS) reveals more information about clients behind a resolver ○ DNSSEC provides data integrity and protects against all fraudulent records

7

slide-8
SLIDE 8

Existing Solutions Aren’t Working

  • Resolvers are still vulnerable to Kaminsky 6

years after its publication

  • Millions of open resolvers on the Internet
  • Current DNSSEC standard released 10

years ago, but deployment is still low

  • Vulnerabilities still being discovered

8

slide-9
SLIDE 9
  • Many security issues that are not being

addressed currently

  • Much of the attack surface lies on the

resolvers

Why don’t we just get rid of resolvers?

Looking In Another Direction

9

slide-10
SLIDE 10

ADNS servers (e.g., a.root-servers.net, a.gtld-servers.net, ns1.google.com)

Current Situation

You (on your laptop) ?

10

slide-11
SLIDE 11

Client Resolution

You (on your laptop)

11

ADNS servers (e.g., a.root-servers.net, a.gtld-servers.net, ns1.google.com)

slide-12
SLIDE 12

What do we gain?

Reduces system complexity Removes the target of cache injection attacks Client resolution not vulnerable to same attacks Benefits CDN load balancing and server selection

12

slide-13
SLIDE 13

What do we lose?

Resolver caches provide performance to the clients ...and scalability to the system Resolvers anonymize clients

13

slide-14
SLIDE 14

But how much scalability and performance do we lose? We use trace driven simulations to estimate client resolutions negative impact.

Measuring The Impact

  • Trace driven simulations to estimate client

resolution’s negative impact

  • The data

○ Network of approximately 100 residences ○ 2 recursive resolvers ○ 4 months of observations ○ Recursive resolutions of each domain name in the data

14

slide-15
SLIDE 15

Effect on Performance

DNS resolvers can reduce resolution time due to shared caching. Resolution times in trace vs. in simulated client resolution

15

slide-16
SLIDE 16

Simulated Resolution Time

Resolutions take a bit longer.

16

slide-17
SLIDE 17

Simulated Resolution Time

Resolutions take a bit longer.

16

slide-18
SLIDE 18

Simulated Resolution Time

Resolutions take a bit longer.

16

slide-19
SLIDE 19

DNS responses are not used immediately.

...But there’s some slack

17

slide-20
SLIDE 20

DNS responses are not used immediately.

...But there’s some slack

17

slide-21
SLIDE 21

DNS responses are not used immediately.

...But there’s some slack

17

slide-22
SLIDE 22

Only a small % of connections are delayed at all!

Delay On Connections

(more details in the paper) 18

slide-23
SLIDE 23

Only a small % of connections are delayed at all!

Delay On Connections

(more details in the paper) 18

slide-24
SLIDE 24

Only a small % of connections are delayed at all!

Delay On Connections

(more details in the paper) 18

slide-25
SLIDE 25

Finding #1:

Performance impact of client resolution is small

19

slide-26
SLIDE 26

Effect on Scalability

DNS resolvers reduce number of resolutions reaching authoritative servers Resolutions per authoritative domain in trace

  • vs. in client resolution

20

slide-27
SLIDE 27

Load on Auth. Domains

93% of authoritative domains will not see an increase in load

~but~

popular domains (e.g., com, google.com) will

○ use com as exemplar

21

slide-28
SLIDE 28

com Domain Load

  • Average load increases by 3.41 times!
  • Peak load only increases by 1.14 times
  • Which is more representative of impact on

com domain?

○ Uncertain, let’s make both manageable

22

slide-29
SLIDE 29

Increase Record Time-to-Live

  • SLD records normally have 2 days TTLs
  • Roughly 1.1% of those records change

during a week

  • What happens when the TTL is 1 week?

23

Average Load 3.41 => 2.13 times trace load Peak Load 1.14 => 1.03 times trace load

slide-30
SLIDE 30
  • Currently 1 question per DNS query
  • Protocol can support multiple questions
  • What happens when we ask 2 questions per

query?

Average Load 3.41 => 1.61 times trace load Peak Load 1.14 => 1.06 times trace load

Increase Questions Per Query

(reduces number of packets, not number of queries) 24

slide-31
SLIDE 31
  • What happens when TTL is 1 week and we

ask 2 questions per query?

Increase TTL And Questions

25

Average Load 3.41 => 1.33 times trace load Peak Load 1.14 => 1.06 times trace load

slide-32
SLIDE 32

Finding #2:

Scalability impact of client resolution is manageable

26

slide-33
SLIDE 33
  • Removing resolvers offers many advantages
  • ...and small loses

○ Loss of anonymity in queries ○ Increase in authoritative domain load

  • DNS prefetching has reduced reliance upon

shared caches

Final Thoughts

27

slide-34
SLIDE 34

?

Thank you!

email me at kgs7@case.edu