- NANOG - lists.nanog.org

Re: Code Red 2 cleanup; reporting..
by ken harris. 10 Aug '01

10 Aug '01

> If nothing is in place, great, I'll just throw e-mails to the > end-users I can find and/or their respective NSP. If something is > in place.. either unofficial or special contacts at the NSPs, great, I'll > go that route. i haven't given this a whirl myself, but i came across it and thought i'd at least share. "Code Red Autoresponder" : < http://www.klippan.seths.se/default.phps > -ken harris (i promised i wouldn't add to the cr noise. woops.)

1 0

Code Red 2 cleanup; reporting..
by z＠s0be.net 10 Aug '01

10 Aug '01

Helu, Is there an effort abound that would allow for lists of verified 'Code Red 2' infected hosts to be reported for cleanup/mitigation? By known 'Code Red 2' infected hosts, I mean that root.exe has been found to exist on the host. Finding the contact information for a lot of these is proving difficult being that a fair amount of the infected machines are Joe Blow broadband customers. Anyone? .z

9 11

RE: NetSol takes over .us TLD and does this
by Roeland Meyer 10 Aug '01

10 Aug '01

Duh! You haven't been keeping up. ICANN/DNSO/GA knew about this *months* ago. In fact, there is an RFP out for managing US. There's problems with the contract though, so there aren't many bidders. US is a royal mess that many don't want to touch. > -----Original Message----- > From: up(a)3.am [mailto:up@3.am] > Sent: Thursday, August 09, 2001 5:41 PM > To: nanog(a)merit.edu > Subject: NetSol takes over .us TLD and does this > > > > > I thought this might be of interest: > > The whois for .us had been working a few weeks ago, but > hadn't been since > then. I dropped an email to action(a)isi.edu (who had been hosting the > whois server until a few weeks ago) and cc'd usdomreg(a)nic.us > and got the > following responses: > > Date: Wed, 08 Aug 2001 12:21:22 -0700 > From: IPC Computing Services <action(a)ISI.EDU> > To: James Smallacombe <james(a)pil.net> > Cc: action(a)ISI.EDU, action-team(a)ISI.EDU > Subject: Re: {2001.08.445} .us TLD whois not in DNS > > > > http://www.nic.us/register/whois.html > > > > Instructs one to use whois.isi.edu > > > > for whois queries on the .us TLD. It's not in DNS: > > > > [richard namedb james]$ traceroute whois.isi.edu > > traceroute: unknown host whois.isi.edu > > > > Could you please look into this and let me know if either > the website > > is wrong or this will be fixed? > > > At the request of the US Department of Commerce, USC/ISI transitioned > all support for the US Domain to Verisign at the end of 2000. We > appologize that the Verisign supported web site still points to > USC/ISI resources but we have no control over their publication of > data. > > IPC Computing Services > > ------- > 31 hours later from the new registrar (Verisign): > > Date: Thu, 09 Aug 2001 19:27:10 -0400 > From: US domreg <usdomreg(a)nic.us> > To: James Smallacombe <james(a)pil.net> > Cc: usreply(a)nic.us > Subject: Re: .us TLD whois not in DNS > > > Dear James, > > Thank you for contacting the US Domain Registry. > > The whois database was run by ISI until recently. The whois > server has > now > been taken offline and so there is no .us whois server > currently. We are > currently working on a replacement but there is no estimate > on how long > that > will take. In the meantime, if there are specific domains you wish to > have > information on, please email them to us and we will manually find the > information for you. > > Regards, > > US Domain Registry > www.nic.us > usdomreg(a)nic.us > > ============================================================== > ================= > > > ok, so .us isn't very widely used, but why then, did the DOC > give it to > Verisign? > > James Smallacombe PlantageNet, Inc. CEO and Janitor > up(a)3.am http://3.am =========================================================================

3 2

Netrail files Chap 11
by Craig Klingler 10 Aug '01

