Enhancing DNS Lookup Performance with Proactive Caching Techniques
This presentation discusses the persistent performance challenges associated with DNS lookups and proposes proactive DNS caching solutions to address latency issues. It covers the architecture of DNS, the concepts of renewal policies for cached entries, and simultaneous validation of expired addresses. The methods aim to reduce latency by increasing the local availability of resource records while minimizing overhead on DNS servers. Implementation challenges and future improvements are also outlined, making the case for a more effective DNS resolution strategy.
Enhancing DNS Lookup Performance with Proactive Caching Techniques
E N D
Presentation Transcript
Proactive DNS Caching:Addressing a Performance Bottleneck Edith Cohen AT&T Labs-Research Haim Kaplan Tel-Aviv University SAINT ‘01
Talk Overview • Overview and Motivation • DNS architecture • DNS lookup latency • Proactive DNS caching • Renewal Policies • Simultaneous Validation • Conclusion
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
resolving www.research.att.com ? ? Local Name-Server ? DNS Hierarchy
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
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.
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.
Latency of DNS Lookups All requests > 60 sec after previous, ATT log
Latency of DNS Lookups AltaVista referrals requests, ATT proxy log
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.
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
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:
Methodology and Logs • Proxy logs • Simulate associated DNS cache • Separately-issued DNS queries obtain: TTL values, rate-of-change of IP-address.
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
Performance of Renewal Policies ATT proxy log
Performance of Renewal Policies UC (NLANR) log
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
Renewal Policies: Implementation issues • Preferred Implementation: • within the name-server • Overhead control: • pre-expiration renewals (~1 RTT) • off-peak renewals
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
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
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), ...
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.
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
Future Work • Large, local, hostname database + SV • Co-operative DNS caching • SV and Renewal at the RR level • Combine SV and Renewal
