AWS CloudLinux

Use of DNS and Common DNS Record Types

In this blog we discuss the use of DNS and Common DNS Record Types:

What is DNS?

Domain Name System (or Service or Server), an Internet service that translates domain names into IP addresses. Because domain names are alphabetic, they’re easier to remember. The Internet however, is really based on IP addresses. Every time you use a domain name, therefore, a DNS service must translate the name into the corresponding IP address. For example, the domain name might translate to

The DNS system is, in fact, its own network. If one DNS server doesn’t know how to translate a particular domain name, it asks another one, and so on, until the correct IP address is returned.

The basics of creating A records (which translate a hostname to an IP address) are simple enough
TTL (Time to Live) is a setting for each DNS record that specifies how long a resolver is supposed to cache (or remember) the DNS query before the query expires and a new one needs to be done.

The benefits of caching are pretty obvious: it’s a lot faster to check your local resolver’s cache then having to look up a DNS record that isn’t already cached. This speed up your Internet experience when visiting a site you go to often (since less time is needed to complete DNS lookups) and also helps lower the load on DNS servers around the world.

What happens when the DNS record changes?

This is where the potential downside of caching becomes evident. If a DNS record is cached, then a new lookup is not done until that cache expires. Thus that resolver that has the cached record won’t have any way to find out about the changed record until its cache expires.

When you hear someone mentioning they are waiting for DNS to propagate, they are waiting for cached DNS records to expire at all of the different resolvers that previously looked it up. If you have a 1-day TTL on a record, which means it would take a full day for any change to propagate around the world.

When specifying Time To Live (TTL) you should be aware of the following important factors:

•    The higher the TTL, the less frequently caching name servers need to query authoritative name servers.
A higher TTL reduces the perceived latency of a site and decreases the dependency on the authoritative name servers.
•    The lower the TTL, the more frequent updates are propagated to other name servers.

If you’re going to make DNS changes, we suggest lowering the TTL to make the changes. If you’re using DNS for failover, then lowering the TTL is a good idea as it takes less time to fail-over to another server.

Generally, we recommend a TTL of 24 hours (86,400 seconds). However, if you are planning to make DNS changes, you should lower the TTL to 5 minutes (300 seconds) at least 24 hours in advance of making the changes. After the changes are made, increase the TTL back to 24 hours.

Note: If DNS is used for failover, then you should probably keep the TTL at approximately 5 minutes all the time.
Common DNS Record Types:

A or AAAA Record – Usually a 1 hour TTL is a good compromise between enabling fast changes while taking advantage of DNS caching while someone is visiting your site. If changes to this record are often or need to happen quickly in an emergency, you can usually set it as low as 30 seconds.

DNS features

such as Active Failover, Load Balancing, and GSLB, you can set the TTLs between 30 seconds and 5 minutes. For non-critical records that rarely – if ever – will need to change, you may be able to get away with having a TTL in the 12 hours to 1-day range.

CNAME record – In many cases, a CNAME record will never be modified (ex. pointing to’s A record). In those scenarios, a 12 hour to 1 day TTL is a good compromise as the benefits of caching outweigh the need for a faster propagation time. If your CNAME record could potentially change (such as if you are using a CDN), you will want to a have a lower TTL.

MX Record – MX records rarely, if ever, change, especially if you are using an email provider with a good track record or you have lots of redundancy when self-hosting. You can usually set this to a 12 hour or 1 day TTL. If you want to ensure faster propagation times in the event of an emergency, a 1 to 4 hour TTL is a good compromise.

TXT Records – Most commonly used for SPF or DKIM records. Usually safe to set in the 1 hour to 12-hour range since they rarely change. In the end, keep in mind that what you set the TTL to is what you are most comfortable with. It is all about striking a reasonable balance between a fast propagation time and taking advantage of DNS caching.

Related Articles

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Adblock Detected

Please consider supporting us by disabling your ad blocker
%d bloggers like this: