Ok, they're still undergoing load-testing and it's possible they'll be a bit crash-y meanwhile, but we've got two publicly-available DNS resolvers ready for some load testing:
188.8.131.52 (hostname-mapped to dnschain2.cryptostorm.net)
These resolvers are backed up by our deployment of the DNSchain system, as implemented by OKTurtles (github repository here). Yes, it's sort of silly to provide subdomain-based TLD lookups to these IP addresses (dnschain1.cryptostorm.net; dnschain2.cryptostorm.net), since to use those as resolvers you'd first be doing a traditional resolver lookup, then using that IP address to do a DNSchain-based lookup... but we mapped them even so, just in case there's some use to such mappings we haven't figured out ourselves, just yet.
DNSchain is a powerful approach to solving a good chunk of the deep structural problems that currently bedevil the Domain Name System (DNS), & everyone who uses it to connect human-readable domain names with internet protocol (IP) addresses. There's several layers to DNSchain, and our fully leveraging of these layers is a work-in-process. For now, we're implementing these publicly-available resolvers even as we continue to backfill the additional functions of DNSchain within our own network architecture.
For those curious, here's a quick intro whitepaper to how DNSchain is implemented:
These resolvers are intended, once testing is complete, to serve two core purposes:
- 1. Provide first-priority lookup service in our "pushed" DNS resolver settings for members connected to cryptostorm. As we discuss in this thread, DNS resolution is an important element in our overall network security model; adding our in-house resolvers to the resolver pool members use during cryptostorm network sessions is an important step forward towards increased resilience, security, and reliability in this function.
2. Offer publicly-available resolver access, for anyone who wants to have a DNSchain-based resolver to use in their own setup. The choice to make our resolvers publicly available is one we found easy to make, to be honest - it's a reflection of how we approach most all of our technological tasks, at cryptostorm.
As we continue to flesh out the additional elements of the DNSchain security model in our production framework - adding public key validation to cryptostorm-session lookups, offering .bit domains to compliment traditional TLDs, and so on - we'll post those details here. Meanwhile, feel free to share ideas, feedback, results of your testing, and suggestions here in this thread.
Thanks in advance for your help in testing and improving these resolver resources!