November 1998 - Test - lists.nanog.org

Journal of Internet Disasters
by Sean Donelan 16 Nov '98

16 Nov '98

eric.CArroll(a)acm.ORG (Eric M. Carroll) writes: >Do we actually need the cooperation of the organizations in question to >effect this? Yes and no. It would be fairly 'easy' to become a editor, start Donelan's Journal Of Internet Disasters, get a number of noted experts to contribute articles analyzing failures with no cooperation of the organizations. But I can predict what the organizations in question would say about such an endeavor: 1) Donelan is engaging in FUD to sell his journal. 2) They are making rash assumptions without knowing all the facts. 3) You know the Internet, you can't please everyone. Its just a small group of people with an axe to grind. 4) It didn't happen. If it did happen, it was minor. If it wasn't minor, not many people were affected. If many people were affected, it wasn't as bad as they said. If it was that bad, we would have known about it. Besides we fixed it, and it isn't a problem (anymore). Sure, sometimes a problem breaks through to the public even when the company tries all those things. Just ask INTEL's PR department about their handling of the Pentinum math bug. But that is relatively rare, and not really the most efficient way to handle problems. >For large enough failures, the results are obvious and the data is fairly >clear. Perhaps a first stage of a Disruption Analysis Working Group would >simply be for a coordinated group to gather the facts, sort through the >impact, analyze the failure and report recommendations in a public forum. I'm going to get pedantic. The results may be obvious, but the cause isn't. I would assert there are a number of large failures where the initial obvious cause has turned out to be wrong (or only a contributing factor). Was the triggering fault for the western power grid failure last year caused by a terrorist bombing or a tree growing too close to a high tension line. From just the results you can't tell the cause. It may have been possible for an outside group, with no cooperation from the power companies, to have discovered the blackened tree on the utility right of way. But without the utility's logs and access to their data, I think it would have been very difficult for an outside group to analyze the failure. In particular I think it would have been close to impossible for an outside group to find the other contributing factors. This should go on the name-droppers list, but here goes.... What do we know about the events with the name servers - f.root-servers.net was not able to transfer a copy of some of the zone files from a.root-servers.net - f.root-servers.net became lame for some zones - tcpdump showed odd AXFR from a.root-servers.net - [fjk].gtld-servers.net have been reported answering NXDOMAIN to some valid domains, NSI denies any problem Other events which may or may not have been related - BGP routing bug disrupted connectivity for some backbones in the preceeding days - Last month the .GOV domain was missing on a.root-servers.net due to a 'known bug' affecting zone transfers from GOV-NIC - Someone has been probing DNS ports for an unknown reason Things I don't know - f.root-servers.net and NSI's servers reacted differently. What are the differences between them (BIND versions, in-house source code changes, operating systems/run-time libraries/compilers) - how long were servers unable to transfer the zone? The SOA says a zone is good for 7 days. Why they expire/corrupt the old zone before getting a new copy? - Routing between ISC and NSI for the preceeding period before the problem was discovered Theories - Network connectivity was insufficient between NSI and ISC for long enough the zones timed out (why were other servers affected?) - Bug in BIND (or an in-house modified version) (why did vixie's and NSI's servers return different responses?) - Bug in a support system (O/S, RTL, Compiler, etc) or its installation - Operator error (erroneous reports of failure) - Other malicious activity? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

7 7

Multicast storm
by Wilson Chu 16 Nov '98

16 Nov '98

