North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)

  • From: John Palmer (NANOG Acct)
  • Date: Tue Jul 05 21:34:49 2005

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" <[email protected]>
To: "NANOG" <[email protected]>
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                                                [email protected]
> 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
> 
>