On using dummy domains

Friday September 28, 2007 - 10 months ago

Posted by James Ellis / Filed under Web

Moving a website from one web hosting provider to another can be frustrating. Domains take a long time to propagate. How do you keep email from getting lost? How do you properly test a site before moving? A dummy domain can help.

Let’s say you have a new client. They have an existing website that your firm is going to redesign. Not only will you be redesigning the site, but you’ll be starting over with a new CMS and fancy front-end framework. Chances are that the client is currently hosting their site with some lame provider (i.e. out of date software, no Subversion support, no server-side spam software, etc.). You need to move the site to a provider you trust, and come launch time, the transition needs to be as smooth as possible.

After a bit of trial and error, we’ve come up with a system of using dummy domains to test projects in development, and ease the transition during domain name propagation.

The basics, step by step

  1. Go buy a dummy domain. We use a variety of dummy domains — athletics-transfer.com is a good example. You’ll notice that this was the dummy domain we used for the recently launched Dangerbird Records website. In a few weeks we’ll disable this and use it for some other project.
  2. Set up the new hosting environment. There are many great hosting providers out there. We like Empowering Media, but you can use whoever you like.
  3. Point your dummy domain to the new host. Set the dummy domain’s nameservers to point to your new hosting provider.
  4. Develop and test the new site. Develop and test the entire project on the new server using the dummy domain. To keep folks from peeping the unreleased site, we always lock things down behind a password, which we provide to the client.
  5. Set up email addresses. The client is already using a number of email addresses. You’ll need to set up these addresses on the new server. It doesn’t matter that the addresses are behind the dummy domain. So, for address@clients-domain.com, you’ll create address@dummy-domain.com.

Launch time

Once the site has been fully developed, tested, and the client is ready to go live, there are few steps to ensure a smooth transition.

  1. Add a domain alias. In the new hosting environment, add the client’s live domain as an alias of the dummy domain — meaning, visiting either domain in your web browser should resolve to the same site.
    (Of course, nothing will happen until you point the live domain’s DNS to the new hosting provider, but we still have a few things to do before we get to that…)
  2. Wait two hours. Give the hosting provider a bit of time to add the client’s live domain to their internal nameservers.
  3. Forward all email. On the client’s old server (that you’re about to abandon), set up forwards on each email account forwarding all email to the corresponding address at the dummy domain. So, example@clients-domain.com should forward all email to example@dummy-domain.com.
  4. Test email forwards. Send a few tests to make sure that email is being forwarded correctly.
  5. Change DNS. Now you can finally change the client’s domain’s nameservers to point to the new hosting provider. A domain’s nameserver information gets cached and stored all over the internet — thousands of servers cache this information to keep the internet moving fast. It can take up to 72 hours for all of these servers to switch over and begin using the new nameservers.

So what just happened?

By forwarding email on the old server to corresponding addresses at the dummy domain, we made sure that email didn’t get lost during the domain name propagation period (again, this can last up to 72 hours). Any email that made its way to the old server was forwarded along to the new one.

Post-launch

Once the client’s domain has had time to propagate (7 days is pretty safe), you can remove the dummy domain.

Was all the fuss about email?

Pretty much. For most of our clients, losing email is a deal breaker. However, with an $8 dummy domain and a bit of jiggery-pokery, we can ensure that nothing gets lost.

Also, we like the professional touch. To clients, dummy domains feel more real than something like http://dev.athleticsnyc.com/client-name/. We explain to the client that the dummy domain is running directly on their new server. The client gets a sense of comfort knowing the dummy domain is their website, just behind a different name.

Why don’t you just set up an MX record to send email somewhere else?

True, that’s another solution. We love that Google Apps now offers the ability to pipe your domain’s email over to Google’s servers and use Gmail to manage your email at @your-domain.com instead of @gmail.com. It’s easy to set up, and free.

A major benefit of using an MX record to bounce all email along to a hosted service is that you don’t have to worry about losing email when switching web hosts. You’re cool as long as both the old and new hosting providers’ DNS include an MX record routing all email to the third party email service.

There are a number of professional solutions for managing email in this way. Just google “hosted email” and you’ll find a bunch of them. However, I find most of these services to be geared for the corporate crowd. Further, a third-party pro email service just isn’t necessary for most of our clients. Running email and web services on the same server works fine for most.

Worth the $8

I try to enjoy peace of mind whenever possible. The dummy-domain-email-bouncery trick helps with that.

Questions? Comments? Contact James via email - .