North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: ISP network design of non-authoritative caches

  • From: Simon Higgs
  • Date: Mon Nov 19 18:35:26 2001 
At 11:13 AM 11/19/01 -0500, [email protected] wrote:

On Sun, 18 Nov 2001 17:56:44 PST, Simon Higgs said:

> prevail and that running code and rough consensus demands the peering of
> non-conflicting TLDs for everyone's benefit. It's a common practise in

Hmm..  "non-conflicting".  Let's think about this for a moment.

Let's assume we have 3 TLD managment groups called A, B, and C.  In order
for there to be non-conflicting roots, A, B, and C have to enter into some
sort of agreement that if A registers a TLD .frobozz, that B and C will
promise to not register a conflicting definition of said TLD.

So what we really have here is (A+B+C) functioning as a single root, but
A, B, and C individually publishing only a subset of the root to their
customers (although why the customers want a value-subtracted view of the
DNS is beyond me).
Most alt.roots started off in order to support a specific set of TLDs which were supplemental to the legacy root. The legacy root was used as a baseline, and for whatever reason, the TLDs in question were not able to be added directly to the legacy root. So root A publishes the legacy root plus .FOO, and root B publishes the legacy root plus .BAR - and remember this occurred totally independently. Later, these roots discover each other and decide it would be easier for all their users if they peered their non-conflicting TLDs. So root A adds a stub for .BAR and root B adds a stub for .FOO. OK so far. But this doesn't address conflicts.

So, to name names - if the ORSC crew and the ICANN crew were to collaborate
on a non-conflicting definition of "the root", then the composite of the
two of them would be a root, with each feeding only a subset to their
customers.
In the unlikely event this happens, it needs to be a true peering where ORSC publishes all the non-conflicting ICANN TLDs in its zone, and ICANN publishes all the non-conflicting ICANN TLDs in its zone. Any conflicting TLDs are noted by which zone is used. Ideally, the goal is zero collisions. You know, "rough code" and "running consensus" and good stuff like that. ;-) This type of cooperation exists outside of the legacy root. Just not inside it. :-(

Of course, such collaboration is *NOT* happening in the real world, so we
*will* eventually see a conflict.  It will probably happen the first time
ICANN allocates a new TLD that ORSC carries, but nominates a different
registrar or a different server on the NS record for the TLD.
You're right. But ICANN has already done this. The conflict already exists. The collider is .BIZ and it was introduced by ICANN a few months ago. In addition, moving .US to the ICANN .BIZ name servers only screws things up worse. Even ICANN's Karl Auerbach has already noticed the cache pollution problems. If you use a name server within .US, your cache will eventually be polluted. I say let it break, but folks in the ORSC think they can stop the NS pollution at least within ORSC, which just lets ICANN's uncooperative behavior continue to go unnoticed by the masses.


Best Regards,

Simon

--
###