Traditional DNS-related research has focused on the problems in the server-side DNS infrastructure. As a seminal study in DNS measurement, Danzig et al. found that a large number of network packets were being wasted due to DNS traffic, blaming nameserver software bugs and misconfigurations as major culprits [5].
Since then, bugs in the resolvers and nameservers have been reduced [12], but recent measurements show that there is still much room for improvement. In 2000, Wills et al. [24] and Huitema et al. [7] reported 29% of DNS lookups take over 2 seconds, and Cohen et al. [3] reported 10% of lookups exceed more than 3 seconds. Jung et al. also present data indicating 23% of all server-side lookups receive no results, indicating the problems of improper configurations and incorrect nameservers still persist [9]. They measure the client-side performance in terms of response time and caching hit ratio as well. However, that work does not trace the origins of name lookup delays from the client-side, concentrating only on the wide-area DNS traffic. Given the fact that local nameserver cache hit ratios are 80% - 87% [9,24], even a small problem in the local nameserver and its environment can skew the latency of a large number of lookups. Our study addresses this problem. Liston et al. indirectly provide some evidence of local nameserver problems by attributing the major sources of response time delay to end nameservers rather than the root/gTLD servers [13].
The research community has recently renewed its focus on improving server-side infrastructure. Cox et al. investigate the possibility of transforming DNS into a peer-to-peer system [4] using a distributed hash table [21]. The idea is to replace the hierarchical DNS name resolving process with a flat peer-to-peer query style, in pursuit of load balancing and robustness. With this design, the misconfigurations from mistakes by administrators can be eliminated and the traffic bottleneck on the root servers are removed so that the load is distributed over the entities joining the system.
In CoDoNS, Ramasubramanian et al. improve the poor latency performance of this approach by using proactive replication of DNS records [18]. They exploit the Zipf-like distribution of the domain names in web browsing [2] to reduce the replicating overhead while providing O(1) proximity [17]. Our approaches differ in several important aspects - we attempt to reduce overlapping information in caches, in order to maximize the overall aggregate cache size, while they use replication to reduce latency. Our desire for a small process footprint stems from our observation that memory pressure is one of the causes of current failures in client-side infrastructure. While their system appears not to be deployed in production, they perform an evaluation using a DNS trace with a Zipf factor above 0.9 [18]. In comparison, our evaluation of CoDNS uses the live traffic generated by CoDeeN after its proxies have used their local DNS caches, so the request stream seen by CoDNS has a Zipf factor of 0.50-0.55, which is a more difficult workload. We intend to compare the live performance of CoDNS versus CoDoNS when the latter system enters production and is made available to the public. In any case, since CoDNS does not depend on the specifics of the name lookup system, we expect that it can interoperate with CoDoNS if the latter provides better performance than the existing nameservers at PlanetLab sites. One issue that will have to be addressed by any proposed DNS replacement system is the use of intelligent nameservers that dynamically determine which IP address to return for a given name. These nameservers are used in CDNs and geographic load balancers, and can not be replaced with purely static lookups, such as those performed in CoDoNS. Since CoDNS does not replace existing DNS infrastructure, we can interoperate with these intelligent nameservers without any problem.
Kangasharju et al. pursue a similar approach to reducing the DNS lookup latency by more aggressively replicating DNS information [10]. Inspired by the fact the entire DNS record database fits into the size of a typical hard disk and with the recent emergence of terrestrial multicast and satellite broadcast systems, this scheme reduces the need to query the distant nameservers by keeping the DNS information up to date by efficient world-wide replication.
The difference in our approach is to temporarily use functioning nameservers of peer nodes, separate from the issue of improving the DNS infrastructure itself. We expect that benefits in improving the infrastructure ``from above'' will complement our ``bottom up'' approach. One advantage of our system is that misconfigurations can be masked without name server outage, allowing administrators more time to investigate the problem.