Differences between revisions 2 and 3
Revision 2 as of 2011-08-20 02:38:20
Size: 2596
Editor: ?IvanSavov
Comment: dyndns discussion + proposal for DynDNS server under the control of the user
Revision 3 as of 2014-12-01 05:04:15
Size: 2596
Comment: Update link to Router page
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This page is for working on how to configure [[http://www.dyndns.com/support/kb/using_inadyn_with_dyndns_services.html|inadyn]] as part of a [[FreedomBox/router| FreedomBox Router]] This page is for working on how to configure [[http://www.dyndns.com/support/kb/using_inadyn_with_dyndns_services.html|inadyn]] as part of a [[FreedomBox/Router| FreedomBox Router]]

This page is for working on how to configure inadyn as part of a ?FreedomBox Router

Required information

As part of the freedom box setup process, the user is prompted to register with a ?DynamicDNS provider, and supply the following required informaiton:

  1. domain : domain name registered with dyndyns

  2. dyndns_username : @dyndns.com

  3. 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 ?

Script

A configuration formula fills in this template and puts it in /etc/inadyn.conf:

   1    # Basic configuration file for inadyn
   2    #
   3    # /etc/inadyn.conf
   4    update_period_sec 600 # Check for a new IP every 600 seconds
   5    username $dyndns_username
   6    password $dyndns_password
   7    dyndns_system dyndns@dyndns.org
   8    alias $domain

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?)


CategoryFreedomBox