North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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, Valdis.Kletnieks@vt.edu 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
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.