July 1997 - Test - lists.nanog.org

Good Timing for .COM Problems ?
by Jim Fleming 21 Jul '97

21 Jul '97

People might want to look on the bright side of the recent failure by Network Solutions, Inc. to properly distribute the .COM zone information. This failure will likely make it clear that .COM, .NET and .ORG should be moved to a collection of private, NSI, TLD Name Servers and off of the legacy Root Name Servers operated by the U.S. Government and a few volunteers. The failure comes at a time when the NSF has made it clear that they are slipping out the back door of the "Registry Industry", at a time when Network Solutions, Inc. has recently relocated domain registration personnel to a new building, and at a time when Network Solutions, Inc. is raising more capital via an IPO and making it clear that they intend to continue registering .COM domains. <http://www.netsol.com> The timing could not be better for this "failure". The solution is clearly for NSI to harden the .COM, .NET and .ORG TLD servers with their own infrastructure. The various Root Name Server Confederations around the world have little choice but to point .COM, .NET and .ORG references to the NSI servers (currently the legacy roots). Until other States besides Virginia or other countries set up their own .COM servers, this will be the case and NSI will have what some people view as a "monopoly". -- Jim Fleming Unir Corporation

8 7

RE: Good Timing for .COM Problems ?
by Jim Fleming 21 Jul '97

21 Jul '97

On Monday, July 21, 1997 5:59 AM, Matthew Crosby[SMTP:mcrosby@ms.com] wrote: @ Jim Fleming wrote: @ > @ > People might want to look on the bright side @ > of the recent failure by Network Solutions, Inc. @ > to properly distribute the .COM zone information. @ > <snip> @ @ Let me see if I understand this logic. @ @ _NSI_ screws up. This proves that the volunteer and govt TLD name servers @ can't do their job, and that _NSI_ should do their job. @ @ Hmm. @ You might also want to look at it from a .COM customer point of view.... .COM customers have subscribed with NSI to register their domain names. They might expect that NSI will invest in the infrastructure necessary to provide that service with few if any interruptions. One of the only ways that NSI can totally control the level of customer service they want to deliver is to own or subcontract the operations of their TLD Name Servers. They could do this by setting up a special, secure, high-speed network behind the scenes for zone transfers and high-performance servers to handle the expected demand for .COM names. If they do this, then the legacy Root Name Servers will be free from operating .COM, .NET and .ORG. The legacy Root Name Servers can be migrated to be True RFC 2010 compatible Root Name Servers or the U.S. Government could decide that the best way for it to get completely out of the domain name business is to turn off the legacy Root Name Servers... Would this impact anything...?...of course not, NSI and ISI have already set up new RFC 2010 Root Name Servers that some people have merged into their root.cache file. Those servers do not have .COM, .NET and .ORG on them. They are different from the legacy Root Name Servers, they are not run by the U.S. Government or "volunteers". -- Jim Fleming Unir Corporation

1 0

Re: NSI bulletin 097-004 | Root Server Problems
by woods＠most.weird.com 21 Jul '97

21 Jul '97

