Admittedly, this claim is a bit odd to start with. It's credited merely to "a source," per this quote:
"We got the permission to pentest Cryptostorms VPN servers we haven’t yet but we heard from a source that Cryptostorm uses Opendns for their servers..."
To be clear, it's not necessary to "pentest" our network to confirm what DNS resolvers we push during network sessions. Nor does doing so require a token; simply doing test connects to any node, or cluster, with random login info will get the pushed data before the session aborts due to an auth failure. Perhaps some folks don't know this is easy to do and publicly available to anyone, but simply asking us about it would have resulted in us sharing this method for verifying the production pushed config parameters from any openvpn-based service. Here's what the relevant lines in a verbosity 7 client-side logfile will look like:
We publish our server-side resolver settings in our server configuration thread, here in the forum. Here's a snapshot of what those lines in our conf's look like:
- cstorm_confDNSresolve.png (16.42 KiB) Viewed 15642 times
As far as I'm aware, all current production nodes in our network are using these same resolvers currently, which are:
push "dhcp-option DNS 198.100.146.51"
# OpenNICproject.org
push "dhcp-option DNS 91.191.136.152"
# Telecomix is.gd/jj4IER
push "dhcp-option DNS 213.73.91.35"
# CCC http://is.gd/eC4apk
That said, as our network has grown, I know our network admin team has had to prune resolvers from time to time as one we used previously went offline or otherwise had troubles. So if anyone spots a variance in the resolvers being pushed, it'd be helpful to post to this thread so we can make sure we're synched across the network. Also, I do recall a staff discussion about optimising resolvers for lower-hop closeness to specific exitnode clusters, so for example our cluster in Montreal might first look to a resolver that's closer geographically than one further away. I don't actually know if this was implemented yet, and I suspect even if it was it was only partial. That's because...
We're in final testing of our in-house resolver configuration, something we've been discussing and debating and researching for - no exaggeration - several years. In the end, when we saw the DNSchain tool mature enough to be considered production-ready, we decided as a team to move towards in-house resolvers based around this namecoin-blockchain driven DNS solution. It's demonstrably a step forward in terms of resilience against censorship, MiTM attacks, and all manner of DNS badness at the upstream resolver level.
Finally, as to OpenDNS, I personally have a great deal of respect for their team and the technical expertise they bring to bear. They have shared a number of nice, opensource, DNS tools with the community free of charge - DNScrypt being one prominent example. Further, they're always available to answer questions and share advice with the community, and that's enormously helpful for such a complex topic. Because, yes, DNS is complex; take a read of our DNS weirdness thread for a short intro.
So demonising OpenDNS for "logging" DNS queries is, to me, dumb. It reflects a tragically naive understanding of what DNS resolvers do in the context of a secure network like cryptostorm's. We do use, often in fact, OpenDNS's basic resolver settings (like many network geeks, I can declaim them from memory and have been able to do so for more than a decade: 208.67.222.222 | 208.67.220.220) for in-house testing, when we don't want to have any concerns that DNS resolution is a snag during tuning of other parameters. Further we do use them for some in-house services such as our own mailservers and admin boxes, as they are quick and reliable and low-drama. Needless to say, such uses - testing, & in-house/admin - are not production network matters, and reflect both our respect for OpenDNS and our acknowledgement that they run reliable, well-managed resolvers for the most part.
That has nothing to do with member connects, obviously. Indeed, absent inexplicable weirdness in production (which, to be fair, does happen wrt DNS, sometimes!), DNS lookups on-network with cryptostorm carry only the physical IP address of the node through which a member is connected. Thus, any "logs" OpenDNS keeps would show... cryptostorm. That's hardly an OpSec issue, is it?
We're not angry about errors like this, when folks are reviewing our network. Errors happen, it's cool. Some of this stuff can be a little complex, and while for those of us who work with this tech day in and day out it may be fairly obvious how things work, for outside folks this can be a mystifying world. I do hope those involved in making this inaccurate observation will take the chance to learn a bit about what we do in our network, share their findings with us so we can discuss, and - in the case we're in error in anything we're doing or saying - continue to publicly defend the positions they take.
For those curious, here's the text of some recent tweets on this topic, for reference:
Cheers,
- ~ pj
