[82007] in North American Network Operators' Group
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
daemon@ATHENA.MIT.EDU (John Palmer (NANOG Acct))
Fri Jul 8 15:32:16 2005
From: "John Palmer (NANOG Acct)" <nanog@adns.net>
To: <nanog@merit.edu>
Date: Tue, 5 Jul 2005 20:29:55 -0500
Errors-To: owner-nanog@merit.edu
I have the BIND source, its available to the public.
You want to know how hard it is? I'll show you. I will
write it. Thats what I do for a living.
I accept your challenge. See you in six months.
FYI: I don't speak for anyone but myself and ADNS/American Webmasters.
----- Original Message -----
From: "Jay R. Ashworth" <jra@baylink.com>
To: "NANOG" <nanog@merit.edu>
Sent: Tuesday, July 05, 2005 6:37 PM
Subject: Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
>
> On Wed, Jul 06, 2005 at 01:06:15AM +0200, Brad Knowles wrote:
> > > To many alt-roots? Or too many alt-TLD's?
> >
> > Too many of the former is likely to lead to having too many of
> > the latter. Both are bad.
>
> I don't know that I agree with either of those assertions, absent
> collision problems, personally, but this subthread officially makes
> this a religious argument; comments here off-list.
>
> > >> The problem is that they are pretty much guaranteed to get at
> > >> cross-purposes.
> > >
> > > Well, there have been alt-root zones available for, what 6 or 7 years
> > > now? And how many collisions have there actually been in practice? 2?
> > > 3?
> >
> > We have not yet hit the knee of the curve.
>
> Perhaps. I think those people are *much* more concerned about this
> than I think you think they are.
>
> > >> I don't think that's really practical. I'm sorry, I just don't
> > >> trust them to write a resolver that's going to get included in libc
> > >> (or wherever), and for which the world is going to be dependant.
> > >
> > > Well, I meant "at your customer recursive resolver servers", since the
> > > topic at hand was "what do IAP's do to support their retail customers",
> > > but...
> >
> > I don't trust them to write code that will be used in
> > mission-critical situations or places, regardless of where that is.
>
> Wasn't sure which them you meant here...
>
> > It's not that they don't have the best intentions -- I'm sure
> > that at least some of them do. It's that they don't have the
> > necessary experience.
> >
> > The people I would trust to have enough of the right experience
> > to make something like this work (if that's possible at all) are the
> > same people who wrote Nominum's ANS and CNS. However, I suspect that
> > they would probably be about the last people in the world who would
> > be interested in trying to make something like this work.
>
> And then I figured it out.
>
> Hmmm... again, absent TLD collisions, I don't see that writing a
> recursive-only server that can coalesce the TLD namespace from multiple
> roots ought to be *that* hard... but then I'm not Cricket, neither.
>
> > >> People will always be able to access data by pure IP address, or
> > >> choosing to use the real root servers. Push come to shove, and the
> > >> real root servers could be proxied through other systems via other
> > >> methods.
> > >
> > > "Real" is *such* a metaphysical term here, isn't it? :-)
> >
> > Heh. Shall we use the term IRS? As in Incumbent Root Servers?
>
> I don't have a problem with that one, the amusing connotations
> notwithstanding. Incumbent isn't a value judgement, it's merely
> descriptive.
>
> > >> The reverse problem is more difficult to deal with -- that of
> > >> people wanting to access Chinese (or whatever) sites that can only be
> > >> found in the Chinese-owned alternative root.
> > >
> > > Stipulated. But whose problem *is* that?
> >
> > The users will make it our problem, if we don't get this sorted out soon.
>
> Yup, it is.
>
> And my perception is that the cat is *out* of the bag, and fretting
> about how bad it would be were the cat to get out of the bag (which is
> my perception of most people's view of this issue) isn't especially
> productive; the solution is to figure out how to manage the problem.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth jra@baylink.com
> Designer Baylink RFC 2100
> Ashworth & Associates The Things I Think '87 e24
> St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
>
> If you can read this... thank a system administrator. Or two. --me
>
>
