Comcast, Alternative DNS and CDNs

Recently I started noticing problems with our Comcast service that although speed tests were very speedy, as were certain downloads – primarily torrents of Linux distributions, other content downloads were pathetically slow.  These would include items such as iTunes downloads, streaming content and the like.  It wasn’t until I switched my router from using Google DNS (8.8.8.8, 8.8.4.4) back to using Comcast DNS and seeing a drastic speed increase did I realize why this slowdown was occurring.  The issue here is with Content Delivery Networks (CDNs) and alternative DNS services.

CDNs are great services that replicate data across a number of data centers to offer faster access to the content by allowing you to reach a center closer to your physical location.  This allows for lower latency as your connection has to go through fewer hops so you can get a better experience.  The problem comes with using alternative DNS services such as Google DNS.  These services tend to mess with the geo-location features of the CDNs and as such, they may route you to a center that is further away which would create a slower experience for the users.

This is the problem that we were seeing.  As mentioned, once I changed us back to using Comcast’s default DNS servers, everything from iTunes downloads and general page loading times increased dramatically.  Despite my disdain for Comcast DNS, I guess I’ll be leaving that alone for a while.

DNS Propagation

In setting up a new domain today I wanted to find a well-written article that explained DNS propagation in terms that anyone can understand.  I came across the article below from DevShed’s Rich Smith that is a great summary of the process and why caching of records are important.

You’ve registered your domain name, and paid for hosting with a hosting provider, and uploaded your website to the web server. If this is all done, why can’t you see the results of your hard work right away? What is this DNS propagation people keep telling you about?
In order to understand DNS propagation, you must first understand a little about how DNS works. When you set up your website with your hosting provider, they create a Master DNS record in their Domain Name Servers. Your domain registrar (the company you paid for the honor of owning your domain name) points to your web host’s DNS server as being the master authority of your domain.

When any outside source wants to know how to find your website, they first go to the registration database to find out who the DNS authority is for your website. Then they visit your hosting provider’s DNS servers to find out what the IP Address is for your domain name, and from there your audience can now view your website.

The problem with this whole scheme is that in order to speed up the rate at which their customers can view the internet, each Internet Server Provider caches their DNS records. This means that they make their own copy of the master records, and read from them locally instead of looking them up on the Internet each time someone wants view a website. This actually speeds up web surfing quite a bit, by (1) speeding up the return time it takes for a web browser to request a domain lookup and get an answer, and (2) actually reducing the amount of traffic on the web therefore giving it the ability to work faster.

The downside to this caching scenario and what makes it take so long for your website to be visible to everyone, is that each company or ISP that caches DNS records only updates them every few days. This is not any kind of standard, and they can set this time anywhere from a few hours to several days. The slow updating of the servers cache is called propagation, since your websites DNS information is now being propagated across all DNS servers on the web. When this is finally complete, everyone can now visit your new website. Being that the cache time is different for all servers, as mentioned above, it can take anywhere from 36 to 72 hours for DNS changes to be totally in effect.

Source: DevShed’s Rich Smith