- NANOG - lists.nanog.org

A quick examination of the VeriSign disaster
by Jason Garman 16 Sep '03

16 Sep '03

Okay, it's late and I've only spent about an hour on this, but I've whipped up a quick piece examining this whole mess from VeriSign. I've only *brushed* the surface of the issues that this presents and it's already a pretty long piece already. Questions, comments to me. Send your concerns to VeriSign :-) http://www.haque.net/verisign_dns_rant.php You are free to quote this as you see fit, just please don't copy it verbatim without attribution. enjoy -- Jason Garman / jgarman(a)wedgie.org

1 0

Re: Change to .com/.net behavior
by dani-nanog＠roisman.com 16 Sep '03

16 Sep '03

A couple things come to mind -- 1) Does this increase the RAM needed on a caching resolver? I.e. does it take more RAM to cache the 15-minute positive reply, than an NXDOMAIN negative reply? 2) In the "bestpractices.pdf" file, it states the following: "A response server should be configured to return an indication that the provided services were reached as a result of wildcard processing when the server returns a response to connection requests sent by end user applications." Can Verisign explain how the following transaction is consistent with the above guideline (where is the indication of wildcard processing): $ telnet mx.no-suchdomain-yadda-yadda.com 25 Trying 64.94.110.11... Connected to mx.no-suchdomain-yadda-yadda.com. Escape character is '^]'. 220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready helo example.com 250 OK mail from: nobody(a)example.com 250 OK rcpt to: nobody(a)example.com 550 User domain does not exist. Oh well -- here's to looking out for the BIND patch... - Dani

1 0

Re: Change to .com/.net behavior
by Dr. Jeffrey Race 16 Sep '03

16 Sep '03

On Mon, 15 Sep 2003 19:24:29 -0400, Matt Larson wrote: >10:45AM EDT to 13:30PM EDT. The wildcard record in the .com zone is >being added now. We have prepared a white paper describing VeriSign's >wildcard implementation, which is available here: > >http://www.verisign.com/resources/gd/sitefinder/implementation.pdf The file is mutilated by the ColorSpace Error which will cause difficulties for persons on some platforms in reading it. You may wish to recreate it without this error. See <http://www.camblab.com/nugget/colorspc.htm>. Thanks for making this file available. Jeffrey Race

1 0

Re: Change to .com/.net behavior
by George William Herbert 16 Sep '03

16 Sep '03

Did it occur to Verisign that perhaps this needed some external policy and technical review before you just went ahead and did this? Have you formally or informally asked ICANN, the US DOC, etc. for policy approval? If so, where and when? Did you consider that nonexistent domains returning an error was a feature in use by a wide number of security authentication mechanisms in email and other applications? Did you consider that major network operators might want to know about things like this beforehand? Have you notified any major network operators prior to this email to NANOG? Were the root servers apprised of this prior to it being implimented? [Paul et al, any comments on this one?] It is nice that Verisign at least documented what you are doing and why, however, the documentation is not ipso facto reasonable procedure and community approval. WiFrom what I can see here and today, you don't have community approval and don't appear to have followed anything vaguely like reasonable procedure in getting here. .com and .net are not your private playthings, and to be frank Verisign's position in control of the zones is dependent on it not being the sort of company to pull stunts of this nature without appropriate warning and discussion. -george william herbert gherbert(a)retro.com

2 1

RE: What *are* they smoking?
by Johnny Eriksson 16 Sep '03

16 Sep '03

"Jeroen Massar" <jeroen(a)unfix.org> wrote: > Any kiddie group already planning to "take down" the advert server ? > It's just 1 IP to take out a *lot* of domains, anything you can mistype ;) > "Look mommy we took down <think up something>.net, now you see it now you..." idea for next virus: after reproducing itself, construct a random domain name ending in .net and ddos it at a low rate for a day or so. if the faked up domain is someones real one, you get a small number of packets to that domain. if a large number of domains resolve to the same ip, well, too bad for that ip... that might even be a virus a lot of people want to run. --Johnny

