North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Microsoft spokesperson blames ICANN

  • From: Morris Allen
  • Date: Thu Jan 25 13:41:58 2001

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]>
>