From lackhand@gmail.com Wed Mar 1 18:55:22 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HTML_00_10, HTML_MESSAGE autolearn=no version=3.1.0 X-Spam-Level: Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196] (may be forged)) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k21NtMt14290 for ; Wed, 1 Mar 2006 18:55:22 -0500 (EST) Received: by zproxy.gmail.com with SMTP id x3so276521nzd for ; Wed, 01 Mar 2006 15:55:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=MK3FQoUr/Zth2suHcr3ogrjffSx//+U3V6ojJmkrsbqBStYKTuI+mPh4J2YyDTJ8g0aAV/yzFPrgLQIXvd0dvj+XkpZRuAsPp/2K7CUJb3ro8HIer7Z0eseJhL8qkAeHXJN20PBFmSNAWR3svQcDQlRR7IzXG9r7ZaG8m9/2d2Y= Received: by 10.36.222.25 with SMTP id u25mr982058nzg; Wed, 01 Mar 2006 15:55:22 -0800 (PST) Received: by 10.36.147.10 with HTTP; Wed, 1 Mar 2006 15:55:21 -0800 (PST) Message-ID: <9aa7a97d0603011555g3eb2ce5bs9f96c1dd4719b76f@mail.gmail.com> Date: Wed, 1 Mar 2006 18:55:21 -0500 From: "Andrew Cunningham" To: egs+summary@cs.cornell.edu Subject: PAPER 11 MIME-Version: 1.0 X-Security: message sanitized on sundial.cs.cornell.edu See http://www.impsec.org/email-tools/sanitizer-intro.html for details. $Revision: 1.148 $Date: 2004-12-19 11:59:17-08 X-Security: The postmaster has not enabled quarantine of poisoned messages. Content-Type: multipart/alternative; boundary="----=_Part_4988_31705272.1141257321927" ------=_Part_4988_31705272.1141257321927 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andrew Cunningham arc39 _Serving_DNS_Using_a_Peer_to_Peer_Lookup_Service Russ Cox, Athicha Muthitacharoen, Robert T. Morris An exploratory paper on splitting DNS responsibilities, this paper creates a system where records may be verified through means above trusting the delivery-point. This is performed through DHash, built on top of Chord, in order to eliminate administrative issues found in the current DNS. There are already certain measures in place to authenticate these data -- DNSSEC effectively separated the authentication from the delivery of data. Thus, this paper seeks to improve on the behavior of the currently constructed service; studies show that much of the current DNS traffic is either faulty or due to the current structure's hierarchical construction. Because of this, there is a lot of load which could in some sense be better apportioned. Because they are severing the link between administrative hierarchy and service structure, we remove certain skill-sets from system administrator's tasks, provide better load balance, and provide robustness against denial or service attack. Updates are prepared, signed, and inserte= d into the DHash with key Sha1(domain name|query type). This is a neat hat-trick of a public key distribution system, punting the problem over to the same method used to distribute DNS IP addresses (an= d similar). They claim that this reduces certain capabilities extended by DNS= , the major one being that of dynamically generated records. In fact, these are still available, but through more complex load-management at the server side -- by returning the IP address of some server which manages whichever dynamic content would normally be returned, and performing some sort of redirection, this can be achieved. Even protocols which do not support redirection can be handled in this fashion, by the dynamic-application server handling the traffic as a middle-man. This requires good load balancing, as otherwise whichever computer exposes this service will collapse under the weight of requests; this must almost certainly be handle= d at client side. Nevertheless, the acknowledged flaw of the scheme is indeed latency and load; it is clearly a mistake to assume that this is the death-knell of peer-to-peer DNS (see: beehive!) but rather that simply using chord does no= t expose the correct level of services. _The_Design_and_Implementation_of_a_Next_Generation_Name_Service_for_the_I= nternet_ Venugopalan Ramasubramanian, Emin Gun Sirer DNS nameservers are easy targets for malicious agents, and moreover badly load-balanced in that 80% of the domain names are served by just two nameservers, and 0.8% by only one nameserver. Name-adress translation in th= e DNS incurs long delays, also; the flattening of the namespace leads not jus= t to imbalanced load on root nameservers, but also to high latency. Moreover, the current DNS suffer from a high degree of replication through caching which prevents quick updates, since the locations of caches is not stored, using instead timeout-based invalidations of stale mappings. CoDoNS uses Beehive as a substrate to achieve extremely low latency (under one hop on average) with reasonable storage overhead, given rank of objects. Also, due to Beehive's proactive replication, root nodes for a given object are aware of all copies of the object, and can therefore ensure reasonably fresh copies are dissemenated. What strikes me as unusual in this paper is the degree of immediacy required from it. While we are no longer in the "days of yore" we once were= , where the hosts.txt file was updated on a nightly basis, DNS remains relatively stable. Indeed, this "need for speed" grows from the removal of the hierarchical nature of the current implementation, since theoretically all views rely on global state of the Beehive substrate being correctly updated, versus the current state in which only the parent node for a resource need be informed -- ignoring the fact that currently, stale cached copies can predominate anyway! The use of cryptography is admirable and necessary given the lack of hierarchy, but "unnecessary" in that we do not have it now. It is, however, desirable, and so the slight overhead incurred is irrelevant; it is worth noting, however, that legacy programs will not b= e able to take advantage of the new form. The real problem is one that we've had for the last few papers, to whit= : the tragedy of the commons. The paper implies that "institutions" should ru= n this service, but it is unclear whether this is intended to mean any entity currently operating a nameserver, or some other interpretation. Unfortunately, since this protocol places a higher load on the unpopular nameservers than they are used to seeing, it is "not worth their time" to participate; some middle ground must be reached between requiring participation in the system and yielding services from the system to balanc= e the resources of smaller and larger entities while giving them both incentives. ------=_Part_4988_31705272.1141257321927 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Andrew Cunningham
arc39

    _Serving_DNS_Using_a_Peer_to_Peer_Lookup_Service
    Russ Cox, Athicha Muthitacharoen, Robert T. Morris
    
    An exploratory paper on splitting DNS responsibilities, this paper creates a system where records may be verified through means above trusting the delivery-point. This is performed through DHash, built on top of Chord, in order to eliminate administrative issues found in the current DNS. There are already certain measures in place to authenticate these data -- DNSSEC effectively separated the authentication from the delivery of data. Thus, this paper seeks to improve on the behavior of the currently constructed service; studies show that much of the current DNS traffic is either faulty or due to the current structure's hierarchical construction. Because of this, there is a lot of load which could in some sense be better apportioned. Because they are severing the link between administrative hierarchy and service structure, we remove certain skill-sets from system administrator's tasks, provide better load balance, and provide robustness against denial or service attack. Updates are prepared, signed, and inserted into the DHash with key Sha1(domain name|query type).
    This is a neat hat-trick of a public key distribution system, punting the problem over to the same method used to distribute DNS IP addresses (and similar). They claim that this reduces certain capabilities extended by DNS, the major one being that of dynamically generated records. In fact, these are still available, but through more complex load-management at the server side -- by returning the IP address of some server which manages whichever dynamic content would normally be returned, and performing some sort of redirection, this can be achieved. Even protocols which do not support redirection can be handled in this fashion, by the dynamic-application server handling the traffic as a middle-man. This requires good load balancing, as otherwise whichever computer exposes this service will collapse under the weight of requests; this must almost certainly be handled at client side.
    Nevertheless, the acknowledged flaw of the scheme is indeed latency and load; it is clearly a mistake to assume that this is the death-knell of peer-to-peer DNS (see: beehive!) but rather that simply using chord does not expose the correct level of services.
    
    _The_Design_and_Implementation_of_a_Next_Generation_Name= _Service_for_the_Internet_
    Venugopalan Ramasubramanian, Emin Gun Sirer
    
    DNS nameservers are easy targets for malicious agents, and moreover badly load-balanced in that 80% of the domain names are served by just two nameservers, and 0.8% by only one nameserver. Name-adress translation in the DNS incurs long delays, also; the flattening of the namespace leads not just to imbalanced load on root nameservers, but also to high latency. Moreover, the current DNS suffer from a high degree of replication through caching which prevents quick updates, since the locations of caches is not stored, using instead timeout-based invalidations of stale mappings. CoDoNS uses Beehive as a substrate to achieve extremely low latency (under one hop on average) with reasonable storage overhead, given rank of objects. Also, due to Beehive's proactive replication, root nodes for a given object are aware of all copies of the object, and can therefore ensure reasonably fresh copies are dissemenated.
    What strikes me as unusual in this paper is the degree of immediacy required from it. While we are no longer in the "days of yore" we once were, where the hosts.txt file was updated= on a nightly basis, DNS remains relatively stable. Indeed, this "need for speed" grows from the removal of the hierarchical nature of the curren= t implementation, since theoretically all views rely on global state of the Beehive substrate being correctly updated, versus the current state in which only the parent node for a resource need be informed -- ignoring the fact that currently, stale cached copies can predominate anyway! The use of cryptography is admirable and necessary given the lack of hierarchy, but "unnecessary" in that we do not have it no= w. It is, however, desirable, and so the slight overhead incurred is irrelevant; it is worth noting, however, that legacy programs will not be able to take advantage of the new form.
    The real problem is one that we've had for the last few papers, to whit: the tragedy of the commons. The paper implies that "institutions" should run this service, but it is unclear whether= this is intended to mean any entity currently operating a nameserver, or some other interpretation. Unfortunately, since this protocol places a higher load on the unpopular nameservers than they are used to seeing, it is "not worth their time" to participate; some middle ground m= ust be reached between requiring participation in the system and yielding services from the system to balance the resources of smaller and larger entities while giving them both incentives.
