Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

cryptostorm's DNS resolvers

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

Topic Author
Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

cryptostorm's DNS resolvers

Postby Pattern_Juggled » Sat Jan 03, 2015 2:33 pm

There was a claim made recently that cryptostorm makes use of OpenDNS's resolver network, so I wanted to open a thread on this topic.

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:

cstorm_dns.png


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
cstorm_confDNSresolve.png (16.42 KiB) Viewed 12793 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:

resolvertweets.png


Cheers,

    ~ pj

User avatar

marzametal
Posts: 500
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm's DNS resolvers

Postby marzametal » Sat Jan 03, 2015 2:56 pm

DNS 213.73.91.35
DNS 213.138.101.252
DNS 80.237.196.2
DNS 194.150.168.168

These four DNS entries are provided by the Windows widget when connecting, after TAP is called and executed...

User avatar

Topic Author
Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm's DNS resolvers

Postby Pattern_Juggled » Sat Jan 03, 2015 4:05 pm

marzametal wrote:DNS 213.73.91.35
DNS 213.138.101.252
DNS 80.237.196.2
DNS 194.150.168.168


213.73.91.35
35.91.73.213.in-addr.arpa domain name pointer dnscache.berlin.ccc.de.

213.138.101.252
252.101.138.213.in-addr.arpa domain name pointer banks.default.nrichards.uk0.bigv.io.

80.237.196.2
2.196.237.80.in-addr.arpa domain name pointer dnsc1.dtfh.de.

194.150.168.168
168.168.150.194.in-addr.arpa domain name pointer dns.as250.net.

These four DNS entries are provided by the Windows widget when connecting, after TAP is called and executed...


Afaik, DNS resolvers are a pushed item both with widget connects; I know they are when it comes to connections via direct/"raw" connections. Allowing for pushed DNS settings enables us, network-wide, to update these resolvers as-needed without requiring folks to grab new conf's or download new widget versions.

That said, I'll want to double-check this with the widget dev guys as that's not my direct area and I don't want to mis-speak. I can confirm those host lookups, posted above, are replicated across several machines from which I've done the queries.

Cheers,

    ~ pj

User avatar

Topic Author
Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: cryptostorm's DNS resolvers

Postby Pattern_Juggled » Mon Jan 05, 2015 12:41 pm

There's an announcement of our beta-available in-house resolvers in this forum thread:

cryptostorm.org/dnschain

Cheers,

    ~ pj

User avatar

marzametal
Posts: 500
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm's DNS resolvers

Postby marzametal » Wed Apr 06, 2016 7:08 am

I didn't want to start another thread just for this, so decided to post here...

Is it possible to assign/re-assign deepDNS hostnames across all DNS addresses used by CS? As per following screenshot, some do not resolve to a hostname, while others don't mention "deepDNS" at all. I am not sure if this is actually tied in with HAF, which might be deprecated?

P.S.: Not all DNS are referenced in screenshot.

IPNetInfo


JH
Posts: 24
Joined: Sun Apr 17, 2016 4:33 am

Re: cryptostorm's DNS resolvers

Postby JH » Sun Apr 17, 2016 8:37 pm

But Tracker Smacker is working on all servers now? There is not more a "free TS" server like the old England server?

User avatar

marzametal
Posts: 500
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm's DNS resolvers

Postby marzametal » Mon Apr 18, 2016 5:54 am

JH wrote:But Tracker Smacker is working on all servers now? There is not more a "free TS" server like the old England server?

I think Voodoo US West - Iceland is TS free. I try other exit nodes and cannot view Vine Videos via Twitter. Nslookup on "vine.co" shows 127.0.0.1 as the last entry. So give the node I mentioned above a shot.


JH
Posts: 24
Joined: Sun Apr 17, 2016 4:33 am

Re: cryptostorm's DNS resolvers

Postby JH » Fri Apr 22, 2016 2:11 pm

marzametal wrote:
JH wrote:But Tracker Smacker is working on all servers now? There is not more a "free TS" server like the old England server?

I think Voodoo US West - Iceland is TS free. I try other exit nodes and cannot view Vine Videos via Twitter. Nslookup on "vine.co" shows 127.0.0.1 as the last entry. So give the node I mentioned above a shot.


Got it, thanks.


ong1599623
Posts: 4
Joined: Fri Dec 02, 2016 2:38 pm

Re: cryptostorm's DNS resolvers

Postby ong1599623 » Tue Aug 08, 2017 1:54 pm

Thanks to a Very good information
สล็อต


Return to “DeepDNS.net - cryptostorm's no-compromise DNS resolver framework”

Who is online

Users browsing this forum: No registered users and 9 guests

Login