I don't really like the direction of the "official" project, especially the part where they decided to use a central authortiy, so I started my own. This is a true distributed approach, for everything else we don't need to develop anything new.
The basic idea is that each and every node of the network caches all the domains we have. Before you cry foul, let's look at how much space this will really need.
Our DNS record has several parts:
- The domain itself. At 8 bit for one char, we'll assume a generous average length of 50 chars, which leaves us with 400 bits.
- Sub-domains. It's difficult to assess how many sub-domains the average domain has, but let's assume we'll need 10, each with 25 chars. That's another 2000 bits.
- The IP. One IP (v4) needs 32 bit, but we'll plan ahead and allow IPv6 too, which needs 128 bit per IP. We'll allow to store as many IPs as one likes for load-balancing, but the average will not be above 4. (just look up a few common domains). That's 512 bit in total then.
- The Key. All our records are signed so nobody can modify them without being detected, and therefore we also need the public key of the owner. While we could store it separately, it's easier to just put it in the record. Usually it's 1024 bits, but we'll assume 2048 to be on the safe side. If a node has once received the key for a domain, it will only replace this key if it receives a message signed by the owner of the corresponding private key. Since this public key is used to verify that the signature is correct, attackers can't tamper with already existing records.
- The Signature. This is the part that verifies that the rest of the record (excluding the key) is authentic and from the owner of the private key. We need 576 bits for it.
- The TTL. Now that's really minor, needs only 32 bit.
- Other records. Of course we need to store other details as well: MX records (for the mail servers), TXT records, etc. We'll assume another 1000 bits for that.
All in all, we would need 6568 bits, or 821 bytes. In other words, we could fit 1277 domains in one Megabyte, or roughly 1,3 million domains in one Gigabyte.
To save all domains currently in existence (about 500 mio - s1, s2), we therefore need 390 GB of diskspace. Note, however, that this is without using any compression at all! A large part of the records is text, so we can probably reduce size by 30% to 50%. Also, my assumptions were probably way too large, but that was on purpose.
Furthermore, it is highly unlikely that we'll see so many p2p domains in the near future, and even now disk space costs a few cents per GB.
The current design consists of two parts: First, a lightweight DNS server which resolves the domains and forwards unknown ones to a real DNS server. Second, the P2P-DNS node itself, which answers requests from the DNS server.
The security of this concept stems from the signed records - once you have received a record, only the original creator can change it. This leaves two different attack vectors:
A new node connects and has no previous data about a domain. In this case, he will query all known nodes (or a random sample of size X). He will follow the opinion of the majority. An attacker could now use a large number of bots (at least half the size of the network)to flood the network with fake nodes and poison the DNS cache of the new node.
A possible countermeasure would be a web of trust: if you want to connect to the network, you need to know at least one node whom you trust. All responses by this node will be modified by how much you trust him. The responses of the nodes he trusts will be modified by how much you trust him and how much he trusts them. ensuring that distant nodes have less weight. This trust system is fully automated, the user only needs to provide the initial trust values.
To successfully attack this network, an attacker would need to find many nodes who trust him, so the responses of his bots gain the necessary weight. Furthermore, he would need to be "close" to the new node, or the responses will have almost no impact.
The attacker floods the network with new spam domains. While annoying, this won't cause any real damage - you could require a certain amount of trustees to be able to announce a domain to counteract this.