> Date: Thu, 17 Jul 1997 22:52:18 +0500 (GMT) > From: David Holtzman <dholtz(a)internic.net> > To: nanog(a)merit.edu > Subject: NSI bulletin 097-004 | Root Server Problems > Resent-Date: Thu, 17 Jul 1997 14:42:42 -0400 (EDT) > > On Wednesday night, July 16, during the computer-generation of the > Internet top-level domain zone files, an Ingres database failure resulted > in corrupt .COM and .NET zone files. Despite alarms raised by Network > Solutions' quality assurance schemes, at approximately 2:30 a.m. (Eastern > Time), a system administrator released the zone file without regenerating the > file and verifying its integrity. Network Solutions corrected the > problem and reissued the zone file by 6:30 a.m. (Eastern Time). > > Thank you. > David H. Holtzman > Sr VP Engineering, Network Solutions > dholtz(a)internic.net So, if the new zone files were re-issued at 06:30 EST, and they take about an hour to download, why was it that some root servers were still handing out bad data many hours later (at least one until about 14:00 EST)? The particular server I'm thinking of, though not residing in the Eastern timezone, does seem to have what I think is a 24x7 NOC nearby, and in theory could have been prepared to reload as quickly as anyone. This may be just a coincidence, but it was about an hour after I e-mailed and telephoned them that they finally had the right data in place. Unfortunately finding the right contact was not entirely trivial because the listed contact person had a full voice-mailbox and his operator had no idea who else I could speak to, and the NOC has only a 1-800 number (and a FAX) listed that doesn't work outside the USA. The NOC person I finally reached on the telephone didn't even seem to be fully aware that they indeed ran a root nameserver for the Internet. He did know that there was e-mail bouncing, and indeed I didn't expect they could answer my e-mail if they were using their own root server.... Worst of all though they left the errant server on-line, handing out NXDOMAIN replies to any and all who asked, while they were downloading the corrected zone files. Hopefully this is not standard operating procedure for a root server, or at least not from now on. What annoys me most is that I didn't receive any notification of any sort of problem from any of the mailing lists out of internic.net. I probably should subscribe to nanog, but I'd have thought namedroppers, or maybe even rs-info, should have had the above announcement posted just as soon as the mailers had enough trustworthy DNS data to deliver it with. There was nothing in http://rs.internic.net/announcements/ either, except for drivel about "maintaining high customer service levels," and there still isn't (though I suppose this event wasn't exactly "good PR"). What are the current procedures for announcing such problems to more than just the root operators themselves? -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods(a)acm.org> <robohack!woods> Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com>

1 0

GTE Seen As Takeover Target
by Randall S. Benn 20 Jul '97

20 Jul '97

Some interesting speculation about GTE's future. Randy > GTE Seen As Takeover Target - Report [Reuters News Service] > 09:46 a.m. Jul 21, 1997 Eastern > > NEW YORK - GTE is seen as an attractive > takover target as long distance carriers aim > to enter local telecommunications markets and > capitalize on GTE's strength in Internet and > data transmission, Business Week reported in > its July 28 issue. > > GTE's chief executive officer Charles Lee is > not discouraging merger talk, the magazine > said. > > ``I'll continue to explore other business > arrangements to the extent that they make > sense for helping shareholders,'' Lee told > Business Week. > > Since GTE is spread out in 28 states in mostly > rural or suburban regions, the company would > serve as a springboard for a leading carrier > such as AT&T, MCI Communications, or Britain's > Cable & Wireless to enter local businesses, > the magazine reported. > > GTE's proposed acquisition of BBN and its > fiberoptic capacity arrangement with Qwest > Communications gives it a strong position in > data transmission, the magazine said. > > Copyright 1997 Reuters Limited. All rights > reserved. Republication and redistribution of > Reuters content is expressly prohibited > without the prior written consent of Reuters. > Reuters shall not be liable for any errors or > delays in the content, or for any actions > taken in reliance thereon. > > ---------------------------------------------------------------------- > Copyright © 1995-97 Infoseek Corporation. All rights reserved. > Disclaimer

1 0

Re: Good Timing for .COM Problems ?
by Dave Crocker 20 Jul '97

20 Jul '97

At 02:16 PM 7/20/97 -0400, David Mercer wrote: >On Sun, 20 Jul 1997, Paul Trotter wrote: >Seems to me that NSI have shown that their training procedures don't work, That's not the problem. The problem is bad procedures, not the failure to follow them correctly. The procedures should have prevented the operator from installing the update, absent serious overrides. Since it is far, far more dangerous to add a bad update than it is to delay the update, the procedures should have prevented the update as soon as the update data failed any of its validity tests. To override preventative mechanisms should require the intervention of senior operations staff. In other words, besides requiring a positive override, it should require additional staff who are not part of the regular, daily activity. Merely issuing passive alarms that can be ignored is representative of basic ignorance about well-understood operator human factors. I said well-understood. That, of course, means that one must use designers knowledgeable in such matters. NSI didn't. That's a management error, not an operator error. >I personally don't find their assurance that such duties will now be Indeed, you shouldn't. It's more important to change the procedures than it is to change the staff. d/ -------------------- Dave Crocker Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info(a)imc.org , http://www.imc.org Member, interim Policy Oversight Committee http://www.gtld-mou.org

1 0

RE: Good Timing for .COM Problems ?
by Jim Fleming 20 Jul '97

20 Jul '97

On Sunday, July 20, 1997 12:44 PM, Paul Trotter[SMTP:ptrotter@ny.ubs.com] wrote: @ Then perhaps we should question why the "problems" are occuring at a @ time when it would be to NSI's benefit (e.g. future IPO) to show that @ the traditional volunteer method doesn't work. @ It should not be very difficult for NSI (and SAIC) to deploy the necessary, robust TLD servers to handle just the .COM, .NET and .ORG TLDs. It seems logical that their "public" shareholders would want their name servers to be under their control. If they decide to do that, then it would be good to coordinate the changes so that the various Root Name Server Confederations can make the switch at the same time. Since the "volunteers" do not have the registry infrastructure to handle .COM, it seems likely that .COM will go where NSI moves it, if they do. Also, not many (if any) companies have stepped forward to provide alternative TLD name servers for .COM. I would imagine that NANOG members would be alerted to these changes well in advance....although, if done properly, it should not be noticed. Only the Root Name Servers need to be changed and it seems to follow that such changes would happen before next year. -- Jim Fleming Unir Corporation

1 0

Re: DC fiber cut: field report
by Jay R. Ashworth 20 Jul '97

20 Jul '97

On Fri, Jul 18, 1997 at 06:44:21PM -0400, Robert E. Seastrom wrote: > Am I the only one who's a cables and switches weenie enough to know > that the telco's _already do this_? Large numbers of local multi-pair ^^^^^^^^^^^^^^^^ > trunking cables are pressurized with nitrogen, and they put pressure > drop alarms on them, so they know if one takes a hit. > > pressurized nitrogen is usually done to keep moisture out, not so that > they can monitor pressure loss. pressure loss in a fed, very long, > pipe is an extremely local phenomenon anyway. i think there are > spooks at some black agencies that monitor against tapping this way. > but in practice, nitrogen pressurization is only done for copper. Yes. I know. ;-) I'm told they really do pressure loss monitor the local stuff, though, even if more for dryness purposes than cable-break. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592

