At some level, the P2P DNS is a kneejerk reaction against arbitrary revocation of names by DNS registries. If registries cannot be trusted, we should replace them by a distributed system, which presumably would be impervious to interferences. Laudable goal, but that does not necessary mean that if people to rush and register P2P DNS names as soon as something like that is designed and the software available. Not all designs succeed!
Dave Thaler and Bernard Aboba discuss many aspects of protocol design in RFC 5218 “What Makes for a Successful Protocol?” They compare many successful and not-so-successful designs, and look at what characterizes wild success, mild success and failure. This is a very good read, and it can certainly inform the designers of a P2P DNS service.
The first rule of success is obviously to fulfill a need. Ideally, the design enables new applications or new services. In the case of the P2P DNS, the need is not entirely obvious. Web sites today use “classic” DNS, and are quite satisfied. Activists and architects may be concerned by the centralized nature of registration authorities, but few users actually experience the failures. The registration fees are low enough that most users don’t feel an urgent need to protest. This does not bode very well for the future P2P DNS, unless the service somehow provides extra value over regular DNS.
Other rules of success include ease of deployment, good scaling properties, and absence of security issues.
The classic DNS is rather easy to deploy. To be successful, P2P DNS will need to be as easy to deploy or maybe even easier. A web site should be able to create or register a P2P DNS name without hassle. Whatever software is required should be easy to install and configure. Ideally, the design should be such that installation requires little more than typing the desired name. If users have to craft arcane configuration files, the service will never become popular.
Ease of deployment also means compatibility with existing applications. Internet users should be able to click of a “P2P URL” from their regular web browser, and the name should resolve to an address just as fast and reliably as any “.COM” name. If it did not, web site managers would have a strong reason to not use the P2P domain. In practice, that means interconnection between P2P and regular DNS through a set of publicly available gateways. This is a difficult issue to solve, as deploying gateways is often a thankless task.
The DNS design has scaled to millions of names. P2P designs can certainly support the same scale. They may in fact scale better that DNS if one considers latency. DNS achieves scaling by resorting to hierarchies and caches. P2P system can use distributed algorithms to spread the load, and may not need to rely quite as much on caching. This may be an advantage for P2P deployments, but if will probably be a rather minor one, not enough to convince site administrators to use “.P2P” rather than “.COM.”
The DNS does have some “interesting” security issues. A P2P DNS could probably be made more secure than regular DNS, because it is less concerned with compatibility with the installed base. P2P DNS can remain compatible with regular DNS if it supports the same name format and record types, but it could do that with a different query protocol and solve many of the current DNS issues. Good security may be a sufficient advantage to attract at least some initial deployment.
Classic DNS is one of the “widely successful” protocol designs quoted in RFC 5218. Competing with it seems hard. P2P DNS will provide essentially the same service, so it needs to differentiate in other areas. Security, scalability, ease of deployment, but mostly security, may make P2P DNS successful.