[Freedombox-discuss] http://politics.slashdot.org/story/11/07/18/0153204/Security-Consultants-Wa rn-About-PROTECT-IP-Act

[Wookey]

+++ Bjarni Rúnar Einarsson [2011-07-21 19:16 +0000]:
> On Thu, Jul 21, 2011 at 5:44 PM, ian at churchkey.org <ian at churchkey.org> wrote:
> 
> Depending on what you want, updates are actually a built in feature of servers
> like bind these days, using recent-ish additions to the DNS standard. 

True, but I've enjoyed life noticeably more since I stopped using bind
and used either DNSmasq or DJBDNS. The former doesn't support dynamic
DNS updates, and so far as I know neither does the latter. Perhaps the
right things to do is make them support this.

> However,
> as is often the case, the devil is in the authentication details:
> 
>    * How do users sign up?
>    * Where is the user database stored?
>    * What is the policy regarding usage/traffic/billing/... ?

I must admit I don't understand why that last is relevant.

> I am not aware of off-the-shelf solutions that handle the signup/user-database/
> web-based updates, and I'm not sure how well the protocols actually support the
> dynamic DNS service provider use-case...
> 
> For historic reasons (I am pretty sure dynamic DNS service predates native DNS
> support for updates), most of the dynamic DNS providers out there do not
> actually use the DNS standard updates at all - instead they provide a web
> interface for new users to sign up, and then a simple web-based API for sending
> in updates as well.

> These ad-hoc web-based protocols are actually what most routers support out of
> the box (anyone please correct me if I am wrong about this) -

No, that's correct, as I said earlier.

> and although they
> are non-standard, it's a lot easier to tell a developer to just fetch https://
> username:password at dyndnasprovider/update.cgi?ip=1.2.3.4 (or the equivalent)
> than it is to get them to craft authenticated DNS update packets.

Yes. It's very simple on the client end but it makes config on the
server end fiddly. 

> When looking through all this stuff for the pagekite.py and the service, I
> ended up emulating the existing dynamic DNS services and provided a web-based
> update service, ignoring the DNS spec entirely and aiming for compatibility
> with the existing dynamic DNS providers.  I have already open sourced most of
> my back-end code, the only thing I haven't released is the web-based updater,
> but I would be perfectly willing to do so if someone wants to try and clean it
> up for reuse and packaging.  My signup and account management stuff OTOH is too
> tightly integrated with the PageKite service to be easily reused, it would
> probably be cleaner to just start from scratch.

OK. That's interesting, and useful as, if packaged, it fills the hole
in question: Server side of DDNS updates. But I worry that it's tricky
to package anything that needs to fiddle with apache/other web-server
config because web-server configs are so variable.

Which is why I thought a siple-minded update over scp was much easier
to make generic (given working ssh), and the authorisation is
intrinsic in having that connection. But as you say, there is an
official mechanism for this now - we should probably just use it. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/