2 1

Re: Change to .com/.net behavior
by Simon Lyall 16 Sep '03

16 Sep '03

On Tue, 16 Sep 2003, Michael Tokarev wrote: > Haesu wrote: > > Before I figure out this BIND thing, for now.. > > > > box02jp5-cr01.twdx.net# set routing-options static route 64.94.110.11/32 di$ > > Please do no do that. You, or your users, will end up having > TONS of undeliverable bounces for forged/bogus domains sitting > in mail spools... On the other hand, what happens to those people who have one of their MX records pointing to host at an invalid domain. eg IN MX 5 mail.example.com. IN MX 10 mail.iforgottodelete.net Now the previously non-existent host will resolve and bounce your email instead of being skipped. -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

RE: list thoughts on "unsupported" hardware?
by Austad, Jay 15 Sep '03

15 Sep '03

I couldn't find anything that said the 7500 is end-of-life/support/etc... This is all I found on their site regarding the 7500: End-of-Sale/End-of-Life: FEIP2-DSW-2TX & FEIP2-DSW-2FX 09/Jul/2003 End of Sale/End of Life: SA-ENCRYPT Services Adapter 31/Mar/2003 End of Sales - VIP2-50, No. 1868 20/Aug/2002 End of Sales: Route Switch Processor 2, No. 1866 20/Aug/2002 End of Sales: SRPIP-OC12, No. 1867 20/Aug/2002 I know it doesn't answer your question, but it appears that the 7500 is still on the list. -jay > -----Original Message----- > From: Ray Wong [mailto:rayw@rayw.net] > Sent: Monday, September 15, 2003 2:07 PM > To: nanog(a)merit.edu > Subject: list thoughts on "unsupported" hardware? > > > > > > I realize this isn't arguing about Windows patch mechanisms, > but recently > realized I've never answered this issue to my own > satisfaction... How long > do we keep upgrading and using network hardware once it's > fallen off the > support lists? The Cisco 7500 finally went off back in Feb > of this year, > as I recall. 3rd party upgrades, and used parts, are still > readily available. > > (Actually, does anyone have suggestions on vendors for said > upgrades and > parts? I've noticed a lot more discounting than in the past, > but usually > from vendors I have no experience with). > > A client I've recently taken on happens to be relying on a > 7500 for their > border. In reality, their current use could fit on a > 2621/2650, though they > have been much larger in the past (there's a small pile of > DS3 cards sitting > on the shelf). They're still relying on a single provider > for connectivity, > etc. > > So, does anyone have any thoughts on how long we should be letting our > poorer customers/employers live with products that are > officially off the > support lists? Clearly there will be (i.e. IOS) image > support for quite some > time. Is keeping (tested) spares around sufficient to > justify actually > spending some money to fit the newer/larger images? > Newer/still current > hardware seems much more a no-brainer, but advocating > spending a thousand > bucks to avoid spending 5x that on a more current fire-sale > item is a little > less clear, to me. > > > -- > > Ray Wong > rayw(a)rayw.net > >

3 2

Internetwork smarTest
by Dean Bogdanovic 15 Sep '03

15 Sep '03

Hi I am looking if somebody has some experience with Internetwork smarTest. Any feedback (preferably off list) would be greatly appreciated. Dean

1 0

RE: Cisco IOS Failure due to Virus
by Mark Segal 15 Sep '03

15 Sep '03

