ISP network design of non-authoritative caches

Mon Nov 19 23:15:16 UTC 2001

At 11:13 AM 11/19/01 -0500, Valdis.Kletnieks at vt.edu 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

--
###