As part of the freedom box setup process, the user is prompted to register with a ?DynamicDNS provider, and supply the following required informaiton:
domain : domain name registered with dyndyns
dyndns_username : @dyndns.com
dyndns_password : @dyndns.com
Note: Are there other options other than dyndns.com ? Should we run some sort of distributed naming service? This would probably be easier if to begin with we offer a dyndns service for subdomains of freedomboxfoundation.org ?
A configuration formula fills in this template and puts it in /etc/inadyn.conf:
then sets up the appropriate rc2.d/ boot script, and starts the service.
More than DynDNS
There are certain advantages if we expand the design of the freedombox to include a partner cloud node for each freedombox node at home.
The cloud node (cn) is assumed to be operated by an untrusted party (a hosting provider) and thus plays only the role of authenticated intermediary for messages sent to the home node (hn).
Suppose an encrypted packet destined for the freedombox hn is sent by another peer. If the home node is offline (due to connectivity problems, or by user choice) then the cloud node can store the message. The next time hn connects to the internet the missed messages can be recovered.
Privacy: The cloud node cannot decrypt messages destined for hn. It can just store them.
Authentication: If the application requires the that the node-to-node communication be authenticated, then we could use the home node's private key to sign a Certificate for the cloud node which authorizes it to act as a representative (for .
The cloud node cn could serve as a DNS server for the user domain. Assuming the cn does not get hacked, the user will have full control of the DNS service for his "profile" domain. In particular, as soon as the home node comes online the domain name will be redirected to the home node. (do it yourself DynDNS?)