eco-dns: expected consistency optimization for dns chen stephanos matsumoto adrian perrig © 2013...

© 2013 Stephanos Matsumoto 1

ECO-DNS:Expected Consistency Optimization for DNS

Chen ChenStephanos Matsumoto

Adrian Perrig


128.2.136.200128.2.136.200128.2.136.200128.2.136.200

128.2.136.200128.2.136.200

Motivation

Caching Server

ece

cmu

edu

.

cs

com

Client 1 Client 2

ece.cmu.edu ece.cmu.edu

128.2.129.29

Client 3

Inconsistency


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)


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)


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


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


Outline

• Model– Defining an Inconsistency Metric– Caching server topology– Assumptions– Model and optimization

• System Design• Evaluation• Future Work and Conclusion


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

9

Defining an Inconsistency Metric

• Inconsistency:

• Expected aggregate inconsistency (EAI)

© 2013 Stephanos Matsumoto

# of updates to rbetween t and tq

All queries for r in time interval T


Outline




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



Inconsistency "cascades"


Outline




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


Outline




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:



Inconsistency "cascades"



• Based on the Poisson Process assumption, the EAI over a time interval is



• The TTL minimizing the cost function is:


Outline

• Model• System Design– Parameter Monitoring and Aggregation– Setting the TTL– Prefetching DNS Records

• Evaluation• Future Work and Conclusion


Parameter Monitoring/Aggregation

• What information is necessary to find the optimal TTL?

• Which nodes need to keep track of this information?



Set update frequency μ

Collect λ's from children

Estimate λ from queries



• Estimate λ using a sliding window for queries• Send λ using special DNS message


Outline




Setting the TTL

• Two choices for TTL:– Record-specified TTL (current method)– Locally calculated optimal TTL

• What are the pros and cons of each?


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


Setting the TTL

• Solution: set TTL to be the minimum of the two values

• Record-specified TTL becomes an upper bound


Outline




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


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


Outline

• Model• System Design• Evaluation– Goals and Methodology– Single-Level Caching– Multi-Level Caching– Dynamic Parameter Changes

• Future Work and Conclusion


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?


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


Outline




Single-Level Caching

• Use KDDI traces for query arrival times• Compare normalized reduced cost U for

various c and μ


Single-Level Caching


Outline




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


Multi-Level Caching


Outline




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


Outline

• Model• System Design• Evaluation• Future Work and Conclusion


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?


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


Thank you!

Questions?

[email protected]

eco-dns: expected consistency optimization for dns chen stephanos matsumoto adrian perrig © 2013...

Documents

stephanos matsumoto1128

stephanos matsumoto9

stephanos matsumoto16model

stephanos matsumoto7defining

stephanos matsumoto2128

stephanos matsumoto8defining

server loadhowever

stale records