1 / 13

The Design and Implementation of a Next Generation Name Service for the Internet

The Design and Implementation of a Next Generation Name Service for the Internet. V. Ramasubramanian, E. Gun Sirer Cornell Univ. SIGCOMM 2004. Ciprian Tutu – Systems Seminar 8/4/04 Johns Hopkins University. DNS: Current Operation and Issues.

kiril
Download Presentation

The Design and Implementation of a Next Generation Name Service for the Internet

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. The Design and Implementation of a Next Generation Name Service for the Internet V. Ramasubramanian, E. Gun Sirer Cornell Univ. SIGCOMM 2004 Ciprian Tutu – Systems Seminar 8/4/04 Johns Hopkins University

  2. DNS: Current Operation and Issues • High latency in query resolve (low cache hit-rates) • High load on root and TLD servers • Slow update propagation (40% have TTL > 1 day) • Lame delegations • Implementation errors (?)

  3. Current DNS: bottlenecks

  4. CoDoNS Goals • High Performance • Low latency, increased lookup performance • Resilience to Attacks • Decentralization • Dynamic load balancing • Fast Update Propagation • Support secure delegation

  5. Beehive • Prefix-matching DHT • O(logN) lookup • Pastry, Tapestry • Proactive caching • O(1) lookup • C=0.5 hops • xi=fraction of objects replicated at level I • b=DHT base

  6. CoDoNS: Architecture • Decouples namespace management from query resolution • Domain names mapped to 128bit unique identifiers • Direct caching for locality • Home node stores permanent copies of RR’s • No TTL associated with records inside CoDoNS • Supports negative caching (NXDOMAIN)

  7. CoDoNS (cont.) • Supports DNSSEC signatures • Caches certificates • Insert/Update use version number to prevent replay attacks. (!! not Dynamic DNS compliant) • Allows multiple operators to manage the same part of the name hierarchy • If conflicting records, clients “simply” pick records signed by an operator they trust (?!) • CoDoNS uses its own centralized authority to sign resource records fetched from legacy DNS (!!)

  8. CoDoNS Evaluation • MIT trace • 12 hours; 281,943 queries; 47,230 unique domain names • Deployed on 75 PlanetLab nodes Query Resolution Latency

  9. CoDoNS Latency

  10. CoDoNS: Flash-crowd Effect Avg bw: 12.2KB/s/node AvgRecords/node: 4217 (10% of total, 13MB storage)

  11. CoDoNS: Update Propagation • For 1 million node CoDoNS network it would take less than 1 minute to update 99% of replicas

  12. Conclusions • Decouple management from query resolution • Reduce resolver latency • Improve update propagation delay • Reduce load on root servers • Resistent to flash-crowd effect (?) • Attempt to eliminate monopoly in namespace management

  13. Questions/Issues • Compatibility with dynamic DNS • Giving RR signing authority to CoDoNS • Not really great behaviour for flash-crowds • CoDoNS caches any data that is queried (size issues) • Selective caching? • No TTL on CoDoNS nodes -> if home node becomes partitioned, then no expiration. • Further issues related to CoDoNS network partitioning • Is there enough incentive for cooperation?

More Related