Has anyone ever seen that only one bogus packet caused multicast storm in a vlan environment? In the following example, the first packet with src/dest MAC addresses 72:3a:20:63:6f:9/41:2d:63:6f:6c:6f caused other machines in the network generated nearly 10Mbps traffic towards some multicast MAC addresses for few minutes in a 10/100 switched vlan. Is there any way to prevent it or let those "amplify" devices not to re-send them? 19:27:07.080000 72:3a:20:63:6f:9 41:2d:63:6f:6c:6f 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 570133376:570134836(1460) ack 13531 58 win 8760 (DF) 19:27:07.080000 0:0:f8:5:60:8d 1:0:5e:7e:68:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.080000 0:e0:21:1:0:b1 1:0:5e:42:63:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.080000 0:a0:24:23:39:82 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:a0:24:2a:5a:33 1:0:5e:7e:68:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:60:97:e2:51:24 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:a0:24:95:7a:34 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:0:f8:5:60:8d 1:0:5e:7e:68:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:a0:24:7:30:3d 1:0:5e:5:48:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:a0:24:95:7a:34 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:0:f8:5:60:8d 1:0:5e:7e:68:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.090000 0:60:97:e2:51:24 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:60:97:e2:51:24 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:60:97:e2:51:24 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:e0:21:1:0:b1 1:0:5e:42:63:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:a0:24:7:30:3d 1:0:5e:5:48:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:a0:24:95:7a:34 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:a0:24:2a:5a:33 1:0:5e:7e:68:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:60:97:e2:51:8a 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.100000 0:a0:24:2a:5a:33 1:0:5e:7e:68:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.110000 0:a0:24:95:7a:34 1:0:5e:7e:67:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) 19:27:07.110000 0:a0:24:7:30:3d 1:0:5e:5:48:1 0800 1514: 206.14.182.201.20 > 210.71.156.70.1062: . 0:1460(1460) ack 1 win 8760 (DF) <snip, a 7 MB file> ------ Wilson Chu AboveNet Communications http://www.above.net

1 0

Re: Journal of Internet Disasters
by Roeland M.J. Meyer 16 Nov '98

16 Nov '98

At 10:20 AM 11/15/98 -0500, Deborah Ann Smith wrote: > >Sure, we have a responsibility to mitigate problems from up the pipe. > >But We as an industry and consumers need to start demanding - via writing >to the congress people (They will read letters, not email- and they will >listen if enough people contact them), complaints to the FCC and other >involved groups - high standards of quality from the InterNic and other >organizations that the Internet depend on. We are essentially captive to >their screwups, NO MATTER HOW WELL we prepare. > >Even the FAA recognizes no matter how good a flight crew, if they get >incorrect information from the Tower, any problems that occur are the >Tower's fault! Ahem, I suspect that you're not a pilot. The last time I went through ground school, the pilot has ultimate responsibility for the lives and welfare of all aboard. This includes the responsibility to tell the tower to buzz-off when it's obvious that they're wrong. Even in controlled air-space, where control is heavily biased towards the tower, the pilot has *final* responsibility. If someone dies, the pilot had better have been there first or have a good reason why they're still around, to explain why they're still around. If you're wrong, you had better be dead wrong. Actually, I find your analogy very apropos. To our customers, their internal systems are most important, after that it is their inter-facility connections, *then* they consider their connections to everyone else. Some of us handle their internal and inter-facility connections, as well as their external connections. When the InterNIC fargs-up who do they call? Are they going to understand? The bottom-line is that they don't care. Failure costs them $cash$. It is our job to shield our customers from this as much as possible. Those of us who do, will have satisfied customers, vs. those of us who rely on excuses. ___________________________________________________ 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/ ___________________________________________ Who is John Galt? "Atlas Shrugged" - Ayn Rand

1 0

Re: Hold on to your news servers
by Dean Anderson 16 Nov '98

16 Nov '98