------=_Part_4988_31705272.1141257321927-- From ns253@cornell.edu Wed Mar 1 23:28:51 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from authusersmtp.mail.cornell.edu (granite1.mail.cornell.edu [128.253.83.141]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k224Sot20588 for ; Wed, 1 Mar 2006 23:28:51 -0500 (EST) Received: from localhost (cpe-69-207-49-126.twcny.res.rr.com [69.207.49.126]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k224SnE4019147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Mar 2006 23:28:50 -0500 (EST) Date: Wed, 1 Mar 2006 23:28:49 -0500 From: Niranjan Sivakumar To: egs+summary@cs.cornell.edu Subject: PAPER 11 Message-Id: <20060301232849.1ae186e0.ns253@cornell.edu> Organization: Cornell Law School X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Niranjan Sivakumar Serving DNS using a Peer-to-Peer Lookup Service The Design and Implementation of a Next Generation Name Service for the Internet Both of these papers are premised on a number of inadequacies that are present in the current DNS implementation. Among these are a lack of robustness due to a relatively small number of bottleneck-prone servers having to bear the load for many names, a lack of a coherent security, complexity of configuring name servers, unbalanced loads, and generally poor performance. DDNS is a proposed system that runs on top of DHash, a variant of Chord. DDNS uses the same granularity level as DNS, a resource set, as its basic elements. The record sets consist of a domain name and address. DDNS relies on public key cryptography to sign and verify record sets. Record sets are inserted into the system and are keyed based on the SHA1 hash of the domain name and record set query type. DHash will verify the signature before accepting the record set. DDNS uses a system of replication of resource sets to ensure some level of fault tolerance and proposes a system of caching popular keys ! to limit the amount of lookups that would be required when obtaining a record set. There is also a proposed proxy server to handle legacy DNS requests to ease transition to the new system. CoDoNS is much like an evolution of the system proposed in DDNS. Like DDNS, it is again a name service running on top of a DHT. In this case, the DHT is Beehive. CoDoNS contains a "bridge" to the legacy DNS sytem, and is able to pull records from it to ease transitioning to the new system. CoDoNS relies on Beehive's proactive caching scheme to deal with load balancing, to reduce lookup time, and for dealing with Zipf-style distributions and flash popularity like the Slashdot or Digg effects. CoDoNS also allows servers to be manually updated with cached addresses that serve their locality in order to avoid local queries being sent out to a random place in the network and incurring unnecessary latency. CoDoNS relies on the DNSSEC standard for security. CoDoNS can cache DNSEC certificates to speed up the process of clients verifying them. Also, in the event that clients do not support DNSSEC, they only need to trust their local CoDoNS server. One of the flaws with the DDNS paper seems to be that it seems to only go "half way". While the paper claims to consider the implementation of DNS on a generic DHT at some level, it is definitely focused on Chord. However, the authors themselves recognize that Chord is not the ideal underlying system for this application. However, while they have thought about implementing some changes to the system, such as caching for resilience against failure, they do not carry out this analysis very far. The paper seems to be somewhere between simply evaluating the suitability of DHash (Chord) for supporting a DNS alternative and proposing a peer-to-peer system that would be suitable for the application in question. One of the problems with CoDoNS appears to be the reliance on DNSSEC. It is acknowledged in the paper that this system has not really taken off, and it does not seem to be a trivial issue to get it up and running. One more issue seems to be that while there are some g! uarantees of load balancing in the system, a balanced load may not always be desirable. It may be a good idea to have some kind of economic system where entities that rely on the system more will provide more resources into the system. From ids3@cornell.edu Thu Mar 2 02:10:59 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from authusersmtp.mail.cornell.edu (granite1.mail.cornell.edu [128.253.83.141]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k227Axt02173 for ; Thu, 2 Mar 2006 02:10:59 -0500 (EST) Received: from [128.253.212.208] (r253212208.resnet.cornell.edu [128.253.212.208]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k227AxnD002509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Mar 2006 02:10:59 -0500 (EST) Message-ID: <44069A82.50909@cornell.edu> Date: Thu, 02 Mar 2006 02:10:58 -0500 From: Ivan Stoyanov User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: egs+summary@cs.cornell.edu Subject: PAPER 11 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Serving DNS using a Peer-to-Peer Lookup Service The paper addresses some of the shortcomings in the current DNS system. DNS is difficult to administer and there exists a coupling between ownership of domains and responsibility of serving data for them. The solution that the authors propose is to have a global DHT where clients can enter their data and have it handled by the system that provides other extras, such as fault tolerance and load balancing. The problem with this approach is that it comes at a price - DHTs lookup time is O(logN), which is unacceptable for such latency-sensitive applications. The suggested implementation provides no optimizations other than traditional caching and not surprisingly the results show no improvement at all. The paper poses one other issue. Domain owners in the current DNS system may have the painful task of configuring DNS servers, but at least they have all the incentives they need. In a global public DNS DHT, it is not clear what incentives will nodes have to run servers rather than free ride. The Design and Implementation of a Next Generation Name Service for the Internet This paper solves the problem with DHT performance for latency-sensitive applications by using proactive replication. The system proposed, CoDoNS, uses the Beehive framework to achieve O(1) lookup time on average. In addition, it fully exploits the benefits of a DHT, namely load-balancing, scalability, decentralization, self-organization, failure resilience, etc. The properties of DNS (infrequent object mutation and Zipf-like demand distribution) are particularly well-suited for the Beehive framework. Most of the discussion in this paper is based on the Beehive paper, including popularity delta calculation and flash crowds adaptation. In addition, the authors propose a scheme for gradual introduction of CoDoNS as a backup or replacement of legacy DNS. The paper does not address the issue of incentives. From victoria@cs.hmc.edu Thu Mar 2 02:23:15 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from turing.cs.hmc.edu (turing.cs.hmc.edu [134.173.42.99]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k227NEt04970 for ; Thu, 2 Mar 2006 02:23:14 -0500 (EST) Received: by turing.cs.hmc.edu (Postfix, from userid 34382) id 7DF275326D; Wed, 1 Mar 2006 23:23:08 -0800 (PST) Date: Wed, 1 Mar 2006 23:23:08 -0800 From: Victoria Krafft To: egs+summary@cs.cornell.edu Subject: PAPER 11 Message-ID: <20060302072308.GB9120@cs.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i The current DNS system has been around for more than 20 years. The basic design is tree-based with heavy caching. It relies on a single set of authoritative servers, which branch out rapidly to smaller servers for individual domains and subdomains. By caching data along the tree, the system avoids overwhelming the root servers. The paper by Cox et al. proposes a new distributed DNS system, called DDNS. It would be implemented on top of a Chord p2p network, and use DNSSEC, which uses digital signatures to authenticate the domain records. They investigate this idea, and end up deciding that the current system should be retained. The new system offers more stability for individual domains, but it has longer latencies, and does not allow servers to provide dynamic name resolution, which is commonly done for a variety of applications. In addition to these problems, I have to question the logic behind their original motivation. The main problem identified, the inability of users to run their own nameservers.This is not a property of the existing DNS architecture. It's a property of a poor interface to the common software for managing DNS, BIND. It is currently remedied by companies who, for a small monthly fee, will provide name service for a domain. Without this problem, we have no motivation for switching to a p2p system. CoDoNS is another distributed DNS system, which uses Beehive for its underlying network topology. Like DDNS, it relies on DNSSEC to authenticate record in its system. With its proactive caching strategy, Beehive provides much faster lookup times, and handles flash crowds almost as well as the existing system. It fixes many of the problems current DNS servers face, such as load imbalances and DDOS attacks. This system is backwards compatible with the existing DNS network, so organizations can transition at any time. The free rider problem is, for the most part, glossed over, with a note that large organizations will pay for the DNS servers. While this system is quite impressive, they gloss over one potential problem when transitioning: dynamically generated DNS records. These have a variety of uses, such as sharing load between servers, and they work by providing different copies of a DNS record to different sections of the network. In many cases, there is no good way to offload the decision onto the DNS client; people will misconfigure those, or hack the system so that they get the optimal behavior, regardless of what this does to other users. Because this decision can't be offloaded to a client machine, either CoDoNS will have to process these, or they will have to send all the traffic to some other server, which then provides dynamically generated records. While CoDoNS is running with records generated by the old DNS, this could cause serious problems: If a company normally splits the load between 100 servers, and CoDoNS is used by half the internet, then one of the machines will be overwhelmed, while the rest see less traffic. -- Victoria Krafft From pjk25@cornell.edu Thu Mar 2 02:25:46 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from authusersmtp.mail.cornell.edu (granite1.mail.cornell.edu [128.253.83.141]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k227Pkt05815 for ; Thu, 2 Mar 2006 02:25:46 -0500 (EST) Received: from [192.168.0.101] (user-10mt73g.cable.mindspring.com [65.110.156.112]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k227PjgA003059 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 2 Mar 2006 02:25:45 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: egs+summary@cs.cornell.edu From: Philip Kuryloski Subject: PAPER 11 Date: Thu, 2 Mar 2006 02:28:38 -0500 X-Mailer: Apple Mail (2.746.2) SERVING DNS USING A PEER-TO-PEER LOOKUP SERVICE The authors propose DDNS, an implementation of DNS (or more accurately DNSSEC) running on top of DHash, a DHT based on Chord. Although the system is successful in some respects, the authors use its shortcomings to make recommendations on what issues remain in DHTs that limit their effectiveness for DNS. Despite these limitations, there are some immediate benefits from a DHT based system: the challenge in administering DNS servers is greatly reduced, and greater load balancing is achieved by eliminating root servers which typically are under very high load. DDNS still uses CAs and asymmetric cryptography to validate DNS resource record sets which a placed into the DHash DHT. In order to reduce traffic generated in validating records, DHash's demand based replication/caching scheme is used, as well as the speculative inclusion of additional DNSSEC signatures are stored with resource record sets. Simulation of DDNS demonstrates effective load balancing, and effective caching for extremely popular items. However, these items are popular my orders of magnitude of requests, resulting in replication of those objects at every node. The latency of lookups in DDNS are unfortunately more than 7 times longer on average than traditional DNS. Also, dynamically generated records are not supported by DDNS. DDNS is, however, more resilient to denial of service attacks than DNS. THE DESIGN AND IMPLEMENTATION OF A NEXT GENERATION NAME SERVICE FOR THE INTERNET The authors propose the Cooperative Domain Name System (CoDoNS), a distributed DNS service built on top of a DHT using the Beehive replication framework. They begin with a discussion of the limitations of the existing DNS system, mainly its susceptibility to DoS attacks, primitive caching scheme, and susceptibility to server misconfiguration. The Beehive active caching system is analytically driven based on the popularity of objects, greatly reducing the latency of the underlying DHT and addressing a critical issue with other DHT based DNS schemes. The authors also discuss the limitations of traditional DNSs caching scheme against heavy tailed query distributions, and the fragility of the system introduced by manual configuration. Codons uses beehive proactive caching layered on top of a Pastry DHT, and proactively queries the existing DNS system for entries which do not yet exist in CoDoNS. The asymmetric cryptography used in DNSSEC is used is as well for verifying the authenticity of records. A centralized entity is used to sign records brought into Codons from the legacy DNS. The authors tests Codons on 75 machines in the PlanetLab network. They find that the latency of lookups is below that of legacy DNS. They also find that codons is effective in load balancing even against flash crowds. The primary difference between DDNS and Codons is the push type proactive caching used in codons versus request driven caching. As a result it achieves much better lookup latency. Both schemes do however sit on top of a DHT and are designed as gradual replacements for legacy DNS. As a result, they rely to some extent on centralized authorities for validating existing DNS records. From tc99@cornell.edu Thu Mar 2 02:57:32 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k227vWt12612 for ; Thu, 2 Mar 2006 02:57:32 -0500 (EST) Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k227vVNL017276 for ; Thu, 2 Mar 2006 02:57:31 -0500 (EST) Received: from 24.59.114.243 by webmail.cornell.edu with HTTP; Thu, 2 Mar 2006 02:57:31 -0500 (EST) Message-ID: <2032.24.59.114.243.1141286251.squirrel@webmail.cornell.edu> Date: Thu, 2 Mar 2006 02:57:31 -0500 (EST) Subject: paper 11 From: "Theodore Ming Shiuan Chao" To: egs@cs.cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal The two papers discuss using P2P networks to perform DNS lookups to address some of the issues that legacy DNS has: largely network resilience and updating. One of the papers uses Beehive over a Pastry ring overlay, which we already discussed in class. It uses proactive replication of popular lookups to achieve less-than-one-hop performance. The MIT DNS system (DDNS) is overlaid on a Chord network (though the exact network overlay is not especially important for theirs). Both DDNS and CoDoNS preserves the hierarchy of legacy DNS by signing data with the key of the next level higher, all the way to the top-level domain and then the root domain. This allows for security in legitimizing the results from a search, but requires many extra queries to go through the key hierarchy, even when popular results maybe have multiple levels cached at one location. In addition, DDNS only performs reactive caching, which is not entirely sufficient to minimize latency. A major issue with these is that the nodes in the network must all be trusted. Even with a signing hierarchy like in DDNS, malicious nodes could attack the network in other ways, via Sybil and Eclipse attacks for instance. Domain Name Service is a critical service that should not be able to be compromised at all, and opening it up to Eclipse attacks might have a similar effect to DoS attacks. This would probably restrict the nodes in the network to certified trusted agents like the current top-level servers. This also removes the worry about nodes not having the resources to handle the latency-sensitive application, but can reintroduce the limited points of failures if the servers are not sufficiently widely distributed. It would be a significant improvement over the single-point of failure of the root domain servers, but it could still present a vulnerability. From tudorm@cs.cornell.edu Thu Mar 2 08:17:15 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from exchfe2.cs.cornell.edu (exchfenlb-2.cs.cornell.edu [128.84.97.34]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22DHEt15564 for ; Thu, 2 Mar 2006 08:17:14 -0500 (EST) Received: from exchfe1.cs.cornell.edu ([128.84.97.27]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 08:17:14 -0500 Received: from [192.168.0.6] ([65.110.147.185]) by exchfe1.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 08:17:13 -0500 Message-ID: <4406EFAF.3030204@cs.cornell.edu> Date: Thu, 02 Mar 2006 08:14:23 -0500 From: Tudor Marian User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: egs@cs.cornell.edu Subject: PAPER 11 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2006 13:17:14.0037 (UTC) FILETIME=[9F010E50:01C63DFB] The paper proposes an alternative secure DNS using the hashtable interface provided by a p2p overlay in a straightforward way. The system takes advantage of Chord's fault tolerance and load balancing properties, and eliminates the administrative issues faced by the current DNS deployment. The namespace authority entities are thus decoupled from where the data entries are stored. Although resolved lookups are cached along the return path, the latency incurred by the system is considerable compared with the default DNS (median response time of 350ms as opposed to 43ms in favor of the conventional system). Replicating entries only to six sites to begin with might not be enough, and data could be lost before request replies store cached copies. Also network partitions may yield unexpected scenarios when nodes are unable to lookup names that are part of the same organization because they have been hashed on the other edge of the Internet, while a hierarchical DNS would only sever the connection to the outer world and allow lookup resolves to names in a common subtree. The paper presents the implementation of a backward - compatible alternative DNS system that, like the previous paper is build on top of a structured DHT. Aside the fact that it takes advantage of the same properties given by a p2p underlying overlay (like load ballancing , failure resilience and authority - location decoupling), CoDoNS also addresses the low latency problem using proactive replication. The Beehive replication framework provides an analytical solution to optimal replica placement when the popularity of the items obey a power law distribution, and it is well known that DNS lookups do obey such a model. At the moment, if a lookup is routed towards a home node that does not have the record, another DNS query is issued towards the legacy DNS system. In such a scenario, the latency of a cold start could be significant. Tudor From nsg7@cornell.edu Thu Mar 2 09:49:23 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22EnNt12777 for ; Thu, 2 Mar 2006 09:49:23 -0500 (EST) Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k22EnKZ2021362 for ; Thu, 2 Mar 2006 09:49:21 -0500 (EST) Received: from 132.236.227.119 by webmail.cornell.edu with HTTP; Thu, 2 Mar 2006 09:49:21 -0500 (EST) Message-ID: <1702.132.236.227.119.1141310961.squirrel@webmail.cornell.edu> Date: Thu, 2 Mar 2006 09:49:21 -0500 (EST) Subject: PAPER 11 From: "Nicholas S Gerner" To: egs+summary@cs.cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Legacy DNS, as argued by Cox, Muthitacharoen and Morris's "Serving DNS..." and Ramasubramanian and Sirer's "The Design and Implementation" presenting DDNS and CoDoNS respectively, is fragile with respect to workload and threats it faces today. Both papers describe how the heirarchical nature of DNS and the coupling of phyisical/administrative structure and abstract namespace structure lead to imbalance and tend toward the frequent occurence of human error in DNS. Additionally, Ramasubramanian and Sirer present an indepth analysis of a study on DNS failures and weaknesses including everything from failures due to network and delegation bottlenecks to latency and miconfiguration issues. Both papers present distributed implementations of DNS (DDNS and CoDoNS), hoping to address some or all of these issues. DDNS is a simple ring-based DHT with the addition of passive caching. CoDoNS also builds on a DHT with the addition of Beehive proactive caching (similar to the evaluation used in the Beehive paper). DDNS supports queries on RRSets (from legacy DNS) and includes DNSSEC. CoDoNS is presented as a potial DNS replacement and supports a completely legacy DNS interface along with DNSSEC extensions (using a centralized authority to verify non-DNSSEC DNS records) and an interface to support many current DNS applications (from simple name-to-ip or ip-to-name lookup to services such as Akami). Both papers use real DNS workload measurements to evalute their systems. DDNS is evaluated in a simulated environment against analytical derived legacy performance. The conclusion here is that median response time of DDNS is 350ms compared to 43ms for conventional DNS (on average 10 RPCs without caching in DDNS vs 2 RPCs with legacy DNS). DDNS goes on to argue that a DHT cannot provide performance and features equivalent to legacy DNS. Ramasubramanian and Sirer present wholly different results. This evaluation is conducted on PlanetLab and runs a DNS workload both against CoDoNS and against a legacy DNS implementation. The results of this experiment (along with a strong presentation of how legacy DNS operates) show that legacy DNS incurs a median lookup time of 39ms with a mean of 382ms. CoDoNS on the other hand (thanks to Beehive proactive caching) provides a median lookup time of 1ms and a mean of 106ms (with Beehive average lookup cost set to .5 hops). Additional results show that CoDoNS similarly outperforms legacy DNS in the face of flashcrowds (as expected from Beehive). And the storage cost per node in CoDoNS is roughly 13MB. These two papers present systems which seek to address similar problems in legacy DNS; however, they present two very different results and come to two opposite conclusions. CoDoNS is able to show that many of the issues faced in legacy DNS can be addressed by a distributed system and can provide much better performance at low per-node cost (in constrast to the conclusion made as a result of DDNS). While CoDoNS addresses many of the problems faced by legacy DNS it does not address some new problems arising from the decoupling of namespace management from physical and administrative location. DDNS calls some of these out relating to traditional problems of a node's incentive to cooperate. From gp72@cornell.edu Thu Mar 2 10:58:25 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22FwOt04778 for ; Thu, 2 Mar 2006 10:58:24 -0500 (EST) Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k22FwLUf007741; Thu, 2 Mar 2006 10:58:22 -0500 (EST) Received: from 132.236.227.145 by webmail.cornell.edu with HTTP; Thu, 2 Mar 2006 10:58:23 -0500 (EST) Message-ID: <1671.132.236.227.145.1141315103.squirrel@webmail.cornell.edu> In-Reply-To: <3587.128.253.122.16.1141143202.squirrel@webmail.cornell.edu> References: <3587.128.253.122.16.1141143202.squirrel@webmail.cornell.edu> Date: Thu, 2 Mar 2006 10:58:23 -0500 (EST) Subject: PAPER 11 From: "Gopal Parameswaran" To: egs+summary@cs.cornell.edu Cc: gp72@cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal CoDoNS This paper describes the CoDoNS system that is a peer to peer network for Domain Name Systems used on the Internet for address translations to increase performance and resilience to Denial of Service Attacks and faster propagation of updates. This network is based on the Beehive system that implements an effective replication policy based on choosing different levels of replication based on different objects and their usage. Thus by placing cached copies one level up in the lookup the number of hops required can be reduced by one at each level. Thus choosing different levels for different objects based on certain criteria helps in reducing the latency for a query. AS can be seen from the graphs initially as the system starts up the latency is high compared to traditional DNS systems but then as more and more objects are replicated with each request the latency of the system decreases as more cached copies are returned at higher levels in the system and thus reducing the number of hops and latency. The gain in latency is very high and the median latency is around 2 milliseconds compared to around 39 milliseconds for conventional DNS systems. This system uses public key cryptography to ensure security of the resources and the certificates are used for data verification between servers. Serving DNS using a Peer-to-Peer Lookup Service This paper also discusses the implementation of a DNS system that is based on an underlying peer to peer system though the underlying system in this case is based on Chord unlike beehive in the other paper. The authors states that their systems performance for DNS lookup is worse than the conventional lookup by about 10 times they claim that their lookup is better for searches with high latency and that all their queries would succeed. This approach seems to suggest a very underperformed system that is good for only the worst cases. From asg46@cornell.edu Thu Mar 2 11:23:57 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22GNut12047 for ; Thu, 2 Mar 2006 11:23:56 -0500 (EST) Received: from webmail.cornell.edu (hermes21.mail.cornell.edu [132.236.56.20]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k22GNs5c025383 for ; Thu, 2 Mar 2006 11:23:55 -0500 (EST) Received: from 128.84.98.90 by webmail.cornell.edu with HTTP; Thu, 2 Mar 2006 11:23:55 -0500 (EST) Message-ID: <1440.128.84.98.90.1141316635.squirrel@webmail.cornell.edu> Date: Thu, 2 Mar 2006 11:23:55 -0500 (EST) Subject: paper 11 - DNS From: "Abhishek Santosh Gupta" To: egs+summary@cs.cornell.edu User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal SERVING DNS USING PEER-TO-PEER.. the authors point out to various flaws in the current DNS system: 1) malicious people can impersonate DNS servers as IP addresses can be forged 2) most common name server problems are configuration errors ( appx 35% of queries suffer due to incorrect configurations) 3) the root serves as a single point of failure and attack (especially DoS attacks) the authors suggest serving DNS data over the chord network thereby eliminating the concept of a root server. This provides better robustness against Dos attacks. BASIC IDEA : separate the authentication of data from the the service of that data the paper discusses DNSSEC mechanisms which use public-key cryptography for signing resource sets. Each resource set is signed with the public key for the enclosing domain (until the root is reached). DDNS stores and retrieves resource record sets using Chord-based distributed hash table. Verifying a DNS RRSet for a name with n path elements requires n KEY lookups. in order to address this problem the authors allow the owner to present additional relevant KEYs in the RRSet. KEYs for popular resource sets can be omitted to decrease size of response based on the assumption that it would be widely cached. the authors themselves state that their system has significantly higher latencies and other disadvantages in comparison with conventional DNS. the O(log N) lookup time is not appreciable for latency critical applications like DNS. Accepting a system which is slower than the current system (DNS needs appx 2RPCs) would be another social aspect to overcome. low-latency P2P applications will also suffer due to the high latency of this new system. Chord performance gets worse in case of malicious nodes which may choose to be alive but not respond or simply forward incorrect information. DNS USING BEE-HIVE the authors point to the load imbalance due to the skewed distribution of names under popular domains. they point to the dilemma of choosing a TTL for cached records in legacy DNS systems. BEE-HIVE: it places copies of the object at all nodes nodes one hop prior to the home node in the request path, reducing the lookup latency by one hop. it minimizes the total number of replicas subject to the constraint that the aggregate lookup latency is less than a desired constant. ( object frequencies being updated every aggregation interval) OTHER DETAILS: in order to allow the CoDoNS to gradually grow into a globally recognized system, the authors have incorporated compatibility to the legacy DNS. NXDOMAIN responses are cached temporarily to preserve the capacity of the system. FLASH-CROWD EFFECT: represents the worst case for CoDoNS. graphs show a temporary increase in the median latency for flash-crowd effects. it takes appx 7 hours to achieve normal latency times. the churn for a look-up system should be low and bee-hive performance is very good for systems with low churn. From ryanp@cs.cornell.edu Thu Mar 2 11:25:44 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from exchfe1.cs.cornell.edu (exchfe1.cs.cornell.edu [128.84.97.27]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22GPit13029 for ; Thu, 2 Mar 2006 11:25:44 -0500 (EST) Received: from exchfe2.cs.cornell.edu ([128.84.97.34]) by exchfe1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 11:25:44 -0500 Received: from [128.253.211.203] ([128.253.211.203]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Mar 2006 11:25:43 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <6B4AA970-CDE3-4E0F-BBCF-1592C931F420@cs.cornell.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Gun Sirer From: "Ryan S. Peterson" Subject: PAPER 11 Date: Thu, 2 Mar 2006 11:25:45 -0500 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 02 Mar 2006 16:25:43.0674 (UTC) FILETIME=[F412B5A0:01C63E15] After repeated attempts to send this to egs+summary last night and this morning, the mail server refuses. Says egs+summary is an invalid user... This week we explore the issue of DNS, which currently exists as a centralized hierarchical entity with several limitations. Cox, et al. notes that most DNS traffic is caused because of faulty or misconfigured name servers, suggesting that a less error-prone solution is in order. The authors implement a name server on top of Chord, a peer-to-peer DHT. Using a DHT to serve names improves DNS by reducing errors due to configuration problems, providing better load balancing, and defending against DoS attacks. The paper focuses on separating DNS record validation from the lookup algorithm, as is true with today's DNS service. However, the author's conclude that using Chord is a worse solution because of its O(log n) lookup time, and propose that researchers investigate more efficient ways for serving DNS requests in a distributed manner. Rama and Gun take the MIT guys' challenge with a system called CoDoNS. CoDoNS is a DNS service implemented on top of Beehive. Beehive is a ring-based peer-to-peer system that proactively replicates objects based on their popularities, which studies have shown follow a Zipf power-law distribution for DNS and many other types of queries. If enough institutions around the world dedicated one or two nodes, they could become part of a new decentralized DNS service with load balancing and, unlike the MIT guys' approach, average constant record lookup time. In order to validate entries in the system, each entry can use public key cryptographically for authentication, separating authentication from entry lookup. As an added benefit, the authors add support for slowly introducing CoDoNS into common use, or else using legacy DNS as a safety net for CoDoNS. When a lookup reaches the home node (where home node is defined as in Beehive), if the home node does not contain the entry, it can send a legacy DNS query and forward the response back to the client. Thus, CoDoNS offers the load balancing properties and other benefits of other distributed DNS systems, but is practical for use in the real world because of its efficient lookup times. Ryan From asr32@cornell.edu Thu Mar 2 11:31:09 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from authusersmtp.mail.cornell.edu (granite1.mail.cornell.edu [128.253.83.141]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22GV9t14541 for ; Thu, 2 Mar 2006 11:31:09 -0500 (EST) Received: from dreadnought.cornell.edu (r253240123.resnet.cornell.edu [128.253.240.123]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k22GV8op001900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Mar 2006 11:31:08 -0500 (EST) Message-Id: <6.2.1.2.2.20060228214208.02fbc128@postoffice8.mail.cornell.edu> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 02 Mar 2006 11:29:06 -0500 To: egs+summary@cs.cornell.edu From: Ari Rabkin Subject: PAPER 11 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed DNS using Peer-to-Peer lookup: The authors attempted a more-or-less naive implementation of DNS via a distributed hash table (built on Chord). They measured the performance of their system, and showed that it increased average latency by over a factor of 8. Moveover, their system does not support any of the more interesting uses of DNS, such as dynamic server choice. They conclude that something much more clever would need to be done to support DNS via a distributed hash table. It seems as though the authors were setting themselves up for failure. Chord is by no means the best available DHT for performance, and the caching system their system implemented was not designed for this specific problem. Showing that the most naive implementation imaginable performed poorly does not provide strong evidence that moderate optimization might not have improved performance drastically. As the CoDoNS result shows, using a DHT with better caching performance can greatly alter the conclusion. Next Generation Name service [CoDoNS] The CoDoNS authors first demonstrate that the current domain name system has serious architectural flaws. The TTL based caching and hierarchical resolution is inflexible, concentrates load at the root, and performs badly with dynamic server selection. Moreover, DNS servers are often configured badly, suggesting that the process should be automated to reduce human error. The authors suggest using Beehive to ensure O(1) lookup. (In fact, they suggest sufficient replication that the expected number of hops per lookup is .5 -- that is, half the queries will hit the cache immediately. The system should thus give reliable and flexible resolution for DNS queries--all without breaking existing clients. They ensure trust by leveraging existing work on DNSSEC; essentially replacing the DNS server hierarchy with a public key hierarchy. One of the consequences of using Beehive/Pastry is that the home node for a given DNS record might be located at some distant server on the internet. This is doubtless upsetting to IT staff, as well as a likely performance penalty. The authors propose to handle malicious servers by using the Castro et al secure routing algorithm; this seems both excessively costly, and possibly inadequate. A malicious home node might return NXDOMAIN messages for a live domain name; to prevent this, every query would need to use the Castro algorithm (or at least every query that didn't return a valid domain name record). Ari Rabkin asr32@cornell.edu Risley Hall 454 3-2842 The resources of civilization are not yet exhausted. --William Gladstone From sh366@cornell.edu Thu Mar 2 11:53:12 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from postoffice10.mail.cornell.edu (postoffice10.mail.cornell.edu [132.236.56.14]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22GrCt21295 for ; Thu, 2 Mar 2006 11:53:12 -0500 (EST) Received: from orpheus3.dataserver.cornell.edu (orpheus3.dataserver.cornell.edu [128.253.161.167]) by postoffice10.mail.cornell.edu (8.12.10/8.12.6) with ESMTP id k22GrA2A017043 for ; Thu, 2 Mar 2006 11:53:11 -0500 (EST) Message-ID: <1153761301.1141318390248.JavaMail.webber@orpheus3.dataserver.cornell.edu> Date: Thu, 2 Mar 2006 11:53:10 -0500 (EST) From: Huang Shiang-Jia To: egs+summary@cs.cornell.edu Subject: PAPER 11 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: uPortal WEB email client 3.0 Current DNS confronts a lot of problems, many of which can be solved with the properties of fault tolerance and load balance in peer-to-peer systems. Among the two works to be discussed today, DDNS concludes that a naive application on top of DHT is inadequate to provide name service due to its high latency, while CoDoNS solves this problem by its proactive caching layer: Beehive, and provides fast update propagation in addition. Problems of current DNS: * About 80% domains set up only two or one name server, and 32% name servers are connected to Internet through a single gateway or router. They can be disabled by small-scale attacks. Name servers on top levels of the hierarchy and those for popular domains are easily subject to denial of service attacks. * Its hierarchical structure implies more loads on servers at higher levels than lower levels. * 35% of DNS queries never receive an answer or a negative answer. Many of them are caused by configuration errors. * 40% DNS records have TTLs of one day or more. Cache coherency can't be guaranteed and unanticipated changes can't be fast disseminated. Serving DNS provides better load balance since the concept of root servers is eliminated. Due to its nature of decentralization, attackers have to take down a set of servers to make the records unavailable. Each name owner is responsible for the correctness of its records. No sub-domain delegation is needed. One important feature to support DNS using DHT is the "separation of name resolution from verification in DNS" (DNSSEC). It enables the exploration of alternative storage and lookup systems for DNS records. * DDNS is designed on top of Chord. All the properties of DHT remaining the same, the only shortcoming of DDNS compared with DNS is its lookup latency. * CoDoNS achieves low lookup latency by its proactive caching layer, Beehive. Other contributions of CoDoNS include its remarkable resilience to denial of service attacks and quick propagation of record updates. * The implementation of CoDoNS provides an incremental deployment path. It can serve as a supplement as well as a complete replacement for the legacy DNS. * A client sends a query to its local CoDoNS server. The CoDoNS server replies immediately if it has a cached copy of the record. Otherwise, it routes the message within the system according to Pastry's protocol. The routing terminates either at a node that has a cached copy or at the home node of the record. If the home node has no this record, it retrieves it from the legacy DNS and respond to the CoDoNS server which replies to the client. In the background, CoDoNS proactively replicates records according to their measured popularity. * Direct caching and negative caching are supported in CoDoNS. * CoDoNS is particularly resilient to denial of service attacks because (1) hotspots have more replicas in Beehive's replication framework; (2) Beehive quickly detects changes of access to records and spreads replicas among more nodes in the occurrence of denial of service attacks. * Selection of a suitable TTL value is a dilemma in DNS. Long TTL makes it difficult to maintain cache consistency. Short TTL decreases the cache hit ratio and increases the lookup overhead. In CoDoNS, the home node stores the record according to the TTL specified by DNS. Once expired, it re-fetches the record from DNS and propagates if the record is updated. The analytical model of Beehive is applicable to DNS workload since it follows a Zipf-like distribution. * The experimental results show that the median lookup latency of CoDoNS is lower than that of the legacy DNS. Besides, 98% of the replicas are updated within one second even for level-0 records in CoDoNS. Relocation of services can therefore be disseminated quickly. One feature of DNS that can't be replaced so far is the "dynamic name resolution". The name server prompts different mapping according to the status (loads or failures) of its application servers or to route clients to nearby servers. CoDoNS forwards queries to the domain name that implements this feature to its legacy DNS server. From km266@cornell.edu Thu Mar 2 11:54:00 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from authusersmtp.mail.cornell.edu (granite1.mail.cornell.edu [128.253.83.141]) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22Gs0t21429 for ; Thu, 2 Mar 2006 11:54:00 -0500 (EST) Received: from KEVSTOY (cpe-69-207-37-68.twcny.res.rr.com [69.207.37.68]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id k22Grxix028319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 2 Mar 2006 11:53:59 -0500 (EST) Message-ID: <000501c63e19$e736a360$4425cf45@KEVSTOY> Reply-To: "Kevin" From: "Kevin" To: Subject: PAPER 11 Date: Thu, 2 Mar 2006 11:53:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Serving DNS using a Peer-to-Peer lookup system a look at many of the problems the current DNS system has and tries to fix it using a p2p network. The problem with their approach is that they broke a lot of good things current DNS has going for it. The paper talks extensively about the misconfiguration of current DNS servers and how difficult it is to get them correct. The claim is that a DHT based p2p system will be able to scale better and provide far more security due to less misconfiguration. The protocol they use signs messages received from the CHORD implementation (which is log[2](n) unlike pastry and others which are log[16](n)) to verify security. For the sake of latency, one node sends out multiple RRSets with its response in order to cut down on lookup time. The system uses passive caching along the path the message traveled (this is where CoDoNS comes in to help) but this does not help latency. Another problem the paper fixes with current DNS is the slow response time of servers to update their entries: because of the caching scheme they currently use, entries might not be updated for days. In the end, the system is significantly slower than current DNS. The problem they are trying to solve is security (by not having a single point of failure) and stability but they crippled the system's responsiveness, basically making it unusable (taking the average DNS response time up over 7x). Furthermore, it seems odd that they are writing a paper to say that stability is a problem because of a software issue. Either new software needs to be written or an easier way to manage it needs to be thought up, switching over to a p2p infrastructure does not make total sense just for stability. CoDoNS ([Co]operative[Do]main[N]ame[S]ervice) uses a Pastry network with Beehive active replication in order to speed up delivery of content. Using beehive makes it possible to have sub-1 hop average lookup times, significantly decreasing the latency of the p2p content delivery. As a matter of fact, in their tests on PlanetLab, CoDoNS gets better performance than the current DNS system. The system therefore fixes many things wrong with current DNS: single point of failure is no longer a problem. Latency is less of an issue with the reduced lookup times and more active caching. Flash crowds and popular nodes are handled (load balanced and locally cached) quickly. Security is handled by DNSSEC, signing records that are sent out can be verified without even needing to keep public keys online. The only issue I see is the question of motivation at this point. Would ISPs and others want to switch their current systems over to a CoDoNS system. Free loaders would be an issue with this system (although solvable). From kelvinso@gmail.com Thu Mar 2 11:55:54 2006 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on sundial.cs.cornell.edu X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Level: Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196] (may be forged)) by sundial.cs.cornell.edu (8.11.7-20031020/8.11.7/M-3.22) with ESMTP id k22Gtrt22274 for ; Thu, 2 Mar 2006 11:55:53 -0500 (EST) Received: by wproxy.gmail.com with SMTP id i3so698983wra for ; Thu, 02 Mar 2006 08:55:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Eyh0oCOEataWAitwP30JcteP4E9xImAFJvWGUPkZZC6fyezFQzVjAFijxd18itMGMNd0R2kjqOH7IlI3qxnK3aaqxixOjum+VE9jTQDytl1XsqrXVbAG8YDWpKhFMPKIZePx3PIzJwuFC6LRun6JHk1BEzWDPyrCpY8w8kF2kMU= Received: by 10.54.151.7 with SMTP id y7mr1165620wrd; Thu, 02 Mar 2006 08:55:53 -0800 (PST) Received: by 10.54.81.5 with HTTP; Thu, 2 Mar 2006 08:55:53 -0800 (PST) Message-ID: <6e1ca4560603020855x300390h34b4c84cf4a42b9f@mail.gmail.com> Date: Thu, 2 Mar 2006 11:55:53 -0500 From: "Chiu Wah Kelvin So" To: egs+summary@cs.cornell.edu Subject: Paper 11 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id k22Gtrt22274 The DNS uses hierarchical structure, and it is partitioned into non-overlapping region called domains. DNS delegates the responsibility for each domain to a set of replicated nameservers. It passively caches the result in server with a TTL corresponded to it. There are many existing problems in the current DNS implementation. Name servers are difficult and time-consuming to administer. Loads are imbalance across servers and are frequently subjected to Dos attack because of its hierarchical structure. They are not resilience to attack and failure. Also, because it maintains passive caching in DNS and it does not know where all the copies are, it is difficult to propagate updates. The two papers talk about how to build peer-to-peer DNS service which solves some of the problems in the existing DNS. The first paper, "Serving DNS using a Peer-to-Peer Lookup Service," presents a domain name system, DDNS, which built on top of a DHT. It uses Chord as underlying DHT to store record, which is a mapping between name and ip. Therefore, it inherits the fault tolerance and load balancing properties in DHT. It uses DNSSEC which separates the authentication of data from the service of that data. DNSSEC uses public key to sign each record. It also removes the administrative problems because of its flat namespace. There are many advantages using the peer-to-peer DNS, but this paper also presents some of the limitation of DDNS. Because of the heavy tail of query distribution, unpopular contents will take up to log(n) number of hops to reach the record. Their experimental result shows that median latency of lookups in DDNS take about 350ms while conventional DNS's is about 43ms. Although this paper does not address how to overcome the limitation of peer-to-peer DNS, the next paper shows how to achieve low lookup latency in peer-to-peer DNS. The second paper, "The Design and Implementation of a Next Generation Name Service for the Internet," also presents a peer-to-peer DNS, coDoNS. coDoNS is built on top of Pastry and Beehive. Because of the Zipf-like query distribution in DNS, Beehive can efficiently and proactively replicate records to optimal number of peers to achieve low latency according to each record's popularity. At the same time, home node of a record knows where all the replicas are, therefore it can efficiently prorogate update to all the replicas. In order to compatible with the legacy DNS, coDoNS uses legacy DNS to resolve queries for records not explicitly inserted by name owners. Using proactive caching, coDoNS achieves a lot lower latency with median lookup latency of 2ms while median lookup latency in legacy DNS is 39ms. There are also other problems in peer-to-peer DNS. Because the domain names are served from other servers instead of the server which owns the responsibility of the domain names, servers have less incentive to serve the content.