review of Chord DNS

From: Guoli Li <gli_REMOVE_THIS_FROM_EMAIL_FIRST_at_cs.toronto.edu>
Date: Wed, 9 Nov 2005 20:02:52 -0500

This paper discusses the DDNS system, which provides DNS service based on
Chord. The conventional DNS server maintains naming information and
responses the queries of its data at the same time. This makes the
conventional DNS vulnerable to denial-of-service (DoS) attacks. With the
increasing hosts and users in the Internet, some DNS servers may be
overloaded. The imbalance is because of the hierarchical server structure.

With the growth of Internet and new p2p techniques, cooperative DNS is
proposed to replace the hierarchy, for example, the DDNS. DDNS uses a
peer-to-peer Chord-based distributed hash table to manage DNS records.
Routing information is maintained automatically by Chord. Chord also
provides a better load balance on query workload and robustness against
DoS. The properties of the p2p system, such as scalability, load
balancing, self-organizing, and fault tolerance, benefit the DNS
application.

However, the evaluation shows that DDNS has a higher latency than
conventional DNS. The main reason is more RPCs are needed per lookup.
Proactive caching technique can be used here to improve the look up
latency. The basic idea is to cache objects one or more hops earlier than
the original node. CoDoNS uses this approach. Its results show the latency
is highly improved.

The workloads used in DDNS evaluation do not convince me. It is not clear
to me why the workloads are splits into successful queries and
unsuccessful queries. Caching is useless for the unsuccessful trace
because no query will find a cached copy. It is better to use a real
workload to show the performance. The Slashdot test, obviously, makes the
record cached at every peer, which makes later request successful at the
first node. It is better to use a workload following Zipf-like
distribution.
Received on Wed Nov 09 2005 - 20:03:06 EST

This archive was generated by hypermail 2.2.0 : Wed Nov 09 2005 - 20:39:56 EST