North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: ISP network design of non-authoritative caches
At 11:13 AM 11/19/01 -0500, [email protected] wrote:
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.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).
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. :-(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.
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.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.