Proactive DNS Caching: Addressing a Performance Bottleneck

1
Proactive DNS CachingAddressing 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 DistributionURLs 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 Validationsuccess rate

27
Simultaneous ValidationImplementation 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