Proactive DNS Caching: Addressing a Performance Bottleneck

1
Proactive DNS CachingAddressing a Performance
Bottleneck

• Edith Cohen
• ATT Labs-Research

Haim Kaplan Tel-Aviv University
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
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)
• 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 gt 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
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

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

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
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
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 Validationdeployment 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 lt c TTL
• Simultaneous Validation
• minimal overhead
• more involved implementation
• inter-request-time lt 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