[discuss] Real world Impact of multiple roots

Tue Jan 28 20:33:01 UTC 2014

This discussion about alternate root depicts how much we usually tend to confuse {technical] possibilities and their effective implementations. In the world we leave today, it is mainly Economic Power (either political, financial or social business) that drives the sustainable implementation of any possibilities out there. If 10 years ago we were having a debate on the ability of one single agency/Company (because the issue of privacy is not only NSA issue) to be able monitor a wide scale of data on the Internet, I'm sure we will have the same sort of arguments around the fact that it practically impossible because complex, difficult to mange, irrealistic, not cost effective etc … untill it happens (or disclosed that it sort of happening). My personal view is that anything that can be thought, articulated, and expressed can also be done if someone/something/a_business reality give it enough interesting value. So instead of looking at if it is possible or not why not see what the impact will be an and see how to mitigate its impact, be prepared to deal with it smoothly in oder not to have the surprise factor anymore? That could be a very interesting legacy we can leave for the future.

- a (my personal view). 

On 2014-01-28, at 23:14 PM, David Cake <dave at difference.com.au> wrote:

> I agree with Avri that multiple roots are something we should be aware of, and strive to understand, and likely will happen in some form. There are multiple alternate roots currently in operation - they just have insignificant numbers of users. All it would require is for one of them to pick up significant user adoption, and we'll have to deal with it. 
> 
> And we need to be aware of the different forms of alternate root, and the different responses they require. I think most alternate root proposals are likely to be those that resolve the majority of names in current use the same way - that is, roots that supplement the existing ICANN root (and there have been multiple projects of this type over the years, AlterNIC, new.net, ORSC etc). 
> 
> Such alternate roots that will keep most of the ICANN zones, but add some more, have been tried before, and seems unlikely to succeed on a broad scale unless the added new domains carry some obvious advantage, such as enabling new services by a different resolution method. 
> 
> But what if there was a significant different in resolution method, such that there was a strong incentive to adopt such a 'supplementary' root? The TOR .onion (and .exit, etc) domains are a fledgling example of that. The namecoin .bit domain is another. Technically such 'domains' aren't alternate roots at all, as they don't use the standard DNS architecture for resolution at all (indeed, the whole point of the TOR system is it doesn't give you the destination IP address), but they use the DNS namespace. I can imagine scenarios in which similar technology was in broad enough use that it became a true alternate root. Would such alternate roots, where the ICANN root was supplemented by some additional domains, be a problem if ICANN did not attempt to allocate such domains, so there was no name collisions? Certainly the IAB, in RFC 2826, strongly condemns alternate roots, but would it really be a problem if non-technical methods were used to minimise name collisions? If ICANN never allocates .onion, .exit and .bit it is hard to see how their use in an alternate name space would cause any problems at all. The TOR .exit syntax also gives us one possibility for how we might deal with genuine widespread alternate roots making domain name resolution problematic, and it is fairly ugly (the ,exit syntax is used to specify a particular TOR exit node by adding a suffix to the name to be resolved). 
> 
> It is also conceivable to think of alternate roots that contained the same domain names as the ICANN root, but instead of (or as well as) supplementing the list, deliberately removed some names such that they became unresolvable. It is certainly obvious that this could be done for reasons of censorship etc, but it is such a simplistic and easily system that hopefully few nations would be naive enough to implement it, or at least to expect widespread adoption. At a level below the root, the BIND dnsrpz feature has been around for a few years now, and so features to enable non-resolution of domain you dislike have been widely deployed for a while. An alternate root that took some things out would just be moving that feature to the root level - but it is hard to see how it wouldn't be widely circumvented if imposed. We will see such systems widely deployed - but generally as ISP or company wide DNS resolvers, rather than true alternate roots. Does this represent the same fragmentation of the name space that alternate roots do, just a milder form? Perhaps.
> 
> That leaves the case of true alternate roots, that ignore the root zone as we know it entirely. I frankly can't see much reason why this would ever happen - and if it did, we probably would even think of it as an alternate root, but as a separate service (I can't think why we would want a completely separate root for IP address resolution or why it would become popular, but I can conceive using the DNS technology but dealing with different record types). 
> 
> Regards
> 
> David
> 
> On 29 Jan 2014, at 12:01 am, Avri Doria <avri at acm.org> wrote:
> 
>> 
>> 
>> On 28-Jan-14 07:51, Milton L Mueller wrote:
>>> Interesting pre-emptive move for David to
>>> suggest that something he doesn't want
>>> cannot and should not even be studied.
>> 
>> 
>> I have been told that by various people for about a decade.
>> 
>> The issue as I understand it, if we condone studying then that will be seen as condoning the idea of multiple root and make it more likely to happen.
>> 
>> I have always maintained that it can and will happen and that we need to be ready with the way to heal it and create the next order Internet before it happens.  But I never had either the convincing power or money to do anything about it.
>> 
>> So here we are 10 years later still having the same arguments, though on a more global scale.  That is a change.
>> 
>> I also still maintain that it is the addressing and routing that determines whether we have one Internet or more.  And we even seem to be finding ways to heal the actuality of having two internets at the IP level (v4 & v6) and in routing for v4 and v6, enough so most think of it as a single Internet still to this day.
>> 
>> I admit it is not as clean and as easy for incumbent businesses to deal with multiple roots and it will affect their bottom lines in some short term and temporary way. But there will also be multiple businesses that starting up in response and, while I don't pretend to be economist, it seems they might offset each other to some degree.  Not that this is my greatest concern - maintaining global discovery and reachability is.  I am curious to see if ICANN's blue ribbon panel on naming, or whatever they call that one, is actually going to face the realities of multiple roots or are going to stay true to the world view that "There can be only one"  and require that all solutions adhere to that article of faith.  As the incumbent authority, that would certainly be to ICANN's advantage.
>> 
>> As long as name authorities can be isolated so as to make references globally unique, the naming systems is just business, like the people competing over which phone book I use in Rhode Island.  Strangely enough I still have the same telephone connectivity, despite having multiple phone books. And incidentally there are names in each of these books, that don't show up in the other books and sometimes my search needs to drop down to the next favorite look-up mechanism.
>> 
>> avri
>> 
>> _______________________________________________
>> discuss mailing list
>> discuss at 1net.org
>> http://1net.org/mailman/listinfo/discuss
> 
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net.org/mailman/listinfo/discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 313 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140129/6a9b4d9d/signature.asc>