Re: Routing Issue?
On Jun 28, 2007, at 12:21 PM, Justin Scott wrote: Good afternoon, is there anyone on the list from Cox communications? Many of our customers that use Cox in Arizona (Phoenix and Tucson specifically, 68.15.190.16 is one of the sources) are having trouble reaching our network in Tampa, FL (64.156.29.150 is one address here). Oh my, operational content. Getting there fine from my Cox connection at home: saturn:~ brett$ traceroute 64.156.29.150 traceroute to 64.156.29.150 (64.156.29.150), 64 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 1.613 ms 4.405 ms 1.064 ms 2 10.118.160.1 (10.118.160.1) 9.586 ms 10.388 ms 9.223 ms 3 ip68-2-6-105.ph.ph.cox.net (68.2.6.105) 6.612 ms 9.043 ms 11.786 ms 4 68.2.12.90 (68.2.12.90) 14.047 ms 9.227 ms 8.446 ms 5 68.2.12.9 (68.2.12.9) 10.464 ms 10.181 ms 7.367 ms 6 68.2.12.5 (68.2.12.5) 10.777 ms 12.353 ms 11.128 ms 7 68.2.12.1 (68.2.12.1) 10.702 ms 8.516 ms 8.381 ms 8 chnddsrj02-ae1.0.rd.ph.cox.net (68.2.14.13) 8.427 ms chnddsrj01- ae1.0.rd.ph.cox.net (68.2.14.1) 11.738 ms chnddsrj02- ae1.0.rd.ph.cox.net (68.2.14.13) 16.041 ms 9 langbbr01-ae0.r2.la.cox.net (68.1.0.232) 25.915 ms 27.174 ms 30.961 ms 10 eqix.lsan.twtelecom.net (206.223.123.36) 29.998 ms 24.942 ms 33.905 ms 11 66.192.251.26 (66.192.251.26) 24.072 ms 42.779 ms 27.813 ms 12 dist-01-so-0-0-0-0.tamq.twtelecom.net (66.192.243.17) 69.665 ms 71.239 ms 77.077 ms 13 66.192.247.195 (66.192.247.195) 79.921 ms 110.116 ms 72.971 ms 14 66.193.50.238 (66.193.50.238) 77.826 ms 70.636 ms 67.940 ms 15 e1-3.co2.as30217.net (84.40.24.101) 69.092 ms 69.722 ms 71.671 ms 16 e49te.dr5.as30217.net (84.40.24.82) 73.954 ms 73.596 ms 74.129 ms 17 g7-0.sr1.as30217.net (84.40.24.54) 71.934 ms 72.736 ms 73.029 ms 18 64.156.25.74 (64.156.25.74) 73.085 ms 71.631 ms 77.315 ms 19 64.156.29.150 (64.156.29.150) 73.284 ms 75.421 ms 74.044 ms But the source you listed, I cannot get to and it should be across town from me: saturn:~ brett$ traceroute 68.15.190.16 traceroute to 68.15.190.16 (68.15.190.16), 64 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 1.520 ms 1.229 ms 1.113 ms 2 * * * 3 * * -brett
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
On Jun 28, 2007, at 11:44 AM, Steven M. Bellovin wrote: Whatever -- it exists as a reasonably stable design; starting over would cost us 15 more years that we just don't have.) Are you saying we (collectively) would take yet *another* 15 years to come up with another and/or better design? -brett
Re: Security gain from NAT
On Jun 4, 2007, at 9:51 PM, Donald Stahl wrote: A SI firewall ruleset equivalent to PAT is a single rule on a CheckPoint firewall (as an example): Src: Internal - Dst: Any - Action: Allow Done. Done indeed! Botnet operators *love* this policy. This type of policy is probably worse than any issue discussed in this thread so far. -b
Re: death of the net predicted by deloitte -- film at 11
On Feb 11, 2007, at 10:58 AM, Chris L. Morrow wrote: perhaps next time the news folks could ask someone who runs a network what the problems are that face network operators? they did ask one, you must have missed this from the article: "Verisign, the American firm which provides the backbone for much of the net, including domain names .com and .net,..." -b
Re: [da] news: Trend Micro launches anti-botnet service
On Sep 25, 2006, at 9:04 PM, Jeff Kell wrote: Well, a prefix hijack either means a router has been pwned, as I suggested, or a router is (as Governor Tarkin put it) "far too trusting" of its peers. And anyhow, I was speaking of BGP flaps in the context of botnets - has anybody seen an in-the-wild botnet that played BGP games? No, but playing some BGP games could certainly help to *mitigate* them. Turn the C&C list into a community. I've thrown the idea around several times but can't get any takers... been there, tried that: http://www.mainnerve.com/security/darknet.html -b
pre-nanog dns-operations workshop
If anyone is interested in attending a 1-day pre-nanog (June 2) workshop for dns-operations, details can be found at the URL below. http://public.oarci.net/dns-operations/workshop-2006 -b
Re: DNS deluge for x.p.ctrc.cc
On Feb 24, 2006, at 11:47 AM, Randy Bush wrote: this would be a fine thread to discuss on dns-operations, which a bunch of you here have already joined. http://lists.oarci.net/mailman/listinfo/ i joined but have never seen a message on that list. and this discussion seems useful. maybe we should not do a gadi? just a suggestion, but: http://lists.oarci.net/pipermail/dns-operations/2006-February/ 05.html there has been one topical post (ignore a handful of test messages). -b
Re: DNS deluge for x.p.ctrc.cc
On Feb 24, 2006, at 11:30 AM, Ejay Hire wrote: It may be coincidental, but TXT and ANY queries for this zone were the ones used in the multi-gigabit reflected dns DDOS against us earlier this month. this would be a fine thread to discuss on dns-operations, which a bunch of you here have already joined. list details here if not already subscribed: http://lists.oarci.net/mailman/listinfo/ -b
reminiscing (was re: level 3)
On Nov 11, 2005, at 2:50 PM, [EMAIL PROTECTED] wrote: we clustered the engineers into the IETF terminal room since we're reminiscing, we did this at dallas ietf in 1995, i think it was (yes, http://merit.edu/mail.archives/nanog/2000-11/ msg00222.html). we had hit a timer bug in is-is that was causing routers to lose adjacencies. ravi sat down at a terminal, found the bug in the code, compiled a new image, and we loaded and "rebooted the network" that evening. nasty, but fun. we don't seem to have fun like this anymore. (maybe it wasn't as simple as ravi "finding the bug", but i do seem to remember he fixed this in short order) -b
re: commonly blocked ports (but not on backbones)
seems to me this is the wrong question... a default security "posture" (network or system, isp or enterprise or any type of entity) should be: "if it's not explicitly allowed, it's denied." apologies, i see the original poster was talking about a *backbone*... my mind was on campus/edge/customer networks. this policy, of course, does not apply to backbones (unless you want an avalanche of customer calls). -b
Re: commonly blocked ISP ports
On Wednesday 14 September 2005 15:41, Luke Parrish wrote: Not quite looking for tips to manage my network and ACL's or if should or should not be blocking, more looking for actual ports that other ISP's are blocking and why. seems to me this is the wrong question... a default security "posture" (network or system, isp or enterprise or any type of entity) should be: "if it's not explicitly allowed, it's denied." don't look for specific ports to block. lock down everything, both *egress* (arguably as important as ingress, and typically completely ignored) and ingress, and start opening only specific ports that are absolutely necessary. yes, it's a lot more work to do this but it's a lot safer. many worm/trojan infections happen because egress is completely open, and "permit tcp any any established" is the first line in the ingress acl. -b
Re: LA power outage?
On Sep 12, 2005, at 1:32 PM, Jared Mauch wrote: there's also a blurb on yahoo news of an outage http://news.yahoo.com/s/ap/20050912/ap_on_re_us/la_power_outage AM radio news is reporting a "wrong cable cut" by the department of water and power folks... they're saying "no ties to terrorism"...-b
Re: More long AS-sets announced
On Jun 20, 2005, at 12:44 AM, Randy Bush wrote: June 15th: Lorenzo gives us 24 hours notice that he is going to be using our (a very general our here, meaning all Internet operators) network for performing his experiments on. (oh, and points out that hes been doing the same with IPv6 since last year, just unannounced, but thats okay because noone noticed) he is announcing his own bleedin' prefixes. get a life and you forgot to add: "welcome to the internet, the largest beta- test network in the world" -b
Re: Traceroute with ASN
On 3/15/05 3:11 AM, "Ziggy David Lubowa" <[EMAIL PROTECTED]> wrote: > > > On Tue, 15 Mar 2005 17:51:32 +0800 (CST), Joe Shen wrote >> Yes. Can I do this on a Linux box without having to >> install Zebra BGP on it? > > Doesnt look like you have to, below is the link to the tarball > > http://oppleman.com/dl/?file=lft-2.3.tar.gz I believe the author of LFT is working on a new release that does *not* use the oft-times incorrect radb data, but instead pulls from a router (not sure of the source) somewhere. -b
Re: Converged Networks Threat (Was: Level3 Outage)
>> 1) their backbones currently "work" - changing them >> into something which may or may not "work better" is a >> non-trivial operation, and risks the network. i would disagree. their backbone tend to reach scaling problems, hence the need for bleeding/leading edge technologies. that's been my experience in three past-large networks. > > This is perhaps current. Check back to see large deployments > GSR - sprint/UUNEt > GRF - uunet > Juniper - UUNET/CWUSA indeed, and going back even further is-is, 7000 and the original SSE - mci/sprint vip and netflow - genuity (the original)/probably many others -b
Re: AT&T carrying rfc1918 on the as7018 backbone?
> > Wasn't it established that they did infact not leak it but just routed it > inside their own network? Sorry, shouldn't have said "leaked".
Re: AT&T carrying rfc1918 on the as7018 backbone?
> RFC1918 addresses are unpredictable on any network other than your own. > You shouldn't make assumptions about them. Anyone may use them for any > purpose on their network. If you send packets into their network using > RFC1918 addresses, you get whatever you get. If you require certaintity > its up to you to impose your policy at your edge. > > Does sending packets to RFC1918 addresses on other networks meet the "be > conservative in what you send" credo? I understand all that. We're working with the customer to harden the border (ACLs) and possibly take a bogon feed, etc. I was just having a hard time believing AT&T was leaking 10/8 and that any other large provider was accepting it so wanted to verify. -b
Re: AT&T carrying rfc1918 on the as7018 backbone?
> > The router at route-server.ip.att.net shows about 25 10.0.0.0/8 > prefixes, most showing up over 4 weeks ago. Odd. I didn't see this when looking at at&t's looking glass via web browser. I was looking for some smaller prefixes though and didn't just look for 10/8 :-/ -b
AT&T carrying rfc1918 on the as7018 backbone?
First, yes I know I should call AT&T but I want to know if anyone else sees this problem: I have a customer that is multi-homed to AT&T and WCOM. They accept "default" via BGP from both providers and announce a handful of prefixes to both providers. Given that they receive default, it's just the same as if they had a *static* default to both providers. The customer installed a "network mapping tool" today and suddenly discovered they were seeing RFC1918 addresses in the map (hundreds of them) that were *not* part of the customer's internal network. It turns out that from what we can tell, insightbb.com (an AT&T sub or customer) is probably unintentionally leaking 10/8 and AT&T is propogating that across their network.Since the customer defaults for any "unknown" destination, they're crossing the AT&T network. If my customer had been taking full routing, with appropriate filters of course, they wouldn't be seeing this. But given that they are taking default, they see it. So I just wanted to see if anyone that is defaulting to AT&T is seeing this same problem just to verify that what we're seeing is correct (for my customer's edification). Yes, I'm calling AT&T now :) -b
Re: sniffer/promisc detector
>> i wish you were right. i wish you were even close to right. but we've > been >> attacked many times over the years by some extremely smart adolescent >> psychopaths -- where adolescence is a state of mind in this case, rather >> than of years -- and i wish very much that they would either stop being >> so smart, or stop being so psychotic, or stop being so adolescent. > > Hmm. > > It depends of, what is _attack_. For example, if I have old, unpatched sshd > daemon (which is easy to hack), but > run it at port 30022, how long do I need to expose it on Internet to be > hacked? (Answer - you will never be hacked, if > you use nonstandard port, except if you attracks someone by name, such as > _SSH-DAEMOn.Rich-Bank-Of-America.Com_. Uhm, that would be wrong. This is simply "security through obscurity". Go grab nessus (www.nessus.org), modify the code a bit, and I guarantee you that your ssh daemon running on a non-standard port can still be found, identified, and exploited. Trivial. -b
nanog@merit.edu
On Wednesday, Mar 19, 2003, at 12:28 America/Phoenix, Sean Donelan wrote: On Wed, 19 Mar 2003, German Martinez wrote: Anybody here seeing problems with AS7018 ? ... ... If you report it to AT&T, they seem to get it fixed; but then the problems re-appear a few days later. I'm guessing that packet size is relevant, but I haven't spent much time trying to troubleshoot it. isn't at&t heavily MPLSed? maybe something to do with mpls tunnels, or diff-serv marking?
RE: DWDM interconnects
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of David Diaz > Sent: Monday, January 06, 2003 5:24 PM > To: [EMAIL PROTECTED] > Subject: Re: DWDM interconnects > > Actually I forgot to mention. Since we have different frequencies > for the lasers, you and your peer would have to agree ahead of time > and stock that particular frequency or "color." IT's a major > stocking nightmare especially for spares. The real explosion may > occur as tunable lasers drop in price that can allow 8 or more > different frequencies. there are nifty boxes out (have been for 8 months or so) that do wavelength conversion. so the box-operator in the middle handles the wavelength map, and users on each end can all use the same lasers (colors). they were expensive at the time I looked but I would think prices would have come down. but yes, cheap tunables would be great. -b
performance testing/monitoring
hate to break up the peering thread but i'm wondering if anyone has experience/knowledge of Empirix tools? i worked with them back when they were known as midnight networks but they focused on protocol conformance testing at the time (mid-90s). they're "corporate history" has no mention of midnight though. they do seem to have some network simulation tools which i'm also interested in. heck, i think someone might have even asked about that in the last few days so maybe this is a relevant/appropriate topic. will take replies off-list if not. -b
re: GE over oc48
point of clarification: i mentioned luminous and "RPT". their marketing folks call it that, it is in fact RPR (resilient packet ring). -b
Re: Gig-E over OC48?
--On Saturday, June 22, 2002 5:02 PM -0400 Ralph Doncaster <[EMAIL PROTECTED]> wrote: > > What's the cheapest way to get Gig-E over OC48? > A couple used Cerent(Cisco) boxes would work, but the $15-$20K price tag > is too high. last i talked to Luminous (about 7-8 months ago) they were making pretty cheap RPT boxes. i suspect in the current market, they're cheaper still. that is, if you don't mind doing RPT (basically DPT if i remember correctly). -b
RE: remember the "diameter of the internet"?
--On Tuesday, June 18, 2002 3:17 PM -0700 Vadim Antonov <[EMAIL PROTECTED]> wrote: > > Demonstrably (proof by existence), those switches can be made reasonably > reliable. So can be routers. It's the fabled computer tech culture of "be > crappy, ship fast, pile features sky high, test after you ship" aka OFRV's > Micro$oft envy, which is the root evil. now *that* i agree with, and to be even more specific, it's not that any of us are against making profits... it's that many of these vendors, and service providers, have decided to make a profit at the expense of *everything* else (good service, happy customer, etc). i truly wonder how low the economy, and specifically this industry, is going to have to go before this paradigm is shifted. -b
Re: remember the "diameter of the internet"?
--On Tuesday, June 18, 2002 11:52 AM -0700 Vadim Antonov <[EMAIL PROTECTED]> wrote: > > Er... back then it took 2 months to learn everything a backbone engineer > had to know. Nowadays it's an alphabet soup of stupid techniques to > achieve the same result - i.e. to deliver a packet from place A to place > B. Blame gredy vendors (OFRV, particularly, and don't forget > hellcore) who sell FUD instead of making their products easy to use. > Given their dominant position on the market, everyone else has to be > "compatible" with the zillion little features just to stay afloat. that's an interesting point of view. i would say that really nothing at all has changed in 10 years. sure, there is a bag-of-stupid-ip-tricks to choose from that didn't exist back then but none of the tricks have solved our problems. the political/financial issues crept in, and the bag-of-stupid-ip-tricks seems to have developed as a way to solve those issues, which they have not solved. the same level of fundamental knowledge required back then applies today, and many network and systems engineers are *still* lacking that knowledge. i suppose your are right if you're implying that the bag-of-stupid-ip-tricks has obfuscated what's really important. uucp and modems are looking pretty attractive to me again. > Regarding the diameter of the Internet - I'm still trying to figure out > why the hell anyone would want to have "edge" routers (instead of dumb > TDMs) if not for inability of IOS to support large numbers of virtual > interfaces. Same story goes for "clusters" of backbone routers. everyone note: vadim threw that can of worms, it wasn't me! -b
Re: remember the "diameter of the internet"?
--On Tuesday, June 18, 2002 6:39 PM + "E.B. Dreger" <[EMAIL PROTECTED]> wrote: > That's what happened here. Rather than transitting the traffic > via a "last resort" across town/state, the higher local-pref of a > "local" peer won. > > Geography requirements for peers aren't inherently bad. There's > a point where things get extreme, but it would be nice to see > nationals peer in the south as well. If one has peering > requirements, at least set them to reach a positive goal... man, i threw the can-o-worms out for fun, i didn't expect anyone to actually *open* it. this all has nothing whatsoever to do with bgp. it has everything to do with politics and revenue. the bgp decision tree is being manipulated by human nature. now drop the can before someone yells at me for throwing it in the first place.
Re: ATTBI refuses to do reverse DNS?
--On Tuesday, June 18, 2002 11:30 AM -0700 Lou Katz <[EMAIL PROTECTED]> wrote: > > A client of mine just discovered that he could no longer do ftp > transfers to my machine. His IP address had changed to one in > 12.240.20 and there is no reverse DNS for that block. His > previous assignment was in a totally different block which did > have reverse DNS. Calls to ATTBI got the answer that they > are not obligated to provide reverse DNS and have no plans to > do so. My servers refuse connections when there is no reverse > lookup. > > Is this common? yes, i've had similar problems with cox both when i had cox@work business service, and now that i have cox@home residential service. this feeds right into the thread that branched off my post about "network diameter" in which people are talking about "clue factor". these networks spring up overnight, built by people who are missing some of the fundamental knowledge about how all this "stuff" works. and we're stuck with it as end users. -b
Re: remember the "diameter of the internet"?
--On Tuesday, June 18, 2002 1:33 PM -0400 Pawlukiewicz Jane <[EMAIL PROTECTED]> wrote: > Hi Brett, > > Are you asking _why_ there are so many hops between yourself and the guy > across town? no, just lamenting the passing of an era. an era where we engineers cooperated, and "just fixed" the problems as they occured. and we didn't do things like this. turn on the sarcasm tone, and re-read my post. this could win the prize on Latenight with David Letterman, Stupid IP Routing Tricks. -b
Re: Diagnostic Tools
> - Original Message - > From: "Pawlukiewicz Jane" <[EMAIL PROTECTED]> > To: "Marc Pierrat" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, June 06, 2002 10:02 AM > Subject: Re: Diagnostic Tools > > >> No. But I was thinking of something more robust. And I think it depends >> on what level you want your diagnostics to go to. Then there's metrics, >> analysis, detection processes. >> >> Ping and traceroute give me a ton of data. I was thinking of something >> that takes that data and turns it into the bottom line. Where is the >> problem, when did it start, all the good stuff. >> >> I still can't believe someone hasn't cashed in on this. Or is it >> something you wouldn't need or use? the bottom line is, when you're on the outside looking in, there's only so much you're going to be able to see or analyze on someone else's network. everyone needs tools like this, and would use them. trouble is, it's a hard problem to solve and design tools for. many groups have formed to discuss "standard metrics" with respect to IP backbones. i'm not sure there's ever been much concensus from them. see www.caida.org. just poke around, lots of data on the order of what i think you're looking for. however, they usually anonymize (is that a word?) the data to be politically correct and protect themselves legally. some folks at caimis.com (acquired by ixia) were doing some really interesting development of tools for routing performance metrics. www.ixiacom.com. if you want to participate in standards for this kind of thing, go peruse www.ietf.org and look for the performance metrics working groups and netops groups. -b
FWD: FC: Verisign reportedly sending deceptive domain registrationbills (fwd)
in case anyone has experienced this and wants to complain... -- Forwarded Message -- Date: Monday, March 25, 2002 12:57 AM -0500 From: Declan McCullagh <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: FC: Verisign reportedly sending deceptive domain registration bills > > --- > > Date: Fri, 22 Mar 2002 19:26:15 -0500 > To: [EMAIL PROTECTED] > From: Peter Wayner <[EMAIL PROTECTED]> > Subject: Fwd: A WARNING TO OUR CUSTOMERS > > [Another scandal mixing spam, the DNS tables and ICANN.--Peter] > > >> Date: 23 Mar 2002 00:07:10 - >> To: [EMAIL PROTECTED] >> From: [EMAIL PROTECTED] >> Subject: A WARNING TO OUR CUSTOMERS >> >> Please be aware that Verisign, Inc. (formerly Network Solutions) is >> sending via the US Mail, what we believe to be deceptive and predatory >> domain expiration notices. >> The purpose behind these notices is to get the unsuspecting customer to >> transfer to and renew their domain name(s) with Verisign Inc. at >> significantly higher prices. >> >> The domain expiration notices are designed so that it is not obvious >> that the notices are from Verisign, Inc. as opposed to Go Daddy >> Software. To see a copy of one of these deceptive expiration notices, >> please go to the following URL: >> http://www.godaddy.com/gdshop/private_vsrn.asp?display=letter. >> >> Those customers who fall prey to the Verisign, Inc. scheme will have >> their domain name(s) renewed at a price more than 3 times higher than >> would be the case if they renewed with Go Daddy Software. >> >> For a .com, .net or .org domain name renewal, the victimized customer >> would pay $29.00 to Verisign, Inc. instead of the $8.95 charged by Go >> Daddy Software. >> Those customers who fall prey to this scheme, will not receive any >> better service or value. They will however be tricked out of $20.05 >> per domain name. >> >> Renewal notices from Go Daddy Software are sent via email, and always >> mention the Go Daddy name. You can be sure that any communications you >> receive concerning your domain name that do not explicitly and obviously >> display the Go Daddy name are not from Go Daddy Software. >> >> If you believe, as we do, that this practice of Verisign Inc. is >> misleading, predatory and improper, we invite you to make your feelings >> known by writing to ICANN (who is the governing body for all Registrarís >> and Registries) and to Verisign Registry. Email links for both are >> provided below. >> >> Sincerely, >> >> Bob Parsons, President >> Go Daddy Software, Inc. >> >> ICANN Registrar Complaint Form (hosted at InterNIC) >> http://www.internic.net/cgi/registrars/problem-report.cgi >> >> VeriSign Registry Customer Service >> [EMAIL PROTECTED] >> Phone: 703-948-3200 > > > > > - > POLITECH -- Declan McCullagh's politics and technology mailing list > You may redistribute this message freely if you include this notice. > Declan McCullagh's photographs are at http://www.mccullagh.org/ > To subscribe to Politech: http://www.politechbot.com/info/subscribe.html > This message is archived at http://www.politechbot.com/ > - > Politech dinner in SF on 4/16: http://www.politechbot.com/events/cfp2002/ > - > -- End Forwarded Message -- --- Begin Message --- --- Date: Fri, 22 Mar 2002 19:26:15 -0500 To: [EMAIL PROTECTED] From: Peter Wayner <[EMAIL PROTECTED]> Subject: Fwd: A WARNING TO OUR CUSTOMERS [Another scandal mixing spam, the DNS tables and ICANN.--Peter] >Date: 23 Mar 2002 00:07:10 - >To: [EMAIL PROTECTED] >From: [EMAIL PROTECTED] >Subject: A WARNING TO OUR CUSTOMERS > >Please be aware that Verisign, Inc. (formerly Network Solutions) is >sending via the US Mail, what we believe to be deceptive and predatory >domain expiration notices. >The purpose behind these notices is to get the unsuspecting customer to >transfer to and renew their domain name(s) with Verisign Inc. at >significantly higher prices. > >The domain expiration notices are designed so that it is not obvious that >the notices are from Verisign, Inc. as opposed to Go Daddy Software. To >see a copy of one of these deceptive expiration notices, please go to the >following URL: http://www.godaddy.com/gdshop/private_vsrn.asp?display=letter. > >Those customers who fall prey to the Verisign, Inc. scheme will have their >domain name(s) renewed at a price more than 3 times higher than would be >the case if they renewed with Go Daddy Software. > >For a .com, .net or .org domain name renewal, the victimized customer >would pay $29.00 to Verisign, Inc. instead of the $8.95 charged by Go >Daddy Software. >Those customers who fall prey to this scheme, will not receive any better >service or value. They will however be tricked out of $20.05 per domain name. > >Renewal notices from Go Dad
