> 2) Legitimate domain owners can't recover from key loss
That doesn't seem like an insurmountable obstacle to me. You could devise a scheme where there's the option of a majority of multiple offline backup keys can be used to invalidate and replace the current online key.
Then it's up to the legitimate owner whether the domain is valuable enough to do that kind of key management and backup.
This is a problem of interest to me because I've just started working on a P2P project in Erlang that would benefit a lot from having DNS that isn't as easily squattable. Do you know of any solutions to that, or attempted solutions?
Thanks for clarifying that - I remember hearing about the project a while ago. I looked at the most recent documentation and it did seem more like a P2P network, although I just assumed there was also some concept of decentralized DNS within the project as well.
Not that I'm criticising the work, but DNS is already P2P; it is -by design- a federated system. However, -as Mononofu's project's README notes- it is not highly tamper resistant. [0]
I know that one could see this as a petty quibble, but just because something isn't tamper resistant doesn't mean it's not a P2P system. :)
[0] I make liberal use of this lack of tamper resistance to provide various levels of ad and tracking blocking for all systems on my LAN. BIND's RPZs (and mechanisms similar to them) are pretty great.
I don't think DNS is P2P in the sense that all actors in the system are homogenous and equipotent. Although modern P2P systems have supernodes, they usually serve the purpose of rendezvous, and not typical operationl
DNS is a more of a hierarchical system, where the roots are at the center, and they delegate trust and responsibility as necessary.
This is a more accurate description IMO. However DNS does not have to be that way. Before DNS there used to be file sharing of all the data via a single file in the simple "HOSTS file" format. Then there was a feature in DNS for sharing all the data of each nameserver, in a "zone file" format. With network bandwidth as it is today, sharing of data in bulk could be quite useful to make DNS more peer-to-peer like. People still share data, e.g., block lists. But, practically speaking, everyone running a nameserver connected to the public internet disables axfr.
Also, in my view peer-to-peer supernodes do not monitor or forward all data, they only maintain address information of the peers (rendezvous as you say). DNS, as it is implemented on the public internet, is ripe with passive monitoring as all data flows through centralised points in the tree. Leaves, at the network's edge, are expected to be "dumb", needing to make hundreds single requests for the same information, 365 days per year, even when the majority of it is relatively static.
Every query and response packet containing a seemingly useless "Query" field that never varies from "1". There's no pipelining (when using TCP) or packets containing more than one query.
From what I understand there was interest in so-called "P2P DNS" in reaction to various incidents of censorship via the centralised points in the tree. If the leaves were truly connected as "peers", and sharing the database data directly "peer to peer", then we might have better protections against censorship.
Incidentally, "DNSSEC", as advertised, appears to anticipate centralisation and usage as a CA-like system where peers at the network edge are not only dumb but incapable or verifying messages themselves without involvement of third parties.
In contrast, encrypting DNS packets requires no third party assistance. It can be done by peers all by themselves. A client can encrypt queries and a nameserver can encrypt replies. Well suited to peer-to-peer style usage of DNS. Bulk DNS data can be rysnc'd between peers over SSH, or perhaps mrysnc'd among groups of peers.
There is "DNS" as implemented so far and then there is "what's possible" using DNS. Peer to peer sharing of the data is hardly far-fetched. But it does not yet seem to have caught on outside of small groups doing passive monitoring, blocking and other manipulation.
> I don't think DNS is P2P in the sense that all actors in the system are homogenous and equipotent. ... DNS is a more of a hierarchical system, where the roots are at the center, and they delegate trust and responsibility as necessary.
So, on the one hand I see where you're coming from and your comments are totally valid.
On the other hand, there is no actual centralized authority to which one must appeal to to get data into DNS. Want to have porn site blocking? OpenDNS has you covered! [0] Want to attach Namecoin's .bit TLD into your DNS tree? That's available on my LAN and -when last I checked- through a few Internet-accessible DNS servers. Ad/malvertizing blocking for every client attached to your network? Again, just point to (or stand up) a DNS server that's appropriately configured.
In DNS, the "edges" have just as much power as the nodes in the "center", but their sphere of influence is often much smaller.
So how do I register foobar.com in such a way that everyone using DNS can access it without paying an organisation registered (directly or indirectly) with ICANN?
Filtering can be done - certain very-small-scale extensions can be done - and local DNS networks can be done - but if you take the goal of DNS-as-a-global-service as "provide globally unique, globally available name resolution", it very much is centralised.
It does, to a lesser or greater extent. The problem is that the root node/TLD provides trust for everything below it. This means that like HTTPS trust is also centralised (but also federated, which is even worse.)
However I'm not an expert in DNSSEC so there could be nuances that I'm missing
dnscrypt protects the traffic between you and your resolver.
DNSSEC makes sure that the records presented by your domain have not been tampered with (though in fact it only makes sure that the records have not been tampered with by anyone but the registry or the government the registry is controlled by)
Codebase has not seen significant recent activity.