Sheesh. I'm getting tired of increasingly large logs of cancels and reposts. I think we should start treating all cancels that are sent out by someone who is not a moderator or the original poster as an abuse. Anyone who cancels someone elses post who is not a moderator or the original poster should lose their account/job at ISP/etc. So lets start sending in complaints... --Dean At 02:20 PM 11/13/1998 -0500, Jeff Garzik wrote: > > >Hey guys, this is a heads-up about Karl Denninger's new clean-news >system. I haven't seen any posts on this list about it. His message >describing the implementation is attached below, posted "publicly" on >chi.internet. (skip the quoted stuff) > >Karl is about to send out cancel messages, cancelling _every_ Usenet >binary that is not PGP-signed by someone registered with his system. >He says that these cancels will only go out to people he explicitly >peers with, and not Usenet at large. He then adds that what these >peers do with the cancel msgs is their own business. > >Folks, the goal is good, but the implementation is bad. > >These cancel msgs will leak out to Usenet at large. History proves >this; leaking of net.*, bofh.*, clari.*, etc. occurs all the time >despite admins' best efforts. > >And when these cancels leak, every news server on Usenet will >* suddenly be receiving _thousands_ of additional cancels, and >* 99.9999% of the binaries out there will disappear from your servers. > >I do not want to be handling the support calls when this occurs. > >If you are interested in this issue, there is a discussion on >news.admin.net-abuse.usenet, thread "Karl Denninger loses his marbles..." > >Or ask me, I'm more than happy to outline the technical ramifications >of this, and why it's a bad idea, in more detail. I'll cut and paste >from my e-mails to Karl. :) > > Jeff > (news admin/consultant) > > > >P.S. Had mailer problems. Apologies if you are seeing this twice. > > > > >>Path: news.teleport.com!uunet!in3.uu.net!nntp.ntr.net!news.maxwell.syr.edu!news-xf er.newsread.com!netaxs.com!newsread.com!news.mcs.net!ddsw1!news.mcs.net!not- for-mail >>From: karl(a)Denninger.Net (Karl Denninger) >Newsgroups: chi.internet >Subject: Re: MegsInet Newsgroup server >Date: 12 Nov 1998 03:59:06 GMT >Organization: Karls Sushi and Packet Smashers >Message-ID: <72dmea$stt$1(a)Nntp1.mcs.net> >References: <3647E943.3A3(a)spambusters.ml.org> <72dgku$jo6(a)enews4.newsguy.com> >NNTP-Posting-Host: kdhome-2.pr.mcs.net >X-Newsreader: trn 4.0-test69 (20 September 1998) >Xref: news.teleport.com chi.internet:17477 > >In article <72dgku$jo6(a)enews4.newsguy.com>, >Tommy the Terrorist <mayday(a)newsguy.com> wrote: >>In article <3647E943.3A3(a)spambusters.ml.org> Clifton T. Sharp Jr., >>agent150(a)spambusters.ml.org writes: >>>There were some problems of late. One notable thing from the statistics >>>is that we weren't getting our usual hundreds of thousands of articles >>>from the MCI feed. Since C&W bought MCI's internet stuff, it seems like >>>anything associated with the former MCI has gone straight to hell. It >>>looks to me that as of now the problems are fixed; the newsgroups I follow >>>have suddenly found hundreds of articles apiece. >> >>Who's kidding who? I presume you guys have heard of a certain asshole in >>New York government (what a redundancy!) named Vacco? Presumably the >>problem is the collective flushing of digital toilets now that ISP's have >>become the new hunting ground for Evil Substances, etc. >> >>The problem with this particular war is that nothing short of a total >>victory for the people, to keep anything and everything on ISP's, can >>possibly prevent the state aggressors from eating away at free forums of >>communications as fast as they can have their pet narks post child >>pornography (with impunity) to anywhere they want the police to >>"legitimately" attack and destroy. And if that happens, then the last >>permitted forum of free speech in America, or damn near anywhere else, is >>dead, and the only hope of humanity for political progress will be in >>violence so unrestrained and universal that the smallest and weakest of >>people have an equal power of destruction because it is unlimited for >>all. And that is what inevitably will happen, unless something worse >>happens. > >Read this. It solves the problem. > >And yes, this system WILL be going online. The software is already working. > > > >The "Clean-News" System >======================= > >ABSTRACT: > >"Clean-News" is a means to identify the poster of binary data >on Usenet, remove most illegal content, and create a presumption of >accountability. > > >IMPLEMENTATION - USER SIDE: > >The "Clean-News" servers will have a key-ring of PGP keys. Anyone wanting >to post "unmolested" binaries does the following: > >1. Creates a PGP key for either 2.6.2 or 5.0 of the PGP software. > >2. Obtains, from the www.clean-news.org web site, a list of authorized > signers of their PGP key. > >3. Contacts one of those signers, follows their procedures (which may > include the payment of a fee), produces appropriate identification > demanded by that signer, and gets their public key *signed* by that > organization or individual. That is, the signer *vouches* for the > authenticity of the key; that it belongs to the person who claims > to be represented, that the email address associated with it is > valid, and creates and maintains appropriate records to back up > that assertion. > >4. Submits the SIGNED key to the clean-news.org system. > >This database (of signed keys) is PUBLIC. Anyone can query it given an >article which is signed by said key and obtain the name, email address, >AND SIGNER of the key in question. > >The person with the private key associated with the signed, public key >is then free to post binaries on Usenet, and clean-news will not molest >them. > > >IMPLEMENTATION - SERVER SIDE: > >The "clean-news" system obtains a feed from major backbone sites. It >accepts all articles sent to it and maintains no database. It speaks >both the older "ihave" protocol as well as the "check/takethis" newer >NNTP protocol. > >Upon receipt of an article, the software checks to see if the posting >contains binary data. It looks for common encoding formats - UUENCODE >and MIME image data, primarily. > >Textual messages are ignored. > >Binary messages are run through the PGP software, and the output of >the PGP verification process is read back. This process returns one >of several results: > >1. No signature on the file at all. > >2. A signature is on the file, but the key ID is not known. > >3. A signature is on the file, and the key is known, but it is > not certified as "trusted". > >4. A signature is on the file, is valid, and the key is both > known and has a level of trust associated with it. > >In cases 1 - 3, the clean-news system emits a cancel message for the article >in question immediately upon receipt. It does this by following the >convention established for NOCEMs and other "spam cancels"; that is, it >prepends "cancel." to the Message ID, and emits the cancel with this >synthetic message Id. It also returns the posting with the system >identification "clean-news" in the PATH line to permit aliasing out >of the clean-news feed by those site admins who do not want the cancels. > >In case 4, the binary is ignored, as textual messages are. > > >IMPLICATIONS - USENET SITE ADMINS READ THIS: > >1. If you DO NOT want the "Clean-News" cancels, you should alias out > the site "clean-news" from your Usenet software. Note that doing > this will REMOVE any presumption that you would otherwise gain > by ACCEPTING this feed. > >2. If you DO want the "Clean-News" cancels, then do nothing, and > further, contact your upstream News peers and insure that THEY > are not aliasing out the feed. > >3. If you CANNOT obtain these cancels (because all your upstreams > are aliasing them out), or if you want the BEST possible feed, > contact feedme(a)clean-news.org by email. You will receive in > response an automated email detailing how to obtain a direct > feed of the clean-news cancels. > > Note that this feed is rather low in volume - while it emits > MANY cancels, they are small articles. You MUST BE able to > keep up with this feed - the feed software will NOT keep > articles for more than a few hours before it "junks" them. > The feed will come to you via a Diablo feed system and is > UNIDIRECTIONAL. Attempting to connect back to the Diablo > machine will fail. > >4. If you want to pass these cancels on to your PEERS, be advised > that some of them may consider this service to be a "bad thing". > I recommend, but obviously cannot enforce, that such is noticed > to your peers so they may alias out the feed if they do not > want it. > > > >WHAT DOES THIS MEAN TO POSTERS: > >1. The use of a valid key creates a *presumption*, but not proof, > that the poster really is who they said they are. That is, enough > to get a search warrant. If Kiddie Porn shows up with a signature, > the TRUSTED SIGNER of the key is determinable. That signer must, > to be considered a trusted signer, keep records suitable for > interrogation based on a published policy (ie: "serve us with a > subpoena", etc). > > The LEO in question then asks the signer for the data, and complies > with the policy they have set (which may include obtaining a warrant > and/or subpoena). They then get a search warrant for the alleged > perpetrator of the transmission, and see if in fact the material > in question is being emitted there using standard forensic > techniques. > >2. LEGITIMATE binary posters have nothing to fear. Anonymous binaries > get cancelled instantly, as do any which are unauthenticated. > Those which ARE authenticated are free to be posted, but your > identity is known, its undeniably yours (since it WAS your private > key used to sign the article) and if you post something "naughty" > the LEOs have all they need to come after you. > > > >WHAT ARE MY RESPONSIBILITIES AS A USER OF THIS SYSTEM WHO SUBMITS A KEY? > >Your primary responsibility is to PROTECT YOUR PRIVATE KEY. It is >*STRONGLY* recommended that you keep this key on a protected, safe, >removable device (such as a floppy with write-protect enabled) and NOT >let it out of your personal control. > >If your PRIVATE key is COMPROMISED (ie: you lose the disk, you have reason >to believe someone has stolen a copy of the key file, etc) you should >IMMEDIATELY contact the introducer (the organization or person you had sign >the key) *AND* the clean-news system at "revoke(a)clean-news.org" by email. >When you contact the clean-news system, SIGN YOUR REVOCATION REQUEST. >DO NOT send anything other than a revocation request to the above address. >NOTE THAT REVOCATION OF A KEY IS PERMANENT AND CANNOT BE REVERSED. >You should ALSO immediately revoke the key from any other key rings >that you may have registered this key with. > >Note that ANY message signed with your key will be PRESUMED to be issued >by you *PERSONALLY*. For this reason you should take EXTREME care with >your private key. If it is stolen and used for illicit purposes those >transactions will be traced to *YOU*, and you could find yourself under >investigation by either civil or criminal authorities for something you >have not done. > > > >HOW DO YOU REVOKE A KEY IF IT IS COMPROMISED? > >Keys may be revoked by: > >1. The person who owns it at any time (ie; "I lost my key disk"). > >2. Any LEO who provides an affidavit that said key was used to > post copyrighted or otherwise illegal material. > >3. Any LEO who provides an affidavit that a trusted introducer > is not in fact trusted (ie: cannot produce the records, or produces > false records, regarding a key they signed). > >4. A trusted introducer may revoke their signature of any person's key > that they have signed, in the event they discover that the key does > not in fact belong to the person claimed or identification was > falsified. > >When a key is invalidated the owner of the key is notified by email that >their key was removed, and why (which of the above categories "happened"). > >A cancelled or revoked key is removed from the key ring, and is treated >exactly as if it was never submitted to the system. > >To revoke a key as the owner of the key, send a PGP-signed request >to "revoke(a)clean-news.org". IF THE REQUEST IS NOT SIGNED OR THE SIGNATURE >IS INVALID IT WILL BE IGNORED. Assuming that the signature is good, you >will be notified by return email when the revocation is processed. > > > > >IS THERE A COST FOR THIS? > >1. Individuals do not pay to list keys. However, INTRODUCERS may > charge for signing a key (at their discretion) and maintaining > the records necessary to comply with identification requests. > >2. Systems desiring a *direct* feed may be assessed a small charge > to cover the operating expenses of the systems involved. NO CHARGE > FOR THE FEED ITSELF IS MADE, NOR FOR THE PROCESSING - ONLY THE > TRANSPORT. If you receive a feed of the cancels you are encouraged > to propagate it to others on mutually-agreeable terms to others > who are also willing to receive it. > > > >WHAT ABOUT PRIVACY ISSUES? > >1. The records of the clean-news system are EXPLICITLY public. > Ergo, submitting a public key to the system constitutes > publication of that key, and the fact that it is signed by one > or more organizations and individuals. HOWEVER, that, alone, is > worthless to an interloper. The email address on the key does NOT > have to be valid, nor does the name - it must only map to a unique > person at the SIGNER'S location which can be disclosed through > their policies. As such, there is no privacy issue on the keyring > used by the clean-news system ITSELF. > >2. Customers and users who have their keys signed by an introducer > should make themselves aware of the privacy policies of the signer. > IF YOU ARE NOT COMFORTABLE WITH THEIR PROCEDURES AND ASSURANCES, YOU > SHOULD USE A DIFFERENT KEY SIGNER! > >-- >-- >Karl Denninger (karl(a)denninger.net) http://www.mcs.net/~karl >I ain't even *authorized* to speak for anyone other than myself, so give >up now on trying to associate my words with any particular organization. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

