Regardless of whether you are a small business with a website or a multi-branch international business, DNS plays a key role in your day-to-day business transactions. It allows your website to be reached, your business partners to access your APIs and your disaster recovery failover plan to take effect.
This article will discuss the choices you have to make when choosing an internal domain name for your business and how you should structure it so that you are in control as your business grows.
DNS (Domain Name System) is a zone-partitioned globally available distributed database of different types of domain records. It provides autonomy to manage domain records using delegation, this delegation is based on nodes in an inverted tree structure.
You can consider yourself a fortunate person if you have been asked to come up with the internal domain name strategy and standards. This task might sound simple, but you will need to get this right as it influences on the technology choices and teams’ interaction. To help you get started, here are a few questions that you need to consider as technical architect within the business.
Question One: What should the internal domain name be?
RFC 2606 goes back to 1999, just around the time when Cloud computing started to see the light. So using Example.com, .test or .invalid might be justifiable back then but not now.
There are two options to choose from:
Register a domain on the internet and use it internally in a private hosted zone. This ensures a complete separation between your public facing domain and internal one. You might still have the same automation and monitoring to manage both. As such, there is very little additional cost to this option. TLS certificates can be generated for both domains using a proper CA if needed.
Having this separation means that any future business rebranding can be done quickly on the public facing domain, the internal one can be done separately at a different pace.
Alternatively, use the same external domain with a split horizon setup, external records using a public hosted zone while internal ones are available using the private hosted zone. Adding a subdomain of .int. or .internal. makes it clearer to the different teams as to which one to use and where to find the relevant records for a given FQDN.
If you are still not currently using a Cloud Service Provider like AWS, GCP or Azure; it doesn’t mean that you won’t be using one soon.
One advantage of having a valid domain in this case is that you can offer your APIs to other AWS VPCs using PrivateLink and AWS will take care of the DNS records even if the destination account doesn’t belong to the same organisation.
Question Two: How should I structure the internal domain?
Now that your internal domain name is confirmed to be something like organisation.tld, it could even just be a different TLD from the public facing FQDN, there are a few things to think about, such as environment names, product names, service names, datacentre/cloud-service-provider and region. Team name might be something to consider but these tend to change often and handing over a service or a product from one team to another make this option less favourable.
Putting all together:
(product-name).(region).(env).(aws|azure|gcp|on-prem-dc-name).(cloud|onprem).organisation.tld
You may not need to include all these details but being consistent with the number of dots would make managing any conditional forwarders and fault finding easier. If you have a variable number of environments and the automation to create and destroy these on demand or provide region specific products, it would make more sense to re-arrange some parts of the FQDN to (env).(product-name). (region).(aws|azure|gcp|on-prem-dc-name).(cloud|onprem).organisation.tld
Question Three: What tooling should I think about for the internal domain?
DNS records are infrastructure resources after all; Infrastructure as Code is a good fit to programmatically create and manage these. The use of version control means that everyone can review these, new starters can get a good insight on what services are being managed, and contributions can be made with a simple pull request. Terraform is my personal default choice for this, however, you may need to build your own custom provider or use your infrastructure vendor specific tools if terraform is not supported by your existing DNS service.
Managing DNS using IaC unlocks the ability to automate failovers, automate TLS certificate renewal, deploy using Blue/Green or Canary if your cloud DNS Provider supports that and any being able to stand-up an environment without manual actions.
