1 / 25

Proactive DNS Caching: Addressing a Performance Bottleneck

Proactive DNS Caching: Addressing a Performance Bottleneck. Edith Cohen AT&T Labs-Research. Haim Kaplan Tel-Aviv University. Talk Overview. Overview and Motivation DNS architecture DNS lookup latency Proactive DNS caching Renewal Policies Simultaneous Validation Conclusion.

mablen
Download Presentation

Proactive DNS Caching: Addressing a Performance Bottleneck

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proactive DNS Caching:Addressing a Performance Bottleneck Edith Cohen AT&T Labs-Research Haim Kaplan Tel-Aviv University SAINT ‘01

  2. Talk Overview • Overview and Motivation • DNS architecture • DNS lookup latency • Proactive DNS caching • Renewal Policies • Simultaneous Validation • Conclusion

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

  4. resolving www.research.att.com ? ? Local Name-Server ? DNS Hierarchy

  5. Resolution may involve multiple remote name-servers DNS Lookup Client root • 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 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) • 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 of DNS Lookups All requests > 60 sec after previous, ATT log

  9. Latency of DNS Lookups AltaVista referrals requests, ATT proxy log

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

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

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

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

  14. Renewal Policies - Issue a renewal query upon expiration. - Policy determines when to renew. - Tradeoff of overhead/reduced-latency. • R-LRUrenew r times past the most-recent cache hit • R-LFUgrant r additional renewals per hit ( TTL interval) • R-FIFOgrant r renewals at entry time to the cache • R-OPToptimal omniscient offline renewal policy

  15. Performance of Renewal Policies ATT proxy log

  16. Performance of Renewal Policies UC (NLANR) log

  17. Renewal Policies: Conclusions • 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

  18. Renewal Policies: Implementation issues • Preferred Implementation: • within the name-server • Overhead control: • pre-expiration renewals (~1 RTT) • off-peak renewals

  19. Challenge: How do we benefit from valid expired addresses while still respecting TTL values. TTL vs. 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 lose valuable and valid information

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

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

  22. Simultaneous Validationsuccess rate

  23. Simultaneous Validation:deployment issues • browser or proxy • 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.

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

  25. Future Work • Large, local, hostname database + SV • Co-operative DNS caching • SV and Renewal at the RR level • Combine SV and Renewal

More Related