- NANOG - lists.nanog.org

rfc-1918 reverses broken again (still?)
by Marc Slemko 29 May '98

29 May '98

The reverse lookups for the RFC-1918 address space are broken again, or still. $ dig -x 172.16 any @blackhole.isi.edu ; <<>> DiG 8.1 <<>> -x any @blackhole.isi.edu ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_send to server blackhole.isi.edu 128.9.64.26: Connection timed out blackhole.isi.edu and rs0.internic.net are timing out, while ns2.internic.net is giving wrong answers: $ dig -x 192.168.1.1 @ns2.internic.net ; <<>> DiG 2.2 <<>> -x @ns2.internic.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10 ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; 1.1.168.192.in-addr.arpa, type = ANY, class = IN ;; Total query time: 145 msec ;; FROM: valis.worldgate.com to SERVER: ns2.internic.net 198.41.0.11 ;; WHEN: Fri May 29 01:33:24 1998 ;; MSG SIZE sent: 42 rcvd: 42 $ dig -x 192.168.1.1 @blackhole.isi.edu ; <<>> DiG 2.2 <<>> -x @blackhole.isi.edu ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_send to server blackhole.isi.edu 128.9.64.26: Operation timed out Heck, not having any servers for the space is a lot better than the current situation. It makes traceroutes over links using private address space (it happens and some people recommend it, even though I'm not fond of the idea...) annoying.

2 2

Oversea's ISP
by Nathy Thongphok 29 May '98

29 May '98

I need to find an ISPs that can provide me multiple least T-1s in the following countries and give me the least latency. France, United Kingdom, Russia, Portugal, Pakestan. I also need to know the latency between Bethesda Maryland to an ISPs in the above countries. Can someone direct me to the right direction in completing this project. Thanks, nathy

2 1

nice...
by John Fraizer 29 May '98

29 May '98

>Date: Thu, 28 May 1998 18:45:32 -0500 >From: "Jeff Miller" <Jeff_Miller(a)oldnational.com> >To: John.Fraizer(a)EnterZone.Net >Subject: Re: >Content-Disposition: inline > >I will be out of the office Wed., Thurs, and Fri. >Will return Monday June 1st. > > >J_ Time to teach someone how to use procmail. It seems that Jeff is sending his canned message to the sender of EVERY message going to NANOG. ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

AUTORESPONDERS
by jamie＠dilbert.ais.net 29 May '98

29 May '98

OK.. People need to learn how to use autoresponders for nanog e-mail. I received three replies to my last post saying "I'll be out of the office". If this were my list, those people with less than a quarter clue (as ass-u-med in my last post) would have earned themselves auto unsubscribes. Please.. Please people :) If you're going to set up autoresponders, take appropriate measures to make sure your listmail doesnt get replied to. Here's a procmailrc for those who cant figure it out. Please, change "jamie" to "youremailaddress". :-p :0 h c * !^FROM_DAEMON * !^X-Loop: jamie * ^TO(jamie@) | (formail -r -A"Precedence: junk (autoreply)" \ -A"X-Loop: jamie" ; \ cat $HOME/.autoreply) | $SENDMAIL -t and then I have "~/.autoreply" with the body of what I want to reply with. Then again, if you set up an autoreply and don't know how to do it right, you probably aren't important enough to matter, and you should remove it anyhow. Now I go back to my lil' lurk hole. -jamie -- jamie rishaw (dal/efnet:gavroche) American Information Systems, Inc. rdm: "Religion is obsolete." gsr: "By what?" jgr: "Solaris." (1996) Tel:312.425.7140, FAX:312.425.7240

1 0

RE: ingress filtering
by John Fraizer 29 May '98

29 May '98

