CoDoNS: Fast, Resilient, and Scalable Name Service for the Internet

1
CoDoNS Fast, Resilient, and Scalable Name
Service for the Internet

• Venugopalan Ramasubramanian
• Emin Gün Sirer

Computer Science, Cornell University
2
introduction

• Domain Name System (DNS)
• large scale distributed lookup service
• hierarchical structure
• extensive caching
• Changing Internet Environment
• increasing malicious activity (eg. code red worm)
• dynamic bindings (server selection)
• high bandwidth clients (broadband, dsl)

3
DNS problems

• failure resilience
• vulnerability to DoS attacks
• performance
• high lookup latencies
• consistency
• slow update propagation

4
DNS overview
beehive.cornell.edu
5
delegation bottlenecks (1/2)

• survey 593160 domain names, 164089 nameservers
• 75 of names have a bottleneck of two nameservers

6
delegation bottlenecks (2/2)

• 60 of top-500 web sites have small bottlenecks

7
physical bottlenecks

• majority of names bottlenecked at one network link

8
DoS attacks

• delegation and network bottlenecks make DoS
  attacks feasible
• january 2001 attack on Microsoft nameservers
• DoS attacks high up in the hierarchy can affect
  the whole system
• october 2002 attack on root servers
• roots are already disproportionately loaded
  Brownlee et al. 01a, 01b
• root anycast helps but does not solve the
  fundamental problem

9
performance

• dns lookups affect web latency
• 20-40 of web object retrieval time spent on DNS
• 20-30 of DNS lookups take more than 1s
• Jung et al. 01, Huitema et al. 00, Wills Shang
  00, Bent Voelker 01
• lame delegations
• manual administration leads to inconsistencies
• 15 of domains have lame delegations Pappas et.
  al. 01
• introduces latency up to 30 sec
• server selection
• disables caching with small timeouts (30 sec)
• increases latency up to 2 orders of magnitude
  Shaikh et. al. 01

10
consistency

• DNS caching is timeout-driven
• conflict in choosing timeouts
• fundamental tradeoff between lookup and update
  performance
• large timeouts
• an emergency remapping/redirection cannot be
  performed unless anticipated
• 86 of records have TTLs longer than 0.5 hours
• small timeouts (lt 10 min)
• increased lookup latency Jung et. al. 01, Cohen
  et. al. 01

11
Cooperative Domain Name System

• supplement and/or replacement for legacy DNS
• based on distributed hash tables (DHTs)
• self-organizing
• failure resilient
• scalable
• worst-case performance bounds
• naïve application of DHTs fails to provide
  performance comparable to legacy DNS

12
prefix-matching DHTs
object 0121 hash(beehive.cornell.edu)

• logbN hops
• several RTTs on the Internet
• caching along lookup path is ineffective NSDI
  04
• no performance guarantee
• cache consistency is expensive

2012
13
key intuition

• tunable latency
• adjust extent of replication for each object
• fundamental space-time tradeoff

0021
0112
0122
2012
14
proactive, analysis-driven caching

• optimization problem
• minimize total number of replicas, s.t.,
• average lookup performance ? C
• O(1) lookup latency
• configurable target
• continuous range, better than one-hop
• leverages object popularity to achieve high
  performance
• DNS follows zipf-like popularity distribution
  Jung et. al. 01

15
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
• i object replicated at level i shares i digits
  with its servers
• b base
• K logb(N)
• xi fraction of objects replicated at level i

16
optimal closed-form solution
, 0 ? i ? K 1
xi
, K ? i ? K
1
where b b(1- ?) /?
K is determined by setting xK-1 ? 1 ?
bK-1 (K C) / (1 b bK-1) ? 1
17
latency vs. overhead tradeoff
100 x 106 bindings
x106
18
CoDoNS vision

• a cooperative cache for DNS data
• composed of local resolvers and DNS nameservers
• serves the same namespace as legacy DNS
• supports the same interface as legacy DNS

LegacyDNS
19
CoDoNS operation (1/2)

• home node initially populates CoDoNS with binding
  from legacy DNS
• minimum replication level ensures resilience
  against home-node failure
• proactive caching in the background replicates
  binding based on analytical model
• local measurement and limited aggregation to
  estimate popularity of names and zipf parameter
• discards bindings or pushes bindings to neighbors

