[discuss] Real world Impact of multiple roots

Thu Jan 30 03:00:33 UTC 2014

I think much of the discussion in SSAC09, the 2006 report on alternate roots http://www.icann.org/en/groups/ssac/alt-tlds-roots-report-31mar06-en.pdf,  remains relevant, though obviously the advent of new commercial gTLDs removes almost of the commercial interest in new TLDs via alternate roots, and the demand for alternate roots to support IDNs has been mostly removed due to the hard work put in by many people at ICANN to get to the point of allocation of IDN TLDs. That still leaves categories such as experimental registries (Namecoin is a current example), private domains, political and protest motivated domains. 

Regards

David

On 29 Jan 2014, at 4:19 pm, Steve Crocker <steve at shinkuro.com> wrote:

> Right.
> 
> The larger question is what is the problem that is driving this discussion?  What isn't working?  Many of us on this are having trouble understanding why it's useful to discuss "multiple roots", which I put in quotes because I think the term means different things to different people.
> 
> Steve 
> 
> Sent from my iPhone
> 
>> On Jan 29, 2014, at 10:15 AM, David Cake <dave at difference.com.au> wrote:
>> 
>> An excellent point, Steve. It is easy to consider how such a system would exist without DNSSEC, but it would be significantly more complex to implement with DNSSEC. I admit I'm not knowledgable enough about DNSSEC to know if it could be achieved with DNSSEC Lookaside Validation or similar (though its my understanding that DLV was designed for a multiple trust anchors?). 
>> It is easy to see that those willing to adopt such alternate roots might be willing to use an alternately configured DNSSEC validator that would permit the use of such domains, but it would certainly raise difficult questions about managing multiple trust anchors, and potentially weaken the protection afforded by DNSSEC. 
>> 
>> Regards
>> 
>> David
>> 
>>> On 29 Jan 2014, at 2:38 pm, Steve Crocker <steve at shinkuro.com> wrote:
>>> 
>>> The end systems would also need multiple trust anchors.
>>> 
>>> A deeper problem is that DNNSEC provides definitive assertions about the non-existence of undelegated names, so there really isn't any room for "supplemental, non-overlapping" names.
>>> 
>>> Steve
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jan 29, 2014, at 8:28 AM, David Cake <dave at difference.com.au> wrote:
>>>> 
>>>> 
>>>>> On 29 Jan 2014, at 1:30 am, David Conrad <drc at virtualized.org> wrote:
>>>>> 
>>>>> Milton,
>>>>> 
>>>>>> On Jan 28, 2014, at 4:51 AM, Milton L Mueller <mueller at syr.edu> wrote:
>>>>>> On Jan 26, 2014, at 10:55 PM, Ben fuller <ben at fuller.na> wrote:
>>>>>>>> Does anyone out there know of studies on the economic impact that having two or more root zones.
>>>>>>> 
>>>>>>> As far as I am aware, current technology does not support more 
>>>>>>> than one root zone, so I'm not sure how such studies could have been done.
>>>>>> Interesting pre-emptive move for David to suggest that something he doesn't want cannot and should not even be studied.
>>>>> 
>>>>> Fascinating assumptions about what I want and believe can or cannot and should or should not be studied.  Wrong, but fascinating.
>>>>> 
>>>>>> It is not inconceivable to coordinate separately administered root zones, depending on the rate of change in either one. I've modeled the problem in an academic paper published more than 10 years ago.
>>>>> 
>>>>> Well, since you have written an academic paper and are clearly the expert: please point me to the _current technology_ that supports "two or more root zones".  Not the coordinated _single root zone_ you posit below (which is blatantly obvious but _not_ what Ben asked). Specifically, what name server software, what resolvers, and what applications exist that can deal with "two or more" instantiations of the DNS namespace as represented by different root zones (presumably simultaneously)?
>>>> 
>>>> Milton said separately administered, not separately resolved. It is trivial to have a root zone server that peers root zone file changes from other root zones (yes, it needs rules to resolve incompatibilities, but this isn't that complicated) as long as the other root server allows zone transfer. 
>>>> So it is trivial to have multiple roots that peer each other (and indeed, they exist now - for example OpenNIC (http://www.opennicproject.org/) peers multiple alternate root zones into one), as long as there are rules for resolving clashes (ie root zones that give different info for the same TLD would be a problem, but a peered root zone could simple choose one on a simple priority rule). Virtually all existing alternate roots peer the IANA root. 
>>>> Whether this constitutes supporting two or more root zones is really an implementation detail - whether it is built into the DNS protocol itself, or we use zone transfer (AXFR) and a script, doesn't seem a significant detail. 
>>>> 
>>>> BTW, Milton, is this the paper you were referring to? http://arxiv.org/pdf/cs/0109021.pdf 'Competing DNS Roots: Creative Destruction or Just Plain Destruction?'
>>>> 
>>>> 
>>>>>> thus "solving" the problem tautologically but overlooking the real institutional, economic and operational differences between coordination that is hierarchical and coordination that comes from bargains among autonomous actors.  
>>>>> 
>>>>> The point you appear to be missing is that regardless of whether coordination is hierarchical or non-hierarchical, the end result is a _single namespace_. Most of the folks who get excited about multiple roots want their own namespace and want to impose that namespace on others.
>>>> 
>>>> It is trivial that if one operator can create a new root zone file that combines multiple zone files into one, then a second operator can do so using different rules for combining sources. 
>>>> 
>>>> If the desire to create a new namespace is strictly supplemental - i.e. if they want to add separately administered namespaces, but not remove or override the namespaces of others - then this isn't problematic. Indeed, it has happened a few times on a fairly large scale (eg experimental Chinese IDNs). As noted in Milton's paper, what he calls Type 2 competition in that paper mentioned above, but I'm calling 'supplemental' (taking the terminology from Vottorio Bertola here http://www.wgig.org/docs/book/Vittorio_Bertola.html ) is invariably the form alternate roots take. Direct clashes between the IANA root and alternate roots has happened only when ICANN allocated TLDs knowing that they were already in use in alternate roots (e.g. .biz). 
>>>> It is only when namespaces clash that the desire to 'impose that namespace on others' becomes really problematic, and it seems fairly likely that any alternate root that desires to overrule the IANA root would have even more negligible take up than supplemental alternate roots, so we are left only with those who are in dispute over namespaces not allocated by ICANN, and that can be resolved by simple rules of prioritisation within the process by which your peered root zone file is created. 
>>>> 
>>>> The real issue, as Milton suggests, is what should ICANN (as the administrator of the authoritative namespace) do about such supplemental namespaces - ignore them entirely, actively discourage them, treat them as experimental spaces that might ultimately be acknowledged (either by migrating them into the IANA root zone, or by permanently reserving them so that there will never be a clash), etc. 
>>>> 
>>>>> You are in essence saying "let's coordinate the multiple namespaces" but that simply results in a coordinated single namespace. There are a myriad ways in which to solve the coordinated single namespace problem (hint: ICANN is one of them). That isn't (as far as I can tell) what Ben was asking about.
>>>> 
>>>> No, there might exist multiple namespaces that largely share (in that is likely they would be supplementing the ICANN namespace, but not actively clashing with it), but are mutually incompatible (in that multiple namespaces have different assignments for various supplemental names). This would be neither a single coordinated namespace, nor a totally competing namespace, and I would argue is easily the most likely scenario for competing alternate roots (and to some degree, is the situation we currently have, it is just that currently the take up rates of alternate roots are extremely small). 
>>>> 
>>>> Cheers
>>>> 
>>>>     David
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140130/a044c40c/signature.asc>