10 Aug '01

Unfortunate for the many fine people at Netrail http://atlanta.bcentral.com/atlanta/stories/2001/08/06/daily59.html

2 1

Re: Strange trace to netsol...
by John Fraizer 10 Aug '01

10 Aug '01

Just in case anyone felt like telling me to contact Winstar directly, they don't have an entry at puck.nether.net and email addresses to noc(a)winstar.net bounces. (Was the NOC the first thing to get the AXE as part of the Ch 11 restructure?) --- John Fraizer EnterZone, Inc ---------- Forwarded message ---------- Date: Thu, 9 Aug 2001 18:13:10 -0700 From: Mail Delivery Subsystem <MAILER-DAEMON(a)winstar.net> To: nanog(a)Overkill.EnterZone.Net Subject: Returned mail: User unknown The original message was received at Thu, 9 Aug 2001 18:13:08 -0700 from mail.winstar.net [207.98.129.30] ----- The following addresses had permanent fatal errors ----- \jbuskirk (expanded from: <support(a)noc.seattle.winstar.net>) \mlanham (expanded from: <support(a)noc.seattle.winstar.net>) \mguled (expanded from: <support(a)noc.seattle.winstar.net>) \noc (expanded from: <support(a)noc.seattle.winstar.net>) ----- Transcript of session follows ----- 550 \jbuskirk... User unknown 550 \mlanham... User unknown 550 \mguled... User unknown 550 \noc... User unknown

2 1

Re: Strange trace to netsol...
by John Fraizer 10 Aug '01

10 Aug '01

Just as expected. It appears that it was a typo on someones part while configuring a ptp link. Notice that hop #2 no longer uses a UUnet address. Strange that the person who built the ptp circuit didn't catch it. 1 1.ATM6-0.CMH-0.WINSTAR.NET (209.140.29.9) [AS 5696] 0 msec 0 msec 4 msec 2 69.winstar.net (65.36.1.69) [AS 5696] 16 msec 16 msec 20 msec 3 pos2-0.wdc1-bb1.winstar.net (216.172.247.117) [AS 5696] 24 msec 24 msec 24 msec 4 7.atm8-0.vienna-0.winstar.net (65.36.0.130) [AS 5696] 24 msec 24 msec 24 msec 5 internic-goodnet.internic.net (209.54.51.90) [AS 5696] 28 msec 28 msec 24 msec 6 www.netsol.com (216.168.224.111) [AS 6245] 24 msec 28 msec 28 msec --- John Fraizer EnterZone, Inc On Thu, 9 Aug 2001, John Fraizer wrote: > Did someone at WINSTAR typo an address on a ptp link? > > > 1 1.ATM6-0.CMH-0.WINSTAR.NET (209.140.29.9) [AS 5696] 4 msec 0 msec 4 msec > 2 4Cust5.tnt36.lax3.da.uu.net (63.36.1.69) [AS 701] 20 msec 20 msec 16 msec > 3 pos2-0.wdc1-bb1.winstar.net (216.172.247.117) [AS 5696] 20 msec 24 msec 24 msec > 4 7.atm8-0.vienna-0.winstar.net (65.36.0.130) [AS 5696] 24 msec 24 msec 24 msec > 5 internic-goodnet.internic.net (209.54.51.90) [AS 5696] 24 msec 28 msec 28 msec > 6 www.netsol.com (216.168.224.111) [AS 6245] 28 msec 28 msec 28 msec > > --- > John Fraizer > EnterZone, Inc

1 0

Another fiber cut in Maryland?
by Sean Donelan 10 Aug '01

10 Aug '01

Its either the continuation, or a new fiber cut in Maryland between Baltimore and Washington DC this afternoon in addition to the one this morning.

2 1

Re: Strange trace to netsol...
by John Fraizer 10 Aug '01

10 Aug '01