At 08:57 AM 5/29/98 -0400, you wrote: >> Actually it has nothing to do with WINS. If all the ISP's would >implement > >Bzzt. Thank you for playing, though. If it were not for WinS, there >wouldn't >be a second packet being sent, no matter what junk is the payload. Thanks. I knew I wasn't crazy and seriously doubted that my sniffer was inventing these packets just to piss me off. >Now I agree ISP's should do better DNS resolution, but every MS box >plugged into >the net sending a second packet adds up to a lot of junk packets eating >up >expensive bandwidth. MS catches the blunt of the critisizm because they >are the >only ones to have adopted such a lame networking scheme, and then forced >it >down others quotes. As stated before: [OverKill]:/# nslookup www.stefcam.com Server: NS1.ENTERZONE.NET Address: 209.41.244.5 Name: STEFCAM.COM Address: 209.41.244.238 Aliases: www.stefcam.com [OverKill]:/# nslookup 209.41.244.238 Server: NS1.ENTERZONE.NET Address: 209.41.244.5 Name: StefCAM.Com Address: 209.41.244.238 By the way, Stronghold will refuse to bind to an address that does not reverse so, I knew it was right even before the lookup. ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

RE: PC Bozo's World bites again (CNN, too)
by Jeff Victor - Sun Microsystems Systems Engineer 29 May '98

29 May '98

Of course, instead of just theorizing about which factors have the greatest impact after changing the client's MTU, someone could end this discussion by performing the following experiment with: * PC with MS Windows * Macintosh * Unix box Hook each box up to the same dial-up line, using the same dial-up service. Measure response time to visit various web sites, ftp sites, etc. Perform various runs with different MTUs. Of course, to ensure validity of the data, memory and disk caches must be cleared between tests, and the tests must be run multiple times to remove the effects of caching at the servers and between the servers and the client. If the PC shows a significant performance improvement at smaller MTUs, but the other two don't, we can conclude that Windows is unusual (in a new way). But if they all behave similarly according to MTU size, Windows would be "innocent." I would be very interested in the results. Unfortunately, I don't have the equipment at home to do this. Does anyone out there? ---------------------------------------------------------------------------- Jeff Victor Voice#: 518-782-1046 Systems Engineer Fax#: 518-783-7359 Sun Microsystems jeff.victor(a)east.sun.com ----------------------------------------------------------------------------

1 0

Cable & Wireless buys MCI Internet
by hhui＠arcfour.com 29 May '98

29 May '98

http://www.news.com/News/Item/0,4,22519,00.html well, this should be interesting. --- Tung-Hui Hu (HH26) Network admin and poet hhui(a)arcfour.com

10 9

Re: ARIN Advisory Council recommendations I have made
by John Fraizer 29 May '98

29 May '98

>These changes will fix the transparency problems which I believe exist today >within the structure of ARIN. AMEN > >You have the other two (the address allocation policy changes and pricing >changes) as well. Would you like me to write these up formally? Yes, please do and make them available via www. ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

RE: ingress filtering
by Eric Germann 29 May '98

29 May '98

