ICANN/DNSO
DNSO Mailling lists archives

[ga-full]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: ITU and BIND configs (Re: [ga] GA position on Verisign contract)



> From: Harald Tveit Alvestrand [mailto:harald@Alvestrand.no]
> Sent: Sunday, April 01, 2001 2:13 PM

> At 02:19 01/04/2001 +0200, Jefsey Morfin wrote:
> >New.net is obviously a wrong example since they are not at 
> root level.

> ns1.earthlink.net, which belongs to an organization that 
> new.net claims as 
> a supporter, responds to a query for NS records of shop. with 
> the reply 
> that shop. has NS records pointing to udns1.newdotnet.net and 
> udns2.newdotnet.net

> Care to define how you understood "at root level"?

Actually, they appear to be running their own root zone. Jefsey may be
slightly incorrect here.

> >Harald, what I say is simply that if BIND was written in a slightly 
> >different way, the whole conception of the iCANN and the USG will be 
> >different. Exactly like if the use of the DNS was slightly 
> different the 
> >whole TM issue would be different. This you should undestand 
> and know. 
> >(Will I have some spare time, I will pick and change my 
> named code and use 
> >it for my own root).
> 
> Please.....if the DNS (as defined by RFC 1035 and associates) 
> had been 
> slightly different, it would not have been the DNS.
> And if men were more friendly, we would have less anger.
> So what?

I seriously disagree. BIND, from its infancy, has been crippled. The reason
for the disability was that, at the time, no one wanted to chase down
recursive effects beyond the current design. The reason is simple and
admirable, there were already too many unkowns, at the level that they did
stop, and there was no forseeable benefit to going beyond that point. The
architects drew a semi-arbitrary line in the sand and said "we stop here,
for this moment". Now, those unknowns exist no longer and be need to go
beyond that line. To claim that this would make it no longer a DNS system is
fallacious. As an architect, I might have done the same thing. But, as an
architect, freezing the design there, in perpetuity, is just plain wrong. A
design that cannot grow and mutate with changing requirements is a bad
design. Fortunately the DNS doesn't fall into that catagory. Stopping
innovation by artificial/political means is equally as wrong. In fact, it
can't be done. The open source movement has proven that admirably. BIND is
open-source.

Please allow me to repost something I sent to the DOMAIN-POLICY list;

> -----Original Message-----
> From: Roeland Meyer [mailto:rmeyer@MHSC.COM]
> Sent: Wednesday, March 21, 2001 11:31 PM
> To: DOMAIN-POLICY@LISTS.NETSOL.COM
> 
> > My problem has never been with the idea of
> > alternative roots... it
> > is with rogue operations that don't concern themselves with
> > their impact on others.
> 
> That is our concern too.
> 
> > I'm willing to depart the idea of ICANN as "THE" root... just
> > tell me what we're accepting in it's place, and why we should.
> 
> We need to switch gears from root-zone to name-space and give 
> up on having them be synonymous anymore. Just like we parted 
> ways with hosts.txt. In fact, none of this would be an issue 
> if BIND did restricted iterative searches among root servers.  
> The algorithm is not that hard and the code is
> even easier. There are one or two caveats you have to watch 
> out for. If each of the 13 entries was then a pointer to a 
> load-balancer, which each had a whole constellation of identical 
> root-servers, then the whole thing becomes
> extremely scalable, moreso than the present system. 
> By an order of magnitude, or more.
> 
> I've been sitting on this technology for years. It works. 
> It's part of our WarpGate project. Yes, it requires a slight 
> re-architecture, at the top, in order to see maximum 
> benefit(TANSTAAFL). 
--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html




<<< Chronological Index >>>    <<< Thread Index >>>