DNS Records - Best Practice to Keep DNS Zones Fast

TL;DR

Avoid overusing CNAME records — and never point CNAMEs to other CNAMEs
Keep subdomains simple to reduce DNS lookup overhead
Multiple A records pointing to the same IP are allowed and encouraged
Modern TTL values should balance performance and propagation speed
Structure DNS zones logically to improve reliability and maintenance

Although the basics of DNS records is easy to understand, I often see badly configured DNS zones. Here are a few pointers to help keep that DNS pure and fast according to industry best practice.

CNAME Recommendations

These records are heavily overused and abused. The basic rule is that a CNAME should never point to another CNAME. And the following records should never point to a CNAME: NS, CNAME, MX, PTR, NAPTR, and SRV. The reasoning behind this is simple.

It is very easy to get a circular reference or DNS loop if you point a Reference RR (Anchor Referring) to another Reference RR. These RR's should always point to an Anchor (A) RR (an A record). If you don't really need CNAME, do not use it. It is a slower record to look up than a direct A record and can lead to errors.

Dot Separation Frenzy

Avoid using dots to separate sub-domains ie. server1.cab3.row2.dc5.jhb.mydomain.com. Each dot represents another lookup for a DNS server. If for example, server1.cab3.row2 is missing in the DNS records, it would take 4 lookups before returning an error.

A faster structure would be server1-cab3-row2-dc5-jhb.mydomain.com. This would return an error on the first lookup with the missing DNS and also translate into a hostname easily.

Multiples Allowed

One of the often cited reasons for using CNAME for everything pointing to the domain root A record is "I don't want to have multiple entries of the same IP. Not only is this allowed, it is encouraged.

You can point multiple hosts to the same IP, but you may also have different IP addresses for the same host entry. This is usually used in load balancing or when Geo-Fencing DNS (like Google does).

DNS TTL (Time To Live) Values

This is the amount of time (usually in seconds) before a record expires, is regarded as stale or is checked for change. The standards (written a long time ago in 1987) suggest 86,400 seconds (1 day) as the minimum default TTL.

Modern DNS servers can handle far more queries at a far higher rate than in 1987. TTL values have not kept up and still reflect archaic practices of the eighties and nineties when the typical server had less computing power than an entry-level cell phone of today.

If you set the value too low, your server will get loaded down with lots of repeat requests. Setting it too high means that the information you change will not get distributed in a reasonable amount of time. If you leave the TTL field blank, it will default to what is specified in the SOA record for the zone.

A reasonable modern TTL is 86,400 seconds for your longest value and down to about 300 seconds (5 minutes) for the shortest. Shorter values help to pick up changes quicker, but will also be removed from DNS caches more quickly.

The latest recommendation for SOA (Start Of Authority) TTL values is:

example.com.  3600  SOA  dns.example.com. dnsmaster.example.com. (
                         2018012301   ; serial YYYYMMDDnn
                         86400        ; refresh (  24 hours)
                         7200         ; retry   (   2 hours)
                         3600000      ; expire  (1000 hours)
                         172800 )     ; minimum (   2 days)

Dynamic zones i.e. load-balanced hosts or failover hosts need shorter TTL times and can even be down to 120 seconds, but this is very seldom needed or used.

Most load-balanced hosts use 5 minutes as a TTL or a moving static IP (sounds like a contradiction). This is when a single IP that is assigned to a domain is moved from a host that is down to the failover host. These mechanisms are usually a lot faster than DNS failover.

Summary

Take care if you construct your own DNS zone. Make sure that your records are in logical order and grouped - the usual order is:

SOA *
NS (at least 2) *
A *
AAAA (if any)
MX
CNAME
TXT
SRV

Records with an asterisk(*) are a must in a normal Forward Lookup Zone. All other records are optional. Keeping this order will make all Systems Administrators far happier when helping you with any issues.

Frequently Asked Questions

Why should CNAME records not point to other CNAMEs?

Because chained CNAMEs increase lookup time and can create circular references or DNS loops, leading to failures and hard-to-debug issues.

Are multiple DNS records pointing to the same IP a problem?

No. This is a standard practice and is often used for load balancing, redundancy, and geo-based routing.

What is a good TTL value for most DNS records?

For most setups, 86,400 seconds for long-lived records and 300 seconds for frequently changing records is a good balance.

Do shorter TTLs improve website performance?

Not directly. Shorter TTLs improve how quickly changes propagate, but they increase DNS query volume and cache misses.

How important is DNS record order?

While DNS technically works regardless of order, keeping records structured and grouped makes zones easier to manage and troubleshoot.

Happy Hosting.