DNSChain is a DNS server that uses Namecoin as a backend, but compromises Namecoin’s security without any improvements to usability or legacy interoperability. However, DNSChain’s faulty and grandiose claims have led to a frightening degree of interest and adoption. The Namecoin blog is not the place to engage misguided projects but, as an official Namecoin developer, I feel compelled to speak out.
I’ve written a more-up-to-date technical overview of okTurtles, DNSChain, and Unblock.us. While the security model for DNSChain has improved, they are still misrepresenting the security parameters of their software.
I’m going to leave this up since it debunks what DNSChain was selling. I also think their resistance to outside security concerns is very troubling.
DNSChain erroneous claims to have passed a “peer review” process. However, its most important peers, Namecoin developers, have rejected it. This has been the reaction of every Namecoin developer who has evaluated the project (over four at this point). The project misrepresents its security model, its design is unfixable, it should not be used in any nonlocal capacity.
DNSChain is architected on the premise that local Namecoin installations won’t scale thanks to the size of the blockchain, but this is based on a lack of understanding regarding lightweight clients. Functionally speaking, lightweight clients require a trivial amount of data to be stored locally. Would-be attackers must compromise the client’s machine directly, which is comfortably outside of any application’s security model.
DNSChain, on the other hand, requires individuals to maintain a server and setup client software. This effectively introduces third party trust because 99.9% of users will rely on someone else to maintain a server for them.
Lightweight clients make DNSChain’s server/client model obsolete. Any additional functionality is largely duplicative of our work on NMControl, middleware we developed long before DNSChain came into being. DNSChain introduces security issues without improving on usability or backwards compatibility.
We have tried to raise these issues with the lead DNSChain developer, but have been unable to engage with him in a productive manner.
Namecoin Lightweight Resolvers
DNSChain’s security model resorts to the use of a trusted third party, based on the premise that local deployment of trust-free Namecoin clients is not scalable. However, our plans for lightweight clients disprove this assertion. A lightweight node using SPV and UTXO commitments would enable trivial deployment footprints. Unlike DNSChain, this would preserve almost all of the security of a full node without the need for third-party trust.
In fact, even intermediate modes are quite scalable. In Summer 2014, experiments with UTXO pruning indicated that the UTXO database could be compressed to a size on the order of 300MB, and further optimizations should be possible. The .bit TLD could scale to the size of .info or .biz (the largest tertiary gTLDs) and a Namecoin UTXO client would still be compact enough for use on smartphones.
DNSChain’s Slippery Security Model
Under DNSChain’s security model, users can run their own server. However, very few people are qualified and motivated to administer their own server, even 1% would be a gross overestimate. Thus, under DNSChain’s security model, the other 99% of the userbase must rely on “friends.”
This “friend” terminology is doublespeak: DNSChain carefully avoids terms like third party trust, instead opting for euphemisms like friends, first-party trust, and second-party trust. The truth is that people who cannot operate their own servers must rely on third parties, which introduces third-party trust.
Claiming that DNSChain does not require third party trust is not technically a lie, but it is incredibly dishonest. Email technically doesn’t require third party trust either, but very few people run their own email server. Even if you accept their premise that trusting a “friend” is different than the traditional concept of third-party trust, how many people do you know that:
- you trust not to snoop on your email;
- are capable of defending a server from attacks;
- are willing to run a server for free?
I used to compare DNSChain to DNSSEC/DANE, but even the ICANN DNS encryption system offers superior security to DNSChain. DNSChain introduces the worst kind of third party trust: DIY and private corporations operating independently. At least with DNSSEC/DANE, there is a publicly auditable security process.
If we consider a parallel universe that has achieved universal adoption of DNSChain, the situation would be virtually identical to the current DNS system in which ISPs maintain a DNS server that the client trusts.
DNSChain Cannot Be Fixed
Despite a tweet claiming that DNSChain will support lightweight clients, the DNSChain website, documentation, and recent commits indicate that they are continuing with their broken client/server model. However, even if they adopted lightweight clients tomorrow, NMControl is written in Python, has a standard remote procedure call interface, offers a pluggable architecture, and is multithreaded; it is an architecture that we think others will prefer to work with.
NMControl could use some love, but we have plans to revamp the software. However, whenever possible, we aim to reuse existing software, such as replacing our DNS server library with the widely respected Unbound DNS resolver.
How This Happened
I take no pleasure in writing this; there is no joy in tearing down others work, and I avoided a public dispute for as long as I could. I partly blame the situation on the sad state of Namecoin’s documentation and the core development team’s limited bandwidth.
The current core Namecoin development team took over about a year ago. While our documentation has improved, it’s still a mess. There is no developer guide or even reliable API documentation. We have simply been lacking the bandwidth to properly mentor new contributors. As a result, we’ve had multiple instances of people contributing unworkable “solutions” or solving problems we’ve already solved.
Myself and others have spent a great deal of time trying to engage with DNSChain’s lead developer in a productive manner, but his responses have been acrimonious. We initially kept our rejection of DNSChain to IRC and the forum, hoping that DNSChain’s lead developer would change course. However, potential technology partners, academics, and funding agencies are increasingly bring up DNSChain in private conversation. This silence is perpetuating the notion that DNSChain has passed “peer review” or that it has formal ties with the Namecoin project; neither notion is correct.
I fear that DNSChain’s security problems will damage Namecoin’s reputation, continue to drain our resources, and threaten our users. Widespread adoption of DNSChain would seriously damage the security of the Internet even relative to the traditional and ICANN DNS and CA model. DNSChain is not endorsed by the Namecoin project, the developer is not officially affiliated with the Namecoin project, and it should not be used in any nonlocal capacity.
Greg, DNSChain’s lead developer, contributes to the OS X port and I would like to encourage him to continue contributing to the project. Given his recent history with the project, any contributions will be met with a healthy dose of skepticism. However, building a secure, usable, and censorship resistant domain name system will require a lot of blood, sweat, and tears from lots of smart people … including Greg.