1 / 48

CoDoNs A High-Performance Alternative for the Domain Name System

CoDoNs A High-Performance Alternative for the Domain Name System. Emin G ü n Sirer Venugopalan Ramasubramanian. Computer Science, Cornell University. introduction. caching is widely-used to improve latency and to decrease overhead passive caching caches distributed throughout the network

jersey
Download Presentation

CoDoNs A High-Performance Alternative for the Domain Name System

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. CoDoNsA High-Performance Alternative for the Domain Name System Emin Gün Sirer Venugopalan Ramasubramanian Computer Science, Cornell University

  2. introduction • caching is widely-used to improve latency and to decrease overhead • passive caching • caches distributed throughout the network • store objects that are encountered • not well-suited for a large-class applications

  3. problems with passive caching • no performance guarantees • heavy-tail effect • large percentage of queries to unpopular objects • ad-hoc heuristics for cache management • introduces coherency problems • difficult to locate all copies • weak consistency model

  4. domain name system (dns) • part of critical Internet infrastructure • resolves names to addresses • “www.cnn.com”  67.45.223.12 • also resolves other flat queries • hostname to mail server mappings • hostname to owner information • ipaddress to hostname • and others • based on a static hierarchy of servers

  5. a.root-servers.net ns1.verisign.com cit.cornell.edu ns.cs.cornell.edu dns operation root • namespace partitioned into hierarchy • lookup occurs from the top down • through delegations • static, manually-crafted, fragile hierarchy • lookups are expensive • no bounds! com org gov edu mil cornell upenn cnn math cs ece arts www syslab

  6. dns band-aids • replicate nodes at the top of the hierarchy • 13 root servers • 13 com, mil servers • 2 org servers • use passive caching for dns records • at every possible location • associate a TTL with every dns record • no invalidations root com net gov edu mil cornell upenn math cs ece cit www syslab

  7. dns problems • performance bottleneck • cold misses lead to high latencies • vulnerable to DDoS attacks • November 2002 attack on root servers • can target branches of the name tree • high load on nodes close to the root • tree not a scalable data structure • manual maintenance expensive, error prone • DNS hierarchy full of errors • coherency guarantees at odds with performance • low TTL enables dynamic updates reduces performance

  8. a better solution? • distributed hash tables (DHTs) can help • self-organizing • scalable • worst-case performance bounds • but average-case performance for scalable DHTs is too high

  9. 0021 0112 0122 prefix-matching DHTs object 0121 0121 = hash(“www.cnn.com”) • map all nodes into an identifier space • map all objects into same space based on key • logbN hops • several RTTs on the Internet 2012

  10. DHT properties • scalable DHTs not suited for DNS • Morris, Balakrishnan et al. • O(log N) overlay hops is too slow for critical, latency-sensitive applications • need faster lookups • proactive, model-driven caching can help

  11. Outline • Problem • passive caching • DNS: a motivating example • DHTs • Beehive approach • analytical model • distributed implementation • evaluation • CoDoNs • overview & operation • evaluation • Summary

  12. overview of beehive • general replication framework • suitable for structured DHTs • decentralization, self-organization, resilience • properties • high performance: O(1) average lookup time • scalable: minimize number of replicas and reduce storage, bandwidth, and network load • adaptive: promptly respond to changes in popularity – flash crowds

  13. key intuition • tunable latency • adjust extent of replication for each object • fundamental space-time tradeoff 0021 0112 0122 2012

  14. analytical model • optimization problem minimize: total number of replicas, s.t., average lookup performance C • configurable target lookup performance • continuous range, sub one-hop • minimizing number of replicas decreases storage and bandwidth overhead

  15. target domain • zipf-like query distributions • number of queries to rth popular object  1/r • fraction of queries for m most popular objects  (m1- - 1) / (M1- - 1) • commonly encountered in practice • dns, web •  typically between 0.80 and 1.00 • MIT DNS trace = 0.91

  16. level of replication • level of replication • nodes share i prefix-digits with the object • i hop lookup latency • lower level means greater extent of replication • replicated on N/bi nodes

  17. optimization problem minimize (storage/bandwidth) x0 + x1/b + x2/b2 + … + xK-1/bK-1 such that (average lookup time is C hops) K – (x01- + x11- + x21- + … + xK-11-)  C and x0  x1  x2  …  xK-1  1 b: base K: logb(N) xi: fraction of objects replicated at level i

  18. 1 [ ] 1 -  dj (K’ – C) 1 + d + … + dK’-1 optimal closed-form solution , 0  i  K’ – 1 x*i = , K’  i  K 1 where d = b(1- ) / K’ is determined by setting x*K’-1 1  dK’-1 (K’ – C) / (1 + d + … + dK’-1)  1

  19. implications • O(1) average-case lookup performance • C hops for Zipf-like distributions • bounded worst-case • K’ forms upper bound • optimal number of replicas for  1 • no wasted bandwidth, storage or coordination

  20. latency - overhead trade off

  21. beehive: system overview • estimation • popularity of objects, zipf parameter • local measurement, limited aggregation • replication • apply analytical model independently at each node • push new replicas to nodes at most one hop away

  22. L 2 0 1 * B 0 1 * E 0 1 * I 0 * L 1 0 * 0 * 0 * 0 * 0 * 0 * 0 * 0 * A B C D E F G H I beehive replication protocol home node object 0121 L 3 E 0 1 2 *

  23. replication protocol • low-overhead mechanisms • distributed, no consensus • asynchronous • performed in the background • modest state per object • id (128 bits) • home node indicator (1 bit) • version number (64 bits)

  24. mutable objects • leverage the underlying structure of DHT • replication level indicates the locations of all the replicas • proactive propagation to all nodes from the home node • home node sends to one-hop neighbors with i matching prefix-digits • level i nodes send to level i+1 nodes

  25. implementation and evaluation • implemented using Pastry as the underlying DHT • evaluation using a real DNS workload • MIT DNS trace • 1024 nodes, 40960 objects • compared with passive caching on pastry • main properties evaluated • lookup performance • storage and bandwidth overhead • adaptation to changes in query distribution

  26. 3 2.5 2 latency (hops) 1.5 1 0.5 Pastry PC-Pastry Beehive 0 0 8 16 24 32 40 time (hours) evaluation: lookup performance passive caching is not very effective because of heavy tail query distribution and mutable objects. beehive converges to the target of 1 hop

  27. evaluation: overhead Storage Object Transfers 6 x 10 2 PC-Pastry Beehive 1.5 object transfers (#) 1 0.5 0 0 8 16 24 32 40 time (hours)

  28. Latency 3 2.5 2 1.5 latency (hops) 1 Pastry 0.5 PC-Pastry Beehive 0 32 40 48 56 64 72 80 time (hours) evaluation: flash crowds

  29. evaluation: zipf parameter change

  30. Outline • Problem • passive caching • DNS: a motivating example • DHTs • Beehive approach • analytical model • distributed implementation • evaluation • CoDoNs • overview & operation • evaluation • Summary

  31. Cooperative Domain Name System (CoDoNS) • replacement for legacy DNS • peer-to-peer DNS • based on Beehive • incremental deployment path • completely transparent to clients • uses legacy DNS to populate resource records on demand • can operate without legacy DNS • deployed on planet-lab

  32. CoDoNs operation • home node initially populates CoDoNs with binding from legacy DNS • CoDoNs will propagate the optimal number of replicas • Upon DNS record expiration, the home node checks binding for change www.cnn.com

  33. CoDoNs lookup performance

  34. CoDoNs lookup performance

  35. CoDoNs load balancing • CoDoNs automatically balances load

  36. CoDoNs security • not an issue in a single administration domain • e.g. akamai, google, msn, etc. • attacks targeted at the DHT • Castro et al. ’02 work on secure DHTs • attacks targeted at Beehive • outlier elimination • limited impact • attacks targeted at CoDoNs • DNSSEC signatures

  37. dns trickery • server-side computation • akamai and similar companies reroute clients to nearest nodes through dns • dynamically computed records with low ttl • not compatible with caching • CoDoNs supports this hack by not caching entries whose TTL is lower than a threshold • but better to perform server selection on the client side • or not at all… CoDoNs already provides high average case performance and load balancing

  38. CoDoNs implications • name delegations can be purchased and propagated independently of server setup • no static tree • naming hierarchy independent of physical server hierarchy • no manual configuration • misconfiguration and broken delegations unlikely • no ttl • push updates at any time • no verisign

  39. advantages of CoDoNS • high performance • low lookup latency • median latency of 7 ms for codons (planet-lab), 39 ms for legacy DNS • resilience against denial of service attacks • load balancing around hotspots • self configuring around host and network failures • fast, coherent updates • no TTLs, updates can be propagated at any time

  40. related work - DHTs • Prefix-based • Plaxton, Pastry, Chord, Tapestry • O(log N) lookup, O(log N) storage • deBruijn graphs • Koorde, [Wieder & Naor 03] • O(log N/log log N) lookup, O(log N) storage • Butterfly • Viceroy: O(log N) lookup, O(1) storage • Farsite • O(d) lookup, O(dn1/d) storage • Kelips • Kelips: O(1) lookup, O(N) storage • Full knowledge • [Gupta, Liskov, Rodrigues]: O(1) lookup, O(N) storage

  41. related work - DNS • traces and zipf distributions • web caching and zipf-like distributions: evidence and implications • Breslau, Cao, Fan, Phillips, and Shenker [infocom’99] • popularity of gnutella queries and their implications on scalability • Sripanidkulchai [2002] • caching and replication • replication strategies in unstructured p2p networks • Cohen and Shenker [sigcomm’02] • cup: controlled update propagation in p2p networks • Roussopoulos and Baker [usenix’03] • DNS • development of DNS system • Mockapetris [sigcomm’88] • DNS performance and effectiveness of caching • Jung, Sit, Balakrishnan, and Morris [sigmetrics’01] • serving DNS using a peer-to-peer lookup service • Cox, Muthitacharoen, and Morris [iptps’02]

  42. conclusions • model-driven proactive caching • O(1) lookup performance with optimal replica cost • beehive: a general replication framework • structured overlays with uniform fan-out • high performance, resilience, improved availability • well-suited for latency sensitive applications • CoDoNs: a modern replacement for DNS http://www.cs.cornell.edu/people/egs/beehive/

  43. evaluation: zipf parameter change

  44. Object Transfers per sec 20 PC-Pastry Beehive 15 10 object transfers per sec 5 0 32 40 48 56 64 72 80 time (hours) evaluation: instantaneous bandwidth overhead

  45. typical values of zipf parameter • MIT DNS trace:  = 0.91 • Web traces:

  46. comparative overview of structured DHTs

  47. Beehive DNS: Lookup Performance

More Related