[discuss] Real world Impact of multiple roots

Wed Jan 29 14:32:35 UTC 2014

sent from Google nexus 4
On 29 Jan 2014 09:20, "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.
>
+1 some things are just 1+1=2 while others could give 11. In the case of
naming one root +another root (perhaps icann) will always be equal to a
single digit number of 2(single root) otherwise we did find ourselves
breaking what is not yet broken.
Also naming is a business world, where the best marketer gets his/her root
used. Why then should we worry ourselves in trying to make a name for other
alternate DNS root service providers, if they themselves have not done
their homework.

Cheers!

> 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
> >
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140129/7cda59d4/attachment-0001.html>