DNSChain 0.5 brings about many new features.

It’s important to remember, however, that this project is not really about new bells and whistles. It’s about what kind of a world we want to live in, and for us the answer is clear: we want to live in a free world, and that means addressing these problems:

  • The Internet has been turned into a weapon for surveillance, and this has led to mass self-censorship.
  • The Internet is being used as a battleground to wage "cyber war". Much of our infrastructure relies on TLS to protect us, but its protection is undermined by X.509, a system that forces everyone online to trust the bad apple.
  • Websites rely on TLS/HTTPS to protect them, but it does a very poor job. Even worse, it's common practice for websites to pay for this "non-protection" (although, thanks to StartSSL and Let's Encrypt, it's no longer mandatory to pay).
These issues threaten our freedom of expression and our national security. Attacks happen, and when they do they are almost impossible to detect.

DNSChain 0.5 takes several important steps in the direction of solving those problems:

  1. It has full support for HTTPS lookups, and it uses a "One Pin To Rule Them All" approach, which makes it possible to secure all other Internet connections and protect them from all "non-fundamental" 1 Man-in-the-Middle attacks.
  2. A basic implementation of the Openname Resolver Specification brings support for doing arbitrary blockchain lookups. The API makes it possible for app developers to create secure applications that are as easy to use as their non-secure counterparts.
  3. We've made it super simple to add support for arbitrary blockchains.
Here's the complete list of features, followed by an overview of the salient items:
  • New Features:
    • Basic Openname Resolver RESTful API support!
    • Built-in HTTPS server that can route multiple services over the same IP and port thanks to @SGrondin
    • Automatically generates 4096-bit HTTPS key/certificate pair for you
    • Redis caching for both DNS and HTTP requests thanks to @WeMeetAgain
    • Traffic throttling for both DNS and HTTP requests thanks to @SGrondin
    • Super simple to add any new blockchain to DNSChain thanks to major refactoring work by @WeMeetAgain
    • NXT blockchain support thanks to @toenu23 (this means a `nxt.dns` metaTLD and `.nxt` TLD resolution)
    • Query DNS records over HTTPS using either new Openname API or `icann.dns` metaTLD! (by @WeMeetAgain)
    • Ability to specify configuration file path for any supported blockchain via the dnschain configuration (@WeMeetAgain, again!)
    • RESTful API to fetch server fingerprint (Closes #44).
  • Improvements:
    • Complete overhaul, refactoring, and improvement of the entire code base
    • Travic CI support
    • Comprehensive testing suite with complete code coverage for all critical files (excludes some error handlers and datasources)
    • Replaced a lot of callback code with Promises (still more to be done!)
    • All DNSChain components/servers are started and shutdown asynchronously (using Promise based API)
    • Precisely specified dependency versions to spare sysadmins any annoying surprises
    • Added badges for NPM version, Travis build status, and Gitter to top of README
    • All Namecoin data is now returned for HTTP(S) queries (`txid`, `expires_in`, etc.)
  • Documentation:
    • Comparisons to TACK, HPKP, and Thin Clients
    • Numerous miscellaneous improvements to documentation
    • Updated Contributors list in README
    • Added badges for NPM version, Travis build status, and Gitter chat to top of README
    • This release includes the brand new documentation by @mdw and @taoeffect
  • Fixes:
    • Closed #111: `TypeError` on startup on CentOS machines
    • Closed #90 and #87: Exception on access to unknown metaTLD

Overview of Significant Changes

On to the bells and whistles! 🙂

Basic implementation of Openname Resolver API

The Openname Resolver API is a collaboration between okTurtles and Onename to specify how a DNSChain-type server is supposed to behave. The purpose of this specification is to promote software interoperability in the face of multiple implementations. We provide more info here. The RESTful portion of the specification results in queries that look like this:

https://api.example.com/v1/namecoin/key/id%2Fbob
https://api.example.com/v1/bitcoin/addr/MywyjpyBbFTsHkevcoYnSaifShG2Et8R3S
https://api.example.com/v1/namecoin/key/id%2Fclinton/transfer?to_addr=ea3df...
http://api.example.com/v1/resolver/fingerprint

The URL follows this simple format:

/{version}/{chain|resolver}/{resource}/{property}/{operation}{resp_format}?{args}

Currently, reading from arbitrary blockchains is supported via the key resource. Adding support for other resources is simple and is implemented in a generic fashion.

Try right now!

Fetch DNS records over HTTPS
We've added an `icann` `{resolver}` that can be used to retrieve traditional DNS records over HTTPS. Keep in mind that unlike blockchain records, these are subject to the MITM attack. Still, if for some reason you need it, it's there: 
GET https://api.example.com/v1/icann/key/okturtles.com
=> {"version":"0.0.1","header":{"datastore":"icann"},"data":{"edns_options":[],"answer":[{"name":"okturtles.com","type":1,"class":1,"ttl":299,"address":"192.184.93.146"}],"authority":[],"additional":[]}}

Try right now!

Complete HTTPS support
Starting with this release, DNSChain will auto-generate your SSL/TLS key and cert for you, and it will output its fingerprint to the console. This means you can now actually access it over a MITM-proof channel (so long as you verify the TLS/SSL fingerprint).

It is also possible to combine DNSChain with a web server like nginx, just make sure that both servers are set to use the same cert/key pair.

New Blockchain: NXT

DNSChain now has support for the proof-of-stake blockchain NXT thanks to work from Anton Wilhelm. You should be able to both access .nxt websites and use the RESTful API described above (although it may need more testing), as well as the other supported blockchains:

Blockchain TLD Name used in RESTful API
Namecoin .bit namecoin
KeyID .p2p keyid
NXT .nxt nxt

Ethereum support is planned as .eth and ethereum.

Remember: only websites that use a blockchain-based TLD can provide their visitors with MITM-proof access in a practical manner (to the best of our knowledge).2

Traffic-Throttling for both DNS and HTTP(S)
Thanks to work by Simon Grondin, DNSChain comes with DoS protection out-of-the box, and it's completely configurable by you.
Redis caching of both DNS and HTTP(S) replies
Thanks to work by Cayman Nava, you can hook up DNSChain to a Redis server to improve performance (if you need to).
Comparisons to TACK, HPKP, Thin Clients and more!
Yet again we've overhauled and updated our documentation, including updating our Comparisons documentation. Thanks go to Zachary Lym of Namecoin whose helpful recommendations and critiques resulted in many improvements to our docs.
Comprehensive testing suite + Travis CI support
We have excellent code coverage that covers all critical paths in DNSChain. The parts missing are mostly error situations and NXT/KeyID coverage.
Namecoin queries return all blockchain data (txn IDs, expiration info, etc.)
DNSChain now returns all available information for Namecoin lookups.

To see what else is new, see the complete release notes above.

I’d like to thank Simon Grondin, Cayman Nava, and Anton Wilhelm, without whom this release would not have been possible. I’d also like to thank everyone who is supporting our work in some way or another. This project is powered mostly through volunteer effort. You can help by installing DNSChain, contributing code, using it, spreading the word, or -> donating <- to our efforts.

Thanks for reading! Now go build something with it! 🙂

For updates on these projects, follow @okTurtles and @DNSChain on twitter.

Thanks to Andrea Devers, John Light, Cayman Nava, [withheld], and Simon Grondin for reviewing this post.

1 We use the word “fundamental” to refer to attacks that affect any secure communications system (an implementation bug like HeartBleed, private key compromise, malware, broken cryptography, etc.).
2 See TACK / HPKP discussion for details on why these methods do not provide practical MITM protection.

Donating = Loving!
You can empower our work by donating!

Comments