20
CoDoNS operation (2/2)

• dynamic adaptation
• continuously monitor popularity of names and
  increase replication to meet unanticipated demand
• handles DoS attacks and flash-crowds
• fast update propagation
• replication level indicates the locations of all
  the replicas
• the home node initiates a multicast using entries
  in DHT routing tables

21
CoDoNS name management

• explicit cache management
• records stored until invalidated by updates
• TTLs used only for clients, not necessary for
  consistency in the ring
• upon TTL expiration, the home node checks binding
  for change
• local names treated specially
• a copy of the record retained at the local
  nameserver in addition to the home node
• queries can be resolved locally without
  introducing load into the ring
• server-side computation supported
• low-TTL records not cached, replaced with
  forwarding pointers
• supports Akamai and other CDN trickery

22
CoDoNS name security

• all records carry cryptographic signatures
• if the nameowner has a DNSSEC nameserver, CoDoNS
  will preserve the original signature
• if not, CoDoNS will sign the DNS record with its
  own master key
• malicious peers cannot introduce fake bindings
• delegations are cryptographic
• names not bound to servers

23
CoDoNS implications

• name delegations can be purchased and propagated
  independently of server setup
• naming hierarchy independent of physical server
  hierarchy
• domains may be served by multiple namespace
  operators
• competitive market for delegation services

24
evaluation

• MIT trace
• 12 hour trace, 4th December 2000
• 281,943 queries
• 47,230 domain names
• Planetlab deployment
• 75 nodes
• Lookup performance
• Adaptation to flash crowds
• Load balance, Update propagation SIGCOMM 04

25
CoDoNS lookup performance (1/2)
26
CoDoNS lookup performance (2/2)
Legacy DNS CoDoNS
median 39 ms 2 ms
mean 382 ms 199 ms
90th 337 ms 213 ms
27
CoDoNS flash crowds
reverse popularity injected
28
advantages of CoDoNS

• resilient
• self configures around host and network failures
• resilient against denial of service attacks
• load balances around hotspots
• high performance
• low lookup latency
• updates can be propagated at any time
• autonomic
• no manual configuration, no lame delegations

29
CoDoNS deployment

• incremental deployment path
• uses legacy DNS to populate resource records on
  demand
• completely transparent to clients
• can operate without legacy DNS
• deployed on planet-lab
• 50 to 100 hundred nodes at any given time
• planned expansion to ISPs (e.g. CNNIC)

30
conclusions

• proactive, model-driven caching enables DHTs to
  support latency-sensitive applications
• CoDoNS can serve as a self-configuring, failure
  and DoS-resilient, automatic system for
  disseminating DNS records
• can act as a safety net for legacy DNS
• prototype deployed on Planetlab
• http//www.cs.cornell.edu/people/egs/beehive/

31
CoDoNS servers
planetlab3.cs.duke.edu 152.3.136.3
planetlab01.ethz.ch 129.132.57.2
planetlab03.ethz.ch 129.132.57.4
planetlab1.netmedia.gist.ac.kr203.237.53.170
planet1.cc.gt.atl.ga.us 199.77.128.193pli2-br-1.h
pl.hp.com 192.170.103.20planet1.ics.forth.gr
139.91.70.61 planet1.cavite.nodes.planet-lab.org2
03.177.76.242
planet1.leixlip.nodes.planet-lab.org
192.198.151.98 planetlab1.postel.org 206.117.37.4
planetlab1.netlab.uky.edu 206.240.24.20
planetlab1.eecs.umich.edu 141.213.4.201
planetlab3.csail.mit.edu 128.31.1.13
planetlab5.csail.mit.edu 128.31.1.15
phys0bha-5a.chem.msu.ru 212.192.241.155soccf-pla
net-001.comp.nus.edu.sg 137.132.80.104
planet1.att.nodes.planet-lab.org 192.20.225.130
planetlab1.ias.csusb.edu 139.182.137.141
planlab1.cs.caltech.edu 131.215.45.71planetlab-1
.cmcl.cs.cmu.edu 128.2.198.188 planetlab-3.cmcl.c
s.cmu.edu 128.2.198.199 planetlab1.cs.cornell.edu
128.84.154.49 planetlab2.cs.cornell.edu
128.84.154.71 planetlab1.ewi.tudelft.nl
130.161.40.153