November 1996 - Test - lists.nanog.org

October 1996 notes status
by sob＠academ.com 25 Nov '96

25 Nov '96

My apologies for not getting more of this done by now. It has been a VERY VERY hectic November. I have gotten most of the NAP section done from Thursday morning and have Yakov's talk on Friday done (with all his slides: Thanks, Yakov!). I am going to try to have the rest of the notes done before December 1st. http://www.academ.com/nanog/oct1996 is where to start. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Internic address allocation policy
by matthew＠scruz.net 24 Nov '96

24 Nov '96

I'm having a problem getting the Internic to allocate additional IP addresses to us. I'm looking for feedback (public or private) from others who may have had this problem that I can forward to my lawyers. Scruz-Net recently merged with another company. As the new company, we are in the process of deploying a large DS-3 based IP network, with attachments to more than 5 major interconnect points. As such, we need address space both for our backbone and our customers. First, I tried to get address space for the new company. Response was that under the slow-start policies, I could get nothing bigger than a /19. Well, that's not interesting, because I'm not about to deliberately subject myself to routing filters that I think make good technical sense (hello Sprint). So I turned around and said that the EXISTING company (scruz-net) needs more address space. First off, we got told that because we didn't use our last allocation (a /16) quickly enough (three months is their suggestion, took us more like 9-12 months to fill it up, with careful assignment) we obviously didn't need a block that big. (Now, since the point is to conserve routing table size among us providers who carry full tables, isn't it better for me to get a /16 and use it slowly than to get 4 unrelated /18's that each last three months???) So then I argued that since the merger has happened, and we have sales projections that show that with a much larger geographic coverage and hundreds of people out selling the product, we ought to be using addresses a bit faster. That started a back-and-forth where I had to "prove" that a merger had really occured, when I was in fact under legal requirements to not talk about the merger until it was made public. Now I guess they believe that, and they've fallen back on the argument that I don't allocate addresses as well as they'd like. This is based on looking at our rwhois data. Now, we have large numbers of customers with small static blocks who don't really want their name and address listed publically... and so we've listed those blocks as things like w.x.y.z/24 -> "workgroup ISDN accounts in San Jose". But that apparently doesn't satisfy whoever plays netreg(a)internic.net. In fact, upon reviewing our customer policy about disclosure of customer information, we've had to turn off our rwhois server entirely until we can go through and seriously sanitize it. All I want is some addresses so that I can continue to hook up customers, allocate additional addresses to providers downstream of us who need more addresses for *their* customers, and build a backbone network. But I've been forced into getting our lawyers involved. I never thought that getting another block of IP addresses would come to that. *sigh* Again, anybody who's figured out how to force the Internic to be reasonable about address allocation, *please* drop me a note. -matthew kaufman matthew(a)scruz.net

9 15

RE: First? TRUE Root Name Server On Line
by Jim Fleming 24 Nov '96

24 Nov '96

On Sunday, November 24, 1996 5:54 AM, Derek Elder[SMTP:djelder@accessus.net] wrote: @ Kind sir, I have been a netizen for 10 years and a network administrator @ for an ISP for 4 years. The thing that -you- don't understand is the @ -millions- of people flocking to the net could care one little iota about @ what a root nameserver is. The only thing they care about is getting to @ www.toyota.com that they heard about on television. @ @ And I feel quite certain that www.toyota.com isn't going to turn into @ www.toyota.earth which means that the people that matter and the people @ that cause the change -- our users -- will never know that you exist. @ @ Have a very pleasant day. @ @ | Derek Elder http://www.accessus.net V.P., CIO | @ | djelder(a)accessus.net accessU.S., Inc. 888-637-3638 Ext. 222 | @ @ Your point is well taken. Since you have selected Toyota as an example, let's continue on that theme. Imagine, that a new solid, well-engineered set of Root Name Servers are installed in strategic places in the network. Imagine that they are not run by volunteers, like the current hodge podge collection used by most ISPs. Now, imagine that these TRUE Root Name Servers do nothing but provide other ISP Name Servers with referrals for the location of the .COM TLD Name Servers. (Unlike the current arrangement, where .COM is served off the root name servers) The question (or opportunity) arises regarding "which" .COM Top Level Domain Name Servers are supported by these Root Name Servers. If the current 9 popular .COM TLD Name Servers are used, then Toyota.COM will be visible. If on the other hand, a different collection of .COM TLD Name Servers are used (let's say for some State that wants to collect a "com" tax) then Toyota may find that it has to register with multiple .COM TLD Name Server confederations to be visible to a wide range of people. In summary, rather than Toyota just having to pay $50 per year to a company located in the State of Virginia, they could find that they have to pay $50 to each State that operates their own .COM TLD Name Servers. For Toyota, this should be pocket change and will yield States a share of the domain name taxes being raised. For small companies in the .COM domain, this could be a major expense. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

