Caching & Domain Names
Updated over a week ago

When clients decide to use their own domain name with a Member Splash provided site we often get questions about the new site not loading or displaying a warning about not being private such as this:

The reason? Caching.

DNS & Caching Explained

Domain Name Servers (DNS) act as the phone book for the internet. If you visit CentralOps.net (https://centralops.net/co/) and enter a domain name, say google.com, it will show you the IP address of the server(s) that hosts the site.

There are different types of DNS records and they function like a subdirectory for a business in a phone book. The business might have a main 800 number, and then separate extensions listed for various departments. The various DNS records detail which server(s) are hosting your website, handling your email, and so on.

So Why Am I Having Issues?

Simple: Propagation and Caching.

Let's take a simplied look at what happens when you decide to visit Google to look something up.

1. You put https://google.com into your browser;

2. Your browser checks locally on your computer to see if that is a site you have previously visited and if it has stored the IP address from that visit. It also checks how long ago you last visited and if has been less than certain period of time it connects you to that server and you're off to the races.

If it doesn't find a local record, or if the record has expired, it connects to whatever DNS server your computer is set to use. For most people that's a DNS server operated by your internet service provider and it's automatically configured. Some users may have elected to specify different DNS servers to use, such as Google's public DNS servers (https://developers.google.com/speed/public-dns).

3. The DNS server checks its own file to for an entry for Google. Here is where propagation comes into play. Different DNS servers check for changes in DNS records at different intervals. The DNS server you're connecting to might check very frequently, or it might only check a few times a day (very uncommon these days). So if you update your records to point to the new Member Splash provided site and then try to visit it you might get sent right back to the old site until your DNS server has updated to reflect the change. While it can theoretically take up to 72 hours for DNS changes to fully propagate in practice it rarely takes more than a few hours and is often fairly instantaneous.

If you go to a site like Geopeeker and enter your URL you can see what various places around the country and world see when they try to access your site, which gives you some insight into how widely the update has propagated.

5. The final thing that affects it is local caching in your browser. Chrome, in particular, is notorious for aggressive caching. Generally this is a positive thing as it speeds up your browsing experience. For example, if your site has a number of images, Chrome will download them the first time you visit and then use the locally stored copy on your next visit. That makes the site load much more quickly for you.

But caching can be a challenge if the saved information is no longer correct, such as when the website has been moved. As I'm writing this article I have a client website loaded on my laptop and my desktop which are sitting next to each other and sharing the same internet connection. On my laptop the site loads correctly. On my desktop it shows the privacy warning. Why? Because on my desktop I visited the site after updating their DNS record but before we issued the SSL certificate for the new site. Chrome on my desktop therefore noted that there wasn't a valid certificate and stored that information locally. Even though there is a valid certificate now, Chrome won't check again until its cache expires or until I manually clear the browser cache. As soon as I do that it will recheck, discover that there is a valid SSL certificate, and the error will go away.

Did this answer your question?