As part of building a true "dark network", it would be nice if CS offered an on-network DNS resolver. As noted in the linked thread, it would be a fully trusted DNS resolver and additionally (the most important part) it would be a able to support an unregistered on-network TLD, for example ".storm" or ".cs".
This in turn would open up the possibility of on-network, addressable server resources. However, due to the fact that Cryptostorm uses DHCP to provision non-routable IP addresses to clients, stable IP addresses are not available. This though can be mitigated by the deployment of DynDNS.
Typically, DynDNS services are accessed by a user using standard credentials - email/username and password. In contrast, Cryptostorm network connectivity is accessed using an anonymous, randomly generated and hashed token for a username, with a default password.
So similarly to the OpenVPN access offered by Cryptostorm, I propose that such a DynDNS service should use a default password. So then, what should the username be? It can't be a non-persistent anonymous token, because the domain name chosen by a Cryptostorm user must be able to be looked up against something in order to assign it to that user.
So what would be a suitable username? The possibilities are:
- 1) Disposable email address. Easily done, and oddly enough GMail would be ideal for this because:
- i) it's free
- ii) it's easy enough to create <random 36-character uuid>@gmail.com, for an email address that won't see any other use.
- 2) Unused BitMessage address. Again BitMessage uses a random string of characters to represent an address.
- 3) Unused Bitcoin wallet address. Similar to BitMessage, a Bitcoin address is a randomly generated string of characters.
I am not intimately familiar with the Cryptostorm network architecture, but I have taken some educated guesses. Assuming those guesses are inaccurate (I have to assume that they are) and assuming that each VM running on a given cluster node does NOT have it's own DHCP server, and that there is in fact one DHCP server per cluster which provisions connected clients with an IP address, it still means that each cluster has its own 10.55.x.x IP range for clients.
This in turn means that a darknet server connected to a given cluster will not be addressable from another cluster. However, this can be mitigated by
- a) replicating DynDNS data between clusters.
- b) a user's darknet server having a router in front of it which is connected to each cluster's OpenVPN server, and also to each cluster's DynDNS server. pfSense supports this.