How to Handle Bad DNS Practices

I’m curious how other web developers and admins handle this – particularly for blogs and similar things that accept user comments/submissions.

I’m in the process of moving several sites from one hosting provider to another. Of course this means having to update the DNS records. I’m also switching to the new provider’s name servers.

After having done many site moves over the years, I tried to make sure that I’d have minimal DNS issues:

  1. On Friday and Saturday (three to four days ago), I setup the entries on the new name servers and set the TTL s very low (five minutes).
  2. Late Saturday, I pointed the domain registrar to the new name servers.
  3. On Sunday and Monday (one to two days ago), I changed the domain records to point to the new IP address.

Most clients picked up the change within an hour. My home provider, almost a day later, seems to be ignoring the TTLs that I set. I flushed my DNS and rebooted my router, just to be sure, then directly queried my ISP’s DNS servers and still received the old entries. Every other provider that I have access to updated very quickly, but I verified that others that use my ISP had a similar experience. For what it matters, it is a smaller, regional ISP and not one of the big boys – just happens to be what’s available where I live.

Doing a quick Google, it sounds like this isn’t necessarily uncommon among ISPs – especially smaller ones.

When I was working with static web sites, this wasn’t a big deal – I’d simply leave both copies of the site up for a few days. Now, however, most of the sites in question allow comment submission and other forms of content submissions. That means that users affected by similarly ignorant ISPs could be commenting on the old version of the site.

In my case, since I have full control over the database server and the firewall protecting it, I could point the old copy of the site to the new database, so that any comments/submissions would post to the new database and appear on both sites. Unfortunately, this isn’t always an available option.

So … has anyone come up with a clever way to take this into account?

P.S. I did switch my router to use Google’s DNS, which got it working for me, but I know that most users will simply use their ISP’s defaults.

2 Comments


  1. Short answer:
    How about a transition DNS record with a web redirect on the old site?

    Long answer:
    This problem comes down to DNS caching on ISP servers for your record, say http://www.domain.com. So, when it comes time to transition, create transition.domain.com (or something better) that points to the IP of the NEW service. On the OLD service, put a redirect page as the main landing page that redirects users to transition.domain.com. A user with an invalid cached record will be directed to the OLD site and then redirected to transition.domain.com, which is the content of the NEW site. Since transition.domain.com is a new record, an entry will not exist in the ISP’s cache and therefore, the user should get a valid response.

    Reply

    1. Google may dock you for having two URLs with the same content. At least, SEO types say that’s the case with completely different domains – sub-domains may he different, I don’t know. That being said, it’d only be for a couple of days, so probably wouldn’t matter. You could always block search engine bots on the sub-domain, I suppose.

      My other concern would be people who get the sub-domain URL who bookmark it or share it. Considering you want the sub-domain to he temporary, that wouldn’t be ideal.

      I’d also have to test how WordPress, in particular, would deal with this. It might have an issue with the domain it thinks it is not pointing to the content.

      Not a bad idea, just caveats to be aware of and testing to do.

      Reply

Leave a Reply