The Design and Implementation of a Next GenerationName Service for the Internet

Venugopalan Ramasubramanian Emin Gun Sirer

Dept. of Computer Science, Cornell University,Ithaca, NY 14853

{ramasv,egs}@cs.cornell.edu

ABSTRACTName services are critical for mapping logical resource namesto physical resources in large-scale distributed systems. TheDomain Name System (DNS) used on the Internet, however,is slow, vulnerable to denial of service attacks, and does notsupport fast updates. These problems stem fundamentallyfrom the structure of the legacy DNS.

This paper describes the design and implementation of theCooperative Domain Name System (CoDoNS), a novel nameservice, which provides high lookup performance through pro-active caching, resilience to denial of service attacks throughautomatic load-balancing, and fast propagation of updates.CoDoNS derives its scalability, decentralization, self-organi-zation, and failure resilience from peer-to-peer overlays, whileit achieves high performance using the Beehive replicationframework. Cryptographic delegation, instead of host-basedphysical delegation, limits potential malfeasance by names-pace operators and creates a competitive market for names-pace management. Backwards compatibility with existingprotocols and wire formats enables CoDoNS to serve as abackup for legacy DNS, as well as a complete replacement.Performance measurements from a real-life deployment ofthe system in PlanetLab shows that CoDoNS provides fastlookups, automatically reconfigures around faults without man-ual involvement and thwarts distributed denial of service at-tacks by promptly redistributing load across nodes.

Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Domain Name System

General Terms: Design, Performance, Reliability.

Keywords: DNS, peer to peer, proactive caching.

1. INTRODUCTIONTranslation of names to network addresses is an essen-

tial predecessor to communication in networked systems.The Domain Name System (DNS) performs this transla-tion on the Internet and constitutes a critical component of

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SIGCOMM’04, Aug. 30–Sept. 3, 20034, Portland, Oregon, USA.Copyright 2004 ACM 1-58113-862-8/04/0008 ...$5.00.

the Internet infrastructure. While the DNS has sustainedthe growth of the Internet through static, hierarchical par-titioning of the namespace and wide-spread caching, recentincreases in malicious behavior, explosion in client popu-lation, and the need for fast reconfiguration pose difficultproblems. The existing DNS architecture is fundamentallyunsuitable for addressing these issues.

The foremost problem with DNS is that it is suscepti-ble to denial of service (DoS) attacks. This vulnerabilitystems from limited redundancy in nameservers, which pro-vide name-address mappings and whose overload, failureor compromise can lead to low performance, failed lookupsand misdirected clients. Approximately 80% of the domainnames are served by just two nameservers, and a surprising0.8% by only one. At the network level, all servers for 32%of the domain names are connected to the Internet througha single gateway, and can thus be compromised by a singlefailure. The top levels of the hierarchy are served by a rel-atively small number of servers, which serve as easy targetsfor denial of service attacks [4]. A recent DoS attack [28] onthe DNS crippled nine of the thirteen root servers at thattime, while another recent DoS attack on Microsoft’s DNSservers severely affected the availability of Microsoft’s webservices for several hours [38]. DNS nameservers are easytargets for malicious agents, partly because approximately20% of nameserver implementations contain security flawsthat can be exploited to take over the nameservers.

Second, name-address translation in the DNS incurs longdelays. Recent studies [41, 16, 18] have shown that DNSlookup time contributes more than one second for up to30% of web object retrievals. The explosive growth of thenamespace has decreased the effectiveness of DNS caching.The skewed distribution of names under popular domains,such as .com, has flattened the name hierarchy and increasedload imbalance. The use of short timeouts for popular map-pings, as is commonly employed by content distribution net-works, further reduces DNS cache hit rates. Further, manualconfiguration errors, such as lame delegations [29, 27], canintroduce latent performance problems.

Finally, widespread caching of mappings in the DNS pro-hibits fast propagation of unanticipated changes. Since theDNS does not keep track of the locations of cached map-pings, but relies on timeout-based invalidations of stale co-pies, it cannot guarantee cache coherency. Lack of cachecoherency in the DNS implies that changes may not be visi-ble to clients for long durations, effectively preventing quickservice relocation in response to attacks or emergencies.

Session 9: DNS and Naming

331

Fresh design of the legacy DNS provides an opportunityto address these shortcomings. A replacement for the DNSshould exhibit the following properties.

• High Performance: Decouple the performance ofDNS from the number of nameservers. Achieve lowerlatencies than legacy DNS and improve lookup perfor-mance in the presence of high loads and unexpectedchanges in popularity (“the slashdot effect”).

• Resilience to Attacks: Remove vulnerabilities inthe system and provide resistance against denial ofservice attacks through decentralization and dynamicload balancing. Self-organize automatically in responseto host and network failures.

• Fast Update Propagation: Enable changes in name-address mappings to quickly propagate to clients. Sup-port secure delegation to preserve integrity of DNSrecords, and prohibit rogue nodes from corrupting thesystem.

This paper describes Cooperative Domain Name System(CoDoNS), a backwards-compatible replacement for the le-gacy DNS that achieves these properties. CoDoNS com-bines two recent advances, namely, structured peer-to-peeroverlays and analytically informed proactive caching. Struc-tured peer-to-peer overlays, which create and maintain amesh of cooperating nodes, have been used previously to im-plement wide-area distributed hash tables (DHTs). Whiletheir self-organization, scalability, and failure resilience pro-vide a strong foundation for robust large-scale distributedservices, their high lookup costs render them inadequate fordemanding, latency-sensitive applications such as DNS [18].CoDoNS achieves high lookup performance on a structuredoverlay through an analytically-driven proactive caching layer.This layer, called Beehive [32], automatically replicates theDNS mappings throughout the network to match antici-pated demand and provides a strong performance guaran-tee. Specifically, Beehive achieves a targeted average lookuplatency with a minimum number of replicas. Overall, thecombination of Beehive and structured overlays provides therequisite properties for a large scale name service, suitablefor deployment over the Internet.

Our vision is that globally distributed CoDoNS serversself-organize to form a flat peer-to-peer network, essentiallybehaving like a large, cooperative, shared cache. Clientscontact CoDoNS through a local participant in the CoDoNSnetwork, akin to a legacy DNS resolver. Since a completetakeover from DNS is an unrealistic undertaking, we havedesigned CoDoNS for an incremental deployment path. Atthe wire protocol level, CoDoNS provides full compatibilitywith existing DNS clients. No changes to client-side resolverlibraries, besides changing the identities of the nameserversin the system configuration (e.g. modifying /etc/resolv.confor updating DHCP servers), are required to switch over toCoDoNS. At the back end, CoDoNS transparently builds onthe existing DNS namespace. Domain names can be explic-itly added to CoDoNS and securely managed by their own-ers. For names that have not been explicitly added, CoDoNSuses legacy DNS to acquire the mappings. CoDoNS sub-sequently maintains the consistency of these mappings byproactively checking with legacy DNS for updates. CoDoNScan thus grow as a layer on top of legacy DNS and act as asafety net in case of failures in the legacy DNS.

Measurements from a deployment of the system in PlanetLab [2] using real DNS workloads show that CoDoNS cansubstantially decrease the lookup latency, handle large flash-crowds, and quickly disseminate updates. CoDoNS can bedeployed either as a complete replacement for DNS, whereeach node operates in a separate administrative and trustdomain, or as an infrastructure service within an ISP, whereall nodes are in the same administrative and trust domain.

The peer-to-peer architecture of CoDoNS securely decou-ples namespace management from a server’s location in thenetwork and enables a qualitatively different kind of nameservice. Legacy DNS relies fundamentally on physical dele-gations, that is, query handoffs from host to host until thequery reaches a set of designated servers considered author-itative for a certain portion of the namespace owned by anamespace operator. Since all queries that involve that por-tion of the namespace are routed to these designated servers,the namespace operator is in a unique position of power. Anunscrupulous namespace operator may abuse this monopolyby modifying records on the fly, providing differentiatedservices, or even creating synthetic responses that redirectclients to their own servers. Nameowners that are bound tothat namespace have no other recourse. In contrast, namerecords in CoDoNS are tamper-proof and self-validating,and delegations are cryptographic. Any peer with a validresponse can authoritatively answer any matching query.This decoupling of namespace management from the physi-cal location and ownership of nameservers enables CoDoNSto delegate the same portion of the namespace, say .com,to multiple competing namespace operators. These opera-tors, which are each provided with signing authority overthe same space, assign names from a shared, coordinatedpool, and issue self-validating name bindings into the sys-tem. Since CoDoNS eliminates physical delegations and des-ignated nameservers, it breaks the monopoly of namespaceoperators and creates an even playing field where namespaceoperators need to compete with each other on service.

The rest of this paper is organized as follows. In the nextsection, we describe the basic operation of the legacy DNSand highlight its drawbacks. Section 3 describes the designand implementation of CoDoNS in detail. In Section 4, wepresent performance results from the PlanetLab deploymentof CoDoNS. We summarize related work in Section 5, andconclude in Section 6.

2. DNS: OPERATION AND PROBLEMSThe Domain Name System (DNS) is a general-purpose

database for managing host information on the Internet. Itsupports any kind of data, including network address, own-ership, and service configuration, to be associated with hier-archically structured names. It is primarily used to translatehuman-readable names of Internet resources to their corre-sponding IP addresses. In this section, we provide a briefoverview of the structure and operation of the legacy DNS,identify its major drawbacks, and motivate a new design.

2.1 Overview of Legacy DNSThe legacy DNS [25, 26] is organized as a static, dis-

tributed tree. The namespace is hierarchically partitionedinto non-overlapping regions called domains. For example,cs.cornell.edu is a sub-domain of the domain cornell.edu,which in turn is a sub-domain of the top-level domain edu.Top-level domains are sub-domains of a global root domain.

332

Server

Server

Server

Server

Resolver

root name server

name serverauthoritative

client

local intermediatename server

1

23 4

56

78

9

10

name server

resolver

query: www.cs.cornell.edu

.edu gTLD

ns.cornell.edu

ns.cs.cornell.edu

Figure 1: Name Resolution in Legacy DNS: Resolvers

translate names to addresses by following a chain of del-

egations iteratively (2-5) or recursively (6-9).

Domain names, such as www.cs.cornell.edu, belong to name-owners.

Extensible data structures, called resource records, areused to associate values of different types with domain names.These values may include the corresponding IP address, mailhost, owner name and the like. The DNS query interface al-lows these records to be retrieved by a query containing adomain name and a type.

The legacy DNS delegates the responsibility for each do-main to a set of replicated nameservers called authoritativenameservers. The authoritative nameservers of a domainmanage all information for names in that domain, keep trackof authoritative nameservers of the sub-domains rooted attheir domain, and are administered by namespace operators.At the top of the legacy DNS hierarchy are root nameservers,which keep track of the authoritative nameservers for thetop-level domains (TLDs). The top-level domain namespaceconsists of generic TLDs (gTLD), such as .com, .edu, and.net, and country-code TLDs (ccTLD), such as .uk, .tr, and.in. Nameservers are statically configured with thirteen IPaddresses for the root servers. BGP-level anycast is used inparts of the Internet to reroute queries destined for thesethirteen IP addresses to a local root server.

Resolvers in the legacy DNS operate on behalf of clientsto map queries to matching resource records. Clients typi-cally issue DNS queries to local resolvers within their ownadministrative domain. Resolvers follow a chain of author-itative nameservers in order to resolve the query. The lo-cal resolver contacts a root nameserver to find the top-leveldomain nameserver. It then issues the query to the TLDnameserver and obtains the authoritative nameserver of thenext sub-domain. The authoritative nameserver of the sub-domain replies with the response for the query. This processcontinues recursively or iteratively until the authoritativenameserver of the queried domain is reached. Figure 1 il-lustrates the different stages in the resolution of an exampledomain name www.cs.cornell.edu. While this figure providesa simple overview of the communication involved in nameresolution, in practice, each query may trigger additionallookups to resolve intermediate nameservers [25, 26].

Bottlenecks All Domains Top 500

1 0.82 % 0.80 %2 78.44 % 62.80 %3 9.96 % 13.20 %4 4.64 % 13.00 %5 1.43 % 6.40 %13 4.12 % 0 %

Table 1: Delegation Bottlenecks in Name Resolution: A

significant number of names are served by two or fewer

nameservers, even for the most popular 500 sites.

Pursuing a chain of delegations to resolve a query natu-rally incurs significant delay. The legacy DNS incorporatesaggressive caching in order to reduce the latency of queryresolution. The resolvers cache responses to queries they is-sue, and use the cached responses to answer future queries.Since records may change dynamically, legacy DNS providesa weak form of cache coherency through a time-to-live (TTL)field. Each record carries a TTL assigned by the authorita-tive nameserver, and may be cached until TTL expires.

2.2 Problems with Legacy DNSThe current use and scale of the Internet has exposed sev-

eral shortcomings in the functioning of the legacy DNS. Weperformed a large scale survey to analyze and quantify itsvulnerabilities. Our survey explored the delegation chains of593160 unique domain names collected by crawling the Ya-hoo! and the DMOZ.ORG web directories. These domainnames belong to 535088 unique domains and are served by164089 different nameservers. We also separately examinedthe 500 most popular domains as determined by the Alexaranking service. In this section, we describe the findings ofour survey, which highlight the problems in failure resilience,performance, and update propagation in the legacy DNS.

Failure Resilience - Bottlenecks

The legacy DNS is highly vulnerable to network failures,compromise by malicious agents, and denial of service at-tacks, because domains are typically served by a very smallnumber of nameservers. We first examine the delegationbottlenecks in DNS; a delegation bottleneck is the minimumnumber of nameservers in the delegation chain of each do-main that need to be compromised in order to control thatdomain. Table 1 shows the percentage of domains that arebottlenecked on different numbers of nameservers. 78.63%of domains are restricted by two nameservers, the minimumrecommended by the standard [25]. Surprisingly, 0.82% ofdomains are served by only one nameserver. Even the highlypopular domains are not exempt from severe bottlenecks intheir delegation chains. Some domains (0.43%) spoof theminimum requirement by having two nameservers map tothe same IP address. Overall, over 90% of domain namesare served by three or fewer nameservers and can be disabledby relatively small-scale DoS attacks.

Failure and attack resilience of the legacy DNS is evenmore limited at the network level. We examined physicalbottlenecks, that is, the minimum number of network gate-ways or routers between clients and nameservers that needto be compromised in order to control that domain. We mea-sured the physical bottlenecks by performing traceroutes to10,000 different nameservers, which serve about 5,000 ran-

333

0%

10%

20%

30%

40%

