Start typing to search.
Your search yielded no results.

Setting up your DNS

Introduction

Properly setting up DNS for your custom URLs is imperative for the uptime of your application. When done as per the platform specifications, you will be able to make use of all powerful features the platform has to offer, such as zero downtime switching of URLs between (new versions) of applications, without ever needing any adjustments in your DNS panel.

Never ever setup DNS records to point directly to an IP address of your environment gateway!

Platform DNS concept

The concept behind the DNS management of the platform is simple: ensure that each hostname always resolves to the environment gateway(s). If you have more than one gateway, the platform will make sure that it will resolve to ALL gateways, also known as DNS based loadbalancing.

How the platform can make sure of this is as follows:

  1. When you add a custom URL to your application, the platform will generate an origin URL. You can see this origin URL when opening the DNS setup instructions in the “Web access” pane on the application detail page:

  1. As You can see in the screenshot above, the origin URL is a subdomain in a completely different domain name than your custom URL. It is this origin URL that is managed by the platform.

  2. When you rename the URL, the origin URL will change along with it!

  3. When you delete the URL and re-add it with the exact same name and spelling, the origin URL will be the same as it was! This will allow you to move URLs between projects.

Whenever a new gateway is added, or a gateway is changed for whatever reason, the platform will make sure the DNS entry for this origin URL is updated to resolve to all IP addresses (IP v4 and IP v6 when available) of all gateways.

Advantages

Moving URLs between Apps

If you want to switch a URL from application A to application B, you can do this simply by updating the URL and path mappings as explained here.

Emergency gateway maintenance

Whenever our support engineers need to intervene with a gateway, they can replace it instantly without the need for end user DNS changes since the platform will automatically update the origin URLs as explained earlier.

Cloudflare integration

Each custom URL has a different origin URL. Which means that for each custom URL separately, you can enable the Cloudflare integration. So you can have URLs that are protected and some that are not (which can be useful for admin environments with features that would break when enabling cloudflare but which you could protect using IP whitelisting).

Disadvantages

There is only one: since each custom URL has a different origin URL, you will have to manage each record for your custom domain separately. In the old days it was common to add A/AAA records on the apex domain (say example.com) and set up all subdomains (like www.example.com or app.example.com) as a CNAME record to the apex domain. This way you only had to update a single record to have all subdomains updated as well. That is obviously not possible but we deem this disadvantage as only very minor since the advantages far outweigh it.

Set up in your DNS panel

The full setup instructions can be found under the DNS instructions. See the screenshot above as to where you can find them.

It is very important that you follow these instructions to the letter:

  1. Always use ANAME/ALIAS or CNAME records or CNAME flattening also on the apex domain (e.g. example.com). If your DNS provider does not have support for this, do not doubt: simply switch provider and choose one that does support it. It will vastly improve your life as a developer/maintainer and will benefit your customers! As a last resort, we offer our redirect service which allows you to point an apex domain record to an IP address which is under our control.

  2. Always use the suggested TTL of 60 seconds. This way, any changes the platform makes to the DNS setup of the origin URLs is reflected as fast as possible in your custom records.

  3. When a subdomain (e.g. shop.example.com) has an MX record, you must treat this domain as if it were an apex domain because of the MX record that is present. Otherwise you will end up breaking your DNS setup for the domain with unpredictable results as a consequence.