At 08:57 AM 5/29/98 -0400, jeyers(a)ialn.com wrote: > >-----Original Message----- >From: Eric Germann [mailto:ekgermann@cctec.com] >Sent: Friday, May 29, 1998 8:09 AM >To: John Fraizer >Cc: Mr. Dana Hudes; nanog(a)merit.edu >Subject: Re: ingress filtering > >At 02:32 PM 5/28/98 -0400, John Fraizer wrote: > >> Actually it has nothing to do with WINS. If all the ISP's would >implement > >Bzzt. Thank you for playing, though. If it were not for WinS, there >wouldn't >be a second packet being sent, no matter what junk is the payload. > Buzz, again. Try reading about WINS. It is a manifestation of a NetBIOS name server as defined in RFC 1001/1002. If it were using WINS for this, it would NOT hit the target machine, but the WINS server. Also, if DNS can resolve the in-addr.arpa mapping, the second packet is never sent. Ergo, it has nothing to do with WINS. >>solid in-addr.arpa reverse mappings, this would go away. Microsoft's >DNS >>resolver has been extended, when DNS lookups fail, to do a reverse >NETBIOS >>query against the target machine so it can use its name when displaying >>stuff via NBTSTAT, etc. It was designed this way, before the Internet >>became popular. > >Excuse me? I was using the Internet way before Microshaft was a dream >in Bill's >head. The RFC's you quote were rammed into existance by DARPA to >provide early >ecanpsulation techniques so that companies like MS could say they were >IP/Internet >compatible, (instead of using a real protocol) and get away from Novel >slamming >them for non-routable protocol support only. All they did was to take >the same >non-routable junk and throw it inside an ip packet and call it >"internet" >compatible. The RFC's quoted provide a way to make that encapsulation >work, they >do not recommend conversion to that as a standard. To encourage that >kind of >conversion would be a major leap backwards. (Wow! let's all abandon our >routeable >protocols and use a non-routed local segment only, encapsulated >protocol. Yippee!) > >Now I agree ISP's should do better DNS resolution, but every MS box >plugged into >the net sending a second packet adds up to a lot of junk packets eating >up >expensive bandwidth. MS catches the blunt of the critisizm because they >are the >only ones to have adopted such a lame networking scheme, and then forced >it >down others quotes. > Again, do solid reverse DNS and the problem goes away. It only does it iff reverse DNS fails. Period. As for timing, MS didn't give a shit about IP at the time they were written. MS wasn't even directly in the business at the time. Repeat after me, NetBIOS is a programming interface, not a protocol. Write it 100 times and them come back and play the game. NetBIOS is neither inherently routable or nonroutable. It depends on the underlying transport protocol, be it XNS, IPX, IP, OSI or proprietary NetBEUI. As for forcing it down others "quotes", the industry picked it. MS networking will run quite happily over any of the above mentioned transport protocols. Your customers selected it. Do your reverse DNS right, and you won't have the problem. ============================================================================= Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

RE: ingress filtering
by jeyers＠ialn.com 29 May '98

29 May '98

-----Original Message----- From: Eric Germann [mailto:ekgermann@cctec.com] Sent: Friday, May 29, 1998 8:09 AM To: John Fraizer Cc: Mr. Dana Hudes; nanog(a)merit.edu Subject: Re: ingress filtering At 02:32 PM 5/28/98 -0400, John Fraizer wrote: > Actually it has nothing to do with WINS. If all the ISP's would implement Bzzt. Thank you for playing, though. If it were not for WinS, there wouldn't be a second packet being sent, no matter what junk is the payload. >solid in-addr.arpa reverse mappings, this would go away. Microsoft's DNS >resolver has been extended, when DNS lookups fail, to do a reverse NETBIOS >query against the target machine so it can use its name when displaying >stuff via NBTSTAT, etc. It was designed this way, before the Internet >became popular. Excuse me? I was using the Internet way before Microshaft was a dream in Bill's head. The RFC's you quote were rammed into existance by DARPA to provide early ecanpsulation techniques so that companies like MS could say they were IP/Internet compatible, (instead of using a real protocol) and get away from Novel slamming them for non-routable protocol support only. All they did was to take the same non-routable junk and throw it inside an ip packet and call it "internet" compatible. The RFC's quoted provide a way to make that encapsulation work, they do not recommend conversion to that as a standard. To encourage that kind of conversion would be a major leap backwards. (Wow! let's all abandon our routeable protocols and use a non-routed local segment only, encapsulated protocol. Yippee!) Now I agree ISP's should do better DNS resolution, but every MS box plugged into the net sending a second packet adds up to a lot of junk packets eating up expensive bandwidth. MS catches the blunt of the critisizm because they are the only ones to have adopted such a lame networking scheme, and then forced it down others quotes. >Before we all rant at MS, I suggest we all read RFC's 1001 and 1002 and >UNDERSTAND NetBIOS over IP, before we blame ALL the worlds ills on MS. >Last I knew, they weren't written by MS. > > >RFC 1001-> http://answerpointe.cctec.com/notes/rfcs1/254e_1e2.htm > >RFC 1002-> http://answerpointe.cctec.com/notes/rfcs1/2e46_1e2.htm > >Author(s): Defense Advanced Research Projects Agency, End-to-End Services >Task Force, Internet Activities Board, NetBIOS Working Group > >>------- >>John Fraizer (root) | __ _ | >>The System Administrator | / / (_)__ __ ____ __ | The choice >>mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU >>http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation >> A 486 is a terrible thing to waste... >> > >======================================================================= ====== >Eric Germann Computer and Communications Technologies >ekgermann(a)cctec.com Van Wert, OH 45891 > Phone: 419 968 2640 > >http://www.cctec.com Fax: 419 968 2641 >Network Design, Connectivity & System Integration Services >A Microsoft Solution Provider >

1 0