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? -- TTFN, patrick Composed on a virtual keyboard, please forgive typos.
On Nov 14, 2013, at 22:02, Carlos Kamtha <kamtha@ak-labs.net> wrote:
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
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 On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
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?
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. On 11/14/13 5:19 PM, Andrew Fried wrote:
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
On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
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?
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? -- TTFN, patrick On Nov 15, 2013, at 10:06 , Michael Collins, Aleae <mcollins@aleae.com> wrote:
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.
On 11/14/13 5:19 PM, Andrew Fried wrote:
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
On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
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?
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. On Nov 16, 2013, at 5:28 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
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?
-- TTFN, patrick
On Nov 15, 2013, at 10:06 , Michael Collins, Aleae <mcollins@aleae.com> wrote:
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.
On 11/14/13 5:19 PM, Andrew Fried wrote:
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
On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
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?
On Nov 16, 2013, at 19:30 , Michael Collins <mcollins@aleae.com> wrote:
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.
Not sure why in-addr on CDN would be any different than .. well, anything. Perhaps I do not understand your use case well enough? -- TTFN, patrick
On Nov 16, 2013, at 5:28 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
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?
-- TTFN, patrick
On Nov 15, 2013, at 10:06 , Michael Collins, Aleae <mcollins@aleae.com> wrote:
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.
On 11/14/13 5:19 PM, Andrew Fried wrote:
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
On 11/14/13, 5:11 PM, Patrick W. Gilmore wrote:
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?
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 -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Nov 16, 2013, at 19:36 , Jay Ashworth <jra@baylink.com> 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. :)
Uhhhh.. So who gets to field the Akamai questions now? ;) Sent from my Mobile Device. -------- Original message -------- From: "Patrick W. Gilmore" <patrick@ianai.net> Date: 11/16/2013 4:10 PM (GMT-09:00) To: NANOG list <nanog@nanog.org> Subject: Re: CDN node locations On Nov 16, 2013, at 19:36 , Jay Ashworth <jra@baylink.com> 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. :)
There are a number of us here. Best, -M< On Sun, Nov 17, 2013 at 3:21 AM, Warren Bailey < wbailey@satelliteintelligencegroup.com> wrote:
Uhhhh.. So who gets to field the Akamai questions now? ;)
Sent from my Mobile Device.
-------- Original message -------- From: "Patrick W. Gilmore" <patrick@ianai.net> Date: 11/16/2013 4:10 PM (GMT-09:00) To: NANOG list <nanog@nanog.org> Subject: Re: CDN node locations
On Nov 16, 2013, at 19:36 , Jay Ashworth <jra@baylink.com> 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. :)
On 11/16/13, 7:36 PM, "Jay Ashworth" <jra@baylink.com> 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?
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. Phil Bedard <bedard.phil@gmail.com> wrote:
On 11/16/13, 7:36 PM, "Jay Ashworth" <jra@baylink.com> 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?
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
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
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 From: Jay Ashworth <jra@baylink.com> Date: Saturday, November 16, 2013 at 8:56 PM To: Phil Bedard <bedard.phil@gmail.com>, NANOG <nanog@nanog.org> Subject: Re: CDN node locations Maybe, but I don't use their proxies, I've overriden them for speed. Phil Bedard <bedard.phil@gmail.com> wrote:
On 11/16/13, 7:36 PM, "Jay Ashworth" <jra@baylink.com> 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 <http://8.8.8.8> , and 4.2.2.1 <http://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 wer e 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?
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
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
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. On Thu, Nov 14, 2013 at 10:11:59PM +0000, Patrick W. Gilmore wrote:
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?
-- TTFN, patrick
Composed on a virtual keyboard, please forgive typos.
On Nov 14, 2013, at 22:02, Carlos Kamtha <kamtha@ak-labs.net> wrote:
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
This guy has been maintaining a list for a few years: http://www.cdnlist.com 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".... -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Nov 14, 2013, at 17:25 , Carlos Kamtha <kamtha@ak-labs.net> wrote:
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.
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. -- TTFN, patrick
On Thu, Nov 14, 2013 at 10:11:59PM +0000, Patrick W. Gilmore wrote:
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?
-- TTFN, patrick
Composed on a virtual keyboard, please forgive typos.
On Nov 14, 2013, at 22:02, Carlos Kamtha <kamtha@ak-labs.net> wrote:
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
participants (10)
-
Andrew Fried -
Carlos Kamtha -
Jay Ashworth -
Martin Hannigan -
Michael Collins -
Michael Collins, Aleae
-
Patrick W. Gilmore -
Phil Bedard -
Simon Lyall -
Warren Bailey