1 0

To ListOwner
by Ray O'Keefe 20 Jul '97

20 Jul '97

Attn ListOwner (nanog list) Please remove any and all email addressees at [www.metsys.com] from the nanog list. There are no personal mailboxes at www.metsys.com so any email address coming to this website cannot be correct. Thanks ......... webmaster(a)metsys.com

1 0

IP flooding by using broadcast address
by Edward Henigin 20 Jul '97

20 Jul '97

We're seeing a pernicious sort of DOS attack lately. The attack takes advantage of hosts IP stack implementation, and how it deals with ICMP packets to the broadcast address. Basically, the short and sweet of it is that most hosts will respond to an echo-request to its broadcast address with an echo reply. So imagine this scenario: some disgruntled hax0r forges his source address to be your web server (or shell server, or irc server, or whatever) and sends some broadcast pings to a well populated remote network. His/her ping will be amplified by the number of hosts on the remote network. Here is an example to illustrate: In one window, I did this: (ed) spanky:~$ ping 205.236.175.255 205.236.175.255 is alive (ed) spanky:~$ In another, this: (root) spanky:~# snoop -d isptp0 proto icmp Using device /dev/isptp (promiscuous mode) spanky -> 205.236.175.255 ICMP Echo request toolbox.total.net -> spanky ICMP Echo reply falcon.total.net -> spanky ICMP Echo reply annex-08.mtl.total.net -> spanky ICMP Echo reply 199.166.230.99 -> spanky ICMP Echo reply gig.net -> spanky ICMP Echo reply 205.236.53.122 -> spanky ICMP Echo reply middletown.total.net -> spanky ICMP Echo reply 205.236.53.199 -> spanky ICMP Echo reply server95.total.net -> spanky ICMP Echo reply 205.236.175.20 -> spanky ICMP Echo reply freddy.total.net -> spanky ICMP Echo reply 205.205.162.10 -> spanky ICMP Echo reply tors.accent.net -> spanky ICMP Echo reply lightning.total.net -> spanky ICMP Echo reply c4700-01.mtl.total.net -> spanky ICMP Echo reply as5200-35.mtl.total.net -> spanky ICMP Echo reply newsfeeder.total.net -> spanky ICMP Echo reply annex-03.mtl.total.net -> spanky ICMP Echo reply annex-02.mtl.total.net -> spanky ICMP Echo reply as5200-31.mtl.total.net -> spanky ICMP Echo reply as5200-30.mtl.total.net -> spanky ICMP Echo reply phoenix.total.net -> spanky ICMP Echo reply bretweir.total.net -> spanky ICMP Echo reply 205.236.175.10 -> spanky ICMP Echo reply wacky.total.net -> spanky ICMP Echo reply 205.236.87.200 -> spanky ICMP Echo reply annex-01.mtl.total.net -> spanky ICMP Echo reply annex-10.mtl.total.net -> spanky ICMP Echo reply as5200-06.mtl.total.net -> spanky ICMP Echo reply as5200-33.mtl.total.net -> spanky ICMP Echo reply as5200-13.mtl.total.net -> spanky ICMP Echo reply as5200-34.mtl.total.net -> spanky ICMP Echo reply annex-09.mtl.total.net -> spanky ICMP Echo reply as5200-28.mtl.total.net -> spanky ICMP Echo reply annex-06.mtl.total.net -> spanky ICMP Echo reply as5200-08.mtl.total.net -> spanky ICMP Echo reply as5200-22.mtl.total.net -> spanky ICMP Echo reply as5200-36.mtl.total.net -> spanky ICMP Echo reply as5200-03.mtl.total.net -> spanky ICMP Echo reply cradlerock.total.net -> spanky ICMP Echo reply as5200-26.mtl.total.net -> spanky ICMP Echo reply as5200-37.mtl.total.net -> spanky ICMP Echo reply c4700-02.mtl.total.net -> spanky ICMP Echo reply www.greernet.com -> spanky ICMP Echo reply 199.166.230.69 -> spanky ICMP Echo reply ns2.accent.net -> spanky ICMP Echo reply rizzo.infobahnos.com -> spanky ICMP Echo reply www.webquebec.com -> spanky ICMP Echo reply annex-07.mtl.total.net -> spanky ICMP Echo reply as5200-12.mtl.total.net -> spanky ICMP Echo reply as5200-32.mtl.total.net -> spanky ICMP Echo reply as5200-19.mtl.total.net -> spanky ICMP Echo reply as5200-02.mtl.total.net -> spanky ICMP Echo reply as5200-29.mtl.total.net -> spanky ICMP Echo reply as5200-11.mtl.total.net -> spanky ICMP Echo reply as5200-20.mtl.total.net -> spanky ICMP Echo reply as5200-10.mtl.total.net -> spanky ICMP Echo reply as5200-21.mtl.total.net -> spanky ICMP Echo reply as5200-16.mtl.total.net -> spanky ICMP Echo reply as5200-15.mtl.total.net -> spanky ICMP Echo reply as5200-05.mtl.total.net -> spanky ICMP Echo reply as5200-01.mtl.total.net -> spanky ICMP Echo reply irc.total.net -> spanky ICMP Echo reply as5200-25.mtl.total.net -> spanky ICMP Echo reply as5200-04.mtl.total.net -> spanky ICMP Echo reply squid.total.net -> spanky ICMP Echo reply 205.236.175.12 -> spanky ICMP Echo reply as5200-14.mtl.total.net -> spanky ICMP Echo reply pico.total.net -> spanky ICMP Echo reply c4700-03.mtl.total.net -> spanky ICMP Echo reply nic2.total.net -> spanky ICMP Echo reply under.total.net -> spanky ICMP Echo reply annex-04.mtl.total.net -> spanky ICMP Echo reply 198.168.57.42 -> spanky ICMP Echo reply as5200-09.mtl.total.net -> spanky ICMP Echo reply as5200-24.mtl.total.net -> spanky ICMP Echo reply as5200-27.mtl.total.net -> spanky ICMP Echo reply as5200-23.mtl.total.net -> spanky ICMP Echo reply as5200-17.mtl.total.net -> spanky ICMP Echo reply as5200-18.mtl.total.net -> spanky ICMP Echo reply as5200-07.mtl.total.net -> spanky ICMP Echo reply (I've already been in contact with Total Access Inc, and they were most cooperative in putting filters on their networks to prevent this from happening again.) In the above example, you see that a single echo request resulted in 81 echo replies, an 81x amplification of Internet traffic. A 28.8Kbps Internet connection becomes 2332.8Kbps, about a T1 and a half, worth of bandwidth, when amplified 81 times. You well know that this much traffic is more than enough to peg a small ISP. If one of these fiends either a) enlists the help of a few friends, all on 28.8 connections, or b) does this sort of thing from an open box on a higher speed university connection, well, they can take down even larger ISP's. What you need to do is put filters on your routers to prevent broadcast packets from entering your network. I believe that some networks, like Total Access Inc's, are among a list of "known" networks that can be used as part of a "portfolio", if you will, of networks that can be used to attack other networks. Everyone needs to be doing the following: 1) Keep measured traffic stats, and look at them, using something like MRTG. 2) Filter all broadcast traffic from coming into your network. I believe that it's QUITE rare to have an application that is both *routed* and uses the broadcast address. This is made harder when you VLSM, but I belive the majority of networks are provisioned on an 8 bit boundary, so you can filter 90% of the traffic by filtering to the .255 address. 3) Re-iterating what people have said before, filter outbound traffic to allow only *your* host traffic from getting out. This makes you a responsible Internet citizen, by preventing people from using your network to launch attacks such as this against others. I think it would be very wise of cisco to have a global flag (or at least, a per-interface flag) which would prevent the forwarding of a packet to an all-ones address. If cisco won't add this feature, maybe Ascend will in their GRF, and maybe a few more GRF's will be sold because of it. Thank you for your time. Edward Henigin Engineering Director, Texas Networking, Inc. ed(a)texas.net (512) 427-1655 Alternate POC's for Texas.Net: Michael Douglass Senior Systems Engineer mikedoug(a)texas.net Bill Bradford Systems Administrator mrbill(a)texas.net Jonah Yokubaitis President barron(a)texas.net

3 4

Quote of the day!
by jamie＠comet.net 19 Jul '97

19 Jul '97

From someone-I-can't-name-cuzza-their-job: "MFS is the spawn of satan, it's all a conspiracy to send us back to the dark ages of hand-written communication." jamie jamie(a)comet.net *************************************************************************** For PGP public key, mail me with Subject:GET KEY For random Ambrose Bierce quote, Mail me with Subject: ambrose Support the anti-Spam amendment - Join at http://www.cauce.org/ "Microsoft was invented by domestic terrorists. Remember, it's no longer an import industry."

2 1