North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Microsoft spokesperson blames ICANN
I bet Microsoft had to go get a Unix box and install DNS on it so they could get backup and running.. lol Morris Allen VidcomNet, Inc. ----- Original Message ----- From: "Greg A. Woods" <[email protected]> To: <[email protected]> Sent: Thursday, January 25, 2001 12:26 AM Subject: Re: Microsoft spokesperson blames ICANN > > [ On Wednesday, January 24, 2001 at 20:30:12 (-0500), Henry Yen wrote: ] > > Subject: Re: Microsoft spokesperson blames ICANN > > > > On Wed, Jan 24, 2001 at 06:01:29AM -0500, Greg A. Woods wrote: > > > [ On Wednesday, January 24, 2001 at 13:09:45 (-0800), Roeland Meyer wrote: ] > > > > {OBofftopic: hmm, look at the two timestamps, above. did greg reply to roeland's > > e-mail before it was written?} > > As far as I can tell all my system clocks are close enough to true > network time that NTP hasn't been complaining! :-) > > Note though that my logs show my reply being sent at 18:01 -0500 and the > message came back to me with the date header intact and reading: > > Date: Wed, 24 Jan 2001 18:01:29 -0500 (EST) > > so perhaps the error is actually in your MUA (i.e. in its formation of > the "On ... wrote:" line when preparing the quoted message). Apparently > it gets the "AM" and "PM" wrong when converting from a 24-hour clock to > a 12-hour clock. It should have written "06:01:29PM -0500". > > > whoa, slow down... microsoft apparently hasn't quite figured out what > > hit them (and in these later hours there's implications that there is > > more than one issue happening here). > > In this particular case it's totally irrelevant what hit them. They > needed to get at least one solid reliable replacement nameserver up and > running and answering on one of those IP addresses as soon as humanly > possible if they were to try an mitigate the damage. If it were me and > running the show and if I had even a hint that there were malicious > agents responsible I'd have grabbed as many raw packets off the network > as I could conveniently and quickly store, then I'd have literally > pulled the plug on at least two of the machines and sent the works off > for forensic analysis while a new, slightly different, and far more > secure, machine was brought in to provide this most critical service. > > Given the hindsight gained from reading their announcment (and guessing > what really happened), perhaps they even did that, but it shouldn't have > taken them so many more hours to figure out that the world still wasn't > seeing their DNS no matter what they did to those servers. > > Of course it wouldn't have been nearly so critical an issue requiring > such quick and dirty action if they would have had more diverse DNS > servers. > > Part of the problem of course is that they may not have percieved the > full extent of their problem as quickly as some of us from the outside > were imagining it to be, though that's somewhat difficult to understand, > especially given the nature of the discussion in open forums such as > this one.... > > I wouldn't have been "kicking" them while they were still down if it > wasn't that they'd clearly and obviously tied their own noose and > stepped into it and then pulled the lever on their own trap-door > themselves! > > The comedy of errors in their recovery attempts and the enormous delay > in returning their DNS to operational status points out several grave > operational errors, but none of those errors should ever have caused any > visible problems in the first place -- the root cause of their problems > remains in the fact that they did not follow the best common practices > already well documented by other's who have learned these lessons from > the school of hard knocks. > > -- > Greg A. Woods > > +1 416 218-0098 VE3TCP <[email protected]> <robohack!woods> > Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]> >
|