- Test - lists.nanog.org

Re: root name servers
by owen＠DeLong.SJ.CA.US 31 Jul '95

31 Jul '95

> there has never been a shortage of volunteers to run root servers. i'm > not sure that the exchange points are good spots, since the folks who run > exchange points (MFS, NASA, Pac Bell, etc) usually know a lot more about > the link level than the network level -- and besides, i'm not sure that a > root name server ought to have an ASN and run BGP4, which means that it > will have to be behind a router that _does_ have an ASN and run BGP4. if > this is to be the case, i'd rather see the routers inside NSP offices, > where UNIX experts and network experts are more plentiful than at the > exchange points. > Actually, I think that it might be interesting to look at the possibility of putting Root DNS on the Route-Servers. > to that end, NS.ISC.ORG is one 10Mb/s hop away from BADnet (barrnet-alternet- > digital) in the DECWRL computer room. it's likely that i will shortly add > an SMDS T1 connection to the CIX cloud for other reasons, and that will help > a tiny bit (only a tiny bit, since Alternet has T3 to that cloud from the > router i peer with in that room.) > > work is underway (by the Postel-Mockapetris-Vixie-Kosters quadumvirite) to > implement Bill Manning's suggestion of putting all the root servers under > a single domain, which will let DNS' name compression start winning for us. > if this works out, we should be able to just about double the number of root > name servers. NSP's with multiple T3's to geographically disparite exchange > points will be given strong preference. sites outside the United States will > be given strong preference. > Interesting... That should definitely help. > the root servers are not currently suffering from load (my own server does > about 100 queries per second, which is about 10% of the capacity of my little > 66Mhz/64MB BSD/OS machine). the goal here is to reduce load on the wide area > net rather than on the root servers themselves. and also to increase the > likelihood that any given host can reach a root server during times of wide- > scale connectivity problems (which seem to be more common lately?) > True. However, the nice thing about a RNS on an XP is that the RNS is one hop from EVERY provider at the XP, and is independent of OTHER providers. I agree that the XP management shouldn't manage the RNS. However, I would be QUITE comfortable with MERIT running it on the RS or adjacent machine. > > For security and stability reasons (aswell as political) they should > > not be run by a single organisation. > > they never have been. > Although I agree that ALL RNS's shouldn't be run by a single organization, I would not have a problem with the RNS's at the XP's being run by the RADB group. Owen

4 3

Re: root name servers
by Sean Doran 30 Jul '95

30 Jul '95

>I would not have a problem with the RNS's at the XP's being run >by the RADB group. Well, *I* would! Sean.

2 1

Re: root name servers
by owen＠DeLong.SJ.CA.US 30 Jul '95

30 Jul '95

> > To: owen(a)DeLong.SJ.CA.US (Owen DeLong) > > Cc: paul(a)vix.com, nanog(a)merit.edu, postel(a)isi.edu > > Subject: Re: root name servers > > Date: Sat, 29 Jul 1995 13:32:11 -0700 > > From: Paul Traina <pst(a)cisco.com> > > [...] > > <I'm about to projectile vomit all over my keyboard> > > [...] > > ... although I had a bit of a problem keeping down my dinner when > > I first read it. > > [...] > > If I had to guess, I would suspect that your problems extend beyond > listening to other people's ideas. > > -tjs > In defense of Paul, I'd have to say that although his sense of humor leaves something to taste (I'm sure you'll all have lots of fun with the puns that can be derived from this), he has a valid position. Not one I happen to agree with at the moment, but valid nonetheless. Owen

1 0

Re: root name servers
by salo＠msc.edu 30 Jul '95

30 Jul '95

> To: owen(a)DeLong.SJ.CA.US (Owen DeLong) > Cc: paul(a)vix.com, nanog(a)merit.edu, postel(a)isi.edu > Subject: Re: root name servers > Date: Sat, 29 Jul 1995 13:32:11 -0700 > From: Paul Traina <pst(a)cisco.com> > [...] > <I'm about to projectile vomit all over my keyboard> > [...] > ... although I had a bit of a problem keeping down my dinner when > I first read it. > [...] If I had to guess, I would suspect that your problems extend beyond listening to other people's ideas. -tjs

1 0

Re: root name servers
by owen＠DeLong.SJ.CA.US 30 Jul '95

30 Jul '95

> > Although I agree that ALL RNS's shouldn't be run by a single organization, > > I would not have a problem with the RNS's at the XP's being run by the RADB > > group. > > I would. Elise and her team are experts at what they do, but running a root > name server is not quite the same thing. > That is quite true. However, I have set up a couple of "un-official" root name servers for clients of mine who had HEAVY lookup traffic. It has worked quite well, and didn't seem substantially different from running an ISP nameserver that was secondary for a whole bunch of customer domains. I'm pretty sure that Elise and her team have the knowledge to run DNS generally, and could be capable of running a RNS with very little training. Alternatively, I am sure that something could be worked out. The point is that I think there is a lot of merit to placing RNS's at XP's where no provider at the XP has to traverse another provider to do root-level resolutions. Basically, if that works, you have a situation where if you loose nameservice, it's probably the least of your problems. Owen

2 1

Re: EP.NET ???
by jgs＠aads.net 29 Jul '95

29 Jul '95

At 10:18 AM 7/29/95, Randy Bush wrote: [...] >There's another value-subtracted service offered to IXers by this kind >service. "The block 198.32.0.0/16 is set aside for numbering exchange >points. The block is listed to ISI. Specific sub-delegations can be made as >needed." Nice way to break aggregation, create an extra route, ... What is your proposal for numbering exchange points in a more aggregatable fashion? An exchange point is about as multi-homed as they come, and as you know multi-homed nets "break aggregation" anyway. I suppose you could take the address for the EP medium out of one of the attached providers' address space, but that's a small improvement at best (and a hole at worst, if that provider later disconnects from the EP). BTW, I agree as to the non-utility of ep.net. --John

