Fighting DNS Propagation with a Reverse Proxy

#
By Jeff Gould

Migrating servers is a whole series of blog posts in itself, but here’s one aspect of your server migration that can be greatly improved using a reverse-proxy.

What is a reverse-proxy?

Most of us are familiar with the idea of a proxy server. The recipe is on the tin: it’s a server that acts as a proxy on the internet for your requests.

A reverse-proxy is similar but, as you might have guessed, reversed. A reverse-proxy receives requests from the internet, obtains the requested resource from the server that it’s acting as a proxy for, and then returns that resource to the requester.

You might have even installed Nginx in front of Apache as a way to use the powerful features of Apache, but still benefit from Nginx’s speed. In this scenario, Nginx is acting as a reverse-proxy for Apache.

How can a reverse-proxy help with DNS propagation?

A reverse-proxy can’t really speed up DNS propagation, but it can mitigate a lot of the headache associated with waiting for it to happen.

Say you’re moving a client’s e-commerce site from one host to another. Their VPS at NixNode just isn’t keeping up so you’re moving them to a shiny new cloud server over at SmigitalSmocean. You’ve got everything set up on the new server and you’re ready to switch over the DNS, but you realize that once you save the new zone file, some users will still be hitting your NixNode server until their local DNS cache is updated.

In this scenario, any orders that are received on the old server will need to be migrated manually to the new server. This is a relatively high traffic site, and since DNS could take a few hours to propagate, you might end up moving dozens or even hundreds of orders over to the new server.

The obvious solution would be to disable ordering on the old server to be safe but you’d risk losing that revenue for your client. Alternatively, you can ensure that the switchover happens instantly by turning your old NixNode server into a reverse-proxy for your SmigitalSmocean box.

Setting up the reverse-proxy

Lets assume that the old NixNode server is running a modern LAMP stack on Ubuntu 14.04. After you’ve logged into your NixNode server via SSH, you’ll first need to make sure that you’ve got the proxy_http Apache module enabled:

 $ sudo a2enmod proxy_http

This will actually enable the basic proxy module as well if it isn’t already since proxy_http relies on it.

Then, in your text editor of choice, you’ll need to create a new configuration file in your sites_available folder. I like vim, so the command looks like this:

 $ sudo vim /etc/apache2/sites-available/my-proxy.conf

Then you can paste in the VirtualHost configuration:

 <VirtualHost *:80>
         ServerName mydomain.com
         ServerAlias www.mydomain.com
         ErrorLog ${APACHE_LOG_DIR}/proxy-error.log
         CustomLog ${APACHE_LOG_DIR}/proxy-access.log combined
         ProxyRequests Off
         ProxyPass / http://555.867.530.9/
         ProxyPassReverse / http://555.867.530.9/
 </VirtualHost>

If you’re following this guide to set up your own reverse-proxy, make sure to replace mydomain.com with your site’s domain name, and 555.867.530.9 with the IP address of your new server.

Before we move on, let’s go over the VirtualHost configuration line by line:

  1. <VirtualHost *:80> means we’re defining a new virtual host for all IP’s on this server at port 80.
  2. ServerName proxy.otherdomain.com defines the domain that this virtual host will handle.
  3. ServerAlias www.mydomain.com will make sure that we proxy requests to the www subdomain as well.
  4. The ErrorLog and CustomLog lines let Apache know where to write error and access logs for this virtual host. I like to have them separated out from any other hosts on the server just in case I want to look into anything later.
  5. ProxyRequests Off explicitly disables the forward proxy, just in case.
  6. ProxyPass / http://555.867.530.9/ is where the magic happens, as this line lets the proxy know where to forward requests sent to ServerName. It could even be a subdirectory if that’s what you wanted.
  7. ProxyPassReverse / http://555.867.530.9/ allows Apache to modify any responses from the server it’s acting as a proxy for. For example, if a request to http://555.867.530.9/ sends back a header that redirects you to http://555.867.530.9/index.php, the header will be modified so we’ll get redirected to mydomain.com/index.php instead.

Now you can save the file and exit out of your text editor. Nothing has changed yet since we still need to disable the VirtualHost for our current site, enable the VirtualHost for the reverse-proxy and finally restart Apache.

To figure out which site to disable, you can check which configurations are enabled:

$ ls /etc/apache2/sites-enabled
> 000-default.conf

Since I’ve been using this server pretty much out of the box, the only ‘site’ that’s enabled is 000-default.conf which is the default configuration. So I’ll want to make sure to disable that, enable my proxy, and then restart Apache to make sure everything I’ve done goes into effect:

$ sudo a2dissite 000-default
$ sudo a2ensite my-proxy
$ sudo service apache2 restart

Now anybody who visits mydomain.com will be served a site that’s actually being created by the server at http://555.867.530.9 and we haven’t even updated the DNS yet!

You can now proceed with updating your DNS records to point your domain to your new server. As DNS is propagating, some visitors will be directed to the server at NixNode and some will be sent to the new server at SmigitalSmocean, but all requests will actually be fulfilled by the server at SmigitalSmocean thanks to our reverse-proxy.

Considerations

The reverse-proxy can be incredibly helpful in simplifying the process of moving servers as it puts you back in control of the exact moment a new server starts serving all requests to your domain, but there are a few things that you should be aware of before implementing this solution:

  1. The reverse-proxy only applies to HTTP connections. All other records, such as MX records, and non-HTTP requests will still be routed to the IP address that DNS dictates. You can reduce propagation time by lowering TTL values a few days before you plan to make the move and updating your A records to point at your new server before you update the NS records if you’re also moving to new nameservers. Most DNS servers will update their caches in respect to TTL values, but propagation can still take some time and a record with a TTL of 300 seconds can take a few hours to get updated on every DNS server in the world that receives a lookup request.

  2. If you’re using HTTPS, you’ll need to set up a reverse-proxy for port 443 in addition to the proxy you’ve set up for HTTP traffic on port 80.

  3. The reverse-proxy will not proxy a MySQL or other database. In most cases a web application like WordPress will access your database via an address like localhost or 127.0.0.1, and this should work just fine with your reverse-proxy. On the other hand, if you connect to your database via a subdomain like sql.mydomain.com you’ll want to make sure that you use a new, unique subdomain that DNS servers don’t have a cache for and be sure to update the records at your original host well in advance of your move.

  4. If the host you’re moving from won’t allow you to edit your server configuration to enable a reverse-proxy, that doesn’t necessarily mean that you can’t take advantage of one. In this case you’d need to bring a third server into the mix: I’d use a host like DigitalOcean to spin up a server that will only act as a reverse-proxy.

    At first you’d set this server up to be a reverse-proxy for your old site. Then, you can update the A record for your domain to point at the proxy which will continue to serve resources from your original host. After a few days, when you’re sure that the DNS has propagated, you can transfer your files and database to your new server and update your proxy server to be a reverse-proxy for your new host. Update your DNS records again to point at the new host and after a few days, when traffic stops routing through your proxy, you can shut it down.

TMTOWTDI

Years ago when I used to be a Perl developer I learned a mantra that was often reduced to an unpronounceable acronym: There’s More Than One Way To Do It.

A reverse-proxy can be an incredibly powerful tool for routing traffic around and through tough situations – but there’s always more than one way to do it. What are your best tips for migrating servers or creative uses of the reverse-proxy? Let us know in the comments!

About the Author

Jeff Gould

Jeff is a problem solver at heart who found his way to the web at an early age and never looked back. Before Delicious Brains, Jeff was a freelance web developer specializing in WordPress and front-end development.