The Limitations of DNS A-Records

Last updated 09 September 2015

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.

Both approaches are discussed in the custom domains article: Configure an apex domain for your app

SSL

Traffic routed over SSL behaves, at the DNS level, identical to unencrypted traffic and suffers from the same naked domain limitations.

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).