1 2 3 4 5 6 7 8 9 10bottleneck gateways (#)

do

mai

ns

(%)

all domainstop 500ccTLDs

Figure 2: Physical Bottlenecks in Name Resolution: A

significant number of domains, including top-level do-

mains, depend on a small number of gateways for their

resolution.

domly chosen domain names, from fifty globally distributedsites on PlanetLab [2]. Figure 2 plots the percentage ofdomains that have different numbers of bottlenecks at thenetwork level, and shows that about 33% of domains are bot-tlenecked at a single gateway or router. While this number isnot surprising - domains are typically served by a few name-servers, all located in the same sub-network - it highlightsthat a large number of domains are vulnerable to networkoutages. These problems are significant and affect many toplevel domains and popular web sites. Recently, Microsoftsuffered a DoS attack on its nameservers that rendered itsservices unavailable. The primary reason for the success ofthis attack was that all of Microsoft’s DNS servers were inthe same part of the network [38]. Overall, a large portionof the namespace can be compromised by infiltrating a smallnumber of gateways or routers.

Failure Resilience - Implementation Errors

The previous section showed that legacy DNS suffers fromlimited redundancy and various bottlenecks. In this section,we examine the feasibility of attacks that target these bottle-necks through known vulnerabilities in commonly deployednameservers. Early studies [10, 22, 27] identified several im-plementation errors in legacy DNS servers that can lead tocompromise. While many of these have been fixed, a sig-nificant percentage of nameservers continue to use buggyimplementations. We surveyed 150,000 nameservers to de-termine if they contain any known vulnerabilities, based onthe Berkeley Internet Name Daemon (BIND) exploit listmaintained by the Internet Systems Consortium (ISC) [17].Table 2 summarizes the results of this survey. Approxi-mately 18% of servers do not respond to version queries,and about 14% do not report valid BIND versions. About2% of nameserves have the tsig bug, which permits a bufferoverflow that can enable malicious agents to gain access tothe system. 19% of nameserves have the negcache problemthat can be exploited to launch a DoS attack by providingnegative responses with large TTL value from a maliciousnameserver. Overall, exploiting the bottlenecks identified inthe previous section is practical.

problem severity affected nameserversall domains top 500

tsig critical 2.08 % 0.59 %nxt critical 0.09 % 0.15 %

negcache serious 19.03 % 2.57 %sigrec serious 13.56 % 1.32 %

DoS multi serious 11.11 % 1.32 %DoS findtype serious 2.58 % 0.59 %

srv serious 1.89 % 0.59 %zxfr serious 1.81 % 0.44 %

libresolv serious 1.48 % 0 %complain serious 1.33 % 0 %so-linger serious 1.15 % 0.15 %fdmax serious 1.15 % 0.15 %

sig serious 0.70 % 0.15 %infoleak moderate 4.58 % 0.59 %sigdiv0 moderate 1.86 % 0.59 %openssl medium 1.71 % 0.37 %naptr minor 2.58 % 0.15 %

maxdname minor 2.58 % 0.15 %

Table 2: Vulnerabilities in BIND: A significant percent-

age of nameservers use BIND versions with known secu-

rity problems [17].

Performance - Latency

Name resolution latency is a significant component of thetime required to access web services. Wills and Shang [41]have found, based on NLANR proxy logs, that DNS lookuptime contributes more than one second to 20% of web objectretrievals, Huitema et al. [16] report that 29% of queries takelonger than two seconds, and Jung et al. [18] show that morethan 10% of queries take longer than two seconds. The lowperformance is due mainly to low cache hit rates, stemmingfrom the heavy-tailed, Zipf-like query distribution in DNS.It is well known from studies on Web caching [6] that heavy-tailed query distributions severely limit cache hit rates.

Wide-spread deployment of content distribution networks,which perform dynamic server selection, have further strainedthe performance of the legacy DNS. These services, such asAkamai and Digital Island, use the DNS in order to directclients to closer servers of Web content. They typically usevery short TTLs (on the order of 30 seconds) in order toperform fine grain load balancing and respond rapidly tochanges in server or network load. But, this mechanism vir-tually eliminates the effectiveness of caching and imposesenormous overhead on DNS. A study on impact of shortTTLs on caching [19] shows that cache hit rates decreasesignificantly for TTLs lower than fifteen minutes. Anotherstudy on the adverse effect of server selection [35] reportsthat name resolution latency can increase by two orders ofmagnitude.

Performance - Misconfigurations

DNS performance is further affected by the presence of alarge number of broken (lame) or inconsistent delegations.In our survey, address resolution failed for about 1.1% ofnameservers due to timeouts or non-existent records, mostlystemming from spelling errors. For 14% of domains, author-itative nameservers returned inconsistent responses; a fewauthoritative nameservers reported that the domain does

334

not exist, while others provided valid records. Failures stem-ming from lame delegations and timeouts can translate intosignificant delays for the end-user. Since these failures andinconsistencies largely stem from human errors [27], it isclear that manual configuration and administration of sucha large scale system is expensive and leads to a fragile struc-ture.

Performance - Load Imbalance

DNS measurements at root and TLD nameservers show thatthey handle a large load and are frequently subjected to de-nial of service attacks [4, 5]. A massive distributed DoSattack [28] in November 2002 rendered nine of the thirteenroot servers unresponsive. Partly as a result of this attack,the root is now served by more than sixty nameservers andis served through special-case support for BGP-level any-cast. While this approach fixes the superficial problem atthe topmost level, the static DNS hierarchy fundamentallyimplies greater load at the higher levels than the leaves.The special-case handling does not provide automatic repli-cation of the hot spots, and sustained growth in client popu-lation will require continued future expansions. In additionto creating exploitable vulnerabilities, load imbalance posesperformance problems, especially for lookups higher in thename hierarchy.

Update Propagation

Large-scale caching in DNS poses problems for maintain-ing the consistency of cached records in the presence of dy-namic changes. Selection of a suitable value for the TTL isan administrative dilemma; short TTLs adversely affect thelookup performance and increase network load [18, 19], whilelong TTLs interfere with service relocation. For instance, apopular on line brokerage firm uses a TTL of thirty min-utes. Its users do not incur DNS latencies when accessingthe brokerage for thirty minutes at a time, but they may ex-perience outages of up to half an hour if the brokerage firmneeds to relocate its services in response to an emergency.Nearly 40% of domain names use TTLs of one day or higher,which prohibits fast dissemination of unanticipated changesto records.

3. COOPERATIVE DOMAIN NAMESYSTEM

The use and scale of today’s Internet is drastically dif-ferent from the time of the design of the legacy DNS. Eventhough the legacy DNS anticipated the explosive growth andhandled it by partitioning the namespace, delegating thequeries, and widely caching the responses, this architecturecontains inherent limitations. In this section, we presentan overview of CoDoNS, describe its implementation, andhighlight how it addresses the problems of the legacy DNS.

3.1 Overview of BeehiveCoDoNS derives its performance characteristics from a

proactive caching layer called Beehive [32]. Beehive is a pro-active replication framework that enables prefix-matchingDHTs to achieve O(1) lookup performance. Pastry [34],and Tapestry [42] are examples of structured DHTs that useprefix-matching [31, 20] to lookup objects. In these DHTs,both objects and nodes have randomly assigned identifiersfrom the same circular space, and each object is stored at

Q

B

0210

D

E

lookup (2101)L1

2201

2100

2110L2

L1

Figure 3: Proactive Caching in Beehive: Caching an

object at all nodes with i matching prefix-digits ensures

that it can be located in i hops. Beehive achieves O(1)

average lookup time with minimal replication of objects.

the nearest node in the identifier space, called the homenode. Each node routes a request for an object, say 2101,by successively matching prefixes; that is, by routing the re-quest to a node that matches one more digit with the objectuntil the home node, say 2100, is reached. Overlay routingby matching prefixes in this manner incurs O(log N) hopsin the worst case to reach the home node. Figure 3 illus-trates the prefix matching routing algorithm in Pastry. Arouting table of O(log N) size provides the overlay node withpointers to nodes with matching prefixes. In a large system,log N translates to several hops across the Internet and isnot sufficient to meet the performance requirements of la-tency critical applications such as DNS.

Beehive proposes a novel technique based on controlledproactive caching to reduce the average lookup latency ofstructured DHTs. Figure 3 illustrates how Beehive appliesproactive caching to decrease lookup latency in Pastry. Inthe example mentioned above, where a query is issued forthe object 2101, Pastry incurs three hops to find a copy ofthe object. By placing copies of the object at all nodes onehop prior to the home node in the request path, the lookuplatency can be reduced by one hop. In this example, thelookup latency can be reduced from three hops to two hopsby replicating the object at all nodes that start with 21.Similarly, the lookup latency can be reduced to one hop byreplicating the object at all nodes that start with 2. Thus,we can vary the lookup latency of the object between 0 andlog N hops by systematically replicating the object moreextensively. In Beehive, an object replicated at all nodeswith i matching prefixes incurs i hops for a lookup, and issaid to be replicated at level i.

The central insight behind Beehive is that by judiciouslychoosing different levels of replication for different objects,the average lookup performance of the system can be tunedto any desired constant. Naturally, replicating every ob-ject at every node would achieve O(1) lookups, but wouldincur excessive space overhead, consume significant band-width and lead to large update latencies. Beehive minimizesbandwidth and space consumption by posing the followingoptimization problem: minimize the total number of replicassubject to the constraint that the aggregate lookup latency isless than a desired constant C. For power-law (or Zipf-like)query distributions, Beehive analytically derives the optimal

335

closed-form solution to this problem. The derivation of theanalytical solution is provided in [32]; the final expressionfor the closed-form solution that minimizes the total numberof replicas for Zipf-like query distributions with parameterα < 1 is the following:

xi = [di(logN − C)

1 + d + · · · + dlogN−1]

1

1−α , where d = b1−α

α

In this expression, b is the base of the underlying DHT andxi is the fraction of most popular objects that get replicatedat level i. This solution is immediately applicable to DNS,since DNS queries follow a Zipf-like distribution [18].

The analytical result provides several properties suitedfor latency-sensitive applications such as DNS. First, it suc-cinctly captures the space-time tradeoff and enables appli-cations to achieve any targeted average lookup latency byselecting an appropriate C. In CoDoNS, we set Beehive’starget as C = 0.5 hops, which means that a large percentageof requests are answered immediately without having to takeany extra network hops. Second, it incurs minimal band-width and storage overhead by picking the optimal num-ber of replicas required to achieve the target lookup perfor-mance. Further, replicating objects across several nodes bal-ances the load on individual Beehive nodes, reduces hotspotsand improves resilience against DoS attacks. Finally, thelevel of replication for each object can be used to quicklydetermine the location of all object replicas, and to updatethem when necessary.

Beehive nodes need to know only the Zipf parameter andthe relative popularity rank of objects to apply the closed-form solution and determine the extent of replication foreach object. Beehive employs a combination of local mea-surement and limited aggregation to estimate the Zipf pa-rameter and the popularity ranks of objects. Beehive nodeslocally measure the access frequency of each object, and pe-riodically aggregate them with other nodes every aggrega-tion interval. Each node aggregates values gathered fromnodes one level higher in the routing table. Eventually,the aggregates trickle down through different levels of therouting table and reach the home node. The home nodecomputes a final aggregate and propagates it to all replicasin the system. The Zipf parameter is locally derived fromthe aggregate access frequencies of the object and fed tothe analytical model. Using these estimates, each Beehivenode invokes the analytical model once every analysis inter-val and obtains the appropriate replication levels for objectsit stores. The replication of these objects to the specifiedlevels is then performed by the replication protocol. Repli-cation in Beehive is controlled locally; that is, each node isresponsible for replicating an object on nodes at most onehop away from itself. For example, the home node of a pop-ular object replicates it at nodes that share one prefix less.Those nodes then independently decide to replicate that ob-ject further to one more level. In the replication phase, eachnode exchanges messages with nodes in its routing table,which are one hop away from them, to push, delete, or up-date replicas for which they are responsible.

The aggregation and replication protocols enable Beehiveto quickly detect changes in the demand for objects. Largechanges in the popularity of domain names occur duringdenial of service attacks and flash crowds. Beehive nodesconstantly monitor the access frequency of objects and ad-just the extent of replication. In response to DoS attacks,

they promptly increase the number of replicas and spreadthe load among several nodes, curbing the attack.

Proactive replication also enables Beehive to rapidly pushupdates to all the replicas in the system. In general, pro-active propagation of updates demands expensive mecha-nisms to keep track of all the nodes where the object iscached. Beehive requires just a small integer, the replica-tion level of an object, to determine the range of nodes withreplicas of the object. An object at level i is replicated at allnodes with i matching prefix digits. For a level i object, thehome node propagates updates to all the nodes at level i inthe routing table. Those nodes in turn propagate updatesto nodes at level i + 1. This recursive process disseminatesthe updates to nodes with i matching prefix digits. Nodesin the process of joining the DHT may miss the initial up-date propagation. Such nodes will receive the latest copyof the object in the next replication phase; they may in-cur a slight performance penalty, but will not serve staledata. Proactive update propagation obviates the need fortimeout-based caching.

3.2 CoDoNS: ArchitectureCoDoNS consists of globally distributed nodes that self

organize to form a peer-to-peer network. We envisage thateach institution would contribute one or more servers toCoDoNS, forming a large-scale, cooperative, globally sharedDNS cache. CoDoNS provides query resolution services toclients using the same wire format and protocol as legacyDNS, and thus requires no changes to client resolvers.

CoDoNS decouples namespace management from queryresolution of the legacy DNS. Nameowners need only to pur-chase certificates for names from namespace operators andintroduce them into CoDoNS; they do not need to providededicated hosts for serving those names. CoDoNS placesno restrictions on the hierarchical structure of the names-pace and is agnostic about the administrative policies of thenameowners. To the nameowners, CoDoNS provides an in-terface consisting of insert, delete and update.

CoDoNS associates the node whose identifier is closest tothe consistent hash [20] of the domain name as the homenode for that domain name. The home node stores a per-manent copy of the resource records owned by that domainname and manages their replication. If the home node fails,the next closest node in the identifier space automaticallybecomes the new home node. CoDoNS replicates all recordson several nodes adjacent to the home node in the identifierspace in order to avoid data loss due to node failures.

Replacing the DNS entirely with CoDoNS is an ambitiousplan, and we do not expect nameowners to immediately useCoDoNS for propagating their information. In order to al-low CoDoNS to gradually grow into a globally recognizedsystem, we have incorporated compatibility to the legacyDNS. CoDoNS uses the legacy DNS to resolve queries forrecords not explicity inserted by nameowners. The homenode retrieves resource records from the legacy DNS uponthe first query for those records. The additional redirectionlatency only affects the first query issued in the entire sys-tem for a domain name. CoDoNS decreases the impact ofquery redirection on lookup performance, by bootstrappingthe system with records obtained from legacy DNS name-servers through zone transfers or file transfers.

Overall, query resolution in CoDoNS takes place as fol-lows. Client sends a query in the wire format of the legacy

336

homenode

servercodons

cachedreply

reply fromhome node

client

query

reply

legacyDNS

Figure 4: CoDoNS Deployment: CoDoNS servers self-

organize to form a peer-to-peer network. Clients send

DNS requests to a local CoDoNS server, which obtains

the records from the home node or an intermediate node,

and responds to the client. In the background, the home

nodes interact with the legacy DNS to keep records fresh

and propagate updates to cached copies.

DNS to the local CoDoNS server in the same administrativedomain. The local CoDoNS server replies immediately if ithas a cached copy of the requested records. Otherwise, itroutes the query internally in the CoDoNS network usingthe under-lying DHT. The routing terminates either at anintermediate CoDoNS node that has a cached copy of therecords or at the home node of the domain name. The homenode retrieves the records from the legacy DNS, if it does notalready have it, and sends a response to the first contactedCoDoNS server, which replies to the client. In the back-ground, CoDoNS nodes proactively replicate the records inbased on the measured popularity. Figure 4 shows a typicaldeployment of CoDoNS and illustrates the process of queryresolution.

Clients generate a large number of queries for names intheir local administrative domain. Since the home node of aname may be located in a different domain, local queries canincur extra latency and impose load on wide-area networklinks. CoDoNS supports efficient resolution of local namesthrough direct caching. Nameowners can directly insert, up-date, and delete their records at CoDoNS servers in their ad-ministrative domain, and configure the local CoDoNS serversto use the direct cache for replying to local queries.

3.3 CoDoNS: ImplementationCoDoNS servers are layered on top of Pastry and Bee-

hive. Each CoDoNS server implements a complete, recur-sive, caching DNS resolver and supports all requirements de-scribed in the specification [25, 26]. CoDoNS also supportsinverse queries that map IP addresses to a domain name byinserting reverse address-name records into the DHT whenname-address records are introduced.

Domain names in CoDoNS have unique 128 bit identifiersobtained through the SHA-1 hashing algorithm. The homenode, the closest node in the identifier space, stores perma-nent copies of the resource records of the domain name andmaintains their consistency in the system. Since CoDoNSdoes not associate TTLs with the records, the home nodespush the updates to all replicas in the system, which retain

them until the replication level of the record is downgraded,or until an update is received. Nameowners insert updatedresource records into CoDoNS, and the home nodes proac-tively propagate the updates.

CoDoNS ensure the consistency of records obtained fromthe legacy DNS, CoDoNS by proactively refetching them.The home node uses the TTL specified by the legacy DNSas the duration to store the records. It refetches the recordsfrom legacy DNS after TTL duration, and propagates theupdated records to all the replicas if the records change.Since CoDoNS performs the refetches in the background, itslookup performance is not affected. The TTL values arerounded up to a minimum of thirty seconds; records withlower TTL values are not placed into the system. Low TTLvalues typically indicate dynamic server-selection in legacyDNS. The home node prompts the server that injected thequery to consult the legacy DNS server by issuing a spe-cial error-response. This redirection of queries for low-TTLrecords ensures that services that rely on dynamic server se-lection will continue to work, and reduces overhead on theCoDoNS home nodes.

The legacy DNS relies on error responses, called NXDO-MAIN responses, to detect names that do not exist. Sinceclients reissue a request several times when they do notreceive prompt replies, the DNS specification recommendsthat resolvers cache NXDOMAIN responses. CoDoNS pro-vides complete support for negative caching as describedin [1]. However, permanently storing NXDOMAIN responsescould exhaust the capacity of the system, since an unlim-ited number of queries can be generated for non-existent do-mains. Hence, CoDoNS nodes cache NXDOMAIN responsestemporarily and do not refresh them upon expiry.

3.4 Issues and ImplicationsCoDoNS decouples namespace management from the phys-

ical location of nameservers in the network. Instead of re-lying on physical delegations to trusted hosts and assum-ing that Internet routing is secure, CoDoNS uses crypto-graphic delegations and self-verifying records based on theDNSSEC [12] standard.

DNSSEC uses public key cryptography to enable authen-tication of resource records. Every namespace operator hasa public-private key pair; the private key is used to digitallysign DNS records managed by that operator, and the corre-sponding public key is in turn certified by a signature froma domain higher up in the hierarchy. This process creates achain of certificates, terminating at a small number of well-known public keys for globally trusted authorities. Sincerecords are signed at the time of issue, the private keys neednot be kept online. The signature and the public key arestored in DNS as resource records of type sig and key re-spectively. Clients can verify the authenticity of a resourcerecord by fetching the sig record and the key record fromthe DNS.

The use of cryptographic certificates enables any client tocheck the verity of a record independently, and keeps peersin the network from forging certificates. To speed up cer-tificate verification, CoDoNS servers cache the certificatesalong with the resource records and provide them to theclients. Existing clients that are not DNSSEC compliantneed to trust only the local CoDoNS servers within their ad-ministrative domain, since CoDoNS servers internally verifydata fetched from other nodes.

337

CoDoNS authenticates nameowners directly through cer-tificates provided for every insertion, delete, and update.Insertions simply require a signed resource record with acorresponding well-formed certificate. A version number as-sociated with each record, signed by the owner and checkedby every server, ensures that old records cannot be reintro-duced into the system. Deletions require a signed requestthat identifies the record to be expunged, while updates in-troduce a new signed, self-verifying record that replaces thenow-stale version.

Since CoDoNS removes authority from the identity andlocation of the server providing resource records and vests itwith cryptographic keys, it provides a greater degree of free-dom over namespace management. CoDoNS enables multi-ple namespace operators to manage the same part of thename hierarchy. A domain owner can delegate managementof the same sub-domain to multiple operators by endors-ing their keys as being authoritative for that sub-domain.Ideally, competing operators would preserve a single consis-tent namespace by issuing names out of a common, sharedpool. In the presence of conflicting or inconsistent records,clients simply pick the records signed by an operator theytrust, similar to the way they pick between separate sets ofroot servers today. Essentially, nameowners have the abil-ity to choose the namespace operator that will endorse theirrecords based on price, service and functionality.

Since DNSSEC has not yet been widely deployed in theInternet, CoDoNS cannot rely on the legacy DNS to providecertificates for resource records. Consequently, CoDoNSuses its own centralized authority to sign resource recordsfetched from the legacy DNS. Queries to the legacy DNSare directed to a small pool of certifying resolvers, whichfetch authoritative resource records from the legacy DNS,sign them, and append the sig records to the legacy DNSresponse. This approach requires trust to be placed in thecertifying resolvers. Threshold cryptography [43] can beused to limit the impact of adversaries on these resolversuntil CoDoNS takes over completely. The certifying nameresolvers ensure that CoDoNS participants cannot inject cor-rupted records into the system.

Malicious participants may also disrupt the system by cor-rupting the routing tables of peers and misrouting or drop-ping queries. Castro et al. [7] propose a method to handlerouting table corruptions in DHTs. This scheme augmentsthe regular routing table with a secure routing table wherethe entries need to satisfy strict constraints on node iden-tifiers that limit the impact of corrupt nodes. Since nodesin the secure routing table are not picked based on shortnetwork latencies, this scheme may increase the lookup de-lay. Setting a lower target latency at the Beehive layer cancompensate for the increase in lookup latency at the cost ofbandwidth and storage.

CoDoNS acts as a large cache for stored, self-verifyingrecords. This design, which separates namespace manage-ment from the physical servers, prohibits dynamic name res-olution techniques where the mapping is determined as aresult of a complex function, evaluated at run time. In thegeneral case, such functions take arbitrary inputs and haveconfidentiality requirements that may prohibit them frombeing shipped into the system. For instance, content distri-bution networks, such as Akamai, use proprietary techniquesto direct clients to servers [3, 35]. To nevertheless supportsuch dynamic mapping techniques, CoDoNS enables name-

Parameter Value

Pastry base 16leaf-set size 24

Beehive target C 0.5 hopsaggregation interval 6 min

analysis interval 60 min

Table 3: Parameters for Pastry and Beehive

owners to stipulate redirections of queries for certain namesusing a special redirection record. High lookup performanceduring redirections is ensured through proactive replicationand update of the redirection record in the same manner asregular resource records.

As with any peer-to-peer system, CoDoNS relies on itsparticipants to contribute resources on behalf of others. Whileit may seem, at first, that rational actors might be averseto participating in the system for fear of having to serve ashome nodes for highly popular records, proactive replicationensures that the load perceived by all nodes is comparable.A highly popular record will be replicated until the load itprojects on its home node is comparable to the query loadfor other records.

4. EVALUATIONWe have deployed CoDoNS on PlanetLab [2], an open

platform for developing, deploying, and accessing planetary-scale services. PlanetLab enables us to deploy CoDoNS onservers around the world and evaluate it against the back-ground of real Internet with congestion, losses, and unpre-dictable failures. In this section, we present performancemeasurements from the PlanetLab deployment for a realDNS workload. Our experiments highlight three impor-tant properties of CoDoNS. First, they show that CoDoNSprovides a low latency name resolution service. Second,they demonstrate CoDoNS’ ability to resist flash-crowds byquickly spreading the load across multiple servers. Finally,they evaluate CoDoNS’ support for fast update propagation.

4.1 SetupWe setup a peer-to-peer network of CoDoNS servers on

globally distributed PlanetLab nodes. The values used fordifferent parameters of Pastry and Beehive are listed in Ta-ble 3. We started the CoDoNS servers with no initial DNSrecords. After an initial quiescent period to stabilize Pastry,we issue DNS requests from a real workload to the CoDoNSserver at each node. During the experiment, we measurethe lookup latency of CoDoNS, and periodically record theload handled and overhead incurred by each node. We alsoapply the same workload to the legacy DNS, and measureits performance.

We obtained the DNS workload from traces collected atMIT between the 4th and the 11th of December 2000 [18].Our workload comprises of the first 12 hours of this trace,with 281, 943 total queries for 47, 230 unique domain names.The popularity of the domain names in this workload closelyfollows a Zipf-like distribution with parameter 0.91. We di-vided this workload uniformly and issued DNS requests tothe local CoDoNS server at each node. The measurementsreported in this paper were taken from a deployment on 75geographically distributed PlanetLab nodes.

338

100

101

102

103

104

105

0

10

20

30

40

50

60

70

80

90

100

latency (ms)

CDF (%)

codonscodons+dnslegacy dns

Figure 5: Cumulative Distribution of Latency: CoDoNS

achieves low latencies for name resolution. More than

50% of queries incur no network delay as they are an-

swered from the local CoDoNS cache.

Latency Mean Median 90th %

CoDoNS 106 ms 1 ms 105 msCoDoNS+DNS 199 ms 2 ms 213 msLegacy DNS 382 ms 39 ms 337 msPlanetLab RTT 121 ms 82 ms 202 ms

Table 4: Query Resolution Latency: CoDoNS pro-

vides low latency name resolution through analytically

informed proactive caching.

4.2 Lookup PerformanceFigure 5 shows the cumulative distribution of lookup la-

tencies incurred by CoDoNS and the legacy DNS. Table 4summarizes the results of Figure 5 by providing the me-dian, mean, and the 90th percentile of the latency distribu-tion. We aggregate the latency during the second half ofthe workload, allowing the first half to warm the caches ofboth CoDoNS and the legacy DNS. Note that the secondhalf of the workload also contains DNS requests for domainnames not present in the cache, and CoDoNS incurs the ex-tra latency of redirecting these queries to the legacy DNS.In order to study the impact of legacy DNS redirections onlatency, we separately evaluate the lookup performance ofCoDoNS without redirections, by inserting the records attheir home nodes before applying the work load. This studyessentially evaluates the scenario after a complete take overof the legacy DNS by CoDoNS.

50% of the queries in CoDoNS are answered immediatelyby the local CoDoNS server without incurring network de-lay, since proactive replication pushes responses for the mostpopular domain names to all CoDoNS servers. Consequently,CoDoNS provides a significant decrease in median latencyto about 2 milliseconds compared to about 39 millisecondsfor the legacy DNS. The tail of the latency distribution in-dicates that cache misses leading to legacy DNS lookupshave an impact on the worst-case lookup performance ofCoDoNS. However, a complete take over from the legacyDNS would obviate the extra latency overhead. Overall,CoDoNS achieves low latencies in the mean, median, andthe 90th percentile, for both deployment scenarios, with andwithout redirections to the legacy DNS.

0 2 4 6 8 10 120

10

20

30

40

50

60

70

80

90

100

time (hours)

latency (ms)

codonslegacy dns

Figure 6: Median Latency vs Time: Lookup latency

of CoDoNS decreases significantly as proactive caching

takes effect in the background.

Figure 6 shows the median latency of CoDoNS and thelegacy DNS over time. The fluctuations in the graph stemfrom the changing relative popularities of names in the work-load over time. CoDoNS reacts to these changes by contin-uously adjusting the extent of proactive caching. Initially,CoDoNS servers have an empty cache and redirect most ofthe queries to legacy DNS. Consequently, they incur higherlatencies than the legacy DNS. But as resource records arefetched from legacy DNS and replication in the backgroundpushes records to other CoDoNS servers, the latency de-creases significantly. The initial surge in latency can be eas-ily avoided by bootstrapping the system with records forwell known domain names.

4.3 Flash-crowd EffectNext, we examine the resilience of CoDoNS to sudden

upheavals in the popularity of domain names. To model aflash-crowd effect, we take the DNS workload and modify thesecond half to reflect large scale changes in the popularity ofall domain names. We achieve this by completely reversingthe popularities of all the domain names in the workload.That is, the least popular name becomes the most popularname, the second least popular name becomes the secondmost popular name, and so on. This represents a worst casescenario for CoDoNS because records that are replicated theleast suddenly need to be replicated widely, and vice versa,simulating, in essence, a set of flash crowds for the leastpopular records.

Figure 7 shows the median resolution latencies in CoDoNSduring the flash-crowd effect introduced at the six hourmark. There is a temporary increase in the median latencyof CoDoNS when flash-crowd effect starts. But, Beehive’sproactive replication in the background detects the changesin popularity, adjusts the number of replicas, and decreasesthe lookup latency. The latency of CoDoNS after popu-larity reversal quickly reaches the low values in Figure 6,indicating that CoDoNS has recovered completely from theworst-case, large scale changes in popularity.

4.4 Load BalanceWe evaluate the automatic load-balancing provided by

proactive replication in CoDoNS by quantifying load bal-

339

4 6 8 10 120

10

20

30

40

50

60

70

80

90

100

time (hours)

latency (ms)

codonslegacy dns

Figure 7: Median Latency vs Time as a flash-crowd is

introduced at 6 hours: CoDoNS detects the flash-crowd

quickly and adapts the amount of caching to counter it,

while continuing to provide high performance.

ance using the coefficient of variation, defined as the ratioof the standard deviation of the load across all the nodes tothe mean load. The overall average of query load is about6.5 per second for the system.

Figure 8 shows the load balance in queries handled byCoDoNS servers, either from their internal cache or by query-ing the legacy DNS, for the duration of the workload. Atthe start of the experiment, the query load is highly unbal-anced, since home nodes of popular domain names receivefar greater number of queries than average. The imbalanceis significantly reduced as the records for popular domainsget replicated in the system. Even when a flash-crowd is in-troduced at the six hour mark, dynamic changes in cachingkeep the load balanced after a temporary increase in loadvariance. Overall, continuous monitoring and adaptationof proactive caching enable CoDoNS to respond to drasticchanges in the popularity of names and handle flash crowds.

The network bandwidth and per-node storage costs in-curred by proactive caching are modest. The average band-width consumed over the entire experiment was 12.2 KB/sper node (std. dev. 2.26 KB/s) for all network activities.The average number of records per node was 4217 (std. dev.348), a mere 10% of the total number of records. Theserecords require, on average, 13 MB per node. These mea-surements indicate that CoDoNS distributes the load evenlyacross the system and incurs low uniform bandwidth andstorage overhead at each node.

4.5 Update PropagationNext we examine the latencies incurred by CoDoNS for

proactive update propagation. Figure 9 shows the delay in-curred for disseminating updates to resource records repli-cated at different levels. 98% of the replicas are updatedwithin one second even for level-0 records, which are repli-cated at all nodes in the system. It takes a few secondslonger to update some replicas due to high variance in net-work delays and loads at some hosts. The latency to update99% of replicas one hop from the home node is about onesecond. Overall, update propagation latency in CoDoNS de-pends on the extent of replication of records. In the worstcase, it takes log N hops to update all the nodes in the net-

0 2 4 6 8 10 120

0.2

0.4

0.6

0.8

1

time (hours)

coefficient of variation

flash crowdno flash crowd

Figure 8: Load Balance vs Time: CoDoNS handles

flash-crowds by balancing the query load uniformly

across nodes. The graph shows load balance as a ratio

of the standard deviation to the mean across all nodes.

0.01 0.1 1 100

10

20

30

40

50

60

70

80

90

100

update latency (sec)

rep

lica

s u

pd

ate

d (

%)

level−1 recordslevel−0 records

Figure 9: Update Propagation Time: CoDoNS incurs

low latencies for propagating updates. 98% of replicas

get updated within one second.

work. For a million node CoDoNS network, updating 99%of replicas would take far less than a minute for even themost popular domain names replicated throughout. Thisenables nameowners to relocate their services without no-ticeable disruptions to their clients.

4.6 SummaryPerformance measurements from a planetary-scale deploy-

ment against a real workload indicate that CoDoNS can pro-vide low latencies for query resolution. Massive replicationfor the most popular records, but a modest number of repli-cas per server, achieves high performance with low overhead.Eliminating the static query processing hierarchy and shed-ding load dynamically onto peer nodes greatly decreases thevulnerability of CoDoNS to denial of service attacks. Self-organization and continuous adaptation of replication avoidsbottlenecks in the presence of flash crowds. Proactive up-date propagation ensures that unanticipated changes can bequickly disseminated and cached in the system.

340

5. RELATED WORKSeveral researchers have extensively studied the perfor-

mance of the legacy DNS, and proposed new mechanismsto improve its performance. In this section, we discuss pastapproaches to measure and improve the legacy DNS.

Performance Studies: In 1988, Mockapetris and Dun-lap published a retrospective study on the development ofthe legacy DNS identifying its successful features and short-comings [27]. Several measurement studies since then haveprovided good insight into the advantages and the draw-backs of the system. A recent survey by Pappas et al. [29]studies the impact of lame delegations, cyclic dependenciesand reduced nameserver redundancies, on the performanceof the legacy DNS; their findings confirm the results of oursurvey. Earlier studies by Danzig et al. [10] and Brownlee etal. [4, 5] analyze DNS traffic at root and gTLD nameservers.Huitema et al. [16] and Wills et al. [41] study DNS perfor-mance observed from the client side. A more detailed studyof the performance experienced by clients and analysis ofthe effectiveness of caching in the legacy DNS is presentedby Jung et al. in [18, 19]. These studies have provided in-valuable insight into the operation of the legacy DNS andhelped us to motivate and design CoDoNS.

Design Alternatives: Recently, a few schemes havebeen proposed to improve the failure-resilience and lookupperformance of DNS. Cohen and Kaplan [8] propose a pro-active caching scheme for DNS records. In their scheme,expired DNS records in the cache are proactively fetchedfrom the authoritative nameservers. They analyze severalheuristics-based prefetching algorithms, and evaluate theirperformance. This scheme entails prefetching at interme-diate caches, which generates substantial amount of back-ground traffic to update DNS records. In contrast, CoDoNSfetches each record only once at the home node, significantlyreducing the overhead imposed on the legacy DNS.

CoDNS [30] masks delays in the legacy DNS caused byfailures in local resolvers by diverting queries to other, healthyresolvers. CoDNS provides resilience against temporary prob-lems with the legacy DNS, but is not intended as a replace-ment. DDNS [9] and Overlook [37] are peer-to-peer nameservices designed to enhance fault tolerance and load bal-ancing properties. DDNS implements the legacy DNS func-tionalities on top of Chord [36], an O(log N) lookup timestructured DHT based on consistent hashing. Overlook isa general purpose name service built on top of Pastry [34].Both DDNS and Overlook incur high lookup latencies as re-quests are routed through O(log N) overlay hops. Beehiveprovides a replication framework that enables CoDoNS toachieve O(1) lookup performance.

Some researchers have proposed to replace the hierarchicalDNS and URL namespace with flat global identifiers [39].CoDoNS can be used to map such identifiers to physicallocations or to their content with high performance.

Structured DHTs: In addition to Chord and Pastry,several structured DHTs have been proposed in recent years.CAN [33] maps both objects and nodes on a d-dimensional

torus and provides O(dN1

d ) latency. Tapestry [42] employsconsistent hashing [20] to map objects to nodes, and prefix-matching [31] to route lookups in O(log N) hops. Kadem-lia [24] provides O(log N) lookup performance using a sim-ilar search technique, but uses the XOR metric for routing.SkipNet [15] uses skip-lists to provide O(log N) probabilis-tic lookup guarantee. Viceroy [23] provides O(log N) lookup

performance with a constant degree routing graph. A fewDHTs use De Bruijn graphs [21, 40] to achieve O( log N

log log N)

lookup performance. The multi-hop lookup performanceprovided by these DHTs is inadequate to support perfor-mance sensitive application like DNS.

A few recent DHTs provide O(1) lookup performance atthe cost of increased storage and bandwidth consumption.Kelips [13] limits lookup latency to one or two hops by repli-

cating each object on O(√

N) nodes and using gossip-basedprotocols to manage replication. An alternative method toachieve one hop lookups is described in [14], and relies onmaintaining full routing state (i.e. a complete descriptionof system membership) at each node. The space and band-width costs of this approach scale linearly with the size ofthe network. Farsite [11] also routes in a constant numberof hops using a fixed depth hierarchy, but does not addressrapid membership changes. Overall, these DHTs incur aminimum delay of at least one overlay hop, whereas CoDoNScan decrease the average lookup time to less than a singlehop.

6. CONCLUSIONSThe Domain Name System is a critical component of the

Internet. The growth of the Internet namespace, the ex-plosion in the number of networked hosts, and the recentemergence of large-scale coordinated attacks have strainedthe hierarchical, static architecture of the legacy DomainName System. DNS is vulnerable to DoS attacks, incurshigh latencies for query resolution and update propagation,suffers from misconfigurations, and is difficult to administer.

In this paper, we propose a novel alternative for DNS,called CoDoNS. CoDoNS retains the most succesful parts ofthe DNS design; namely, the hierarchical partitioning of thenamespace, the independent management of different partsof the hierarchy, and the general-purpose database inter-face. CoDoNS combines peer-to-peer overlay networks withanalytically-informed proactive caching to provide an alter-native DNS infrastructure. It resists denial of service at-tacks, heals around failures, automatically distributes load,supports fast updates and adapts quickly to flash crowds. Itdecouples nameservice from the physical location of name-servers through cryptographic delegations, and creates acompetitive marketplace for name services. Performancemeasurements from a deployment on PlanetLab using realDNS workloads indicate that CoDoNS can significantly im-prove the lookup performance of legacy DNS with modeststorage and bandwidth overhead.

CoDoNS provides a new platform for nameowners to effi-ciently publish and manage their data. Our current imple-mentation and deployment provides a simple incrementalmigration path from legacy DNS towards the performanceand functionality offered by CoDoNS. During this processCoDoNS can serve as a safety net alongside legacy DNS.

AcknowledgmentsWe are grateful to Robert Morris, Hari Balakrishnan, JaeyonJung, and Emil Sit for providing their DNS traces.

REFERENCES[1] M. Andrews. Negative Caching of DNS Queries. RFC 2308,

Mar 1998.

341

[2] A. Bavier, M. Bowman, B. Chun, D. Culler, S. Karlin,S. Muir, L. Peterson, T. Roscoe, T. Spalink, and M. Wawr-zoniak. Operating System Support for Planetary-Scale Net-work Services. Symposium on Networked Systems Designand Implementation, San Francisco CA, Mar 2004.

[3] T. Brisco. DNS Support for Load Balancing. RFC 1794, Apr1995.

[4] N. Brownlee, kc Claffy, and E. Nemeth. DNS Measurementsat a Root Server. GlobeCom, San Antonio, TX, Nov 2001.

[5] N. Brownlee, kc Claffy, and E. Nemeth. DNS Root/gTLDPerformance Measurements. Systems Administration Con-ference, San Diego CA, Dec 2001.

[6] L. Breslau, P. Cao, L. Fan, G. Phillips, and S. Shenker. WebCaching and Zipf-like Distributions: Evidence and Implica-tions. International Conference on Computer Communica-tions, New York NY, Mar 1999.

[7] M. Castro, P. Druschel, A. Ganesh, A. Rowstron, andD. Wallach. Secure Routing for Structured Peer-to-PeerOverlay Networks. Symposium on Operating Systems Designand Implementation, Boston MA, Dec 2002.

[8] E. Cohen and H. Kaplan. Proactive Caching of DNS Records:Addressing a Performance Bottleneck. Symposium on Appli-cations and the Internet, San Diego-Mission Valley CA, Jan2001.

[9] R. Cox, A. Muthitacharoen, and R. Morris. Serving DNS us-ing a Peer-to-Peer Lookup Service”. International Workshopon Peer-To-Peer Systems, Cambridge MA, Mar 2002.

[10] P. Danzig, K. Obraczka, and A. Kumar. An Analysis ofWide-Area Nameserver Traffic: A study of the Internet Do-main Name System. SIGCOMM, Baltimore MD, 1992.

[11] J. Douceur, A. Adya, W. Bolosky, D. Simon, andM. Theimer. Reclaiming Space from Duplicate Files in aServerless Distributed File System. International Confer-ence on Distributed Computing Systems, Vienna Austria, Jul2002.

[12] D. Eastlake. Domain Name System Security Extensions.RFC 2535, Mar 1999.

[13] I. Gupta, K. Birman, P. Linga, A. Demers, and R. van Re-nesse. Kelips: Building an Efficient and Stable P2P DHTThrough Increased Memory and Background Overhead. In-ternational Workshop on Peer-To-Peer Systems, BerkeleyCA, Feb 2003.

[14] A. Gupta, B. Liskov, and R. Rodrigues. Efficient Routingfor Peer-to-Peer Overlays. Symposium on Networked Sys-tems Design and Implementation, San Francisco CA, Mar2004.

[15] N. Harvey, M. Jones, S. Saroiu, M. Theimer, and A. Wol-man. SkipNet: A Scalable Overlay Network with PracticalLocality Properties., Symposium on Internet Technologiesand Systems, Seattle WA, Mar 2003.

[16] C. Huitema and S. Weerahandi. Internet Measurements: theRising Tide and the DNS Snag., ITC Specialist Seminar onInternet Traffic Measurement and Modeling, Monterey CA,Sep 2000.

[17] Internet Systems Consortium. BIND Vulnerabilities.www.isc.org/sw/bind/bind-security.php, Feb 2004.

[18] J. Jung, E. Sit, H. Balakrishnan, and R. Morris. DNS Per-formance and Effectiveness of Caching. SIGCOMM InternetMeasurement Workshop, San Francisco CA, Nov 2001.

[19] J. Jung, A. Berger, and H. Balakrishnan. Modeling TTL-based Internet Caches. International Conference on Com-puter Communications, San Francisco CA, Mar 2003.

[20] D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewinand R. Panigrahy. Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving Hot-spots on theWorld Wide Web. Symposium on Theory of Computing, ElPaso TX, Apr 1997.

[21] F. Kaashoek and D. Karger. Koorde: A Simple Degree-Optimal Distributed Hash Table. International Workshop onPeer-To-Peer Systems Workshop, Berkeley CA, Feb 2003.

[22] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller.Common DNS Implementation Errors and Suggested Fixes.RFC 1536, Oct 1993.

[23] D. Malkhi, M. Naor, and D. Ratajczak. Viceroy: A Scal-able and Dynamic Emulation of the Butterfly. Symposiumon Principles of Distributed Computing, Monterey CA, Aug2002.

[24] P. Maymounkov and D. Mazieres. Kademlia: A Peer-to-peerInformation System Based on the XOR Metric. InternationalWorkshop on Peer-To-Peer Systems, Cambridge MA, Mar2002.

[25] P. Mockapetris. Domain Names: Concepts and Facilities.RFC 1034, Nov 1987.

[26] P. Mockapetris. Domain Names: Implementation and Spec-ification. RFC 1035, Nov 1987.

[27] P. Mockapetris and K. Dunlop. Development of the DomainName System. SIGCOMM, Stanford CA, 1988.

[28] R. Naraine. Massive DDoS Attack Hit DNS Root Servers.www.internetnews.com/dev-news/article.php/1486981, Oct2002.

[29] V. Pappas, Z. Xu, S. Lu, D. Massey, A. Terzis, and L. Zhang.Impact of Configuration Errors on DNS Robustness. SIG-COMM, Portland OR, Aug 2004.

[30] K. Park, Z. Wang, V. Pai, and L. Peterson. CoDNS : MaskingDNS Delays via Cooperative Lookups. Princeton UniversityComputer Science Technical Report TR-690-04, Feb 2004.

[31] G. Plaxton, R. Rajaraman, and A. Richa. Accessing nearbycopies of replicated objects in a distributed environment.Theory of Computing Systems, vol 32, pg 241-280, 1999.

[32] V. Ramasubramanian and E. G. Sirer. Beehive: Exploit-ing Power Law Query Distributions for O(1) Lookup Perfor-mance in Peer to Peer Overlays. Symposium on NetworkedSystems Design and Implementation, San Francisco CA,Mar 2004.

[33] S. Ratnasamy, P. Francis, M. Hadley, R. Karp, andS. Shenker. A Scalable Content-Addressable Network. SIG-COMM, San Diego CA, Aug 2001.

[34] A. Rowstron and P. Druschel. Pastry: Scalable, decentral-ized object location and routing for large-scale peer-to-peersystems. International Conference on Distributed SystemsPlatforms, Heidelberg, Germany, Nov 2001.

[35] A. Shaikh, R. Tewari, and M. Agarwal. On the Effectivenessof DNS-based Server Selection. International Conference onComputer Communications, Anchorage AK, Apr 2001.

[36] I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H. Bal-akrishnan. Chord: A scalable Peer-to-peer Lookup Servicefor Internet Applications. SIGCOMM, San Diego CA, Aug2001.

[37] M. Theimer and M. Jones. Overlook: Scalable Name Serviceon an Overlay Network International Conference on Dis-tributed Computing Systems, Vienna Austria, Jul 2002.

[38] P. Thurrott. Microsoft Suffers Another DoS Attack.www.winnetmag.com/WindowsSecurity/Article/ArticleID/19770/WindowsSecurity 19770.html, Jan 2001.

[39] M. Walfish, H. Balakrishnan, and S. Shenker. Untangling theWeb from DNS. Symposium on Networked Systems Designand Implementation, San Francisco CA, Mar 2004.

[40] U. Wieder and M. Naor. A Simple Fault Tolerant DistributedHash Table. International Workshop on Peer-To-Peer Sys-tems, Berkeley CA, Feb 2003.

[41] C. Wills and H. Shang. The Contribution of DNS LookupCosts to Web Object Retrieval. Worcester Polytechnic In-stitute Technical Report TR-00-12, Jul 2000.

[42] B. Zhao, L. Huang, J. Stribling, S. Rhea, A. Joseph, andJ. Kubiatowicz. Tapestry: A Resilient Global-scale Overlayfor Service Deployment. Journal on Selected Areas in Com-munications, 2003.

[43] L. Zhou, F. B. Schneider, and R. van Renesse. COCA: ASecure Distributed On-line Certification Authority. Trans-actions on Computer Systems vol 20, Nov 2002.

342