The first part of this document tells me that a local daemon communicated with Namecoin, ergo the system is dependent on having it running locally for anything approaching security.
> Instead, all of that is done for you by your chosen DNSChain server.
That's just it, why would I ever trust a remote resolver? There's two public resolvers listed on the homepage of the site, one is doing resolution in the clear and the "encrypted" one has no listed public key to verify that again there's no MITM.
None of this is filling me with confidence and we haven't even asked who is running the things yet.
There's is no way to square the circle here - Zooko's triangle [1] guarantees that you can't have a decentralized system with memorable secure names. See Dan Kaminsky's analysis of Aaron's system (which was implemented by NameCoin. [2]
1: https://en.wikipedia.org/wiki/Zooko%27s_triangle 2: http://dankaminsky.com/2011/01/13/spelunk-tri/
That's about right, I think.
> That's just it, why would I ever trust a remote resolver?
You trust yourself right? The docs emphasize in multiple locations that you should be the one who is running the resolver. And if you don't know how, you can use a friend's while you're learning or others are making it easy for you to have your own.
> the "encrypted" one has no listed public key to verify that again there's no MITM.
It does, click on the IP and the public key is listed there in a gist, along with the command to use it with dnscrypt-proxy.
> They promise resolution will be signed by the server some day, but it's not a feature enabled right now.
It's not like it's difficult to implement this. I could do it in a couple of hours, but I came to a stopping point with the code and began focusing on community building for a bit. Don't worry, it's coming real soon, and you're welcome to implement it yourself and submit a pull request if you can't wait. :)
The point is that this approach works.
You're right, github must have hiccuped before. When I looked at that before it was a blank document. I assumed it was a placeholder because the client didn't support any sort of request signing yet.
(Sorry for editing my post out from under you, it wasn't intentional)
The solution as presented doesn't solve ALL of our problems, but solutions rarely do, and it's not reasonable to expect them to. But it does solve SOME, and doesn't present any new ones (although I expect to eat my words as I type that). Progress is progress, even if it doesn't get us the full mile.
As for trusting those writing this particular software, we don't really have to trust them, we simply have to trust the code.