10 23

Re: was i asleep when the gtld servers had the worse problem today?
by stephen＠sprunk.org 15 Nov '98

15 Nov '98

Thanks to the flood of complaints about the technical accuracy of the article, it has been updated: "F root-servers.net was lame for two days because it could not fetch [".com"] from NSI," he wrote. "*MY* server was not sending fatally bad answers, *THEIRS* were." Several other system administrators also said that the problem was caused by NSI and not by Vixie's machine. Holtzman and another NSI spokesman denied yesterday that the problems were caused by NSI or that they went beyond the F root server. Small problems in the root servers, Holtzman added, are "routine," and usually go unnoticed. "On any given day, we have some kind of problem with one of the root servers. It's fairly typical. This is a little worse in that it's returning something, rather than nothing." -- Stephen Sprunk, K5SSS "Oops." Email: stephen(a)sprunk.org CCIE #3723 -Albert Einstein ICBM: 33.00151N 96.82326W

7 8

RE: Hold on to your news servers
by Chris Mauritz 15 Nov '98

15 Nov '98

Um...ok Paul. Can someone please send me a vixie filter? It's been so long that I can't do it in my head anymore. 8-) C -----Original Message----- From: Paul Vixie To: nanog(a)merit.edu Sent: 11/14/98 7:37 PM Subject: Re: Hold on to your news servers > It's unfortunate that someone with such a long history and undoubtedly a > wealth of experience chooses to spend their time in these fruitless > endeavors rather than using that energy for something useful. That's a very portable paragraph. A lot of folks have said it about me, for example. And I've said it about a lot of folks other than just Karl. So while it's well said, it's about how people view each other rather than about Karl in particular. -- Paul Vixie <paul(a)vix.com>

