Uhhhh.. So who gets to field the Akamai questions now? ;)
Sent from my Mobile Device. -------- Original message -------- From: "Patrick W. Gilmore" <[email protected]> Date: 11/16/2013 4:10 PM (GMT-09:00) To: NANOG list <[email protected]> Subject: Re: CDN node locations On Nov 16, 2013, at 19:36 , Jay Ashworth <[email protected]> wrote: >> Second, a list of CDN nodes is likely impossible to gather & maintain >> without the help of the CDNs themselves. There are literally thousands >> of them, most do not serve the entire Internet, and they change >> frequently. And before you ask, I know at least Akamai will _not_ give >> you their list, so don't even try to ask them. > > I find myself unsurprised. > > I was led to a very interesting failure case involving CDN's a couple weeks > ago, that I thought you might find amusing. > > I have a Samsung Galaxy S4, with Sprint. On a semi-regular basis, the > networking gets flaky around 1-2am ish local time, but 3 weekends ago, > the symptom I saw was DNS lookups failed -- and it wasn't clear to me > whether it was "just some lookups failed", or that Big Sites were cached > at the provider, and *all* outgoing 53 traffic to the greater internet > wasn't being forwarded by Sprint's customer resolvers. > > I know that it was their resolvers, though, as I grabbed a copy of Set DNS, > and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like that, > and everything worked ok. > > Except media. > > (Patrick is starting to nod and chuckle, now :-) > > Both YouTube and The Daily Show's apps worked ok, but refused to play > video clips for me. If I reset the DNS to normal, I went back to "not > all sites are reachable, but media plays fine". > > My diagnosis was that those sites were CDNed, and the DNS names to *which* > they were CDNs were only visible inside Sprint's event horizon, so when I > was on alternate DNS resolution, I couldn't get to them. > > But that took me over a day to figure out. Don't get old. :-) > > Patrick? Is that how (at least some) customers do it? #1: I could not possibly comment on customers. But since I've only worked at Markley Group for 3 weeks, I don't know all the customers, so I couldn't tell you even if they were customers at all, more or less how they do things. Besides, Markley Group ain't a CDN. #2: Assuming you are assuming I still work at Akamai (I don't), and are asking me if that's how Akamai does things, I couldn't possibly comment on customers at a previous position. Everything I've said up to now was either public knowledge or something I was more than happy to give out publicly if asked while I was at Akamai. The query above, specifically "is XXX how customer YYY does things", is neither of those. But in the more general sense, your hypothesis does not really fit the circumstances completely. DNS is orthogonal to serving bits. If Sprint's DNS is f00bar'ed, then you can't resolve anything, CDN-ififed or not. It is true some CDNs put some name servers inside other networks, but that is still a race condition, because (for instance) Akamai's DNS TTL is 20 seconds. You have to go back 'outside' eventually to get stuff, which means relying on Sprint's recursive NSes. Plus the two sites you list (YouTube & DailyShow) are not on the same infrastructure. Google hosts its own videos, DailyShow is not hosted on Google (AFAIK), therefore they must be two different companies using two different pieces of equipment and two different name server algorithms / topologies. It would be weird that Sprint's failure mode worked fine for those two and nothing else. Sorry. -- TTFN, patrick P.S. I wasn't chuckling. :)