1 0

RE: First? TRUE Root Name Server On Line
by Jim Fleming 24 Nov '96

24 Nov '96

On Sunday, November 24, 1996 2:27 AM, Paul A Vixie[SMTP:paul@vix.com] wrote: @ Jim. @ @ You do not understand even the difference between "recursive" and @ "resolves second level names." Why in the world do you expect @ anybody, anywhere, to give a rat's ass what you're doing or saying? @ @ Paul @ Paul, Because the 9 popular Root Name Servers are NOT configured as TRUE Root Name Servers, it is difficult to draw fine distinctions between recursion, iteration, referrals, etc. If you check pages 31 and 32 of the book, "DNS and BIND", by Paul Albitz & Cricket Liu you will not serveral statements which attempt to differentiate between "recursion" and "iteration". In one statement, they state, "In recursion, a resolver sends a recursive query to a name server...The queried name server is then obliged to respond with the requested data...The name server can't just refer the querier to a different name server, because the query was recursive." Because the 9 popular Root Name Servers are not configured as TRUE Root Name Servers (and also do not meet other basic Root Name Server requirements), it is a coincidence that they are able to avoid recursion and return information for the .COM, .NET, .ORG, .EDU, .MIL, .ARPA, etc. domains. When they do this, they appear to look like a "recursive" to another server or resolver that is using their services. I hope that we can agree that TRUE Root Name Servers should only return "referrals" to other Top Level Domain Name Servers. In the above book, this is considered "Iterative Resolution" because "a name server simply gives the best answer it already knows... it makes its best attempt to give the querier data that will help it continue the resolution process". While I continue to find it interesting that you always lower yourself to personal attacks, in apparent violation of the IETF Code of Conduct, I am not sure that your attacks help to educate Internet users. Your attacks also do not focus on the real problem which is the fact that the 9 popular Root Name Servers, used by many ISPs, are not properly configured as TRUE Root Name Servers. If you like, we can leave the complex terms, recursion and iteration out of these discussions. In the future, we can refer to TRUE Root Name Servers, as those that meet the technical requirements for being called a TRUE Root Name Server. If and when the 9 popular Root Name Servers ever meet these requirements, then we can refer to them as TRUE Root Name Servers, and everyone will understand that they do not return replys which appear to be the result of a recursive search, thus giving one the impression that they are recursive. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

1 0

FW: First? TRUE Root Name Server On Line
by Jim Fleming 24 Nov '96

24 Nov '96

