July 1995 - Test - lists.nanog.org

Re: EP.NET ???
by Havard.Eidnes＠runit.sintef.no 02 Aug '95

02 Aug '95

> > Personally I think that this is actually a value-subtracted service, > > as the EP.NET organisation does not run the named boxes, or the > > exchange points. > > > > It would be much more helpfull the the interfaces that faces the NAP > > and another provider where following each providers naming > > conventions, and had a domain-name that would point the users to the > > organisation that actually operates the boxes. > > Yes, that is the desired goal, however some sites are not > willing or able to do so, so there is a default case where a > name is available. (There are some exchange points where no > forward is registered, which can be a hassel) The existence of a forward mapping is not a necessary technical precondition for you to insert a reverse mapping which points in the right direction, i.e. at the organization operating the boxes. However I also have trouble seeing why any ISP would willingly decline to register it's boxes in the DNS. I fully agree with PL that introducing EP.NET into this is value- subtraction, in that it will just add unneeded confusion. - Håvard

4 4

Re: US Domain -- County Delegations
by Vadim Antonov 31 Jul '95

31 Jul '95

> We are planning to delegate every county name as a locality name in each > State. For example, "Ventura.CA.US", "Dade.FL.US", "Riverside.CA.US". Too many levels is _very_ bad, as people will stick to using old three-letter domains. How about limiting the scheme to <orgname>.<state>.us? Or, even better, for major metropolitan areas like SF, LA, NYC, CHI etc the name central city can be used instead of state. That scheme worked reasonably well for .SU :) --vadim

15 33

Re: root name servers
by Peter Lothberg 31 Jul '95

31 Jul '95

