One of the most consistently under-recognized operations in preparing to launch a new web application, particularly if migrating from an old one, is managing DNS (domain name system) concerns.
DNS is an essential component of the Internet which allows users to see a “friendly” name (e.g. “spin.atomicobject.com”) when visiting a website or application instead of the much more complex address describing where it is actually hosted (e.g. “d21y6hrjhhoswm.cloudfront.net” or “13.33.164.166”). Finding an appropriate DNS hosting provider ahead of an application launch is critical. If handled improperly, it can substantially delay or disrupt a launch.
Domain Registrar vs. DNS Hosting
Frequently, domain registrars and DNS hosting providers are conflated. While they are often purchased together, they can operate independently.
The domain registrar usually provides some basic DNS hosting as a complimentary service to customers. The registrar is the authority that manages the reservation of domain names and registers the name servers for that domain with the appropriate top-level domain (TLD) name servers (e.g. the name servers for “.com”).
The DNS hosting provider, in contrast, is the provider of the actual name servers for a domain. The hosting provider holds the authoritative DNS records for the domain. These are queried by other name servers and clients on the Internet when attempting to resolve the ultimate address of a domain name.
Selecting a DNS Hosting Provider
Arguably, the DNS hosting provider is more important than the domain registrar. Not all DNS hosting providers are equal. Some support different types of DNS records, larger numbers of queries, and health checking with failover records. Generally, these factors provide for much greater differentiation between DNS hosting providers than domain registrars.
Record Types
Certain types of DNS records may be required for certain web applications. For example, to use custom domains for a Heroku-hosted application, it is often desirable to access the application using the apex domain (i.e. atomicobject.com instead of www.atomicobject.com). Heroku does not assign unique IP addresses to individually hosted applications. In place, it provides a domain name which is typically mapped from the custom domain with a CNAME record. However, CNAME records are not available for apex domains (per RFC), and an A record cannot be readily used because the IP addresses named by the Heroku domain name may change at any time.
Instead, you need a special record called an ANAME or ALIAS record. Many DNS hosting providers do not support these record types. In order to host an application at Heroku using a custom apex domain, you must select a DNS hosting provider that supports them.
Query Volume
DNS hosting providers can only support a limited number of queries. For a high-traffic application, reaching this limit may cause disruption to name resolution for domain records, resulting in an outage.
Hosting providers often provide tiers of service for varying numbers of hosted records and queries. It is important to select a provider and plan which support the needs of the web application.
While higher time-to-live (TTL) values for records can generally reduce the number of queries being directed to DNS name servers, using lower TTL values in preparation for a launch or migration can substantially increase the total number of queries for a period of time. It’s a good idea to include a sufficient buffer in your calculations to prevent reaching query limits during periods of transitioning records.
Failover Records
Web applications and their underlying infrastructure are frequently subject to failures. Some of these can be handled gracefully by the application or infrastructure itself (e.g. a maintenance page), while others cannot (e.g. core router failure).
Typically, DNS records are viewed as static—always resolving to the same address. However, some hosting providers support dynamically changing records based on multiple factors, including availability.
These hosting providers allow the creation of a health check which monitors the availability of the web application whose records it is hosting. If the application or hosting infrastructure cannot be reached, a different set of records can be returned. These failover records resolve to a different address which provides an alternate or backup instance of the web application. For example, it may show a pre-rendered, static copy of a dynamic website.
Conclusion
Often neglected until the last minute, domain registration and DNS hosting are important factors when preparing to launch or migrate a web application.
Going to the most popular domain registrar, picking out a domain name, and utilizing complimentary DNS hosting is one option. However, most modern applications require more features from DNS hosting providers to make launch and continued operations smooth and successful.