RE: First? TRUE Root Name Server On Line Name: NS2.NIC.EARTH IP Address: 199.5.157.5 When history is made on the Internet, it is important to briefly pause to recognize the event, and then move forward. Recently, one of the first TRUE Root Name Servers was put into service by John Palmer of The American Global Network, Inc. (AGN.NET) [1]. AGN is the owner and operator of the Top Level Domain Registry for the .EARTH and .USA TLDs. There are several factors which make this particular Root Name Server unique: 1. First and foremost, this appears to be the first, public access, Root Name Server which operates as a TRUE NON-RECURSIVE Root Server [2]. This is a requirement which is part of the new root name server guidelines which are being discussed by the IETF and other engineering groups. The 9 "popular" root name servers use by many ISPs do NOT meet these guidelines and resolve second level names.[3] True root name servers should do nothing but return references to TLD Name Servers [2], to reduce the scope of their control and their overall load. 2. The official name of this root name server is...NS2.NIC.EARTH. Because of the growing availability of access to the new Top Level Domains, such as .EARTH, it seems appropriate to begin naming the new Root Name Servers with the newly available names. 3. This Root Name Server can be added to the growing collection of Root 64 Name Servers which can be freely used by ISPs in their "root.cache" files. Because this Root Name Server is supported by a commercial enterprise, and not a hodge podge of volunteers (or the U.S. Government), ISPs can use this Root Name Server to help bring added stability and performance to their systems. [4] [5] In these times where confusion is being caused by groups who think that they can continue to debate the Top Level Domain issues primarily to prevent businesses (registries, ISPs, etc.) from making progress, it is important to recognize the efforts being made by business people to bring stability to the system and better service to consumers. As has been proven over and over during the past year, new commercial Top Level Domains are a reality along with new commercial Root Name Servers. The business community is rising to the challenge of building a better, more complete, and better engineered Internet now that the research and development is largely over. More commercial Root Name Servers are being installed and tested. As news of their introduction becomes available the "newdom" mailing list seems like the best place to keep everyone informed. The web interface for subscribing to that list can be found at: http://www.newdom.com/lists/ @@@@@@ [1] @@@@@@@@@ Result of: whois 199.5.156 The American Global Network, Inc. (NETBLK-RABBIT2) 31511 Harper Ave. St. Clair Shores, MI 48082 Netname: NETBLK-RABBIT2 Netblock: 199.5.156.0 - 199.5.157.0 Coordinator: Palmer, John P. (JP4736) jp(a)AGN.NET 800-456-0094 (FAX) 810-790-0156 Domain System inverse mapping provided by: SIMBA.AGN.NET 160.79.1.3 NS.AGN.NET 160.79.1.1 Record last updated on 18-Jan-96. @@@@@@ [2] @@@@@@@@@ Result of: dig @199.5.157.5 mcs.com any ; <<>> DiG 2.1 <<>> @199.5.157.5 mcs.com any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 9, Addit: 9 ;; QUESTIONS: ;; mcs.com, type = ANY, class = IN ;; AUTHORITY RECORDS: COM. 172800 NS A.ROOT-SERVERS.NET. COM. 172800 NS H.ROOT-SERVERS.NET. COM. 172800 NS B.ROOT-SERVERS.NET. COM. 172800 NS C.ROOT-SERVERS.NET. COM. 172800 NS D.ROOT-SERVERS.NET. COM. 172800 NS E.ROOT-SERVERS.NET. COM. 172800 NS I.ROOT-SERVERS.NET. COM. 172800 NS F.ROOT-SERVERS.NET. COM. 172800 NS G.ROOT-SERVERS.NET. ;; ADDITIONAL RECORDS: A.ROOT-SERVERS.NET. 518400 A 198.41.0.4 H.ROOT-SERVERS.NET. 518400 A 128.63.2.53 B.ROOT-SERVERS.NET. 518400 A 128.9.0.107 C.ROOT-SERVERS.NET. 518400 A 192.33.4.12 D.ROOT-SERVERS.NET. 518400 A 128.8.10.90 E.ROOT-SERVERS.NET. 518400 A 192.203.230.10 I.ROOT-SERVERS.NET. 518400 A 192.36.148.17 F.ROOT-SERVERS.NET. 518400 A 192.5.5.241 G.ROOT-SERVERS.NET. 518400 A 192.112.36.4 ;; Total query time: 29 msec ;; FROM: doorstep.unety.net to SERVER: 199.5.157.5 ;; WHEN: Sat Nov 23 10:59:28 1996 ;; MSG SIZE sent: 25 rcvd: 332 @@@@@@ [3] @@@@@@@@@ Result of: dig @a.root-servers.net mcs.com any ; <<>> DiG 2.1 <<>> @a.root-servers.net mcs.com any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 2, Auth: 2, Addit: 2 ;; QUESTIONS: ;; mcs.com, type = ANY, class = IN ;; ANSWERS: mcs.com. 172800 NS CEREBUS.mcs.com. mcs.com. 172800 NS KITTEN.mcs.com. ;; AUTHORITY RECORDS: mcs.com. 172800 NS CEREBUS.mcs.com. mcs.com. 172800 NS KITTEN.mcs.com. ;; ADDITIONAL RECORDS: CEREBUS.mcs.com. 172800 A 192.160.127.125 KITTEN.mcs.com. 172800 A 192.160.127.90 ;; Total query time: 88 msec ;; FROM: doorstep.unety.net to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Sat Nov 23 12:31:25 1996 ;; MSG SIZE sent: 25 rcvd: 128 @@@@@@ [4] @@@@@@@@@ Sample Traceroute to the NEW Root Server 1 chi00-s8-3.nap.net (206.54.225.89) 4.131 ms 4.066 ms 4.211 ms 2 core0-atm0.chi.nap.net (207.112.247.33) 4.013 ms 4.913 ms 4.309 ms 3 909.Hssi3-0.GW2.CHI1.ALTER.NET (137.39.130.173) 5.988 ms 5.735 ms 5.69 ms 4 Fddi1.CR1.CHI1.Alter.Net (137.39.38.193) 5.555 ms 6.243 ms 6.533 ms 5 106.Hssi3-0.GW1.DET1.Alter.Net (137.39.58.58) 14.022 ms 15.304 ms 15.322 ms 6 agn-gw.ALTER.NET (137.39.146.6) 18.409 ms 20.191 ms 19.351 ms 7 NS2.NIC.EARTH (199.5.157.5) 17.695 ms 18.895 ms 17.738 ms @@@@@@ [5] @@@@@@@@@ Sample Ping to NEW Root Server for above route. # ping -c 5 199.5.157.5 PING 199.5.157.5 (199.5.157.5): 56 data bytes 64 bytes from 199.5.157.5: icmp_seq=0 ttl=247 time=19.313 ms 64 bytes from 199.5.157.5: icmp_seq=1 ttl=247 time=20.071 ms 64 bytes from 199.5.157.5: icmp_seq=2 ttl=247 time=18.218 ms 64 bytes from 199.5.157.5: icmp_seq=3 ttl=247 time=19.377 ms 64 bytes from 199.5.157.5: icmp_seq=4 ttl=247 time=18.007 ms --- 199.5.157.5 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 18.007/18.997/20.071 ms @@@@@@@@@@@@@@@ -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming(a)unety.net JimFleming(a)unety.net.s0.g0 (EDNS/IPv8)

