- Test - lists.nanog.org

Re: Is the .to (Tonga) domain completely rogue and should be removed?
by Dean Anderson 01 Oct '98

01 Oct '98

>The simple question here is: who are you to tell a sovereign country what >it can and what it cannot do? hahhahshhahahhaha!! Well put. Anti-spammers make up whatever laws or exemptions to laws they have to. Thats all they need. Thats why they can't be trusted. Fire your anti-spammers before they do something you'll regret... Anyway, I'm laughing too hard (rolling in my chair, knocked the keyboard on the floor) to contribute anything more without endangering safety or equipment... --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

InterNIC modification
by william＠pacific.net.ph 01 Oct '98

01 Oct '98

Hi all! Is it Internic becoming slower in their modifications? We have sent a modification request twice and until now - nothing has happened.... William ---------- Forwarded message ---------- Date: Thu, 24 Sep 1998 20:24:48 -0400 (EDT) From: Domain Registration Role Account <domreg(a)internic.net> To: armand(a)shell.egis.net Subject: Re: [NIC-980924.46494] Re: MODIFY DOMAIN dwrt.com Your request NIC-980924.46494 for [NIC-980924.46494] Re: MODIFY DOMAIN dwrt.com. could not be automatically processed. The request has been queued for manual processing. It will be processed within 5 business days. InterNIC Registration Services email hostmaster(a)internic.net voice (703) 742-4777 ============================================================ >From armand(a)shell.egis.net Thu Sep 24 16:48:22 1998 >Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) > by mail-hub.internic.net (8.9.1/8.9.1) with ESMTP id QAA04873 > for <hostmaster(a)mail-hub.internic.net>; Thu, 24 Sep 1998 16:48:21 -0400 (EDT) >Received: from biprrs3.lb (biprrs3.lb.internic.net [192.168.120.41]) > by opsmail.internic.net (8.9.1/8.9.1) with SMTP id QAA16745 > for <hostmaster(a)internic.net>; Thu, 24 Sep 1998 16:47:54 -0400 (EDT) >Received: (qmail 23915 invoked from network); 24 Sep 1998 05:58:06 -0000 >Received: from unknown (HELO shell.egis.net) (202.163.235.6) > by 192.168.119.41 with SMTP; 24 Sep 1998 05:58:06 -0000 >Received: by shell.egis.net (Smail3.1.29.1 #57) > id m0zMFSJ-001SlLC; Thu, 24 Sep 98 13:45 EDT >Date: Thu, 24 Sep 1998 13:45:27 -0400 (EDT) >From: Armand Hernandez <armand(a)shell.egis.net> >To: hostmaster(a)internic.net >Subject: [NIC-980924.46494] Re: MODIFY DOMAIN dwrt.com >In-Reply-To: <199809240552.BAA17662(a)rrs2.lb.internic.net> >Message-ID: <Pine.LNX.3.90.980924134523.9387A-100000(a)shell.egis.net> >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >X-MTS-Ticket: 980924.46494 >X-MTS-Type: Domain >X-MTS-Mode: Modify >X-MTS-Priority: Normal >X-MTS-Status: Open >X-MTS-Timestamp: 980924164822 > > > > >On Thu, 24 Sep 1998 hostmaster(a)internic.net wrote: > >> ---------------------------------------------------- >> This is the Domain Name Registration Agreement you >> recently created. >> In order to complete this modification, >> >> YOU MUST E-MAIL THIS FORM TO: hostmaster(a)internic.net >> >> After you e-mail this form, you should receive an auto-reply >> with a tracking number. You must use that number in the >> Subject of any future messages you send regarding >> this registration action. >> Once this registration action is completed you will receive >> a notification via e-mail. >> >> [ URL http://rs.internic.net/cgi-bin/domain ] [ 03/98 ] >> [ URL ftp://rs.internic.net/templates/domain-template.txt ] [ 03/98 ] >> >> ******* Please DO NOT REMOVE Version Number or Sections A-Q ******** >> >> Domain Version Number: 4.0 >> >> ******* Email completed agreement to hostmaster(a)internic.net ******* >> >> NETWORK SOLUTIONS, INC. >> >> DOMAIN NAME REGISTRATION AGREEMENT >> >> >> A. Introduction. This domain name registration agreement >> ("Registration Agreement") is submitted to NETWORK SOLUTIONS, INC. >> ("NSI") for the purpose of applying for and registering a domain name >> on the Internet. If this Registration Agreement is accepted by NSI, >> and a domain name is registered in NSI's domain name database and >> assigned to the Registrant, Registrant ("Registrant") agrees to be >> bound by the terms of this Registration Agreement and the terms of >> NSI's Domain Name Dispute Policy ("Dispute Policy") which is >> incorporated herein by reference and made a part of this Registration >> Agreement. This Registration Agreement shall be accepted at the >> offices of NSI. >> >> B. Fees and Payments. >> >> 1) Registration or renewal (re-registration) date through March 31, 1998: >> Registrant agrees to pay a registration fee of One Hundred United States >> Dollars (US) as consideration for the registration of each new domain >> name or Fifty United States Dollars (US) to renew (re-register) an >> existing registration. >> 2) Registration or renewal date on and after April 1, 1998: Registrant >> agrees to pay a registration fee of Seventy United States Dollars (US) >> as consideration for the registration of each new domain name or the >> applicable renewal (re-registration) fee (currently Thirty-Five United >> States Dollars (US)) at the time of renewal (re-registration). >> 3) Period of Service: The non-refundable fee covers a period of two (2) >> years for each new registration, and one (1) year for each renewal, >> and includes any permitted modification(s) to the domain name record >> during the covered period. >> 4) Payment: Payment is due to Network Solutions within thirty (30) >> days from the date of the invoice. >> >> C. Dispute Policy. Registrant agrees, as a condition to >> submitting this Registration Agreement, and if the Registration >> Agreement is accepted by NSI, that the Registrant shall be bound by >> NSI's current Dispute Policy. The current version of the Dispute >> Policy may be found at the InterNIC Registration Services web site: >> "http://www.netsol.com/rs/dispute-policy.html". >> >> D. Dispute Policy Changes or Modifications. Registrant agrees >> that NSI, in its sole discretion, may change or modify the Dispute >> Policy, incorporated by reference herein, at any time. Registrant >> agrees that Registrant's maintaining the registration of a domain name >> after changes or modifications to the Dispute Policy become effective >> constitutes Registrant's continued acceptance of these changes or >> modifications. Registrant agrees that if Registrant considers any such >> changes or modifications to be unacceptable, Registrant may request >> that the domain name be deleted from the domain name database. >> >> E. Disputes. Registrant agrees that, if the registration of its >> domain name is challenged by any third party, the Registrant will be >> subject to the provisions specified in the Dispute Policy. >> >> F. Agents. Registrant agrees that if this Registration Agreement >> is completed by an agent for the Registrant, such as an ISP or >> Administrative Contact/Agent, the Registrant is nonetheless bound as a >> principal by all terms and conditions herein, including the Dispute >> Policy. >> >> G. Limitation of Liability. Registrant agrees that NSI shall have >> no liability to the Registrant for any loss Registrant may incur in >> connection with NSI's processing of this Registration Agreement, in >> connection with NSI's processing of any authorized modification to the >> domain name's record during the covered period, as a result of the >> Registrant's ISP's failure to pay either the initial registration fee >> or renewal fee, or as a result of the application of the provisions of >> the Dispute Policy. Registrant agrees that in no event shall the >> maximum liability of NSI under this Agreement for any matter exceed >> Five Hundred United States Dollars (US). >> >> H. Indemnity. Registrant agrees, in the event the Registration >> Agreement is accepted by NSI and a subsequent dispute arises with any >> third party, to indemnify and hold NSI harmless pursuant to the terms >> and conditions contained in the Dispute Policy. >> >> I. Breach. Registrant agrees that failure to abide by any >> provision of this Registration Agreement or the Dispute Policy may be >> considered by NSI to be a material breach and that NSI may provide a >> written notice, describing the breach, to the Registrant. If, within >> thirty (30) days of the date of mailing such notice, the Registrant >> fails to provide evidence, which is reasonably satisfactory to NSI, >> that it has not breached its obligations, then NSI may delete >> Registrant's registration of the domain name. Any such breach by a >> Registrant shall not be deemed to be excused simply because NSI did >> not act earlier in response to that, or any other, breach by the >> Registrant. >> >> J. No Guaranty. Registrant agrees that, by registration of a >> domain name, such registration does not confer immunity from objection >> to either the registration or use of the domain name. >> >> K. Warranty. Registrant warrants by submitting this Registration >> Agreement that, to the best of Registrant's knowledge and belief, the >> information submitted herein is true and correct, and that any future >> changes to this information will be provided to NSI in a timely manner >> according to the domain name modification procedures in place at that >> time. Breach of this warranty will constitute a material breach. >> >> L. Revocation. Registrant agrees that NSI may delete a >> Registrant's domain name if this Registration Agreement, or subsequent >> modification(s) thereto, contains false or misleading information, or >> conceals or omits any information NSI would likely consider material >> to its decision to approve this Registration Agreement. >> >> M. Right of Refusal. NSI, in its sole discretion, reserves the >> right to refuse to approve the Registration Agreement for any >> Registrant. Registrant agrees that the submission of this Registration >> Agreement does not obligate NSI to accept this Registration Agreement. >> Registrant agrees that NSI shall not be liable for loss or damages >> that may result from NSI's refusal to accept this Registration >> Agreement. >> >> N. Severability. Registrant agrees that the terms of this >> Registration Agreement are severable. If any term or provision is >> declared invalid, it shall not affect the remaining terms or >> provisions which shall continue to be binding. >> >> O. Entirety. Registrant agrees that this Registration Agreement >> and the Dispute Policy is the complete and exclusive agreement between >> Registrant and NSI regarding the registration of Registrant's domain >> name. This Registration Agreement and the Dispute Policy supersede all >> prior agreements and understandings, whether established by custom, >> practice, policy, or precedent. >> >> P. Governing Law. Registrant agrees that this Registration >> Agreement shall be governed in all respects by and construed in >> accordance with the laws of the Commonwealth of Virginia, United >> States of America. By submitting this Registration Agreement, >> Registrant consents to the exclusive jurisdiction and venue of the >> United States District Court for the Eastern District of Virginia, >> Alexandria Division. If there is no jurisdiction in the United States >> District Court for the Eastern District of Virginia, Alexandria >> Division, then jurisdiction shall be in the Circuit Court of Fairfax >> County, Fairfax, Virginia. >> >> Q. This is Domain Name Registration Agreement Version >> Number 4.0. This Registration Agreement is only for registrations >> under top-level domains: COM, ORG, NET, and EDU. By completing >> and submitting this Registration Agreement for consideration and >> acceptance by NSI, the Registrant agrees that he/she has read and >> agrees to be bound by A through P above. >> >> Authorization >> 0a. (N)ew (M)odify (D)elete.........: M >> 0b. Auth Scheme.....................: >> 0c. Auth Info.......................: >> >> 1. Comments........................: >> >> 2. Complete Domain Name............: dwrt.com >> >> Organization Using Domain Name >> 3a. Organization Name................: 99.5 RT >> 3b. Street Address..................: 14/F JAKA (Royal Match) Bldg., 6780 Ayala Avenue >> 3c. City............................: Makati >> 3d. State...........................: MM >> 3e. Postal Code.....................: 1200 >> 3f. Country.........................: PH >> >> Administrative Contact >> 4a. NIC Handle (if known)...........: JRL17 >> 4b. (I)ndividual (R)ole?............: Individual >> 4c. Name (Last, First)..............: >> 4d. Organization Name...............: >> 4e. Street Address..................: >> 4f. City............................: >> 4g. State...........................: >> 4h. Postal Code.....................: >> 4i. Country.........................: >> 4j. Phone Number....................: >> 4k. Fax Number......................: >> 4l. E-Mailbox.......................: >> >> Technical Contact >> 5a. NIC Handle (if known)...........: JRL17 >> 5b. (I)ndividual (R)ole?............: Individual >> 5c. Name(Last, First)...............: >> 5d. Organization Name...............: >> 5e. Street Address..................: >> 5f. City............................: >> 5g. State...........................: >> 5h. Postal Code.....................: >> 5i. Country.........................: >> 5j. Phone Number....................: >> 5k. Fax Number......................: >> 5l. E-Mailbox.......................: >> >> Billing Contact >> 6a. NIC Handle (if known)...........: JRL17 >> 6b. (I)ndividual (R)ole?............: Individual >> 6c. Name (Last, First)..............: >> 6d. Organization Name...............: >> 6e. Street Address..................: >> 6f. City............................: >> 6g. State...........................: >> 6h. Postal Code.....................: >> 6i. Country.........................: >> 6j. Phone Number....................: >> 6k. Fax Number......................: >> 6l. E-Mailbox.......................: >> >> Prime Name Server >> 7a. Primary Server Hostname.........: NS1.PACIFIC.NET.PH >> 7b. Primary Server Netaddress.......: 210.23.234.33 >> >> Secondary Name Server(s) >> 8a. Secondary Server Hostname.......: NS2.PACIFIC.NET.PH >> 8b. Secondary Server Netaddress.....: 210.23.234.65 >> >> >> END OF AGREEMENT >> >> >> For instructions, please refer to: >> "http://rs.internic.net/help/instructions.txt" >> >>

7 9

.cc domain spam
by Jon Lewis 30 Sep '98

30 Sep '98

Are others being spammed on their NIC contact addresses by domainspace.com trying to sell .cc domains? Received: from domainspace.com ([209.203.244.14]) by yoda.fdt.net with ESMTP id UAA01623 for <jlewis(a)FDT.NET>; Fri, 25 Sep 1998 20:19:03 -0400 ------------------------------------------------------------------ Jon Lewis <jlewis(a)fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____

14 20

Fiber outage for BBN 29 Sep
by Andy McConnell 30 Sep '98

30 Sep '98

Curious - no one seemed to mention BBN Planet's "major" fiber cut yesterday. Their trouble system "shortcutted" calls to an automated message saying there were two major cuts in the Texas and Washington DC area. their ticket was #273439. As a BBN customer, we had trouble getting out of BBN all morning, and by early afternoon things were fine. Did anyone on the list see this sort of trouble? -Andy -- Andy McConnell アンディマッコネル Network Architect, NTT Multimedia Communications Laboratories Freedom means that, in time of war, good men and women will be asked to risk their lives because we think it better to die free than to live as slaves.

2 1

1997 Fiber Deployment Update Report Available
by Simon Leinen 30 Sep '98

30 Sep '98

FYI, I just noticed that this had been put on the FCC Web server earlier this month, see http://www.fcc.gov/Bureaus/Common_Carrier/Reports/FCC-State_Link/infra.html -- Simon.

1 0

Re: UDP packet/DNS server
by Roeland M.J. Meyer 30 Sep '98

30 Sep '98

Yeah, and if you do then sendmail will be broken, according to the v8.9.1 dox. It's called a wild-card MX record and is specifically not recommended, more than once, in the sendmail dox. I actually had NetCom tech support recommend it once, then I found out why it's not recommended, the hard way. When it comes to DNS, you're *much* better off by being specific, even if it means being verbose. At 10:39 AM 9/30/98 +0900, Tatsuya Kawasaki wrote: >Eric, > >thank for your reply. Though I did not agree with RFC I understand >what you are saying. >Do you think it is about time to change RFC? > >BTW, according to NDS and BIND 2nd Ed. by O'Reilly, it is okay for >MX record too. :-) > >TIA, >Tatsuya > >$B$+$o$5$-(B >TK3197 > >= = = = = = >Business Network Telecom (BNT) >$B%S%8%M%9%M%C%H%o!<%/%F%l%3%`3t<02q<R(B >$B")(B111-0053$B!!El5~ETBfEl6h@uAp66(B3-8-5 >31$B;35~%S%k(B6$B3,(B >TEL 03-5687-3945 FAX 03-5687-6009 >http://www.giganet.net > >On Tue, 29 Sep 1998, Eric Sobocinski wrote: > >> But it's perfectly ok for PTR records, though perhaps your example is less >> than ideal. The objection to the use of "*" was specific to NS records. >> An NS record should exist for a domain only if that domain exists. Since >> "*" matches any subdomain whether the domain exists or not, an NS record >> will be returned for non-existent subdomains and that violates the rule. >> Some records of other types are incompatible with "*" for similar reasons. >> The major point here is that any DNS record should reference either a valid >> response or another record that will lead to a response, and an NS record >> pointing to a zone file that doesn't exist is neither. >> >> Some folks will contend that the use of "*" in PTR records is bad form even >> though it is legal. That's a religious war, not a technical one. (I >> happen to like the use of "*", though I also believe that one should first >> apply specific host names whenever a static mapping allows). >> >> >> On Monday, 28 Sep 1998 at 21:02 EDT, Eric Germann wrote: >> > >> >you have to admit, it does save one hell of a lot of typing for the 1918 >> >IN-ADDR.ARPA delegations. >> > >> >rfc1918.db >> >---------- >> > >> >@ IN SOA ns1.xxx.net. hostmaster.xxx.net. ( >> > 1997101001 ; serial >> > 300 ; refresh >> > 300 ; retry >> > 604800 ; expire >> > 600) ; minimum >> > >> > IN NS ns1.xxx.net. >> > IN NS ns2.xxx.net. >> > >> > >> >* IN PTR rfc1918.xxx.net. >> >----------- >> > >> >then in named.bt >> > >> >primary 16.172.in-addr.arpa RFC1918.DB >> >primary 17.172.in-addr.arpa RFC1918.DB >> >primary 18.172.in-addr.arpa RFC1918.DB >> >primary 19.172.in-addr.arpa RFC1918.DB >> >primary 20.172.in-addr.arpa RFC1918.DB >> >primary 21.172.in-addr.arpa RFC1918.DB >> >primary 22.172.in-addr.arpa RFC1918.DB >> >primary 23.172.in-addr.arpa RFC1918.DB >> >primary 24.172.in-addr.arpa RFC1918.DB >> >primary 25.172.in-addr.arpa RFC1918.DB >> >primary 26.172.in-addr.arpa RFC1918.DB >> >primary 27.172.in-addr.arpa RFC1918.DB >> >primary 28.172.in-addr.arpa RFC1918.DB >> >primary 29.172.in-addr.arpa RFC1918.DB >> >primary 30.172.in-addr.arpa RFC1918.DB >> >primary 31.172.in-addr.arpa RFC1918.DB >> > >> >repeat for 10.x.x.x and 192.168 space >> > >> >To reiterate the question posed by the original poster, (donning asbestos), >> >why is this bad? >> > >> >Eric >> > >> > >> >At 08:31 AM 9/28/98 -0500, you wrote: >> >>Tatsuya Kawasaki wrote: >> >>>xyz.com. IN NS that.host >> >>>*.xyz.com In NS that.host >> >> >> >>Gah!! >> >> >> >>Illegal! >> >> >> >>Never use "*" in DNS! Just makes /bad things/ happen. >> >> >> >>@ IN SOA xyz.com. hostmaster.xyz.com. ( >> >> 1998092801 3600 1800 3600000 7200) >> >> >> >> ns ns1.xyz.com. >> >> ns ns2.xyz.com. >> >> >> >> mx 0 mail.xyz.com. >> >> >> >>mail a 1.2.3.4 >> >> mx 0 mail >> >> >> >>. etc .. >> >> >> >>-- >> >>jamie rishaw (efnet:gavroche) American Information Systems, >> >Inc. >> >> Tel:312.425.7140, FAX:312.425.7240 >> >> Help stop spam! router(config)#no ip routing >> >> thirty thousand feet above the earth..youre a beautiful thing.. >> >> >> > >> >========================================================================== >> > Eric Germann CCTec >> > ekgermann(a)cctec.com Van Wert, OH 45891 >> > http://www.cctec.com Ph: 419 968 2640 >> > Fax: 419 968 2641 >> > Network Design, Connectivity & System Integration Services >> > A Microsoft Solution Provider >> > >> > ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ I bet the human brain is a kludge. -- Marvin Minsky

1 0

Re: Thanks WAS: any cisco experienced...
by barton＠cent.net 30 Sep '98

30 Sep '98

Sorry if this is the wrong topic for NANOG but some mis-information needs to be fixed before it spreads any further. >I appreciate the assistance several of you provided. As it turns out the >image that was installed on the flash was a compressed image only for the >1605, and not for the 1601-1604 routers. It looks like someone at RMA >inadvertantly loaded the wrong software to flash, and it ended up throwing >most off guard. I knew it had to be something simple. WRONG, WRONG, WRONG. NOT just for 1605. It is a perfectly fine image and one I would routinely recommend for any 1601-1604 user, but you *MUST* understand the implications of running it. You don't mind running about 35% faster, I would assume, as that is what you can now do. You have loaded an image that has to load into DRAM and then self decompresses. Multiple 3rd party toolkits do this routinely for 25xx routers if someone needs more squeeze that an Unix .Z image provides to wedge a recent IOS into FLASH. Sadly the 1601's bootstrap has a **BUG** that precludes running mere .Z images, but then cisco came out with the 1605 and with it came cisco provided -mz images - to everyone's joy. The 1601-1604 have only 2 meg soldered in, so adding a 16 meg non-parity simm ($15 or so these days) only gets you to 18 meg. Not enough for the monster largest images and still leave enough for buffers and tables. Marketing decided to not let the customers only needing some smaller image know you can just as well run from DRAM. Usual cisco arrogance. "keep them stupid - they still pay $1000 for 16 meg DRAM which proves it" So they made the 1605 with 8 meg soldered in. That with a 16meg SIMM is enough to run any image in DRAM and still leave enough for other things. BUY A $15 (or $25 if someone is ripping you off, or $1000 if you are being "ciscoed") 16 meg DRAM simm and your box with the -mz image will not only boot but will run 35% faster than running from FLASH. And, with FLASH left (READ/WRITE), updates are trivial on a running router. This has been rehashed repeatedly on c.d.s.c. Check an archive. >For the record in the 1600-series world.. images with c1600-mz* are >compressed and will only work on the 1605 model. NO NO! - only will work in a 16xx router with adequate DRAM, but since you can MAX that box for a $15 16 meg DRAM SIMM, this is hardly a problem. >Images with c1600-l* are for the 1601-1604 models and are not compressed. Unless someone uses one of the available toolkits to make a -mz. Using a unix compressed .Z image ***SHOULD*** be ok but there is a good old fashioned *BUG* is their boot code. The TAC says so, too (I can probably dig out an old case number if really pressed). Now that cisco ships the -mz images for 1605s, every 16xx should be running them. Many many 25xx users run .Z or -mz images and cisco's code says "wrong image type" which everyone doing this simply ignores.

1 0

RE: UDP packet/DNS server
by Tatsuya Kawasaki 30 Sep '98

30 Sep '98

Raymond, Thnx for a quick reply. I checked with the person in the charge of the host. He could not telnet 53 my host. So I believe that is the problem Since they did not like to have zone transfer. I create to record to pass "NS" to that host via tying xyz.com. IN NS that.host *.xyz.com In NS that.host and it works fine when I type www.xyz.com,which give me the A record but ... in the daemonlog, I see Sep 28 14:34:06 auth2 named[8958]: Ready to answer queries. Sep 28 14:34:16 auth2 named[8958]: bad referral (xyz.com !< *.xyz.com) Sep 28 14:34:16 auth2 named[8958]: bad referral (xyz.com !< *.xyz.com) Any suggestion? what did I do? かわさき TK3197 = = = = = = Business Network Telecom (BNT) ビジネスネットワークテレコム株式会社〒111-0053　東京都台東区浅草橋3-8-5 31山京ビル6階 TEL 03-5687-3945 FAX 03-5687-6009 http://www.giganet.net On Sun, 27 Sep 1998, Raymond Forbes wrote: > It is possible that the router or the firewall is not allowing connections, > that would be the only way to explain what you are seeing. > > ray > > > ---------- > > From: Tatsuya Kawasaki[SMTP:tatsuya@giganet.net] > > Sent: Sunday, September 27, 1998 9:33 PM > > To: Raymond Forbes > > Subject: RE: UDP packet/DNS server > > > > I have tried to get zone transfer via dig. it failed. > > None get back. I have looked at their named.conf. > > I did not see any restriction on it. > > > > I could not receive zone transfer from a host. > > So if someone log in the the host telnet 53 to my host. > > If telnet is sccuessful then zone transfer is possible. > > But telent from my host to the host, and telent failed does not > > really means anything? > > > > TIA > > > > Tatsuya > > > > > > > > > > > > ???? > > TK3197 > > > > = = = = = = > > Business Network Telecom (BNT) > > ?????????????????? > > ?111-0053?"??s'??????3-8-5 > > 31????6? > > TEL 03-5687-3945 FAX 03-5687-6009 > > http://www.giganet.net > > > > On Sun, 27 Sep 1998, Raymond Forbes wrote: > > > > > zone transfers are not done by UDP. They are TCP. A couple of ways you > > can > > > test is to telnet to port 53 and see if you make a connection. Also, if > > you > > > do nslookup and then ls domain name this is equivilant to doing a zone > > > transfer. > > > > > > hope this helps. > > > > > > ray > > > > > > > ---------- > > > > From: Tatsuya Kawasaki[SMTP:tatsuya@giganet.net] > > > > Sent: Sunday, September 27, 1998 8:44 PM > > > > To: nanog ml > > > > Subject: UDP packet/DNS server > > > > > > > > Hello Nanog, > > > > > > > > I am trying get zone trasfer from a host, but it seems that because of > > > > firewals?, I can not get any record. > > > > They acknowelged that there is a host behind the firewalls but they > > claim > > > > it should not affect it. (I don't believe it.) > > > > But I don't know how to check/prove that if certain host can > > > > receive/send an UDP packet. > > > > > > > > > > > > TIA, > > > > > > > > Tatsuya > > > > > > > > > > > > ???? > > > > TK3197 > > > > > > > > = = = = = = > > > > Business Network Telecom (BNT) > > > > ?????????????????? > > > > ?111-0053?"??s'??????3-8-5 > > > > 31????6? > > > > TEL 03-5687-3945 FAX 03-5687-6009 > > > > http://www.giganet.net > > > > > > > > > >

8 9

Your class 'B' address space
by Mark Vickers 30 Sep '98

30 Sep '98

Let's add a little spice to you list...run it up the flag pole etc... but please let's deal with this professionally with out to much flame! My goal is to ensure the network meets the business objective of our company, not simply to debug traffic etc. In order to do this I need redundant connections to multiple ISP's, and a method for delivering delay sensitive traffic in the most efficient way possible. The above implies BGP. I've applied to ARIN for a number block large enough to ensure routablility, and have been rejected. This leaves me with three alternatives, please correct me if you see any another alternatives. First, we can attempt to buy address space which may or may not be transferable, or more likely we acquire a small company, and/or it's assets, one of which just happens to be a large chuck of address space. Second, I can do the time proven technique of lying about how many hosts I have or how many I plan to have, this I find uncomfortable as I think it is dishonest! I'd bet at least one of the readers of this list has exaggerated about how may hosts they have in their network, or how many they planed to have on a template, so don't be to quick to grab for the high moral ground!! Finally, I can appeal ARIN's decision, which I have already requested from IANA, and was told to request an appeal from hostmaster(a)ARIN.net. I'm still waiting to here something. On appeal I plan to quote RFC2050 which according to the ARIN web site is what they use make allocation descions. Basically I think ARIN procedures only take into account network size, and nothing else. I don't think RFC2050 language is that strict. Please see item '3b' below: "In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from 1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. b) the organization is multi-homed with no favored connection. c) the organization's actual requirement for IP space is very large, for example, the network prefix required to cover the request is of length /18 or shorter. All other requesters should contact its ISP for address space or utilize the addresses reserved for non-connected networks described in 1918 until an Internet connection is established. Note that addresses issued directly from the IRs,(non-provider based), are the least likely to be routable across the Internet. " Also, from 3.1 "utilization is a key factor" implying it's not the only factor. " 3.1 Common Registry Requirements Because the number of available IP addresses on the Internet is limited, the utilization rate of address space will be a key factor in network number assignment. " Basically our normal output traffic is about 45mb/s with a peak as high as 67.6Mb/s during Clinton's shinangians, we've been listed as the 16th busiest web site in the world, and I think that ought to count toward getting a routable address space!!! I also wonder if there aren't free speech issues involved if US entities start dropping traffic based on non technical factors? I welcome any suggestions you may have as to how I can archive my goal of obtaining an address block big enough to implement BGP succesfully. Thank You Mark Vickers RealNetworks, Inc. " In order for the Internet to scale using existing technologies, use of regional registry services should be limited to the assignment of IP addresses for organizations meeting one or more of the following conditions: a) the organization has no intention of connecting to the Internet-either now or in the future-but it still requires a globally unique IP address. The organization should consider using reserved addresses from 1918. If it is determined this is not possible, they can be issued unique (if not Internet routable) IP addresses. b) the organization is multi-homed with no favored connection. c) the organization's actual requirement for IP space is very large, for example, the network prefix required to cover the request is of length /18 or shorter.

8 8

Thanks WAS: any cisco experienced...
by Kevin Brown 30 Sep '98

30 Sep '98

I appreciate the assistance several of you provided. As it turns out the image that was installed on the flash was a compressed image only for the 1605, and not for the 1601-1604 routers. It looks like someone at RMA inadvertantly loaded the wrong software to flash, and it ended up throwing most off guard. I knew it had to be something simple. For the record in the 1600-series world.. images with c1600-mz* are compressed and will only work on the 1605 model. Images with c1600-l* are for the 1601-1604 models and are not compressed. The responses ranged from get new flash, get new router, your tftp is broke, you didn't get the whole image, to finally...wrong image, thanks to some fine folks from Cisco here on Nanog :=) Hats off to you folks. Now I can keep all my hair, and draw a quick breath of sanity before the next lightning storm or backhoe comes through.

1 0