Well, if you try to go directly to the IP address, it takes a long trip on the UUnet network to the "REAL" 63.36.1.69. 6 180.at-6-0-0.XR1.CMH2.ALTER.NET (152.63.66.154) [701] 3.670 ms 3.747 ms 5.977 ms 7 189.at-1-1-0.TR1.CHI4.ALTER.NET (152.63.66.218) [701] 14.291 ms 14.748 ms 14.497 ms 8 106.at-6-1-0.TR1.LAX9.ALTER.NET (146.188.141.242) [701] 68.313 ms 68.335 ms 68.843 ms 9 0.so-0-0-0.XR1.LAX9.ALTER.NET (152.63.15.117) [701] 75.470 ms 79.128 ms 67.845 ms 10 191.at-3-1-0.HR2.LAX9.ALTER.NET (152.63.114.129) [701] 68.275 ms 68.263 ms 68.353 ms 11 112.ATM3-0.DR4.LAX3.ALTER.NET (152.63.113.141) [701] 70.499 ms 71.405 ms 70.741 ms 12 tnt36.lax3.da.uu.net (206.115.220.185) [701] 73.373 ms !H 73.859 ms I'm nearly certain that it's a config typo inside Winstar where they hijacked (accidently?) some address space for use on p-t-p links between routers. The reply I'm seeing is simply sourced from 66.36.1.69 so, that is what shows up in the traceroute. This is something that could happen a lot if people don't take care when configuring devices. It will be hard to track inside the misconfigured network because, almost certainly, the address will be in the IGP so, traceroutes to that address from inside Winstars net (and for people who default to winstar) will go to that address. This just showed up within the past few days. I've not seen that address in there in traces previoiusly. --- John Fraizer EnterZone, Inc On Thu, 9 Aug 2001, Peter Helmenstine wrote: > You provide two very good points that I didn't bother looking at. Very > interesting. > > I wonder what you would get for ping times if you pinged directly to the > tnt box. I don't usually trust the times that traceroute gives you. > > -Pete > > On Thu, 9 Aug 2001, John Fraizer wrote: > > > > > I'm not buying that there's a 20ms rtt from Columbus, OH to LA. Beyond > > that, the reverse would indicate that it is a dialup address on a > > TNT. Beyond that, if you will notice, it goes winstar->UU->winstar. > > > > If I had to guess myself, I would say that someone at Winstar hosed the > > addresses when configuring a p-t-p link from Columbus, OH to NJ or NY. > > > > > > --- > > John Fraizer > > EnterZone, Inc > > > > > > > > On Thu, 9 Aug 2001, Peter Helmenstine wrote: > > > > > Seems that if reverse lookups on 63.36.1.69 are resolving to uunet then it > > > wouldn't be a winstar DNS issue. I think it actually goes through that > > > router. I wonder if there is a preferred (static) route through set to > > > point to UUnet on 1.ATM6-0.CMH-0.WINSTAR.NET and UUnet points right back > > > at them. > > > > > > -Pete > > > --- > > > Backbone Engineering V:206-504-5363 > > > Internap Network Services C:206-849-7263 > > > 601 Union Street, Suite 1000 P:888-463-4188 > > > Seattle WA 98101-4064 Text Message:pete-pager@internap.com > > > *The contents of this e-mail message are confidential and proprietary* > > > > > > On Thu, 9 Aug 2001, John Fraizer wrote: > > > > > > > > > > > > > > > Did someone at WINSTAR typo an address on a ptp link? > > > > > > > > > > > > 1 1.ATM6-0.CMH-0.WINSTAR.NET (209.140.29.9) [AS 5696] 4 msec 0 msec 4 msec > > > > 2 4Cust5.tnt36.lax3.da.uu.net (63.36.1.69) [AS 701] 20 msec 20 msec 16 msec > > > > 3 pos2-0.wdc1-bb1.winstar.net (216.172.247.117) [AS 5696] 20 msec 24 msec 24 msec > > > > 4 7.atm8-0.vienna-0.winstar.net (65.36.0.130) [AS 5696] 24 msec 24 msec 24 msec > > > > 5 internic-goodnet.internic.net (209.54.51.90) [AS 5696] 24 msec 28 msec 28 msec > > > > 6 www.netsol.com (216.168.224.111) [AS 6245] 28 msec 28 msec 28 msec > > > > > > > > > > > > > > > > --- > > > > John Fraizer > > > > EnterZone, Inc > > > > > > > > > > > > > > > > > > > >

