Proactive DNS Caching: Addressing a Performance Bottleneck - PowerPoint PPT Presentation

Loading...

PPT – Proactive DNS Caching: Addressing a Performance Bottleneck PowerPoint presentation | free to view - id: 27b3b-NGM3M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Proactive DNS Caching: Addressing a Performance Bottleneck

Description:

DNS lookup (address to name) TCP connection setup. Server processing time / reverse DNS (access control) Transmission time. Request-response RTT ... – PowerPoint PPT presentation

Number of Views:58
Avg rating:3.0/5.0
Slides: 30
Provided by: AT167
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Proactive DNS Caching: Addressing a Performance Bottleneck


1
Proactive DNS Caching Addressing a Performance
Bottleneck
  • Edith Cohen
  • ATT Labs-Research
  • http//www.research.att.com/edith

Haim Kaplan Tel-Aviv University http//www.math.ta
u.ac.il/haimk
2
Talk Overview
  • Overview and Motivation
  • DNS architecture
  • effect of DNS lookup latency
  • Proactive DNS caching
  • Renewal Policies
  • Simultaneous Validation
  • Conclusion

3
Domain Name System
hostname
IP-address
www.research.att.com
135.207.23.30
  • Essential for Internet name-based communication
  • Many-to-many mapping (virtual hosting, mirrors,
    aliases)
  • Distributed database maintained by a hierarchy of
    name-servers

4
DNS Hierarchy
5
DNS Lookup
Client
  • Root DNS server
  • returns NS for att.com
  • dnsprime.att.com
  • returns NS for research.att.com
  • ns0.research.att.com
  • returns IP-address for www.research.att.com

root
dnsprime.att.com
ns0.research.att.com
6
Resolving Hostnames
  • Browser if no answer in browser cache, query is
    sent to the local DNS server.
  • Name-server use own cache. For missing info,
    iteratively query remote name-servers, while
    following referrals/ delegations.

7
DNS Caching Mechanism
  • Data is stored in Resource Records (RR)
    (NS, A, CNAME, SOA)
  • Each record has a TTL value (Time To Live)
  • TTL values are assigned by respective domain
    administrators.
  • Record may be cached and used only for TTL
    duration.

8
Latency Effect of DNS Lookups
All requests gt 60 sec after previous, ATT log
9
Latency Effect of DNS Lookups (2)
AltaVista referrals requests, ATT proxy log
10
Performance effect...
  • NLANR cache service times on AKAMAI servers
    a4,a111.g.akamaitech.net

11
Service Times Distribution URLs served by
a4.g.akamaitech.net
0 to 3 seconds
7351 requests in 6 days, 90lt200ms, 95 lt 500ms
12
Issues with DNS Latency
  • RTTs to (several) remote name servers
  • Not addressed by fatter pipes, faster
    high-capacity content servers.
  • Highly sensitive to packet loss
  • Inconsistent - fraction of lookups suffer
    long/pathological delays
  • As Internet service improves, will increasingly
    become more noticeable.

13
Before DNS DNS
one hosts.txt file centrally maintained ftpd
where needed
Hierarchy of distributed name-servers.
  • no lookup delay (data is available locally)
  • scalability problems
  • growing database size
  • coherence
  • single point of failure/load
  • Scalable robust
  • distributed control
  • distributed presence
  • lookup delays from remote queries

14
Passive DNS caching
Used by BIND name-server software
  • Query remote NS only to answer a current client
    request
  • Cache (use) results till TTL expires

15
Proactive DNS caching
Guidelines
Respect TTL values (be transparent to
client) Minimize overhead to DNS servers
Our Proposals
  • Renewal Policies
    auto-refresh entries just before TTL expires
  • Simultaneous Validation
    Concurrently validate use
    expired address

16
Methodology and Logs
  • Proxy logs
  • Simulate associated DNS cache
  • Separately issued DNS queries to obtain TTL
    values, rate-of-change of IP-address.

17
Performance of Passive caching
18
Renewal Policies
- Issue a renewal query upon expiration. - Policy
determines when to renew. - Tradeoff of
overhead/reduced-latency.
  • R-LRU renew r times passed the most-recent cache
    hit
  • R-LFU grant r additional renewals per hit ( TTL
    interval)
  • R-FIFO grant r renewals at entry time to the
    cache
  • R-OPT optimal omniscient offline renewal policy

19
Performance of Renewal Policies
ATT proxy log
20
Performance of Renewal Policies
UC (NLANR) log
21
Renewal Policies Conclusions from Experiments
  • R-LRU and R-LFU performed equally well across
    logs
  • R-FIFO did not perform as well
  • Reduction in misses corresponds to reduction in
    long DNS query times
  • More effective for more clients

22
Renewal Policies Implementation and Extensions
  • Most natural Implementation is within the
    name-server
  • Overhead control
  • Pre-expiration renewals (usually 1 RTT)
  • off-peak renewals
  • Policies can be adapted to account for varying
    DNS resolution times

23
TTL versus Rate-of-change
  • TTL values are set conservatively Rate-of-change
    of addresses is significantly lower than TTL
    value.
  • So, when expired records are discarded, we
    often loose valuable and valid information

24
Simultaneous Validation
  • Keep expired address records.
  • When a client request arrives, concurrently
  • Initiate a connection to host, using expired
    IP-address, and start fetching content
  • Issue a validating DNS query
  • If validation is successful, serve the content to
    the client

25
SV Latency Gain
Client
DNS
  • DNS lookup
  • session with Web server
  • Establishing TCP connection(s), sending HTTP
    request(s), ...

26
Simultaneous Validation success rate

27
Simultaneous Validation Implementation Choices
  • browser or proxy (with a separate DNS cache)
  • requires maintenance of a separate
    name-to-address cache
  • single-entity implementation
  • name-server (using its internal cache)
  • requires protocol support for 2-phase resolutions
  • requires separate proxy or browser support
  • SV is more effective for a larger user base.

28
Summary
  • DNS lookup delays can be addressed by increasing
    local availability of RRs
  • Renewal Policies
  • incur overhead of additional queries
  • simple limited deployment is effective
  • inter-request-time lt c TTL
  • Simultaneous Validation
  • minimal overhead
  • more involved implementation
  • inter-request-time lt IP-address-lifetime


29
Future Work
  • Single, replicated, hostname database SV
  • Co-operative DNS caching
  • Distributed local name server
  • SV and Renewal at the RR level
  • Collect better data name-server logs combined
    with logged HTTP requests
  • Refreshment policies for Web content

About PowerShow.com