DNS Records – Best Practice

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. Are you in the market for a domain name? View our domain registration offers.

CNAME RECOMMENDATIONS

These records are heavily overused and abused. The basic rule is that a CNAME should never point to another CNAME. 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 ie 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.

• IETF Standards Written by ISC Contributors
• Wikipedia: Domain Name System
• IETF: DOMAIN NAMES – CONCEPTS AND FACILITIES
• IETF: DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION

Happy Hosting.