SAINT ‘01 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

Domain Name System Essential for Internet name-based communication Many-to-many mapping (virtual hosting, mirrors, aliases) Distributed database maintained by a hierarchy of name-servers hostnameIP-address

DNS Hierarchy Local Name-Server resolving

DNS Lookup 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 Resolution may involve multiple remote name-servers

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 Query remote NS only to answer a current client request Cache (use) results till TTL expires Used by BIND name-server software

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

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

Renewal Policies R-LRU renew r times past 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 - Issue a renewal query upon expiration. - Policy determines when to renew. - Tradeoff of overhead/reduced-latency.

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 within the name-server Overhead control: pre-expiration renewals (~1 RTT) pre-expiration renewals (~1 RTT) off-peak renewals off-peak renewals

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

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 Initiate a connection to host, using expired IP-address, and start fetching content Issue a validating DNS query Issue a validating DNS query If validation is successful, serve the content to the client

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

Simultaneous Validation success rate

Simultaneous Validation: deployment issues browser or proxy requires maintenance of a separate name-to- address cache requires maintenance of a separate name-to- address cache single-entity implementation single-entity implementation name-server (using its internal cache) requires protocol support for 2-phase resolutions requires protocol support for 2-phase resolutions requires separate proxy or browser support 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