1 0

Re: Exodus / Clue problems
by Simson L. Garfinkel 15 Nov '98

15 Nov '98

We're seeing it at Vineyard.NET. We're getting volleys of 8 telnets with no apparent username or password provided, roughly once every 9 minutes. ----- Original Message ----- From: Steve Gibbard <scg(a)wwnet.net> To: <nanog(a)merit.edu> Sent: Sunday, November 15, 1998 9:56 PM Subject: Re: Exodus / Clue problems >We're seeing it here too. It appears to have started around 9:10 pm on >one server, and around 9:20 pm on the other. > >-Steve > >On Sun, 15 Nov 1998, William S. Duncanson wrote: > >> Seeing it here, too. >> >> At 18:52 11/15/98 -0500, Daniel Senie wrote: >> >sigma(a)pair.com wrote: >> >> >> >> Let me guess - the IP is 209.67.50.254, and they're trying to login to >> >> nameservers as "root", sometimes a dozen times per second? >> > >> >I'm seeing that IP address trying to telnet into my name servers (don't >> >know if it's as root, since my filters are blocking them). I also see >> >them trying to access IMAP on my servers. >> > >> >Dan >> > >> >-- >> >----------------------------------------------------------------- >> >Daniel Senie dts(a)senie.com >> >Amaranth Networks Inc. http://www.amaranthnetworks.com >> >> >> William S. Duncanson caesar(a)starkreality.com >> The driving force behind the NC is the belief that the companies who brought us >> things like Unix, relational databases, and Windows can make an appliance that >> is inexpensive and easy to use if they choose to do that. -- Scott Adams >> > >-- >Steve Gibbard >WWNet System Administration >+1 734 513-7707 x 2009 >http://www.wwnet.net > >

