CoDoNs

A High-Performance Alternative for the Domain Name System

Emin Gün SirerVenugopalan Ramasubramanian

Computer Science, Cornell University

introduction

caching is widely-used to improve latency and to decrease overheadpassive caching caches distributed throughout the

network store objects that are encountered

not well-suited for a large-class applications

problems with passive caching

no performance guaranteesheavy-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

domain name system (dns)

part of critical Internet infrastructureresolves 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

dns operationroot

edu milgovcom org

cornell upenn

cs math ece arts

www syslab

•namespace partitioned into hierarchy

•lookup occurs from the top down

•through delegations

•static, manually-crafted, fragile hierarchy

•lookups are expensive

•no bounds!

cnn

ns1.verisign.com

a.root-servers.net

cit.cornell.edu

ns.cs.cornell.edu

dns band-aidsroot

edu milgovcom net

cornell upenn

cs math ece cit

www syslab

•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

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

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

0122

prefix-matching DHTsobject 0121

0121 = hash(“www.cnn.com”)

2012

0021

0112

map all nodes into an identifier space

map all objects into same space based on key

logbN hops several RTTs on the Internet

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

Outline

Problem passive caching DNS: a motivating example DHTs

Beehive approach analytical model distributed implementation evaluation

CoDoNs overview & operation evaluation

Summary

overview of beehive

general replication frameworksuitable 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

key intuition

tunable latency adjust extent of

replication for each object

fundamental space-time tradeoff

2012

0021

0112

0122

analytical model

optimization problemminimize: 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

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

trace Dec UPisa FuNet UCB Quest NLANR

0.83 0.84 0.84 0.83 0.88 0.90

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

optimization problem

minimize (storage/bandwidth)x0 + x1/b + x2/b2 + … + xK-1/bK-1

such that (average lookup time is C hops)K – (x0

1- + x11- + x2

1- + … + xK-11-) C

andx0 x1 x2 … xK-1 1

b: base K: logb(N) xi: fraction of objects replicated at level i

optimal closed-form solution

dj (K’ – C)

1 + d + … + dK’-1

11 - [ ]

x*i =, 0 i K’ – 1

where d = b(1- ) /

, K’ i K

K’ is determined by setting x*K’-1 1 dK’-1 (K’ – C) / (1 + d + … + dK’-1)

1

1

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

latency - overhead trade off

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

beehive replication protocol

0 1 2 *

home node

EL 3

0 1 *0 1 * 0 1 *EB IL 2

0 *0 *0 * 0 * 0 * 0 * 0 * 0 * 0 *

A B C D E F G H I

L 1

object 0121

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)

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

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

0 8 16 24 32 400

0.5

1

1.5

2

2.5

3

time (hours)

late

ncy

(hops)

PastryPC-PastryBeehive

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

evaluation: overhead

0 8 16 24 32 400

0.5

1

1.5

2x 10

6

time (hours)

obje

ct t

ransf

ers

(#

)

PC-PastryBeehive

Object Transfers Storage

average number of replicas per nodePastry 40

PC-Pastry 420

Beehive 380

evaluation: flash crowds

32 40 48 56 64 72 800

0.5

1

1.5

2

2.5

3

Latency

time (hours)

late

ncy

(hops)

Pastry

PC-Pastry

Beehive

evaluation: zipf parameter change

Outline

Problem passive caching DNS: a motivating example DHTs

Beehive approach analytical model distributed implementation evaluation

CoDoNs overview & operation evaluation

Summary

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

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

CoDoNs lookup performance

CoDoNs lookup performance

CoDoNS Legacy DNS

median 6.56 ms 38.8 ms90th percentile 281 ms 337 ms

CoDoNs load balancingCoDoNs automatically balances load

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

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

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

advantages of CoDoNShigh 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

related work - DHTsPrefix-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

related work - DNStraces 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]

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/

evaluation: zipf parameter change

evaluation: instantaneous bandwidth overhead

32 40 48 56 64 72 800

5

10

15

20

Object Transfers per sec

time (hours)

obje

ct t

ransf

ers

per

sec

PC-Pastry

Beehive

typical values of zipf parameter

MIT DNS trace: = 0.91Web traces:

trace Dec UPisa FuNet UCB Quest NLANR

0.83 0.84 0.84 0.83 0.88 0.90

comparative overview of structured DHTs

DHT lookup performance

CAN O(dN1/d)

Chord, Kademlia, Pastry, Tapestry, Viceroy

O(logN)

de Bruijn graphs (Koorde) O(logN/loglogN)

Kelips, Salad, [Gupta, Liskov, Rodriguez]

O(1)

Beehive DNS: Lookup Performance

CoDoNS Legacy DNSmedian 6.56 ms 38.8 ms

90th percentile

281 ms 337 ms