[namecast]

I think that's right. But:

a) this is a common problem for CDNs, as you can never guarantee the DNS server that's asking for your CNAME is close to the cache servers that you want to deliver your end-user content; I'd be surprised if the first CDN cache server a client fetches github content from didn't inspect the end-user IP address from the HTTP session and redirect to a closer / "more optimal" point of presence if one were available;

b) In any case, it looks like Fastly is using anycast from a quick telnet to route-views.routeviews.org.

[nl]

this is a common problem for CDNs, as you can never guarantee the DNS server that's asking for your CNAME is close to the cache servers that you want to deliver your end-user content;

This is the case, and it's a significant problem - especially for people who use Google's DNS server or OpenDNS

There is an experimental, but reasonably widely deployed[1] solution available though.

I'd be surprised if the first CDN cache server a client fetches github content from didn't inspect the end-user IP address from the HTTP session and redirect to a closer / "more optimal" point of presence if one were available;

That's pretty unlikely. The redirect is going to cost more than just serving the data (and of course there is no way to persist that redirect back to the DNS layer, so it will happen for every resource). "Media" CDNs (ie, CDNs optimised for delivery of large files like movies) sometimes work like this though.

HOWEVER, since Fastly/Github is doing Anycast, none of this should affect them.

[1] http://www.cdnplanet.com/blog/which-cdns-support-edns-client...

[tomjakubowski]

Google's public DNS (8.8.8.8) uses anycast as well.

https://developers.google.com/speed/public-dns/faq#anycast

[namecast]

I'll just put this here: Anycast doesn't _necessarily_ break CDNs in the way this thread has been implying. Ideally you've got some sort of loose unicast rpf in place for your DNS nodes, and have them receive DNS queries on the anycast address, and send outbound queries out of a local interface so that the NS you're querying knows where you're located... but this is getting a bit far afield of GitHub's new features in any case. PM me if you want to here me blather about DNS and CDNs more. And cross your fingers that edns0-subnet gets implemented sometime soon.

[timrivera]

definitely not doing Anycast. As I wrote just a few days ago [1] github.map.fastly.net resolves to a different IP address based on the geographic location of the user. The exact server location might be approximated from the X-Served-By response header:

  X-Served-By: cache-fra1225-FRA
  X-Served-By: cache-d46-DAL

[1] https://news.ycombinator.com/item?id=6975830

[Nagyman]

That article says that Fastly is not doing Anycast.

[saurik]

Redirecting the user to somewhere closer, for small content like you would have on Pages, would make a bad situation (talking to a suboptimal server) much much worse (due to having to setup a second connection and do another round trip with the new request).

[dfc]

I have always wanted to be able to use routeviews for more than an easy way to bring about feelings of network inadequacy.