Chord Review

Serving DNS using a Peer-to-Peer Lookup Service Review
Review By: Troy Ronda

The Domain Name Service is a hierarchical mapping of names to resource
records. Host names, for example, are mapped to IP addresses. The original
technique for storing the mapping was in a centrally managed hosts.txt
file, that was distributed to all nodes. This evolved into a distributed
database; what is now known as DNS. The current DNS, in typical usage, has
an entity responsible for maintaining name records and also for serving
the records. An alternative structure proposed (and later rejected), in
this paper, is a Peer-to-Peer lookup service using Chord. In this proposed
method, called DDNS, clients will enter their data into a Chord storage
ring. This eliminates the need for an ISP to have an online and correctly
configured DNS server. DNSSEC uses public-key cryptography to sign
resource records in the existing DNS. Each record has a key signed by the
enclosing domain. In DDNS, a distributed hash table, DHash, is used to
store records. Owners, therefore, create or update their records by
preparing it, signing it and inserting it into DHash. The signature of
records is important; both DHash and the user will verify it before using
the data. The authors also give a method for transitioning from the
existing DNS to DDNS. An evaluation looks at storage balance, latency,
load balance, and client load. It shows that DDNS takes longer for lookups
than the existing DNS system. The argument for cooperative DNS centers
around freeing name owners from administrating name servers. The argument
against is the much higher latency in DDNS as compared to the existing
DNS. This is a result of peer-to-peer systems requiring too many RPCs per
lookup. DDNS is also unable to provide server-side calculations as needed
by services like Akamai.

The strength of this paper is in the novel application of peer-to-peer
distributed storage to the DNS. It presents results that show that P2P
technologies used in the paper are not sufficient. It is a negative result
but it sets the path for future research into this area. The simulation
was probably appropriate, as the most important concern for DNS is lookup
time. A large number of services rely on the mapping from names to IP
addresses. The authors are correct in stating that DDNS would make the
situation worse by increasing latency and eliminating the ability for
server-side calculations. A major incentive for the system, however, is
the increased robustness from automatically replicating resource records
in the Chord ring. This is a result of the underlying DHash automatically
storing data on a fixed number of hosts, which were chosen in a
pseodo-random fashion. As the next paper in this class shows, new
peer-to-peer technologies that reduce RPCs improve the chances of adopting
such cooperative DNS systems.

One downside to this paper was the lack of discussion (and evaluation) of
propagating changes to DDNS caches. Is it using the TTL values from the
old DNS system or does it push changes? How do higher-level names unsign
child names? How does the system prevent hosts from reintroducing old
records (if the system can even handle undelegation in the first place)?
It would be a management problem if higher-level domains could not
undelegate children. I also agree that providing incentives for people to
host cooperative DNS is slim. It would probably take a major failure of
DNS, such as another massive DoS attack on the root servers, to get the
ball rolling. A cooperative DNS system still has the problem of requiring
configuration. A client host must still know of a server in the Chord
ring. The main problem, however, is the large number of lookups required
by the technique. The major benefit of robustness does not outweigh the
increased latency, in this case. The system does not provide all of the
current capabilities of DNS. It will be impossible to convince companies
like Akamai to move to this system. Finally the authors were not able to
conduct an empirical study to show that the trace simulation indeed shows
correctness. In fact, they did not really explain the traces except to
give their source.
Received on Thu Nov 10 2005 - 10:35:37 EST