CircleID

Paul, do you think peer-to-peer naming systems, such as distributing signed DNS records using a distributed hashtable (DHT), will ever work?  The Chord folks have done a great deal of work on this topic. 

By the way, I should add that these signed records could establish a binding between any arbitrary string, such as domain name like "www.cnn.com" or a phone number like "510-235-2234", and any arbitrary address/endpoint, such as an IP address or possibly a public key.

Sorry to be a pain, but: is 10.0.01 an IP address, I thought that current IP had 4 numbers. Also, I thought that 10.0.0.1 (which I presume is intended) was reserved for private addressing (local networks, etc.) and so couldn't point to an internet address (as in your example).

I'm probably wrong, which is worrying me as I thought I knew a little about this, you are after all the one writing the articles!

How is the preceding zero formatted to hex?

I have heard of the Chord stuff, but haven't had time to look into it - sounds like the kind of thing I'd like, but the IETF might frown on.

If you have a good reference, I'd appreciate it!

Sorry, I did indeed mean "10.0.0.1", which is a private address, but I'd disagree that it is inappropriate as an example, since I believe that most of the DNS is behind firewalls these days.

This comment is in two parts, as there is a 2500 character limit on comments.

Hi Paul; thanks for responding.  There is a WikiWiki with a good introductory page on distributed hash tables (DHTs) at http://www.infoanarchy.org/wiki/wiki.pl?Distributed_Hash_Table
This page gives an overview and then provides further references to research projects that have implemented different kinds of DHTs, such as Chord, Pastry, Kademlia, etc.

As an example of how powerful DHTs can be as a generic naming substrate, see the open-source project named The Circle at http://thecircle.org.au/ . This application uses a DHT for several uses: to share files, to send instant messages and IRC-style chatting, and for putting together a personalized news service.

Here are some other things to see.  I run a project named P2P Sockets that includes a simple, non-secure distributed DNS.  While it doesn't currently use a DHT (it uses another open-source project named JXTA as its P2P substrate), I plan on transitioning to a DHT in the near-future.  See it at http://p2psockets.jxta.org

The original paper concerning storing DNSSec records in Chord is available at http://www.pdos.lcs.mit.edu/chord/papers/ddns.pdf

Here is the second part to my previous comment; a third part follows.

There has been a great deal of activity both at the grass-roots, open source level and at the academic level in these systems the last few years.  While I don't believe technical solutions can always solve social and political issues, I do believe that an alternative technical approach to the DNS can help ameliorate these problems.  P2P/DHT-based approaches might point the way to such a solution.

There are several significant research issues that must be resolved before this is possible, though.  These are latency, DoS-style attacks on such a substrate, reliability of the naming records, and how to achieve secure name bindings while also ensuring human-friendly names.

The first issue, latency, seems to be disappearing as newer DHT algorithms are developed.  The second issue is DoS-style attacks.  If we go with a First Come/First Served (FCFS) system for handing out naming bindings, which removes DNS-style registrars from the loop, then assailants can programatically exhaust the namespace by simply grabbing names.  While a FCFS system is attractive because it removes the need to have gatekeepers handing out names, it does open this problem.  One way to solve this is to retain DNS registrars who sign but do not store DNS records; DNS records are stored in the P2P substrate using the DNSSec standard.  If a DNS registrar detects that another peer is attempting to DoS it, it can cut it off.  Of course, this doesn't protect against distributed DoS attacks, where many peers in the network might be compromised and requesting names.  We might have to introduce some "friction" into the system, such as money or hashcash (i.e. clients have to provide a proof that they ran some computationally-heavy algorithm).

The third issue is reliability of the naming records.  Chord has its own solution to this problem, as does the OceanStore team at http://oceanstore.cs.berkeley.edu/ This is a difficult problem without an elegant solution at this point.  A good paper comparing some P2P replication schemes is at http://oceanstore.cs.berkeley.edu/publications/papers/pdf/erasure_iptps.pdf and is named "Erasure Coding vs. Replication: A Quantitative Comparison".

Here is the third part of the comment.

The final issue is to achieve secure name bindings while also ensuring human-friendly names.  The problem with achieving these two goals in a distributed, peer-to-peer system is succinctly explained in a position paper by an open-source programmer nicknamed Zooko.  This paper is titled "Names: Decentralized, Secure, Human-Meaningful: Choose Two" and is available at http://zooko.com/distnames.html . Some P2P projects have decided to simply abandon human-friendly names, instead going with secure pointers instead.  This is the approach the Freenet project has taken (http://freenet.sourceforge.net/). 

Unfortunately, these secure pointers are incomprehensible to ordinary computer users.  I think there is value in a global namespace that is human-friendly, such as the current DNS.  While I believe that Zooko is correct in identifying that you can't achieve complete decentralization, complete security, and human-friendly names at the same time, I do feel that it is possible to have both security and human-friendly names with a partially decentralized system.  The question then becomes how much can we decentralize while still retaining the other two aspects.  Perhaps we will be able to decentralize the portions of DNS that are capital intensive, such as storing records or acting as root servers.

These ideas fascinates me, so if you would like to continue this discussion feel free to email me at

Hope all is well,
Brad Neuberg

The P2P Sockets Project - http://p2psockets.jxta.org
Paper Airplane - http://www.paperairplane.us

Paul and all,

Lets not forget, Paul did not "Invent" or even do all of the development of the DNS. 

I am glad to see that Paul has finnaly come to the understanding that the DNS is changing and needs to.  However he is only 6 years behind the curve on this in process that has been ongoing sense 1998. 

The process of others adding to or building on top of the original DNS protocol has actually been going on since the early 1980s.

My point was all of the people working on these ideas today aren't working together as well as they might be.

As for who invented the DNS protocol, I'll let the RFC record speak for itself.  Anybody who reads them will recognize Francis Bacon's hand.

Paul, any comments on the DHT links I posted?

Brad

From Brad Neuberg's comment:

"While I believe that Zooko is correct in identifying that you can't achieve complete decentralization, complete security, and human-friendly names at the same time, I do feel that it is possible to have both security and human-friendly names with a partially decentralized system. The question then becomes how much can we decentralize while still retaining the other two aspects. Perhaps we will be able to decentralize the portions of DNS that are capital intensive, such as storing records or acting as root servers."

It makes a lot of sense to have a 2-stage system.

1. A mapping of completely secure, completely decentralized, but meaningless handles to IP addresses.

2. A separate mapping of meaningful names to handles.

Both stages can be implemented with DNS. The 2-stage modular design allows flexible experimentation in the mapping of meaningful names to accommodate different tradeoffs with security and decentralization.

Mike O'DOnnell