|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: ingress filtering
At 08:57 AM 5/29/98 -0400, [email protected] wrote: > >-----Original Message----- >From: Eric Germann [mailto:[email protected]] >Sent: Friday, May 29, 1998 8:09 AM >To: John Fraizer >Cc: Mr. Dana Hudes; [email protected] >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 [email protected] 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
|