Why peer-to-peer naming is difficult

| Comments (7) | TrackBacks (1) |
There's been a fair amount of buzz going around about peer-to-peer (P2P) naming as a replacement for the DNS. Here's one example a recent Slate article:
The best solution might simply be to allow any country that wants the job to host the DNS system. How? Peer-to-peer networks like BitTorrent.

Here's how it could work, according to computer security researcher Robert G. Ferrell, a former at-large member of ICANN. Countries that choose to house Torrent servers would receive a random piece of the DNS pie over a closed P2P network, with mirrors set up to correct data by consensus in the case of corruption or unauthorized modification. No one country would actually physically host the entire database. In essence, everybody would be in charge, but no one would be in control. Isn't that how the United Nations functions anyway?

I can't find a detailed writeup for this proposal, but in general it's hard to replace a distrubuted but hierarchical system like DNS with a purely P2P system.

A name resolution system is basically a method of mapping one set of strings onto another set of strings. You start with a string A and get the string B that it maps to. Obviously this is easy if you have a single server that holds the whole mapping table, but this isn't really practical on the Internet, where you want a distributed system.

Any distributed name resolution system has to deal with two separate issues:

  • Data distribution.
  • Authorization.

Data distribution is a relatively well understood problem. It's the kind of thing that P2P networks are good at. Authorization isn't so simple. How do we know, for instance, who is entitled to have "educatedguesswork.org"? In the DNS, it's easy: the server which has the data for ".org" also has the authority to tell you who owns "educatedguesswork.org". Even when you don't get the data directly from the authoritative server (e.g., from a cache), authority still descends from that server (in DNSSEC, that server signs the data and it gets placed with the secondaries).

P2P systems, however, break the binding between authority and the source of the data, and when you get the record for "educatedguesswork.org" from some random site, you don't have any reason to trust it. Of course, you could use signed DNSSEC records and then store them in a P2P network (as described here), but that doesn't really solve the problem that people are complaining about, which is centralized control. Using DNSSEC with P2P just means that the data is distributed, but the authorization is still centralized, so this wouldn't make it any harder for the US to control things.

What people really want, of course, is decentralized control. Unfortunately, building a system like that is currently an unsolved problem.

1 TrackBacks

Listed below are links to blogs that reference this entry: Why peer-to-peer naming is difficult.

TrackBack URL for this entry: http://www.educatedguesswork.org/cgi-bin/mt/mt-tb.cgi/487

7 Comments

BitTorrent is, in fact, one of the best examples of why doing distrubtion using P2P doesn't solve the authorization problem. Anyone who has set up a torrent (not just served one or participated in a mesh) knows that. The fact that bad torrents are also commonly put into torrent search services as a way of discouraging content sharing is another good reason this analogy should give us pause; sure a closed p2p network might be able to avoid that, but that means almost everyone is on the open part, getting their data the same old way. And the question of who gets to be part of the closed network gets added to who gets to decide what data goes in what zone....


There are reasonable systems for assigning names without global hieirarchies, but they rely on a properties that ensure
that the resulting identifiers are not human-friendly. That is, they use big, near-random strings that are unlikely to collide and then set up mechanisms to handle what collisions do occur.


Those aren't replacing the DNS any time soon.

Also, structured P2P programs are very vulnerable.

EG, its still an unsolved problem to do the following in a conevntional (eg, Chord) DHT:

Find data associated with key K if data exists in the presence of some malicious nodes. Just a couple of malicious nodes can really selectively fubar DHT routing.

These are all good points, but I think the whole thing breaks at the resolution step. Just what is the resolution algorithm? 1) randomly ask any TLD server. 2) if it has no answer, repeat step 1 until all ~250 servers have been asked, and then you know the name doesn't exist.

I'm not sure I understand your point, Grumpy.

I'm sure you understand the DNS resolution algorithm better than I do, but as I understand it, if you ask an authoritative server for a given domain and you get an NXDOMAIN, then you know the data's not there.

Or are you talking about resolution in P2P systems? In DHT systems, for instance, it's quite clear which server ought to have the data, modulo the security issues raised by Nick.

Well, I was responding to the bit about the DNS resolution side, not the data distribution side. I'm not aware of any DNS mechanism that allows lateral referals. As far as I can guess, the only way to do this with DNS is for the authoritative servers to not answer at all if they don't have the answer (as opposed to RCODE 3), causing the resolver to try another of the 13 authoritative servers.

Of course, if we're talking some protocol other than DNS, well then that's a different story. And if we have ICANN board members talking of replacing DNS, that explains quite a lot about ICANN.

Sorry, I still don't think I understand what system you're envisioning. The idea here is to use soemthing that's not DNS, but probably more like Chord.

And I think Ferrell is ex-ICANN board.

"The idea here is to use soemthing that's not DNS, but probably more like ..."

Exactly!

Leave a comment