7 6

A little funny.
by Derek Elder 24 Nov '96

24 Nov '96

Ok -- one last post about the 'root name server'. While responding to the email address of Bob Allisat <tor(a)wtv.net>, I got the following bounce: The original message was received at Sun, 24 Nov 1996 13:14:20 -0500 from djelder(a)mtvernon1.accessus.net [204.248.93.5] ----- The following addresses had delivery problems ----- <tor(a)wtv.net> (unrecoverable error) ----- Transcript of session follows ----- 554 MX list for wtv.net. points back to presence.lglobal.com 554 <tor(a)wtv.net>... Local configuration error ----- Original message follows ----- [ Part 2: "Included Message" ] The newest net revolutionary can't even setup sendmail and he expects us to take him seriously? Bob, you really, really, should add wtv.net to the sendmail.cw on your mail server. *chuckles politely* | Derek Elder http://www.accessus.net V.P., CIO | | djelder(a)accessus.net accessU.S., Inc. 888-637-3638 Ext. 222 |

1 0

Re: First? TRUE Root Name Server On Line
by tor＠wtv.net 24 Nov '96

24 Nov '96

Derek Elder wrote: >Perhaps you should move this drivel to a list populated by 31337 warez >dudes. You may find your revolution there -- however, I have serious >doubts that any of them even know what bind is, let alone how to changed >root.cache. And I have serious doubt you understand any of the millions of people now rushing onto the internet media. Once the inevitable transfer of Internet to television and smart box is completed your roles as info-czars will be finished. By clueless people like me. Your gang is treading on thin ice now. Very thin, cracking ice with the sun coming out. Bob Allisat PO Box 191 Station E Toronto Canada M6H 4E2 (416) 588-0670

2 1

Re: FW: First? TRUE Root Name Server On Line
by Joel M Snyder 24 Nov '96

24 Nov '96

The ONE TRUE ROOT SERVER? Why, I'M RUNNING that! All BOW DOWN and WORSHIP at the ALTAR of the TRUE ROOT SERVER! These other servers are FALSE and you must NOT heed them! The ONE TRUE ROOT SERVER is MINE! YOUR server is FALSE! You WORSHIP FALSE SERVERS! Your PACKETS will ROT IN IPX if you DO NOT REPENT! YOUR data will be ENCAPSULATED! Your CHECKSUMS will NOT CHECK if you continue in THIS HERESY! The SERVER, the ONE TRUE ROOT SERVER, ... (you get the picture) jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX) jms(a)Opus1.COM http://www.opus1.com/jms Opus One

2 1

Bah.
by Derek Elder 24 Nov '96

24 Nov '96

Sorry for the cross-emails on the last CC. Got a bit overzealous responding to the idiot^H^H^H^H^H^Hgentleman that keeps harping on the root server joke. | Derek Elder http://www.accessus.net V.P., CIO | | djelder(a)accessus.net accessU.S., Inc. 888-637-3638 Ext. 222 |

1 0

Re: First? TRUE Root Name Server On Line
by tor＠wtv.net 24 Nov '96

24 Nov '96

Paul A Vixie wrote: >Your desire to make a distinction between "popular" and "actual" is >dishonest, misleading, ugly, and rude. There are exactly nine root >name servers. Not "popular" root name servers - 9 SERVERS, total: Paul - your peculiar brand of orthodox and narrowly defined reality are not in line with the fluidic and creative nature of the Internet IMHO. Should the people choose to circumvent these silly bottlenecks they will. And then you can rave all you want. My experience is that the citizans of the internet like revolution and love change. And you're sounding awful reactionary and even counter-revolutionary, Paul... Bob Allisat PO Box 191 Station E Toronto Canada M6H 4E2 (416) 588-0670

2 1