[166885] in North American Network Operators' Group
Re: CDN node locations
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Sat Nov 16 20:08:27 2013
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <20110405.1978.1384648600292.JavaMail.root@benjamin.baylink.com>
Date: Sat, 16 Nov 2013 20:07:42 -0500
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_61C2BA79-DD72-4CBD-B5B3-B2E5FB8324A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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.
>=20
> I find myself unsurprised.
>=20
> I was led to a very interesting failure case involving CDN's a couple =
weeks
> ago, that I thought you might find amusing.
>=20
> I have a Samsung Galaxy S4, with Sprint. On a semi-regular basis, the=20=
> networking gets flaky around 1-2am ish local time, but 3 weekends ago,=20=
> 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=20
> at the provider, and *all* outgoing 53 traffic to the greater internet
> wasn't being forwarded by Sprint's customer resolvers.
>=20
> I know that it was their resolvers, though, as I grabbed a copy of Set =
DNS,=20
> and pointed my phone to 8.8.8.8, and 4.2.2.1, and OpenDNS, and like =
that,=20
> and everything worked ok.
>=20
> Except media.
>=20
> (Patrick is starting to nod and chuckle, now :-)
>=20
> 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".
>=20
> 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=20
> was on alternate DNS resolution, I couldn't get to them.
>=20
> But that took me over a day to figure out. Don't get old. :-)
>=20
> Patrick? Is that how (at least some) customers do it?=20
#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.
--=20
TTFN,
patrick
P.S. I wasn't chuckling. :)
--Apple-Mail=_61C2BA79-DD72-4CBD-B5B3-B2E5FB8324A2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJSiBbeAAoJEHZX8udmu5TXkaYIAN/HicS6fnoZer/UPfFWw3wD
g/OsbpqJPlreI74k25prLg/n1jVrEianAX5/lXHLoMPvLKnv3YjDw0VxQNAVQW9D
V/VLF5zUMlI0Q6Ekmom//g/a+iDNy/hLfKd95RRfbQKAqbuieUWJsPaezHbaMSZP
VBSFW8MPDD2yKye7t+nt2pgYeV2dxYq7AYL+WftqnPCTigoeAHdEioPhmxmvxyLM
b88Jz4iU6QNdsv5PAIeh96bt/sq4HtpewWVMAYiMhpWlsH5bcaMc2QsMUsI5RMII
kmeFn0LDCX9t+Is85M88ENMCw3jW9mmgMLUHV2eXwW/QFUvs9gWpmRD7biMXr20=
=yBic
-----END PGP SIGNATURE-----
--Apple-Mail=_61C2BA79-DD72-4CBD-B5B3-B2E5FB8324A2--
