Status Report About DNS Propagation

The new site is working for a lot of people, but some Filers report they are unable to see the site at its new host, getting error messages, or receiving the last save prior to the move. My best guess is the internet services they connect with have not yet copied the updated DNS.

My new ISP’s Knowledge Base gives this overview of DNS propagation:

DNS propagation can be thought of as the time it takes DNS records to expire on a server. For example, if you update your nameservers to point to a different hosting company, those new nameservers must propagate across the Internet. Each ISP has their own time frame on how often they update/expire their cached DNS records. Because there is no single shared standard throughout the Internet, this entire process can take from a few hours to up to 72 hours.

16 thoughts on “Status Report About DNS Propagation

  1. Had just posted this in the 4/28 scroll but might be more appropriate here 🙂

    @ Mike Glyer

    Yep the DNS change is slowly propagating. About an hour ago CenturyLink was still pointed to the old site but Sprint was landing here at the new. Still some folks posting at the old and waiting. Could take a few days for everyone to update. Usually about 24 to 48 hours though. It’s kind of like updating all the phone books in a city.

  2. As an end user, you don’t have to use the DNS server provided by your ISP. Your system simply needs to know the IP address of the DNS server to use. I was using OpenDNS, a unit of Cisco Systems.

    At the time I switched, it was the fastest third party DNS server, and also kept a blocklist of domains known to serve malware. Try to access a page on the block list and OpenDNS throws up a warning page. I use Firefox, which also keeps one, but an additional layer of protection doesn’t hurt.

    I’m currently testing an alternative service from Cloudflare, an Internet security vendor.

    They have the fastest third-party DNS server, and claim to be privacy oriented and not keep logs of DNS requests.

    My primary reason for switching back when was to reduce lag in DNS updates. The additional features provided by OpenDNS and ClouFlare are icing on that cake.

    I plugged CloudFlare’s DNS entries into my router, so all connected devices here use them.

    (Incidentally, the tool I use to look up server addresses thinks has insecure HTTP access. You might talk to your new ISP about configuring HTTPS as well. With the current focus on security and privacy, It probably won’t be all that long before current browsers will require HTTPS connections.)


  3. @DMcCunney – Yeah, there is no HTTPS access/no SSL certificate installed on File770.

    @OGH – that will become an issue in the near future. Google Chrome is calling sites without SSL “insecure” and sites with SSL “secure” (that last one is misleading at best). Most hosting services give free SSL certificates at this point, using Let’s Encrypt, a service started by the ISRG and recommended by EFF. We’re using Let’s Encrypt where I work now, migrating all non-SSL sites to their certificates.

    Looks like File770 is now hosted at Dreamhost. Adding a cert is probably pretty simple (and it’s free(!!) for Let’s Encrypt certs – when it says adding a unique IP for $6/month is required for older browsers, they mean oooooooolder browsers):

    @PJ – DNS propagation won’t cause slowness or latency – you’ll either go to the old IP address and not see what’s been posted since hosting changed, or see the new site.

    From what I recall, from my best bet when I still had the incorrect records in my resolver, the TTL for was four hours. Everyone should see the new site by now, but there are a host of variables that could explain people who don’t:
    – their ISP’s recursive DNS servers may be misconfigured and have stale data
    – they may be connected to a local router (wireless or otherwise) that acts as their local resolver and is caching stale data (a common issue)
    – their operating system’s resolver may be caching stale records
    – their browser may be caching old records

    A common fix for all of the local issues above (all but the first) is rebooting everything – routers, computers, etc., and clearing the browser cache. I hate rebooting as solution, personally, preferring to clear caches myself. That can be done on some routers through a managemt interface. Not sure about OS resolvers. Chrome’s cache can be cleared by going to chrome://net-internals/#dns and clicking the “clear cache” button.

    Also, seconding what DMcCunney said about using 3rd-party resolvers. Google offers recursive servers at and, and you can clear the cache on google recusive DNS servers at

  4. Also, it’s frustrating to see updates from fellow filers stuck in the dead alternate reality of the old site. I hope they make it here soon!

  5. kathodus: Also, it’s frustrating to see updates from fellow filers stuck in the dead alternate reality of the old site. I hope they make it here soon!

    It’s like the horror of a Doctor Who episode!

  6. I’m in! I’m in! Hurrah!

    I’m in town, but not using wifi. I’m having visions of the old site mysteriously reappearing when I go home!

  7. Any caching name server won’t necessarily respect the TTL (how long to cache the address) some actively override the set TTL to whatever they think appropriate. This serves to reduce load on the dns servers. Which means even if you lower the TTL while migrating a site to speed up the process some people will still get old data.

    If you have dig and nslookup try:
    nslookup (what your default dns server thinks the address should be)
    nslookup (what the address should be)

    If these don’t agree
    dig +nocmd +noall +answer

    The second field will tell you how long your default dns server will take, in seconds, before it will expire the cached entry and do a lookup. And I am one of today’s lucky 10,000

Comments are closed.