post-beta in-house DNS resolvers thread

A core mission of cryptostorm is ensuring consistent, reliable network security with minimal fuss & drama. From DNS-based services like our DeepDNS in-browser native .onion/.i2p site access, through grounbreaking research on IP6 leakblocking, & to firewall-based structures to enable "fail-closed" security, this is where we discuss & develop cryptostorm-style leakblock tech.
User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

post-beta in-house DNS resolvers thread

Post by Pattern_Juggled » Thu Jan 29, 2015 12:20 pm

I've taken the liberty of instantiating a new thread to follow up on the existing beta DNS resolvers thread, as we've somewhat moved from a proper beta testing phase on the resolvers into a more-or-less production context and thus it seems more appropriate to have a new thread versus requiring folks to dig thru the beta thread in order to get to today's status.

And to get the ball rolling, here's a comment I just shared over on the dnschain github repository, regarding full public (versus on-cstorm) availability of our new resolvers. As I say in the comment, I'm echoing it here both to ensure folks can address the issues it raises (even if they aren't active in that particular github repository), and also to let folks know there's an active discussion over there in the event they'd like to jump in and participate directly.

Without further ado, here's the comment as posted:
We'd be happy to be added to the list - thanks for catching this!

There's been some back-and-forth wrt making our newly-birthed resolvers fully public, or only accessible to folks on-cstorm. I'd say this is an open question at the moment, in terms of team discussion, with the current assumption that we'd set up a separate infrastructure to handle fully public usage in order to ensure we don't end up getting hammered and impacting on-cstorm network performance.

Which is all to say - when we do get added to the list of public resolvers, could someone poke us so we know? That way we can accelerate the provisioning of a dedicated foundation to support the public side of this infrastructure ( &

And yes it's a bit weird that our resolvers are hostnames rather than IPs - we refer to them as such in order to give ourselves a bit of flexibility in shifting the physical components of the system around until it settled into a stable equilibrium. For example, we'd used a dev box for our first iteration of beta (public) dnschain'd resolver - with associated IPs - and since then we've repurposed that box as a dedicated Tor relay ( so those IPs are no longer available for use in a resolver context, in terms of security considerations. Thus we'll be re-mapping those dnschain1/dnschain2 hostnames... first to our in-house resolvers in Iceland and then (per rambling discussion above) to a dedicated box separate from our production Icelandic resource pool.

I'm going to echo this post over to a post as well, just to ensure that folks in our community who might not see this here on github can stay in the loop - that's purely for coordination purposes, and we'll consider this thread here as the relevant one with respect to the question of publicising our resolvers as publicly-available resources.

Thanks again!
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github