1 0

root name servers
by Peter Lothberg 29 Jul '95

29 Jul '95

How about trying to move some of the root name servers to the exchange points? This will make them avaliable to all ISP/NSP's regardless of peering arrangements with others and would also improve connectivity to them. For security and stability reasons (aswell as political) they should not be run by a single organisation. --Peter

6 5

Re: US Domain -- County Delegations
by scharf＠vix.com 29 Jul '95

29 Jul '95

> Date: Fri, 28 Jul 1995 00:51:03 -0400 > From: Curtis Villamizar <curtis(a)ans.net> > > Is ibm.nyse.com, dec.nyse, mci.nasdaq.com a problem? This takes the > arbitrary decision out of accepting or denying someone access to the > .com hierarchy and enforces and already strict naming. > There are two problems I see with this. There are many companies who are privately held, including billion dollar ones. Also, there are companies who have certificates traded on more than one trading place (I know of Japan/US situations.) The more fundamental question is where do you put all the companies that you are now forcing out of .com? Jerry

4 3

Re: NEW POLICY ON INTERNET DOMAIN NAMES
by Dave McGuire 28 Jul '95

28 Jul '95

On July 28, you wrote: >> Date: Fri, 28 Jul 95 09:19:42 PDT >> From: "Roy Engehausen" <enge(a)almaden.ibm.com> >> >> Just a lurker normally but how about using product/services as a >> qualifer? Examples: ibm.computers.com att.telephone.com >> specialized.bicycles.com cisco.networks.com? > > I like this one! It not only deepens the name space but can provide > some additional (read "advertising") to the user, making it an easier > proposal to sell. > > For example, I would not want to loose ior.com, but I would be more > willing to use ior.isp.com than ior.spk.wa.us (geographic). > > It shouldn't be too difficult to have your company listed under > multiple product/service categories if your company covers more than > one. I too am normally a lurker here...but I would have to agree. It also makes certain real-world situations easier. Things like "Mr. Sysadmin? You know the Internet real well, right? Can you help me find information on bicycles?" become much easier with a descriptive hierarchy like this. I like it. -Dave McGuire, Systems Digital Express Group, Incorporated mcguire(a)digex.net

1 0

to name or not name
by Hans-Werner Braun 28 Jul '95

28 Jul '95

I have an idea. Lets create a .ssn domain. Better yet, lets assume everything plain numeric is an SSN. As you all know, Vixie's SSN is 123-45-6789. Consider that address to be a middle level. At the bottom you need something that maps it to where, e.g., he can find his email. When he wants to hang out in his hotel in Costa Rica tomorrow, he may have to remap 123456789, so things can be found wherever he really wants them. Probably a host on the hotel's HIPPI switch. Point is, at the identifier-to-location mapping, things have to be flexible enough to easily and quickly be updated. Kind of like cellular auto-roaming. May be he can even use his cellular phone to beacon around where he is *really* located, so the mapper finds him, and so he may not have to do much explicitly. I, as someone who may want to send him email, should never ever even have to know his SSN specifically, because above the unique-person identifier would be a relational data base that allows my Vixie-{plus- whatever-other-attributes-I-choose} to be mapped to his ID, perhaps confirming something back with me if there is not a 1-to-1 mapping between my request and a response. Besides, it is hard enough to remember my own SSN, why would I want to remember his? So, a unique ID would be a funneling point in the middle, that opens up to both the top and the bottom. Kind of like IP numeric addresses are (or should be), where the number should not really matter, but can be mapped to something on the link/physical level (e.g., Ethernet MAC), and is being utilized (also for mapping purposes) by higher level applications. Really, when was the last time you sent email to vixie!vixiehome(a)128.129.130.131? You know, you can reach him there, didn't you? May mean you have to give machines social security numbers as well, as you may have to address more generic resources (humans are just one instantiation) before too long. If such a system were in place, one could consider that there is really no need for such a thing as a COMPANY.COM. In reality one could send structured requests to some DB server, similar to what X.500 attempted, but perhaps a little more arbitrary/dynamic/hierarchical/whatever. Like, I may want to send email to the teacher of one of my children in grade x of school y, perhaps with some more attributes, may be I don't know the teacher's name, though, and somewhere there is some magic in the system that makes it all work. Or to the company of the laptop I bought a few weeks back, because the screen is busted already: I know the company name, I know what my problem is, that should be good enough to get it to the right person with the right unique ID (or group of IDs/people), and if there are any ambiguities, the translater/mapper could ask me questions (like, there may be no company with the name I gave it, but three choices of similar names; or two of identical names, but in different countries). A silly name like ABCDEF.COM is just absolutely meaningless to me, and the strict binding is going down a dangerous path. If only because people even bind it into there products and there is no way in hell they will change things later withough at least a fight (and probably umpteen thousand lawyers). That system has neither technical nor administrative scaling properties that will match the real world requirements. There is ways too much trash and leftovers in the system that nobody is cleaning up, or has the authority or guts to do so, and many figures presented could probably use a multiplication factor (which may have to include a 0 or more). Uh, and considering to cover only the 95th percentile of the companies is just asking for trouble, as viable and defensible as this may be, technically. I for one would not be suprise that if we continue current practice, 5-10 years down the road, above the 95th percentile of names could be just plain trash. Whatever system we come up with will have to account for that.

3 2