Ξ 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: DNSchain + DNScurve + Iceland-based

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
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby cryptostorm_team » Tue Feb 03, 2015 12:42 am

{direct link: cryptostorm.org/mmmdns}

For several years, we've discussed amoungst our team and with our community the pros and cons of bringing DNS resolver functionality for on-cstorm sessions in-house (separate threads found here and here and here, for a start). As that process unfolded, our tech folks cast a wide-net over the literature and best practices surrounding DNS resolution and DNS security in general.

For anyone who has explored this area of technology, they can confirm that the waters run deep. Whether it be the often-misunderstood question of DNS leaks & how to prevent them, the general obscurity of so much client-side DNS behaviour in tunnelled settings, or the ''right DNS settings for cryptostorm members, there's hundreds of posts in the forum collating information, reviewing research, pulling together advice, and sifting useful security kit from the cryptographic catastrophes of failed DNS security efforts so commonly seen in the wild.

After a few years of work invested (on & off) by our team - and new projects developing during the interim - we saw potential coalescing for genuine improvement in both DNS security/resilience against censorship, and in on-cstorm session performance (faster lookups, lower latencies).


Back in December, we deployed a beta-version of a DNSchain-supported resolver on a test machine in our network. DNSchain is an architecture that implements Namecoin blochchain-based resolution of .bit TLD names... names that can't be seized, hijacked, or subverted by state authority - as is so trivially easy to do under the current Certificate-Authority/TLD-based model & all conventional efforts to fix its hideous flaws.

In parallel, we've been testing DNScurve, a cryptographically-robust method to defeat substantial chunks of known attacks on DNS-lookup systems as they pass through the various layers of network resources. Despite the similarity in names, the two tools - DNSchain and DNScurve - really address different components of the attack-surface landscape. Together, they close off big chunks of weak real estate.

And finally, we've been testing various methods for doing the actual boring work of query-by-query DNS lookups via the delegated-authority model underlying the entire IP-to-domain model of packet-switched networking that we know as the internet. This is, itself, a world of layers upon layers - shortcuts that bring misery and elegant solutions that avoid enormous morasses of fruitless work; competing recommendations from smart folks who have studied these questions their entire professional lives, and DDoS skiddies looking for the latest easy amplification attacks to jack up their booter firepower. The final weird factor in these decisions is the near-ubiquitous reliance on "DNS leak" testing websites that each, in turn, implements closed-source, obfuscated code (usually brutalist javascrips) to convince a web browser to ask some part of the kernel what resolver it would use if - theoretically - it were resolving something (most follow this model; a small minority throw actual lookups out of the browser sandbox, usually via privilege-escalated custom Java applets that can pull off such tricks legitimately). All the while, all sorts of other bits and pieces in local client computing ecosystems may well be doing their own decisions about what resolvers to use, and when. Plus there's the local router or gateway, and it's likely go its own hard-coded resolvers it wants to use when it feels like it.

Oh, also there's IP6 leaking all over the place in these configurations: from applications, from kernel processes, from physical NICs, from hideous monstrosities like Microsofts force-down-your-throat Taredo nightmare. Oh also there's other devices on the LAN shouting out their own IP6 "next-neighbour-discovery" queries... some of which may well route out through the gateway and into the wilds of the internet (there's no such thing as "private IP6 addresses" after all). Fire up a packet capture suite, and sit as this putrid tide of IP6 spew rolls around your LAN and out into the waiting arms of whoever's listening upstream from your vuln-riddle little kernel-unpatched gateway hardware...

But when folks visit those mysteriously-opaque "DNS leak test" sites, they better get results they expect to get - if they get variant results, irrespective of whether there's any issue or not - they'll go into a wild panic. Which is totally fair: DNS is complex to do even reasonably well for full-time network admins... cryptostorm members who aren't full-time geeks need clear markers for "safe" or "unsafe - these leak test sites have become that, whether they're worth the virtual paper they're not printed on, in terms of accuracy, or not.

From all that, we've distilled down two production DNS resolvers. For now, they're publicly available - anyone can use them, on-cstorm or off-cstorm (i.e. bareback):

    mmm1.crytostorm.net
    79.134.235.131

    mmm2.crytostorm.net
    79.134.235.132

Why hostnames, and not simply IPs? There are a small number of use-case scenarios where hostname-defined resolvers can be used in production. Beyond that, it provides some form of supple ability to update to new IPs as-needed, even if such queries are manual rather than onbard a specific application. Practically speaking, however, the vast majority of uses of these will be via the two physical IPs.

Those two IPs are settled on one of our best-provisioned exit nodes anywhere in our network: fenrir.cryptostorm.net - which itself sits in the safe confines of our most-beloved datacentre anywhere in the world, Datacell EHF. Thanks again, guys! :-)

