1. ECO-DNS: Expected Consistency Optimization for DNS Chen Stephanos Matsumoto Adrian Perrig © 2013 Stephanos Matsumoto1

2. 128.2.136.200 Motivation Caching Server ece cmu edu.. cs com Client 1 Client 2 ece.cmu.edu © 2013 Stephanos Matsumoto2 128.2.129.29 Client 3 Inconsistency

3. Motivation DNS caching is critical to reducing server load However, cached records can be inconsistent Currently, inconsistency can only be controlled by time-to-live (TTL) © 2013 Stephanos Matsumoto3

4. Motivation Inconsistent records for popular sites affect many users Server operators "set and forget" TTLs These problems will likely get worse due to… – Content delivery networks (CDNs) – Dynamic DNS (DDNS) – Future Internet proposals (Mobility First, SCION) © 2013 Stephanos Matsumoto4

5. Contributions Expected Aggregate Inconsistency (EAI) – Consistency metric that considers a record's update frequency and popularity ECO-DNS – Consistency control mechanism for DNS – Preserves "pull-based" nature of DNS – Backwards-compatible © 2013 Stephanos Matsumoto5

6. Key Ideas Considering a record's update frequency and popularity tells us what inconsistency we need to focus on ECO-DNS considers these factors to create an automated, backwards-compatible, flexible consistency control mechanism Remember this if you remember nothing else © 2013 Stephanos Matsumoto6

7. Outline Model – Defining an Inconsistency Metric – Caching server topology – Assumptions – Model and optimization System Design Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto7

8. Defining an Inconsistency Metric Inconsistency is caused by stale DNS records How bad is this inconsistency? More specifically: – How stale is a record when it is returned? – How many stale records are returned overall? TTLs can only approximate these factors © 2013 Stephanos Matsumoto8

9. Defining an Inconsistency Metric Inconsistency: Expected aggregate inconsistency (EAI) © 2013 Stephanos Matsumoto9 # of updates to r between t and t q All queries for r in time interval T

10. Outline Model – Defining an Inconsistency Metric – Caching server topology – Assumptions – Model and optimization System Design Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto10

11. Caching Server Topology Records are generally cached directly from the authoritative server Caching from other caches is discouraged, but future schemes may change this Thus we consider caching in a logical cache tree © 2013 Stephanos Matsumoto11

12. Caching Server Topology © 2013 Stephanos Matsumoto12

13. Caching Server Topology © 2013 Stephanos Matsumoto13 Inconsistency "cascades"

14. Outline Model – Defining an Inconsistency Metric – Caching server topology – Assumptions – Model and optimization System Design Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto14

15. Assumptions Query and update arrivals can be modeled by a Poisson Process Query patterns of different caching servers are independent Caching servers proactively cache (prefetch) new record before expiration © 2013 Stephanos Matsumoto15

16. Outline Model – Defining an Inconsistency Metric – Caching server topology – Assumptions – Model and optimization System Design Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto16

17. Model and Optimization How does our Poisson process assumption help us calculate the inconsistency? Over time period of length ΔT: – Expected query arrival time: – Expected missed updates for each query: – Expected number of queries: EAI for a single cache: © 2013 Stephanos Matsumoto17

18. Model and Optimization © 2013 Stephanos Matsumoto18 Inconsistency "cascades"

19. Model and Optimization © 2013 Stephanos Matsumoto19

20. Model and Optimization Based on the Poisson Process assumption, the EAI over a time interval is © 2013 Stephanos Matsumoto20

21. Model and Optimization © 2013 Stephanos Matsumoto21

22. Model and Optimization The TTL minimizing the cost function is: © 2013 Stephanos Matsumoto22

23. Outline Model System Design – Parameter Monitoring and Aggregation – Setting the TTL – Prefetching DNS Records Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto23

24. Parameter Monitoring/Aggregation What information is necessary to find the optimal TTL? Which nodes need to keep track of this information? © 2013 Stephanos Matsumoto24

25. Parameter Monitoring/Aggregation © 2013 Stephanos Matsumoto25 Set update frequency μ Collect λ's from children Estimate λ from queries

26. Parameter Monitoring/Aggregation Estimate λ using a sliding window for queries Send λ using special DNS message © 2013 Stephanos Matsumoto26

27. Outline Model System Design – Parameter Monitoring and Aggregation – Setting the TTL – Prefetching DNS Records Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto27