1 0

Strange trace to netsol...
by John Fraizer 09 Aug '01

09 Aug '01

Did someone at WINSTAR typo an address on a ptp link? 1 1.ATM6-0.CMH-0.WINSTAR.NET (209.140.29.9) [AS 5696] 4 msec 0 msec 4 msec 2 4Cust5.tnt36.lax3.da.uu.net (63.36.1.69) [AS 701] 20 msec 20 msec 16 msec 3 pos2-0.wdc1-bb1.winstar.net (216.172.247.117) [AS 5696] 20 msec 24 msec 24 msec 4 7.atm8-0.vienna-0.winstar.net (65.36.0.130) [AS 5696] 24 msec 24 msec 24 msec 5 internic-goodnet.internic.net (209.54.51.90) [AS 5696] 24 msec 28 msec 28 msec 6 www.netsol.com (216.168.224.111) [AS 6245] 28 msec 28 msec 28 msec --- John Fraizer EnterZone, Inc

1 0

RE: Static routes in an AS vs BGP advertised routes
by Murphy, Brennan 09 Aug '01

09 Aug '01

If the theoretical AS advertised its /19 itself to the ISPs, and then one of the /24 networks became inaccessible via the asteroid ISP, wouldn't withdrawing the /19 take all traffic off of the asteroid ISP? What if the outage was not an asteroid but something more common, like uncontrolled testing of the network while the stock market is in session? More specifically, what if there was reason to believe the affected ISP could still deliver service in the unaffected areas? I have examined the responses to my query thus far and it seems there are two options: 1) have both ISPs advertise both the /19 and /24s all the time 2) change nothing til the asteroid hits. call the unaffected ISP and have them send out the /24 for the affected site Option 1 creates larger route tables but automatically handles the asteroid situation. Option 2 respects the desire for smaller route tables but requires a manual process of phoning in a service request. In the meantime, the customers served by that connection may receive sub-optimal routing, ie, if the /19 is still advertised by the asteroid ISP, traffic reaches that AS and where does it go? Am I understanding this correctly? If so, this seems to be a case where being internet friendly conflicts with a theoretical entity's desire for uptime. Maybe I am missing something fundamental here though. Comments? Thanks much to those who responded! -----Original Message----- From: Brandon Ross [mailto:bross@netrail.net] Sent: Thursday, August 09, 2001 1:25 PM To: Greg Pendergrass Cc: 'Nanog@Merit. Edu' Subject: RE: Static routes in an AS vs BGP advertised routes On Wed, 8 Aug 2001, Greg Pendergrass wrote: > The problem is if they aggregate and advertise only a /19 instead of > individual /24s In this case you could: > > - Ask the pulverized ISP to withdraw the aggregate in favor of the specific > /24s > - Ask your second ISP to advertise your specific /24 in that city Better yet, advertise your own /19 aggregate, mark your /24's with communities that mean to your provider that they shouldn't be propagated outside of their network and their customers (if they can't do this, fire them) to be a good neighbor by not polluting the global routing table with unnecessary routes. Then when the asteroid hits, just pull down the /19 advertisement (or if you're lucky, they are so destroyed they won't get the announcement out to the world anymore anyway). -- Brandon Ross 404-522-5400 EVP Engineering, NetRail http://www.netrail.net AIM: BrandonNR ICQ: 2269442 Read RFC 2644!

2 1