Why are they prefixed as "mmm" and not the traditional "dns1" nomenclature? Because... mmmmmmm, these are damned fine DNS resolvers, yes they are! :-P

These two "mmm" resolvers will shift over to on-cstorm only availability in the near future. That's why we've also created two parallel hostname-resolver entities that will always be publicly available and free for anyone to use. To do this, we'll migrate off these resolvers to a dedicated machine (or machines) so they don't run the risk of impacting production network performance. The resolver/IPs are:

    yay1.crytostorm.net
    79.134.235.131

    yay2.crytostorm.net
    79.134.235.132

You can likely guess why they're named as they are. (note also that the deprecated dnschain1.cryptostorm.net and dnschain2.cryptostorm.net resolver hostnames have been updated to these current IPs, but will be quietly retired once this new public/private split resolver pool is fully deployed.

And in the coming days, we'll be implementing cluster-based resolver instances. This way, every geographic cluster will have it's own on-site recursive resolvers to call - a few milliseconds away. This will dramatically speed lookup response times, which translates into a feeling of "faster" internet access (it really does). This also allows us to add mesh-based resolver redundancies between geo-close clusters so attacks on specific nodes in a cluster can never offline resolver functionality on other nodes in the cluster.

The full technical details of what's been deployed, how it goes about various categories of resolution-query completion, and what cryptographic primitives are implemented in each inter-locking layer of this structure, have been split off into a separate post (below) to avoid having this post get even longer than it is.

- - -

There's a good bit of future roadmap yet to be publicly disclosed, when it comes out our resolver framework.

For example, while we've already implemented .bit TLD lookups (if you're using cryptostorms 'mmm' resolvers, you can click on https://cryptostorm.bit and you'll see our main website load seamlessly; if you're not, nothing will come back from the DNS query thrown by the kernel) transparently via our DNSchain'd resolvers, we'll soon be rolling out a parallel capability to transparently access .onion Tor hidden services sites, when on-cstorm.

At that point, our torstorm cstorm-Tor gateway service will be opened up to everyone - not only on-cstorm access as it is currently structured. Those on-cstorm won't need it, as our resolver system will do all that work behind the scenes and .onion sites will just load like any other site in a browser (yes, we'll retain the heavily-tuned cryptographic suite cascades protecting on-cstorm .onion site access, of course. All that will change is the removal of any need to replace 'onion' with 'torstorm.org' in the URL of hidden services sites.

We're also implementing (via itpd, the C++ instantiation of i2p's original Java architecture) the same transparent-access-via-browser for on-cstorm sessions for eepsites, those with the suffix .i2p that are hosted inside the i2p "network-within-a-network" security model (these features are called "inproxies" and "outproxies" in the context of eepsites). Likely we'll enable public access to these between-network gateways via some mechanism similar to torstorm, as discussed above.

Next, we'll open up these between-network gateways to a broader range of packet traffic than only .onions/eepsites: already, we run a dedicated 100 megabit Tor relay (mishi.cryptostorm.net) as a donated resource to help support the Tor Project. It acts as a testbed and way for us to become more experience with the performance-tuning challenges of torrc-based network transit architectures. A test/dev box to act as a dedicated i2p router is also in process.

We're also baking into future widget releases last-mile DNScurve cryptographic hardening, likely via a src-modified fork of the existing DNScrypt Windows libraries (DNScrypt is, itself, a specific instantiation of the DNScurve model itself - as is CurveDNS). With a bit of trickery, we'll be able to support cstorm-resolver DNS queries from widget-based session connections before the cluster/balancer resolvers have even been queried, thus adding an additional strong layer of MiTM protection for use in highly unfriendly local network contexts.

