[discuss] So-called alternate roots

Seun Ojedeji seun.ojedeji at gmail.com
Sat Jan 4 06:44:32 UTC 2014


I am quite a newbie in DNS. In summary, I had understood the alternate root
to be a copy of the main root and there is a master root which has the
capability to update all the other 8 main roots, while individual roots
provide copies to their several alternates (since there was v4 limitation
that then created the anycast option that enabled user to be able to
communicate as if it was a single root). Are we then saying those
alternates are indeed also authoritative roots i.e they send updates to the
root servers?

Cheers!

sent from Google nexus 4
On 4 Jan 2014 02:00, "Brian E Carpenter" <brian.e.carpenter at gmail.com>
wrote:

> Michel,
>
> On 04/01/2014 11:45, Michel Gauthier wrote:
> > At 00:01 03/01/2014, Andrew Sullivan wrote:
> >> Hi,
> >>
> >> On Thu, Jan 02, 2014 at 11:19:30PM +0100, Michel Gauthier wrote:
> >> > ICANN ICP-3 multi-root competition?
> >>
> >> If I may ask, what does it even possibly mean to talk of "multi-root"?
> >
> > I am not a specialist Iike you. I just trust the people in charge and
> > use their words and expertise.
> >
> > The people in charge (ICANN) state the "policy currently followed in
> > administering the authoritative root of the Domain Name System"
> > "provides a facility for future extensions that accommodates the
> > possibility of safely deploying multiple roots on the public Internet"
> > as "ultimately there may be better architectures for getting the job
> > done where the need for a single, authoritative root will not be an
> issue".
> >
> > http://www.icann.org/en/about/unique-authoritative-root
>
> This isn't the first time people have wished to rescind the laws
> of mathematics. If a name space is to be unambiguous it must
> have a single logical root and that is not going to change, even
> ultimately. There could be other implementation techniques that
> would hide the single root from view, although I can't see why
> that would be an advantage.
>
> (That kind of solution, which I investigated at a very abstract
> level a few years ago, requires independent allocation engines
> to communicate with each other to either deny an allocation
> request or to guarantee that it's unique. Although that doesn't
> require a single engine to act as the root, it does require the
> entire set of allocators to communicate with each other. That's
> a lot of complexity for no obvious advantage.)
>
> Regards
>      Brian (2/4 for 2014-01-04 NZDST)
>
> _______________________________________________
> 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/20140104/9c5b2bbc/attachment.html>


More information about the discuss mailing list