Different Realms, Different TLD’s

Many companies break up their internal environments into different realms. A typical setup might look like:

  • The prod realm is where production servers live.
  • The dev or stage realm is a live testing environment, where code gets deployed before it goes into production, or long-running features are tested.
  • The local realm is for code that's developed on your laptop, or in Docker, or in a cloud server provided to each developer.

The names each company assigns to each realm might be different, but that doesn't matter. I strongly recommend purchasing a different TLD for each realm that you operate, and then deploying them everywhere your company accesses sites over HTTP. So following the example above:

  • acme.com serves your production site.
  • acme.dev serves your development realm.
  • acme.app, acme.site or acme.website is reserved for your local realm.

You might need to change the TLD's based on which ones are available, but since there are hundreds, you should be able to snag three. The key is you need to be able to buy the same hostname for every TLD. You want things to be as simple as possible for your team - no needing to remember that the prod website is acme.com and the dev website is acmetest.dev or whatever. Then it becomes dead easy to remember how to navigate to each site - you combine the hostname and the TLD for that realm, and then you get to the right place.

For local development, you're probably going to be redirecting traffic to your local machine, instead of using the public Internet to serve it. You want to buy the domain anyway because you don't want someone who forgot to redirect traffic to end up sending requests to a server you don't control.

There is a special TLD named .test that is designed for local development and DNS testing. However, Google forbids the use of that domain for e.g. SSO authentication, so I recommend buying a live domain and then black-holing the traffic.

I wrote a tool called hostsfile that you can use to automatically add entries to the /etc/hosts file on employee laptops, to redirect their traffic from your "local" domain to localhost.

sudo hostsfile add acme.app 127.0.0.1
sudo hostsfile add acme.app fe80::1%lo0

Why are separate TLD's so important? Besides the fact that it's drop dead easy to remember, there are a few good security reasons. The goal with many security measures is to make entire classes of problems impossible, and that's what this strategy does.

It's impossible to "leak" a production cookie to your dev environment, or vice versa, if you have completely separate TLD's for each realm. If you use www.acme.com for prod and dev.acme.com for dev, you need to host the DNS records for each realm in the same place, which makes it difficult to test changes, and increases the likelihood of accidentally shipping a breaking change. With different TLD's you can use different Route53 realms, or different accounts with your hosting provider. These make it easier to test changes without accidentally breaking production.

Another way that cookies break is because your prod dashboard is served at the root - acme.com - while your dev and staging servers add an additional subdomain, for example dev.acme.com. This can cause subtle breakage; if you use the same hostname scheme in every realm, it's impossible.

I encourage teams to use TLS for local development, for the same "just keep everything the same between all realms" reason. If you are reusing TLD's, you could potentially issue a cert that's valid for a production domain, or be tempted to reuse your production certs for local development. If you own acme.website and only use it for local development, and use acme.com for prod, it doesn't matter if you leak the .website certs accidentally, because you can't use them to do anything that matters.

Finally, it makes it very difficult for people to accidentally confuse what realm they think they are on. If you make a request to .website you know you are not in prod, for example.

Liked what you read? I am looking for work.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments are heavily moderated.