All this control over resolver queries and server-side resolver functionality - from Namecoin lookups to c25519-based PFS crypto wrappers - allows us to step forward into a whole new layer of network capabilities for on-cstorm activities. We'll be able to wrap not only node/cluster-to-client bindings fluidly and (if we desire... which we will desire) stochastically within loose outcomes-based heuristics, but also the very core of the HAF interconnections (IP/instance to hostname and balancer) we'll then have access to full-power 'fast flux' dynamic network re-architecting on the fly. This is the sine qua non of resilient defence against entire classes of highly effective, difficult-to-avoid attacks on tunnelled/encapsulated secure networking tools from Tor to cryptostorm and everywhere in between (think Great Firewall, for example). Fast-flux has evolved as a tool to enable malware and botnets to evade shutdown efforts - we're just turning that on its head, and using the tool to help foks evade efforts to block access to secure, reliable network resources. (more on fast-flux here and here).

And beyond that, we can enable server-side protections against vast classes of known attacks and censorship of traditional PKI/CA DNS records - so even though national governments can mess with root-level domain-to-IP mappings, we can recognise what is essentially a nation-state Kamisky attack and fall back to alternative resolver resources.

Oh, and we can execute fine-grained control over things like the 'randomness' of source port assignments within DNS resolver queries over time - thereby protecting against still more classes of known-good, in-the-wild DNS resolution cache poisioning' attacks. In addition to solid improvements in security and test results from well-designed vuln-analysis tools, we get very nice-looking charts like this, as well:

mmmrandom.png

GRCDNStest.png


Needless to say, investing the long-term research, analysis, testing, and development resources in DNS resolution functionality for cryptostorm is a decision we feel very good about, as a team. It may not be as sexy as some kinds of content-free marketing hype on the surface... but it has the benefit of providing genuine, sustainable improvements in both members security whilst on-cstorm, and in network resilience in the face of DoS/DDoS or resource censorship attacks by highly-resourced attackers.

DNS-centric systems are hardly the only area of focus for the team, as we continue to expand and improve the core network architecture and security model through 2015 and beyond.

We'll use this thread as an ongoing resource for sharing information on this part of our network framework,

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

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

Re: Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby marzametal » Tue Feb 03, 2015 3:29 pm

Can the above two DNS addresses be entered into OpenVPN for Android? More specifically, IP AND DNS --> Overwrite DNS settings by Server?

...or will 2 existing pushed DNS addresses be removed to make away for the above two...

User avatar

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

packets don't lie

Postby Pattern_Juggled » Wed Feb 04, 2015 9:39 am

marzametal wrote:Can the above two DNS addresses be entered into OpenVPN for Android? More specifically, IP AND DNS --> Overwrite DNS settings by Server?

...or will 2 existing pushed DNS addresses be removed to make away for the above two...


Mostly for things like this, my own advice is: test it sand see what happens.

So often we see documentation or manuals that say something should work a certain way... and then it doesn't quite. That's just how life is in tech with everything iterating so far, so we always test stuff rather than assume (whether it's what we hope it'll do or not - sometimes things shouldn't work but we test and they do... perhaps a developer fixed the bug before release but nobody in the documentation team got word of the bugfix, etc.).

Packets don't lie - we do alot of looking at packets as they actually cross the wire, to confirm what should be taking place actually is.

Cheers,

~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Tealc
ForumHelper
Posts: 283
Joined: Tue Jan 28, 2014 12:38 am

Re: Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby Tealc » Sun Feb 08, 2015 12:38 am

So I've been messing around with OpenVPN and the new widget and I have a couple of questions:
(Always connected to London)

- When I use the new widget and I do a DNS test I get this:
DNS Resolver(s) Tested:
23.226.227.93 appears to have GREAT source port randomness and GREAT transaction ID randomness.
79.134.235.130 (fenrir.cryptostorm.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
23.226.227.94 appears to have GREAT source port randomness and GREAT transaction ID randomness.
Test time: 2015-02-07 19:25:52 UTC


-When I use OpenVPN with the 1.4 conf's I get this:
DNS Resolver(s) Tested:
79.134.235.131 (mmm1.cryptostorm.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
79.134.235.130 (fenrir.cryptostorm.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.
Test time: 2015-02-07 19:25:52 UTC


I've done several tests, with https://www.dns-oarc.net/oarc/services/dnsentropy and https://www.grc.com/dns/benchmark.htm and they ALL give the same results.

Where do the 23.226.227.93/23.226.227.94 came from?

Rdns shows no record but if we search a little deeper I got:
Hostname No Hostname
Network AS3842 RamNode LLC
City Forsyth, Georgia, United States
Latitude/Longitude 33.0325,-83.8957
Postal Code 31029


So any thoughts?

Tealc

User avatar

Fermi
ForumHelper
Posts: 208
Joined: Tue Jun 17, 2014 11:42 am

Re: Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby Fermi » Sun Feb 08, 2015 2:23 am

Tealc,

You'll find a discription on how this works here:
viewtopic.php?f=51&t=8476&p=12807&hilit=dnschain#p12807

Nowadays, the following DNS servers get pushed, this should be regardless of node (unless there's a difference in configuration between the nodes), widget or OpenVPN:
79.134.235.131 (mmm1.cryptostorm.net)
79.134.235.132 (mmm2.cryptostorm.net)
213.73.91.35 (dnscache.berlin.ccc.de (Chaos Computer Club Berlin))
192.184.93.146 (2.dnscrypt-cert.okturtles.com)

The spoofability test for:
79.134.235.131 (mmm1.cryptostorm.net) results in: 79.134.235.130 (fenrir.cryptostorm.net)
79.134.235.132 (raw-fenrir.cryptostorm.net / mmm2.crytostorm.net) results in: 79.134.235.130 (fenrir.cryptostorm.net)
213.73.91.35 (dnscache.berlin.ccc.de (Chaos Computer Club Berlin)) results in: 213.73.91.41
192.184.93.146 (2.dnscrypt-cert.okturtles.com) results in: 23.226.227.93 and 23.226.227.94

Seems to me like normal behaviour.

Regards,

/Fermi

User avatar

Tealc
ForumHelper
Posts: 283
Joined: Tue Jan 28, 2014 12:38 am

Re: Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby Tealc » Sun Feb 08, 2015 4:40 pm

@Fermi,

Cheers and thank you man, can't figure out why that post passed my "search" for the same problem.
Still the strange thing is the difference from OpenVPN client and the widget, and actually I did saw the GRC stuff about that.

Once again, thank you.

Tealc

User avatar

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

Cryptostorm's "mmm" DNS resolvers in production

Postby Pattern_Juggled » Sun Feb 08, 2015 5:31 pm

We've rolled our in-house, dnschain/dnscurve domain name resolvers into production across the network this weekend. I know df has intended to do a more detailled post on the technical foundations of the new framework, but as we've been continuing the deployment as well as some profoundly impressive feature extensions nearly complete (see below), priority has been on production integration over documentation. We'll both get back to fully documenting this stuff, in due course (others on the team have pitched in considerably over the months of this DNS resolver project, but the two of us have been the core resources in terms of hands-on responsibility).

The two public-facing IPs are, as noted above:

    79.134.235.131
    79.134.235.132

There will be more; indeed, we're deploying a system wherein every cluster has its own local "mmm resolvers" to maximise speed of lookups as well as resilience against any nodes or clusters going down. For now, we've still got two 'fallback' resolvers in the pushed settings; you'll see them if you check your connection logs. Our test & in-house "team" instances have had only the mmm's for several days now, without issues. However, given that Iceland does from time to time have island-wide network hiccups, having only .is-based resolvers is a bit risky to be pushed across the entire production network (worst-case is resolve-fails if the resolvers aren't accessible - not a security issue, but frustrating).

It is, in the current openvpn framework, still necessary to sighup the individual instances in order to load new server-side conf's into the running processes - this is why, early Saturday morning, folks may have noted an unexpected "glitch in the matrix" as their session dropped and then immediately reconnected. There will be one more of these 'hups when each cluster has its own locally-instantiated mmm's & thus the instances there will be conf'd with their local-cluster mmm's & two other fallback mmm's from outside clusters, as well. We don't do advanced notice of these 'hups as there's immediate session reconnects - the instances are "down" less than 30 seconds; simply a conf reload (which shouldn't require a 'hup, but I digress).

Everyone on-cstorm (test via cstorm.is/test) should now see the mmm's show up in their resolver pools when using web-based "DNS leak test" or general-purpose DNS testing tools such as...

https://www.dnsleaktest.com/
http://dnsleak.com/
http://ipleak.net/
http://netalyzr.icsi.berkeley.edu/
http://tstat.tlc.polito.it/index.shtml
http://entropy.dns-oarc.net/test/
https://www.grc.com/dns/dns.htm

There's more, and most all of this can of course be done locally via terminal query. As we've still got the fallback resolvers in the pools, you'll likely see those IPs show up in some or most of the tests, as well as the mmm's... that'll drop once we deploy across all clusters. When that's complete, you'll see results such as this when using the testing sites:

mmmresolvers2.png


We've hinted a few times, in recent weeks, that there's some next-stage features that our new DNS resolver framework allows us to provide to network members (in addition to the substantial security and anti-censorship features of what we've deployed). I personally have a deep aversion to "pre-announcing" features that we haven't yet more or less completed developing in-house: call it a habit borne of years around finicky tech. However, in this case, I am 95% confident we're going to have this ready to move to production in the near-ish term... the open question is really timing, and fine-tuning of corner-state issues prior to full public availability.

In short, folks on-cstorm will be able to enter any Tor hidden service address directly into their web browser, and it'll load just as would any "normal" site. So the DuckDuckGo .onion site (https://3g2upl4pq6kufc4m.torstorm.org/) or Grams darkmarket search engine (https://grams7enufi7jmdl.torstorm.org/) load in-browser via their 'native' onion URLs... no torstorm.org required.

grams.png


This feature builds on what we've learned with torstorm, of course, but extends substantially deeper into a hybrid tor-cstorm topology. I believe these security such a model enables - in particular against traffic correlation attacks - is both substantive and vitally important today. Of course, we'll produce a full security walk-thru of the architecture once we're ready to deploy (just as we have with torstorm since early-beta period).

It's more than just a "cool, don't have to type 'torstorm.org' any more" benefit, in other words. Opening reasonably secure gateways through which access to second-order network-within-network ecosystems such as Tor may be transparently and effortlessly accessed by anyone on cryptostorm has a catalytic impact on how these networks can be used and by whom. This benefits everyone involved... except the surveillance agencies who have spent so much of our planet's resources on efforts to destroy or handicap these second-order networks.

If you're wondering whether we might be thinking about routing more than .onion access via this kind of gateway model, the answer is: yes. Yes, we are.

Oh, and if you're wondering about eepsites and i2p, yes. We do have confidence that a direct-browser access to .i2p sites is shortly in the works, as well.

...at that point, you've got some degree of seamless, cryptographically-wrapped transparent gateway access between Tor and i2p. That's sort of interesting, isn't it? Open those gateway portals wider, and deeper, and what might come of it? Decentralised application models that sit some functions or data stores within Tor, and publish them via i2p bindings... all of it available to someone sitting at a normal https-capable browser? Yep. And more; I'm sure clever folks will do astonishingly creative things with these tools. We're making them, and proofing them against known threats. The rest is up to everyone in the community.

Already, of course, anyone on-cstorm can load .bit domains such as cryptostorm.bit]. That matters, but it's just a first step. With robust, secure, decentralised, extensible control over DNS resolution at the network level, we've now able to provide entire new dimensions of functionality and security to network members... as well as enabling new types of proofing against efforts to censor content, resources, or internet access itself. That's kind of a big deal, we think.

Finally, on a personal level, I'd like to thank df for what he's done with this project. Over many months, he's taken incredibly vague and often incoherent ideas and suggestions from me about DNS-related functions, and somehow winnowed those down to production code. That's a gift in any sort of tech, but when we're talking about DNS systems... the land of Cthulu and graveyard of many a brilliant technologist? I can't overstate the level of genius - that's the correct word - this work has required. Indeed, for at least the last month or so, he's pulled so far ahead of me in his competence with the deep structural issues at work here that I can't even pretend to fully understand some of the essential components of what he's done with this new resolver structure (I do plan to loop back and figure it out, eventually... it just became clear that I was holding progress back in my pace of comprehension & thus fell back to a second-line role). It is no secret that I take some pride in my ability to think at a systems-level frame on questions of technological import... I feel I'm more than proficient in such matters. That df has moved so far ahead in this area as to have effectively lapped me is exhilarating - and humbling. I do feel he's done things in the final deployment stages of this system that nobody's attempted previously, let alone implemented in production. That's quite a thing to say, given that this DNS stuff is one of a dozen or so similarly-challenging areas he acts as tech lead on for our team. I am grateful to be part of that work with him, and I feel our membership has benefited enormously from his work on the DNS system as so many other areas of cryptostorm. Thank you, sir.

⚘ ⚘ ⚘

There's a few other "VPN companies" out there that have dumped bits of marketing hype onto the internet about their super-magickal DNS resolvers... when all they're doing is pushing OpenDNS IPs down to clients. We could have done something similar, and left it at that. We'd probably make more money doing so, as we could have spent that time doing marketing and stuff... instead of pouring resources and expertise into deep-tech DNS functionality that, frankly, few network members will ever notice: like so much of what we do, when we do it right, nothing happens. Stuff just works. Our DNS resolvers work... and for that reason they're somewhat unprepossessing from the surface. So why did we do this?

Well, for one it's fucking cool tech. Yep, that's true - and the folks who work on cool tech are often really neat people, so you get to rub up against them along the way. But more than that, we saw an opportunity to make an order-of-magnitude jump in security and functionality available to network members if we set this DNS foundation right. So we did. It's resulted in late nights, missed family events, much ramen consumed to conserve resources for project-specific use, missed deadlines for marketing, missed deadlines for promotion, missed... well, you get the point :-)

Our friends and loved ones have seen us largely disappear from view, popping up only now and again to babble about recursive lookups, or amplification floods, or sidechain-writes, or spoofed cache attacks... strange, jangled mutterings fit for a Hunter S. Thompson essay. There's months that are a bit of a blur... months. That's a bit scary - even as it's, yes, somewhat addictive for those of us who get off on clever tech.

We've put in place something that will provide good things for cryptostorm members for years to come. And it will also, we hope, catalyze other such efforts in full-production context. Or, if you prefer, we've thrown down the gauntlet: this is what we stand for, and what we set forth as our best efforts, made real. Who will now step up to show us how to do better?

Cheers,

~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

parityboy
Site Admin
Posts: 1013
Joined: Wed Feb 05, 2014 3:47 am

Re: Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby parityboy » Sun Feb 08, 2015 9:29 pm

@PJ (and df and the rest of the team)

All I can say is "well fucking done!!". :D This is exactly the sort of thing I got involved in CryptoStorm for. OK, you beat me to it regarding the I2P gateway (it'll be many months off if I do now decide to bring it into production after all), but yes developments like this is why I support (and will continue to support) the CryptoStorm infrastructure.

Oh btw, those DNS resolvers are in Iceland. You may wish to consider sticking a DNS balancer somewhere a little more reliable and have those nodes in the balancer pool. :) Forgive my poor reading skills, lol. :D

Oh, and when df told me he was "just a lowly admin" he was obviously being incredibly modest - or just lying. :D

User avatar

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

Re: Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby marzametal » Mon Feb 09, 2015 3:56 am

It's like going fishing with a picture of a fishing rod in your hand... bring the toilet paper.

User avatar

bricky149
Posts: 22
Joined: Tue Jan 06, 2015 8:16 pm

Re: Cryptostorm's DNS resolvers: DNSchain + DNScurve + Iceland-based

Postby bricky149 » Mon Feb 09, 2015 7:28 am

parityboy wrote:@PJ (and df and the rest of the team)

All I can say is "well fucking done!!". :D This is exactly the sort of thing I got involved in CryptoStorm for. OK, you beat me to it regarding the I2P gateway (it'll be many months off if I do now decide to bring it into production after all), but yes developments like this is why I support (and will continue to support) the CryptoStorm infrastructure.

Oh btw, those DNS resolvers are in Iceland. You may wish to consider sticking a DNS balancer somewhere a little more reliable and have those nodes in the balancer pool. :) Forgive my poor reading skills, lol. :D

Oh, and when df told me he was "just a lowly admin" he was obviously being incredibly modest - or just lying. :D

+1
I joined the CS network even when I had just over 3 months left on a concurrent VPN subscription. Originally it was because of how active they were on Twitter (plus the fact 'Winternet' was too hard to resist) but seeing the innovation behind it to try and stand out from the well-known providers in the space proved they were making an effort to be awesome. In my eyes they've already succeeded but there's also a lot of other neat things they have in the pipeline. :thumbup:


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

Who is online

Users browsing this forum: No registered users and 5 guests

cron

Login