> 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?) >From a pretty central place in the Internet; 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 4 msec 4 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 40 msec 8 msec 88 msec 3 icm-fix-e-H2/0-T3.icp.net (192.157.65.122) 20 msec 0 msec 0 msec 4 sura9-fix-cf.sura.net (192.203.229.9) 56 msec 4 msec 4 msec 5 cpk9-cpk-cf.sura.net (128.167.252.9) [AS 86] 0 msec 4 msec 4 msec 6 wtn8-cpk9-c3.sura.net (128.167.212.2) [AS 86] 8 msec 4 msec 4 msec 7 wtn4-wtn8-ce.sura.net (128.167.24.4) [AS 86] 12 msec 12 msec 4 msec 8 netsol-wtn4-c1.sura.net (192.221.22.2) [AS 86] 16 msec 4 msec 8 msec 9 NS.INTERNIC.NET (198.41.0.4) [AS 86] 8 msec 8 msec 8 msec ICM-MAE-E#sh ip bgp 128.63.4.82 % Network not in table ICM-FIX-E>sh ip bgp 128.63.4.82 % Network not in table 1 cpe2.Washington.mci.net (192.41.177.181) 0 msec 0 msec 4 msec 2 border2-hssi4-0.Washington.mci.net (204.70.57.9) [AS 3561] 12 msec 0 msec 0 msec 3 core-fddi-1.Washington.mci.net (204.70.3.1) [AS 3561] 0 msec 4 msec 4 msec 4 core-hssi-3.Atlanta.mci.net (204.70.1.10) [AS 3561] 24 msec 16 msec 20 msec 5 core-hssi-4.Houston.mci.net (204.70.1.26) [AS 3561] 40 msec 36 msec 36 msec 6 core-hssi-3.Bloomington.mci.net (204.70.1.34) [AS 3561] 76 msec 72 msec 76 msec 7 border1-fddi0-0.Bloomington.mci.net (204.70.2.130) [AS 3561] 72 msec 72 msec 72 msec 8 csunet-losnettos.Bloomington.mci.net (204.70.48.6) [AS 3561] 76 msec 76 msec 76 msec 9 ISI-SWRL-GW.LN.NET (204.102.78.1) [AS 2150] 284 msec 236 msec 216 msec 10 ln-gw.isi.edu (128.9.16.1) [AS 226] 228 msec 196 msec 80 msec 11 NS1.ISI.EDU (128.9.0.107) [AS 226] 80 msec 80 msec * 1 mae-east.psi.net (192.41.177.245) 4 msec 4 msec 4 msec 2 38.1.2.14 [AS 174] 124 msec 16 msec 4 msec 3 C.PSI.NET (192.33.4.12) [AS 174] 4 msec 8 msec 16 msec 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 12 msec 12 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 4 msec 4 msec 4 msec 3 icm-fix-e-H2/0-T3.icp.net (192.157.65.122) 4 msec 4 msec 4 msec 4 sura9-fix-cf.sura.net (192.203.229.9) 4 msec 4 msec 0 msec 5 umd-cpk2-c1.sura.net (192.221.61.2) [AS 86] 12 msec 8 msec 4 msec 6 csc1gw-f0.umd.edu (128.8.1.224) [AS 86] 4 msec 8 msec 8 msec 7 TERP.UMD.EDU (128.8.10.90) [AS 86] 8 msec 4 msec 4 msec 1 sl-mae-e-F0/0.sprintlink.net (192.41.177.241) 0 msec 0 msec 4 msec 2 sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41) [AS 1239] 0 msec 0 msec 4 msec 3 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) [AS 1239] 4 msec 4 msec 4 msec 4 sl-stk-5-H1/0-T3.sprintlink.net (144.228.10.2) [AS 1239] 68 msec 64 msec 64 msec 5 icm-fix-w-H2/0-T3.icp.net (144.228.10.22) [AS 1239] 136 msec 68 msec 80 msec 6 NS.NASA.GOV (192.52.195.10) [AS 297] 68 msec 68 msec 68 msec 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 4 msec 4 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 164 msec 16 msec 0 msec 3 icm-pen-1-H1/0-5M.icp.net (198.67.131.18) 8 msec 16 msec 16 msec 4 icm-uk-1-H0/0-T3.icp.net (198.67.131.26) 104 msec 100 msec 100 msec 5 icm-stockholm-2-H0/0-5M.icp.net (198.67.131.42) 124 msec 128 msec 136 msec 6 nord-gw.nordu.net (192.36.148.194) [AS 2603] 196 msec 128 msec 124 msec 7 NIC.NORDU.NET (192.36.148.17) [AS 2603] 128 msec 128 msec 128 msec 1 Vienna1.VA.Alter.Net (192.41.177.249) 4 msec 4 msec 0 msec 2 Vienna5.VA.ALTER.NET (137.39.11.9) [AS 701] 0 msec 4 msec 0 msec 3 San-Jose3.CA.ALTER.NET (137.39.13.5) [AS 701] 68 msec 68 msec 68 msec 4 San-Jose5.CA.ALTER.NET (137.39.27.6) [AS 701] 64 msec 68 msec 68 msec 5 Palo-Alto1.CA.ALTER.NET (137.39.29.3) [AS 701] 68 msec 72 msec 208 msec 6 Palo-Alto3.CA.ALTER.NET (137.39.47.7) [AS 701] 232 msec 72 msec 68 msec 7 fw.ramona.vix.com (204.123.0.3) [AS 33] 84 msec 68 msec 72 msec 8 NS.ISC.ORG (192.5.5.241) [AS 3557] 72 msec 72 msec 68 msec 1 icm-dc-1-H1/0-T3.icp.net (198.67.131.10) 12 msec 8 msec 4 msec 2 icm-dc-2b-F2/0.icp.net (198.67.131.34) 0 msec 0 msec 12 msec 3 icm-fix-e-H2/0-T3.icp.net (192.157.65.122) 20 msec 4 msec 4 msec 4 192.203.229.251 4 msec 4 msec 4 msec 5 137.209.1.2 [AS 568] 8 msec 8 msec 8 msec 6 GSI-GW3.DDN.MIL (198.25.64.2) [AS 568] 12 msec 12 msec 12 msec 7 NS.NIC.DDN.MIL (192.112.36.4) [AS 568] 12 msec 12 msec 12 msec > > For security and stability reasons (aswell as political) they should > > not be run by a single organisation. > > they never have been. The Mannings proposal of a single domain, seems to me like the first step... --Peter

4 3

Re: EP.NET ???
by Peter Lothberg 31 Jul '95

31 Jul '95

> > There have been a number of questions that have been fielded > wrt the EP.NET domain and traceroute failures within that > domain. For your edification, here is a brief note on the EP.NET > domain. > > EP.NET operated as a service by the RA for exchange points around > the globe. Any exchange point may become part of the EP.NET domain. > The default assignment algorithm follows. The next level > identifies the specific exchange. The next level identifies > the attaching organization. > > So, the default for BillsBait&SushiShop (BBSS) at MAE-WEST is: > > bbss.mae-west.ep.net > > When BBSS attachs to the AADS NAP, the default name is: > > bbss.aads.ep.net > > Selection of provider specific names is encouraged. > So when BBSS gets around to it, they may change the names to > something like this: > > mae-west.bbss.org > aads.bbss.org Bill, Personally I think that this is actually a value-subtracted service, as the EP.NET organisation does not run the named boxes, or the exchange points. It would be much more helpfull the the interfaces that faces the NAP and another provider where following each providers naming conventions, and had a domain-name that would point the users to the organisation that actually operates the boxes. You can still provide the service of running the nameservice. --Peter

3 4

Re: EP.NET ???
by Peter Lothberg 31 Jul '95

31 Jul '95

begin kludge interface fddi0/0 ip address yor.own.net.work your.mask.as.desired ip address bill.assigned.c.net 255.255.255.0 secondary end kludge; If the box decides to send a ICMP message out on the interface that faces the RA pirated network it will use the primary address, so it will show up with the name and network number you prefer. -Peter

2 1

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