[Freedombox-discuss] distributed DNS
On Tue, Mar 15, 2011 at 01:45:51PM +0000, Bjarni R?nar Einarsson wrote:
> On Tue, Mar 15, 2011 at 12:36 PM, <bertagaz at ptitcanardnoir.org> wrote:
> > Yeah, the idea is to build a dynamic DNS service, distributed if possible.
> > I see no point in building a freedombox if its DNS system is based on
> > "cloudy" (or mainstream if you prefer) services like dyndns.
> Hmm. If millions of people use Freedom Boxes, whatever they rely on will by
> definition become "mainstream".
> Again, what problem are you trying to solve? I am going to assume you
> aren't being anti-business just for the sake of being anti-business. :-)
I'm afraid my political opinion on this subject hasn't much to do in the
discussion, and it won't serve it to reply :)
> Dynamic DNS providers have very little chance to spy on you, and (assuming
> you use your own domain name) if they don't play nice, you just switch to a
> different one. Why do they need to be replaced? There are quite a few
> options out there, including some very community-minded ones like
Dynamic DNS providers have a hudge chance to spy what IPs your domain had
since you registered. And to me (an I don't think I'm the only one) that
is an important problem. What are the logging practice of the
community-driven one you talk about? Do they have privacy/anonymity in
If one of the freedombox project goal is to "take back users data where they
belong", why not this (important) one?
But I don't see a problem to offer both solutions, and let users choose.
> If you use a "free" subdomain, then it does become very important to choose
> a provider carefully because you'll probably be forced to discard the name
> if or when you move. But from the point of view of the average Joe that
> problem is not made obviously better by replacing commercial interests with
> those of idealistic volunteers - both can be equally fickle, provide good or
> bad service, change their minds or simply go broke.
> Rather then charging off to just replace all the existing providers out
> there, I would much rather see a considered discussion on what
> characteristics a "FreedomBox friendly" provider of DNS services should
> have, and an evaluation of the existing options to see how they measure
> Well, pay the bill for a DNS domain at least, not that expensive though.
> > Some are already rented by people around here.
> > Bandwidth shouldn't be a problem if the system is decentralized. I guess
> > the best would be for such a system to be able to support multiple domain
> > name, so that if some fb user wants to own and use one, he/she could
> > manage it.
> What do you mean by decentralized? I hope you don't intend to replace the
> small number of commercial entities who can currently
> coopt/corrupt/manipulate my DNS records with a much larger number of
> decentralized, anonymous volunteers who can all do the same thing! :-)
Decentralized is probably a confusing term, I was meaning a system where
users control their dns registration themselves, without any central
But all this is just a problem I'm thinking about and that would need a
lot of design to be really consistent.
> DNS is by nature hierarchical, DNS servers are assumed to be trusted.
> You can't just "decentralize" the system any more than it already is,
> without raising serious security and trust issues.
Depends. What if the user can register his/her sub-domain when getting a
freedombox, maybe associating this domain to a gnupg ID, and then use some
gnupg mechanism to update its NS delegation record in the top domain DNS
pool, pointing it to his/her current IP? Then he/she could control his/her
subdomain, add other subdomains, etc. And update this record when his/her
> > I've implemented a dynamic DNS service, on top of powerdns and redis.
> > It's
> > > part of the infrastructure behind pagekite.net. I wouldn't mind sharing
> > > that code, I am sure some peer review would do it good. :-)
> > Nice, sure I'd like to see/test that. I'm not a lot in redis and all, but
> > might be usefull in the futur.
> OK, I'll see about getting the code out later today - at least the bits
> which are loosely coupled from the pagekite.net service internals.