Re: AT&T Wireless outage in SoCal
On Saturday 24 September 2011 22:24, Adrian wrote: > On Saturday 24 September 2011 21:27, Chris Woodfield wrote: > > Hearing rumblings of a major AT&T Wireless outage in southern California. > > Anyone have more detail? Limited to cell towers or are transit circuits > > affected? > > Apparently their switching and core infrastructure (affecting both voice > and data) across the LA basin. ***I should clarify, apparently it is only affecting the ATT cell service. Transit/landline service is apparently unaffected. Adrian
Re: AT&T Wireless outage in SoCal
On Saturday 24 September 2011 21:27, Chris Woodfield wrote: > Hearing rumblings of a major AT&T Wireless outage in southern California. > Anyone have more detail? Limited to cell towers or are transit circuits > affected? > Apparently their switching and core infrastructure (affecting both voice and data) across the LA basin. Been ongoing since about 5pm PDT. One of the latest words from their corporate people: "Company officials told KCBS and KCAL-TV that about 1,000 cell phone towers were out of service and the problems were not expected to be fixed until 2:30 a.m. Sunday." Adrian
AT&T Wireless outage in SoCal
Hearing rumblings of a major AT&T Wireless outage in southern California. Anyone have more detail? Limited to cell towers or are transit circuits affected? -Chris
Re: Nxdomain redirect revenue
On Sat, Sep 24, 2011 at 8:33 PM, Cameron Byrne wrote: > Just an fyi for anyone who has a marketing person dreaming up a big nxdomain > redirect business cases, the stats are actually very very poor... it does > not make much money at all. > It is very important to ask the redirect partners about yields... meaning, > you may find that less than 5% of nxdomain redirects can be actually served Not to take any position on there being a "business case" for NXDOMAIN redirect, or not butthe percentage of NXdomain redirects that actually serve ads isn't too important. It's absolute numbers that matter, even if it's just 1% of NXDOMAINS by percent. The rest of the 99% are referred to as "noise" and aren't relevant for justifying or failing to justify. The important number is at what frequency the _average_ user will encounter the redirect while they are surfing.If a sufficient proportion of their users see the ads at a sufficient rate, then they will probably justify whatever cost they have for the ad serving. When they are doing this crappy stuff like redirecting google.com DNS to intercept search requests; I have little doubt that they are able to inject sufficient volume of ads to make some sort of "business case" behind thehijacking evilness. Regards, -- -JH
Re: Nxdomain redirect revenue
On Sat, Sep 24, 2011 at 9:33 PM, Cameron Byrne wrote: > Just an fyi for anyone who has a marketing person dreaming up a big nxdomain > redirect business cases, the stats are actually very very poor... it does > not make much money at all. > > It is very important to ask the redirect partners about yields... meaning, > you may find that less than 5% of nxdomain redirects can be actually served > an ad page because 95%+ of nxd are printer lookups and such that cannot be > served an ad page. Then from that less than 5% pool, the click through > rates are around 1% > > Net net, no free money of any meaningful value. But, ymmv... but I don't > think by much. > that's some interesting data points, thanks! > Cb >
Re: Earthlink Contact - DNS cache poisoning
On Sat, Sep 24, 2011 at 9:21 PM, Will Dean wrote: > > On Sep 24, 2011, at 9:07 PM, Christopher Morrow wrote: > >> On Sat, Sep 24, 2011 at 8:51 PM, Jimmy Hess wrote: >> I think actually.. earthlink uses barefruit? (or they did when ... >> kaminsky was off doing his destruction of the dns liars gangs...) >> Maybe the same backend is used though for the advertizer side? >> (barefruit provides the appliance, some third-party is the >> advertiser/website-host... same for paxfire?) >> > > Barefruit was just for returning a search engine result for a NXDOMAIN > response. ah, paxfire does the same... > > It appears Earthlink is now using Paxfire to sniff and proxy a users traffic > to at least one popular website. Besides the obvious privacy implications, it > introduces a nice captcha on Google. hrm, they could simply use the appliances to answer: "www.google.com -> jomax.net-ns-answer" which is a frontend simply 30[24]'ing off to the jomax-esque site... Oh, you get the captcha though via earthlink? that sucks :( -chris
Nxdomain redirect revenue
Just an fyi for anyone who has a marketing person dreaming up a big nxdomain redirect business cases, the stats are actually very very poor... it does not make much money at all. It is very important to ask the redirect partners about yields... meaning, you may find that less than 5% of nxdomain redirects can be actually served an ad page because 95%+ of nxd are printer lookups and such that cannot be served an ad page. Then from that less than 5% pool, the click through rates are around 1% Net net, no free money of any meaningful value. But, ymmv... but I don't think by much. Cb
Re: Earthlink Contact - DNS cache poisoning
On Sep 24, 2011, at 9:07 PM, Christopher Morrow wrote: > On Sat, Sep 24, 2011 at 8:51 PM, Jimmy Hess wrote: > I think actually.. earthlink uses barefruit? (or they did when ... > kaminsky was off doing his destruction of the dns liars gangs...) > Maybe the same backend is used though for the advertizer side? > (barefruit provides the appliance, some third-party is the > advertiser/website-host... same for paxfire?) > Barefruit was just for returning a search engine result for a NXDOMAIN response. It appears Earthlink is now using Paxfire to sniff and proxy a users traffic to at least one popular website. Besides the obvious privacy implications, it introduces a nice captcha on Google. - Will
Re: Earthlink Contact - DNS cache poisoning
On Sat, Sep 24, 2011 at 8:51 PM, Jimmy Hess wrote: > On Sat, Sep 24, 2011 at 7:43 PM, Will Dean wrote: > > The "JOMAX.NET" response is indicative that there's a Paxfire box > in the mix, > intercepting the DNS query (probably installed by the ISP). > I think actually.. earthlink uses barefruit? (or they did when ... kaminsky was off doing his destruction of the dns liars gangs...) Maybe the same backend is used though for the advertizer side? (barefruit provides the appliance, some third-party is the advertiser/website-host... same for paxfire?) > >> Anyone out there in Earthlink land? I am seeing what looks to be a cache >> poisoning attack on ns1.mindspring.com. > >> ;; AUTHORITY SECTION: >> www.google.com. 65535 IN NS WSC2.JOMAX.NET. >> www.google.com. 65535 IN NS WSC1.JOMAX.NET. > > > -- > -JH > >
Re: Earthlink Contact - DNS cache poisoning
On Sat, Sep 24, 2011 at 7:43 PM, Will Dean wrote: The "JOMAX.NET" response is indicative that there's a Paxfire box in the mix, intercepting the DNS query (probably installed by the ISP). > Anyone out there in Earthlink land? I am seeing what looks to be a cache > poisoning attack on ns1.mindspring.com. > ;; AUTHORITY SECTION: > www.google.com. 65535 IN NS WSC2.JOMAX.NET. > www.google.com. 65535 IN NS WSC1.JOMAX.NET. -- -JH
Earthlink Contact - DNS cache poisoning
Anyone out there in Earthlink land? I am seeing what looks to be a cache poisoning attack on ns1.mindspring.com. Sporadic of course so it takes a few queries to replicate. will$ dig www.google.com @207.69.188.185 ; <<>> DiG 9.7.3 <<>> www.google.com @207.69.188.185 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26196 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com.IN A ;; ANSWER SECTION: www.google.com. 60 IN A 64.27.117.179 www.google.com. 60 IN A 69.25.212.24 ;; AUTHORITY SECTION: www.google.com. 65535 IN NS WSC2.JOMAX.NET. www.google.com. 65535 IN NS WSC1.JOMAX.NET. ;; Query time: 88 msec ;; SERVER: 207.69.188.185#53(207.69.188.185) ;; WHEN: Sat Sep 24 20:25:40 2011 ;; MSG SIZE rcvd: 120 - Will
Re: Strange static route
On Fri, Sep 23, 2011 at 8:57 PM, jim deleskie wrote: > Wouldn't it make more sense to filter in bound default? or use a single > static default if you where worried about that? Yes, the aesthetics of using a "/1 route" for that purpose are very poor. Don't implement design objectives using subtle side-effects, when a proper tool is available -- human errors later are likely. Using a /1 static to achieve a "longer prefix" to override a default falls in that category, whenrouters have a filtering mechanism capable of explicitly expressing the desired policy :) > -jim -- -JH
