2

On my old ISP's DNS servers, sometimes https://www.facebook.com would return a cert for Akamai instead of Facebook. What I don't understand is that changing my DNS server to Googles (8.8.8.8) fixes the issue.

Any ideas? I have reproduced this on more than one occasion, but I still wouldn't rule it out as being mere coincidence.

1 Answer 1

1

Something like this?

enter image description here

Probably caused by the load balancing techniques used by Facebook.

Essentially, when your computer issues a DNS request to your local DNS server (usually the one run by your ISP), it in turn contacts the authoritative DNS servers for the Facebook domain. Those servers in turn direct the DNS request to Akamai DNS servers, which return an IP address for a Facebook web server based on a number of factors, like geographical distance, load, and congestion.

This has been seen before. A section of that Ars Technica article reveals what has to happen for HTTPS content to be properly delivered over a CDN like Akamai (emphasis mine):

We’ve looked pretty extensively at serving Ars Technica over HTTPS in the past. Here’s what we’d need to do to make this a reality:

First, we would need to ensure that all third-party assets are served over SSL. All third-party ad providers, their back-end services, analytics tools, and useful widgets we include in the page would need to come over HTTPS. Assuming they even offer it, we would also need to be confident that they’re not letting unencrypted content sneak in. Facebook and Twitter are probably safe (but only as of the past few weeks), and Google Analytics has been fine for quite a while. Our ad network, DoubleClick, is a mixed bag. Most everything served up from the DoubleClick domain will work fine, but DoubleClick occasionally serves up vetted third-party assets (images, analytics code) which may or may not work properly over HTTPS. And even if it “works,” many of the domains this content is served from are delivered by CDNs like Akamai over a branded domain (e.g. the server’s SSL cert is for *.akamai.com, not for s0.mdn.net, which will cause most browsers to balk).

Next, we would need to make sure our sensitive cookies have both the Secure and HttpOnly flags set. Then we would need to find a CDN with SSL abilities. Our CDN works really well over HTTP, just like most other CDNs. We even have a lovely “static.arstechnica.net” branded host. CDNs that do expose HTTPS are rare (Akamai and Amazon’s CloudFront currently support it), and leave you with URLs like “static.arstechnica.net.cdndomain.com”. It would work, but we’d be sad to lose our spiffy host name and our great arrangement with CacheFly.

My guess is that your ISP is doing something that affects DNS resolution of one of the domains involved in the FB page request, perhaps directing it to an Akamai server that is not properly configured to serve a Facebook page, thus causing the error.

2
  • thank you for the explanation. so lets say that my dns is pointing to a misconfigured akamai server. how does that happen? the problem would come up infrequently, but definitely enough that it would lead me to believe that they are somehow constantly messing things up. also, why does my new ISP and google not make the same mistake? are they just quicker to update their DNS servers? thanks!
    – tau
    Commented Apr 8, 2014 at 1:40
  • 1
    Again, I'm guessing: one possible cause is that the ISP DNS servers are not complying with the TTL values issued by the authoritative Akamai DNS servers. So when Akamai make a change, the ISP does not comply with it until some time after the change has gone live. Commented Apr 8, 2014 at 6:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .