Managing DNS for a reverse proxy

If you use multiple web applications on one or more servers, you will need to use a reverse proxy like Nginx or Traefik.

(We'll have the opportunity to talk more about Traefik soon, by the way).

In this case, you are faced with the challenge of managing domain names and subdomains.

Before we start

This is not an article on how DNS works. I encourage you to check out Grafikart's article on the subject if needed.

Of course, you will need a static IP address accessible on the internet and a domain name if you want to reproduce what we are going to do.

What is a reverse proxy?

To simplify the examples, we will use a scenario with a single server and several applications running on it.

As shown in Traefik's presentation image, a reverse proxy acts as an intermediary between users and the server. It allows you to associate URLs, with different domains and subdomains, to different applications.

Without a reverse proxy, you would need to use different ports for each application, which is not very convenient and looks messy in the URL.

For example, imagine I have a back office on port 3000 and a PHP API on port 8000. The URLs could look like: guillaumebriday.com:3000 and guillaumebriday.com:8000.

What we want instead is backoffice.guillaumebriday.com and api.guillaumebriday.com. This is much cleaner and easier to maintain.

We are still on the same server, but it is the reverse proxy that will, depending on the subdomain, redirect to either the PHP application or the Ruby one.

The reverse proxy also allows for load balancing, as it can redirect requests to as many instances of our applications as necessary for a given domain or subdomain.

Configuring DNS

We now need to configure our DNS to achieve this behavior. I will use the Gandi interface, but the configuration should be quite similar with other services.

First, we will configure our main domain to point to our server with an A record. You will also need to choose the TTL of your record, keeping in mind that the shorter the time, the more performance will be affected, as clients will have to update their cache more frequently.

Finally, I will create a record that applies to all subdomains using the special character *. The type will be CNAME this time, pointing to the main domain so that we only have to change the server IP address in one place if necessary.

With this setup, I can now use dynamically created subdomains, which will automatically point to the correct server.

And here is the text version:

* 10800 IN CNAME guillaumebriday.fr.
@ 10800 IN A 104.198.14.52

The @ refers to the domain name itself, in my case guillaumebriday.fr..

Beware of propagation

DNS records are cached at various levels, both on the client and server side.

Therefore, DNS updates need to be planned ahead. To avoid errors, you can gradually reduce the TTL of a record to limit cache-related errors when changing the IP address.

For instance, if I set an eight-hour TTL and change the IP address, the application might be inaccessible for that time for some users who still have the old IP address cached. If I drastically reduce this time, the downtime will be much shorter or even unnoticeable.

It is important to set a reasonable TTL again as soon as all caches have been invalidated.

Conclusion

With this setup, we can implement cool tools like Review Apps or even self-hosted services, so we no longer have to use Google's services, for example. Stay tuned for more on the blog.

Thank you!