Hi,
I was wondering if anyone knows where I could find a compiled list of Content Delivery Networks as well
as thier DC nodes? if any..
Please respond offlist.
Cheers,
Carlos
List of CDNs would be difficult, but not impossible. Although they do different things, so a simple list is unlikely to be as useful as it looks.
A lost of CDN "DC nodes" is not possible. Why do you care about such a thing anyway?
Actually, a list of CDNs would be very handy. I harvest botnets and
fast flux hosts out of passive dns, and some of the heuristics used to
identify them are similar to what CDNs look like.
Having a decent list of CDN effective top level domains alone would be
useful for redacting those hosts.
Andy
Andrew Fried
andrew.fried@gmail.com
The goal is to find a solution to optimize the path for DNS queries that traverse via CDNs within certain regions
without the luxury of a network layer.
For instance, some clients in singapore are getting answers from the UK instead of something more local.
Knowing where the CDNs are may allow us to direct them to a more optimal path.
Cheers,
Carlos.
This guy has been maintaining a list for a few years:
although he doesn't seem to have done an update in about 12 months 
How about:
http://www.cdnplanet.com/cdns/
Seriouslyy, these are 2 of the first 3 ghits for "CDN list"....
I'll second that; CDNs are a constant pain for me when I'm doing address
lookups. A list of them would make life a lot easier for a bunch of
different investigative processes.
If there isn't one right now, I think I could get off my tuchas and
start maintaining one if anyone's interested in pitching in.
Depends on the CDN. Using Akamai as an example (since they are essentially as big as all other CDNs combined, and 'cause I know them best), the location of an Akamai web server is not useful since everything is based on name servers. Also, the location of Akamai's name server and the topological path used to reach it is irrelevant to the web server returned. So getting a list of nodes and somehow modifying your network based on that will likely have minimal to zero impact.
Other CDNs use different methods of mapping end users to web servers. Some use anycast, either at the DNS level or even at the HTTP level. In those cases, this information may be of use.
If you have a problem with Akamai mapping, you can always email NetSupport-tix@akamai.com and ask them for help. My guess is other CDNs have something similar. Probably much more useful to go directly to the CDN with the problem than look at a 3rd party list of nodes and try to fix issues yourself with methods that may have no effect.
Or not. 
Your network, your decision, I'm just making suggestions.
First, the location of CDN nodes is not relevant to passive DNS monitoring. If Andrew would like a list of domains with CDN hostnames in them, that might be findable.
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.
Sorry this makes your life more difficult. Perhaps if you explained why you were doing address lookups, the collective body could help you come up with a better solution?
Patrick,
It's Yet Another False Positive in anomaly detection and traffic analysis software that I fiddle with. In the case of CDNs, I mostly want to throw them out the window -- whenever I see one, I know that the reverse lookup information is going to be useless and it's time to toss that address out of the bucket and look at the next weird one on the list.
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?
Cheers,
-- jra
Not sure why in-addr on CDN would be any different than .. well, anything.
Perhaps I do not understand your use case well enough?
#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.
It seems more likely the Sprint resolvers you were using were having
difficulty reaching external authoratative servers but the devices they
proxy all the media content through wasn't... All major media content
these days is CDN'd but I don't think that had anything to do with it.
Phil
Maybe, but I don't use their proxies, I've overriden them for speed.
http://www.sprint.com/legal/open_internet_information.html
Maybe "proxy" was the wrong word, and "transparent video optimization" are
better words. I'm not speaking with any internal knowledge of Sprint
Wireless's network but I wouldn't be surprised if you had no choice in the
matter.
Phil
Uhhhh.. So who gets to field the Akamai questions now? 
There are a number of us here.
Best,
-M<