review of CoDoNS

This paper presents the architecture and implementation of Cooperative
Domain Name System (CoDoNS). Current DNS is vulnerable to denial of
Service attacks (DoS) because of limited redundancy in name servers and
overloaded gateways. The caching prohibits the frequent DNS updates. The
low cache hit rate degrades the performance of traditional DNS systems. A
new DNS system should provide three properties: high performance,
resilience to attacks, and fast update propagation.

The proposed CoDoNS system takes advantages of new technologies:
structured peer-to-peer overlays and proactive caching. CoDoNS resolves
DNS queries on a p2p overlay network based on Beehive, which is a
proactive replication framework. It decouples namespace management from
query resolution. Beehive manages the namespace using a prefix-matching
DHT. To speed up the lookup latency, Beehive places replicas of objects
one hop (or more) earlier than the original node according to the level of
replication. The replication is performed by analyzing the workload, e.g.
Zipf-like distributions.

DNS query issued by client is routed to local CoDoNS server first. The
local server replies if it caches a copy of the request. Otherwise, the
query is routed using the DHT provided by Beehive. If the query cannot be
answered by CoDoNS, the home server will access the current DNS server for
help. It is a good idea to provide an interface with current DNS system,
since it is hard and impractical to replace the whole DNS overnight. The
evaluation results show that CoDoNS can provide low latencies for query
resolution, because the routing latency inside Beehive is optimized by the
proactive caching. The new DNS approach benefits from DHT in terms of
scalability, self-organization, and load balancing, etc.

However, The CoDoNS depends on the operation of under-lying DHT. The DHT
should provide stable lookup services and maintain the consistency of
routing and caching information.

The lower latency is gained from the performance penalty of storage and
bandwidth overhead. Beehive needs to maintain the replication status
periodically. The penalty depends on how often a replication phase is
invoked in Beehive. Moreover, there is an unstable phase while the p2p
overlay is building up, in which less peers in the overlay and less query
caches. Queries issued at this stage may suffer a longer latency. Better
latency is gained when the overlay is stable, that is, node insertion and
departure are almost the same. Highly dynamic node changing also affects
the performance of lookup.
Received on Wed Nov 09 2005 - 20:01:46 EST