28. Setting the TTL Two choices for TTL: – Record-specified TTL (current method) – Locally calculated optimal TTL What are the pros and cons of each? © 2013 Stephanos Matsumoto28

29. Setting the TTL If we only use the record-specified TTL – Very little consistency control – Cache poisoning attacks can last a long time If we only use the locally calculated TTL – Unpopular records have a very large TTL © 2013 Stephanos Matsumoto29

30. Setting the TTL Solution: set TTL to be the minimum of the two values Record-specified TTL becomes an upper bound © 2013 Stephanos Matsumoto30

31. Outline Model System Design – Parameter Monitoring and Aggregation – Setting the TTL – Prefetching DNS Records Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto31

32. Prefetching DNS Records Pros and cons of prefetching records – Latency for a cache miss can be an order of magnitude more than a cache hit – Prefetching an unpopular record provides little benefit for the extra cost in bandwidth overhead © 2013 Stephanos Matsumoto32

33. Prefetching DNS Records Solution: prefetch only the most popular records – Popularity can be measured by query rate parameter λ or relative to other records – Saves cache space by evicting unpopular records © 2013 Stephanos Matsumoto33

34. Outline Model System Design Evaluation – Goals and Methodology – Single-Level Caching – Multi-Level Caching – Dynamic Parameter Changes Future Work and Conclusion © 2013 Stephanos Matsumoto34

35. Goals and Methodology Three main questions: – Does ECO-DNS achieve better consistency than today's DNS for the same bandwidth overhead? – Is multi-level caching more consistent than single- level caching for the same bandwidth overhead? – How well does ECO-DNS adapt to dynamic parameter changes? © 2013 Stephanos Matsumoto35

36. Goals and Methodology Simulations based on real-world data – KDDI (a large Japanese ISP) provided DNS trace data for 10 minutes every 4 hours over 2 days – CAIDA provided inferred AS relationships, which may model the topology of logical cache trees © 2013 Stephanos Matsumoto36

37. Outline Model System Design Evaluation – Goals and Methodology – Single-Level Caching – Multi-Level Caching – Dynamic Parameter Changes Future Work and Conclusion © 2013 Stephanos Matsumoto37

38. Single-Level Caching Use KDDI traces for query arrival times Compare normalized reduced cost U for various c and μ © 2013 Stephanos Matsumoto38

39. Single-Level Caching © 2013 Stephanos Matsumoto39

40. Outline Model System Design Evaluation – Goals and Methodology – Single-Level Caching – Multi-Level Caching – Dynamic Parameter Changes Future Work and Conclusion © 2013 Stephanos Matsumoto40

41. Multi-Level Caching Generate logical cache trees from CAIDA data Compare the cost of each node against the cost it would have in today's DNS We set the TTL in today's DNS to be the best possible value and compared it to ECO-DNS © 2013 Stephanos Matsumoto41

42. Multi-Level Caching © 2013 Stephanos Matsumoto42

43. Outline Model System Design Evaluation – Goals and Methodology – Single-Level Caching – Multi-Level Caching – Dynamic Parameter Changes Future Work and Conclusion © 2013 Stephanos Matsumoto43

44. Dynamic Parameter Changes Simulate random queries at the mean rate for each 4-hour period recorded by KDDI Use two schemes to estimate λ: – Time-based: divide number of queries in the past n seconds by n – Count-based: keep track of the nth most recent query time and divide n by the time interval © 2013 Stephanos Matsumoto44

45. Dynamic Parameter Changes © 2013 Stephanos Matsumoto45

46. Dynamic Parameter Changes © 2013 Stephanos Matsumoto46

47. Outline Model System Design Evaluation Future Work and Conclusion © 2013 Stephanos Matsumoto47

48. Future Work and Conclusion Future Work – Full implementation – Security considerations What if nodes misrepresent their estimates of λ? What if nodes do not respect their TTL? © 2013 Stephanos Matsumoto48

49. Future Work and Conclusion Conclusion – Our consistency metric EAI allows us to explore the tradeoff among various parameters – Out model based on EAI allows us to automate optimization of the TTL to specified inconsistency and bandwidth costs – ECO-DNS is lightweight, backwards-compatible, and flexible to real-time network changes © 2013 Stephanos Matsumoto49

50. Thank you! Questions? smatsumoto@cmu.edu © 2013 Stephanos Matsumoto50