Got love nanog.. A nice man from cisco called me, it looked like a lot of packets on my router were being process switched (sh ip cache - displayed A LOT of entries). Anyway, it turns our some of my atm sub-ints inherited a "no ip route-cache cef" from a parent int and well you can see what happens when the packet volume increase. Richard I would check that.. So now to life the rate-limit and see what happens.. Regards, Mark -- Mark Segal Director, Network Planning FCI Broadband Tel: 905-284-4070 Fax: 416-987-4701 http://www.fcibroadband.com Futureway Communications Inc. is now FCI Broadband -----Original Message----- From: Mark Segal [mailto:MSegal@Corporate.FCIBroadband.com] Sent: September 15, 2003 1:50 PM To: 'Richard J.Sears'; 'Robert Blayzor' Cc: 'Nanog'; Mihai Iancu Subject: RE: Cisco IOS Failure due to Virus We are seeing the same problem on all of the 6400-nrp aggregation boxes we have in the network. Here is the IOS bug ID - CSCec12495.. Actually by rate limiting icmp on our network the problems have stopped/slowed down a lot. Sorry for the delay.. Was out of the country for a while.. Mark -- Mark Segal Director, Network Planning FCI Broadband Tel: 905-284-4070 Fax: 416-987-4701 http://www.fcibroadband.com Futureway Communications Inc. is now FCI Broadband -----Original Message----- From: Richard J.Sears [mailto:rsears@adnc.com] Sent: September 11, 2003 12:26 AM To: Robert Blayzor Cc: Nanog Subject: Re: Cisco IOS Failure due to Virus Hi Robert, Thanks for the info. We are running dCEF...routers show about 4% CPU load and the following memory: BR02#sh mem Head Total(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 613AE340 247798976 106515996 141282980 140653360 134546752 Fast 6138E340 131080 37240 93840 93840 93788 Also, we are not blocking 92 byte ICMP due to the traceroute problems on customers networks... Thanks On Wed, 10 Sep 2003 23:17:01 -0400 Robert Blayzor <rblayzor(a)inoc.net> wrote: > > On 9/10/03 10:58 PM, "Richard J.Sears" <rsears(a)adnc.com> wrote: > > > %SYS-2-MALLOCFAIL: Memory allocation of 704 bytes failed from > > 0x60329F00, alignment 0 > > Pool: Processor Free: 92744 Cause: Memory fragmentation Alternate > > Pool: None Free: 0 Cause: No Alternate pool -Process= "Pool > > Manager", ipl= 0, pid= 6 -Traceback= 6038049C 60382200 60329F08 > > 6038DEDC > > > > %TCP-6-NOBUFF: TTY0, no buffer available > > -Process= "BGP Router", ipl= 0, pid= 132 > > > > %% Low on memory; try again later > > Did you enable CEF? > Are you dropping 92 byte ICMP packets where needed? > > -- > Robert Blayzor, BOFH > INOC, LLC > rblayzor(a)inoc.net > PGP: http://www.inoc.net/~dev/ > Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 > > "I don't need parents. All I need is a recording that says, 'Go play > outside!" - Calvin and Hobbes > ****************************************** Richard J. Sears Vice President American Digital Network ---------------------------------------------------- rsears(a)adnc.com http://www.adnc.com ---------------------------------------------------- 858.576.4272 - Phone 858.427.2401 - Fax ---------------------------------------------------- I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."

1 0

list thoughts on "unsupported" hardware?
by Ray Wong 15 Sep '03

15 Sep '03

I realize this isn't arguing about Windows patch mechanisms, but recently realized I've never answered this issue to my own satisfaction... How long do we keep upgrading and using network hardware once it's fallen off the support lists? The Cisco 7500 finally went off back in Feb of this year, as I recall. 3rd party upgrades, and used parts, are still readily available. (Actually, does anyone have suggestions on vendors for said upgrades and parts? I've noticed a lot more discounting than in the past, but usually from vendors I have no experience with). A client I've recently taken on happens to be relying on a 7500 for their border. In reality, their current use could fit on a 2621/2650, though they have been much larger in the past (there's a small pile of DS3 cards sitting on the shelf). They're still relying on a single provider for connectivity, etc. So, does anyone have any thoughts on how long we should be letting our poorer customers/employers live with products that are officially off the support lists? Clearly there will be (i.e. IOS) image support for quite some time. Is keeping (tested) spares around sufficient to justify actually spending some money to fit the newer/larger images? Newer/still current hardware seems much more a no-brainer, but advocating spending a thousand bucks to avoid spending 5x that on a more current fire-sale item is a little less clear, to me. -- Ray Wong rayw(a)rayw.net

1 0