1 0

RE: Exodus / Clue problems
by Adam Rothschild 15 Nov '98

15 Nov '98

On Sun, 15 Nov 1998, Dave Van Allen wrote: > Same here, dozens of times in a few seconds just now, to all listed > nameservers... I can't imagine what "process" could do this > unintentionally. Exodus??? You home? Interesting you mention this. I've noticed the following on a FreeBSD 2.2.6 box, running BIND 8.1.2... server# netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 server.4375 172.16.1.1.1984 SYN_SENT tcp 0 0 server.ftp server.4374 TIME_WAIT Internal addr space... port 1984.. cute.

1 0

Re: Exodus / Clue problems
by James McKenzie 15 Nov '98

15 Nov '98

I just spoke with Jeff at Exodus. They are working on the problem from there end. What they have so far is that the ip address '209.67.50.254' is spoofed. James James McKenzie mcs(a)1ipnet.net http://www.1ipnet.net

2 1

Re: was i asleep when the gtld servers had the worse problem today?
by Paul Vixie 15 Nov '98

15 Nov '98

> is it just me, or are people confused by the references to > f.root-servers.net (Paul Vixie's machine) > and > f.gtld-servers.net > > which was also reported to have problems? I only read > "F server" in this article, but there are two of those, and > only f.root-servers.net is operated by volunteers, f.gtld-servers.net > is (AFAIK) operated by NSI... three things. 1. there is definitely some confusion here. my f (root-servers.net) was lame (which is not fatal to resolvers who query it). NSI's f (gtld- servers.net) was insane (which was fatal to resolvers who queried it.) 2. my F is not a volunteer. f.root-servers.net is a funded activity of ISC. if my F is "volunteer" than every nameserver everywhere is a "volunteer." 3. holtzman has some other axe he's grinding, this is all smokescreening. if i could just stop worrying about that, i could start being insulted by his wierd comments here and elsewhere. -- Paul Vixie <paul(a)vix.com>

11 11