The Limitations of DNS A-Records
Last updated October 16, 2020
Table of Contents
DNS A-records can be used to configure zone apex domains (also called bare, naked, or root domains). These records have serious availability implications when used in environments such as on-premise data-centers, cloud infrastructure services, and platforms like Heroku.
For maximum scalability and resiliency applications should avoid using DNS A-records and instead use a DNS provider that supports CNAME functionality at the apex, or use sub-domains exclusively.
Limitations
DNS A-records require that an IP address be hard-coded into your application’s DNS configuration. This prevents your infrastructure provider from assigning your app a new IP address on your behalf when adverse conditions arise and can have a serious impact to your app’s uptime.
A CNAME record does not require hard-coded IP addresses and allows Heroku to manage the set of IPs associated with your domain. However, CNAME records are not available at the zone apex and can’t be used to configure root domains.
Supported apex domain configurations
There are two approaches available to serve traffic from the root domain while preserving the ability of your provider to manage your apps’ IP addresses: using a DNS provider that supports CNAME-like functionality at the apex, and using subdomain redirection.
Providers which support CNAME-like functionality are listed in the Custom Domains article.
SSL
Traffic routed over SSL behaves, at the DNS level, identical to unencrypted traffic and suffers from the same naked domain A record availability issues for on premise and cloud deployments.
However, applications requiring SSL encryption should use the ALIAS/ANAME configuration on the root domain. Subdomain redirection will cause a browser error when the root domain is requested over SSL (i.e. https://example.com).