As well as providing a more friendly and memorable address for a website, using DNS names also gives a number of other advantages:
Changing backend systems
Keeping a consistent DNS name allows you to re-point to a different backend system at any point without users needing to be aware of the change. This could be a major change such as a move to a new data center, or short-term changes such as pointing to a DR system or to an updated version of the system as part of a deployment process.
Multiple backend systems
DNS names can be used to obscure that there are actually multiple systems delivering the same system. This could be done on a very simple level where each user is given a selection from a list of available systems, or it could be done more intelligently based on things such as geographical location.
These advantages provide a lot of benefits when looking at the world in a dynamic DevOps or cloud-based system. In this world the physical, IP-based servers that are actually delivering systems are ever changing as systems are automatically created and destroyed on demand, meaning that the easiest way to address systems is by taking advantage of the flexibility that DNS provides.
Considerations and Risks
Of course, there are also downsides to using DNS as a proactive element of your DevOps culture. As with any other tooling/methodology choices, these need to assessed in terms of the benefit/risk trade- off they provide.
Speed of Change
Speed of change is an element that is often raised as a reason not to use DNS for any change that you want to be as close to instant as possible.
As mentioned above, the amount of time a DNS record is cached is determined by the TTL. This is within your control.
By setting a low TTL, you can specify that you don’t want the record to cache for long. However, there are two potential “gotchas” with this:
- Having a low TTL increases the amount of DNS lookups that are happening. This impacts performance for the end user as there is overhead associated with that request and increased overhead on your DNS provider. If your DNS provider cannot cope with that, then it can affect the speed and reliability of DNS resolution. If taking this approach, it is essential that you select a resilient DNS provider that is equipped to handle high throughput of requests.
- Some DNS resolvers do not honor TTL values below 30 seconds. In this case, even if you set a TTL below 30 seconds, the resolution would remain cached for 30 seconds.
On top of the TTL, there is also some additional time to complete the other actions associated with DNS updates:
- Time taken to accept the update and update the record on the central Authoritative server
- Time taken to distribute that update to all other distributed Authoritative servers
These values will be determined by the infrastructure and systems used by your DNS provider, and it is worth analyzing them to determine how long updates take to take effect. If longer than expected, then trial other providers to see if they can make changes more quickly.
Another Point of Failure
Others point to relying on DNS as being another point of failure, another element that has to be managed and therefore can go wrong. It is also pointed out that if IP addresses are used, they will carry on working even if the DNS system fails.
This is true; however, in the extremely unlikely situation where the DNS system was to fail, the entire internet as we use it today would be unusable. DNS is the ubiquitous glue that is the basis for most internet-based communications.
For this reason, DNS is a highly distributed system that is fault tolerant (but like any other system it is not infallible) and built that way from the ground up.
For most usages, the flexibility gained by using DNS outweighs the additional overhead and risk of adding that potential point of failure.