DNS Record Types and TTL Caching

Difficulty: Intermediate

Question

What are the common DNS record types (A, AAAA, CNAME, MX, NS, TXT, PTR, SOA)? How does TTL affect caching and migrations?

Answer

When you buy a domain and open the DNS panel at your registrar, you see a table of records. Each row is a small instruction telling the world something about your domain. Knowing what each type does is essential for anyone who has ever deployed a website, and it comes up in interviews for backend and DevOps roles constantly.

The A record maps a hostname to an IPv4 address, for example internhack.xyz to 203.0.113.10. The AAAA record does the same for IPv6 (the name is four times A because the address is four times longer). The CNAME record is an alias from one name to another name, such as www.internhack.xyz pointing to internhack.xyz or to a load balancer hostname like myapp-123.elb.amazonaws.com; the resolver then looks up the target's A record. Rules to remember: a CNAME cannot coexist with other records at the same name, and therefore cannot be placed at the zone apex (the bare domain), because the apex must also hold SOA and NS records. Providers work around this with ALIAS or ANAME flattening.

The MX record lists mail servers for the domain with a priority number, where lower means preferred; mail is delivered to the lowest number first and falls back to higher ones. The NS record names the authoritative name servers for a zone and is used for delegation. The TXT record holds arbitrary text and is widely used for domain ownership verification, SPF (which servers may send mail for you), DKIM public keys and DMARC policy. The PTR record does reverse DNS, mapping an IP back to a name, living under in-addr.arpa, and it matters for mail deliverability. The SOA record, start of authority, contains the primary name server, admin email, a serial number that changes with each update, and timers for zone transfers. There are also SRV records (host and port for a service), CAA (which certificate authorities may issue certificates for the domain) and NS glue records.

Now TTL, time to live, in seconds. Every record carries one, and it tells resolvers and clients how long they may cache the answer before asking again. A TTL of 3600 means up to an hour. High TTLs mean fewer queries, lower latency and less load on your name servers, and more resilience if your DNS provider is briefly down. Low TTLs mean changes propagate quickly but there are more queries.

This leads to the classic real-world scenario: you are migrating a website to a new server with a new IP. If the A record has a TTL of 86400 (a day), some users will continue to hit the old IP for up to 24 hours after you change it. The professional approach is to lower the TTL to 300 seconds a day or two before the migration, wait for the old TTL to expire everywhere, make the switch, verify, and then raise the TTL again. People call this DNS propagation, but nothing is really propagating: it is simply many independent caches expiring at different times. Some ISP resolvers ignore low TTLs and enforce a minimum, and browsers and operating systems have their own caches.

A few edge cases worth mentioning: multiple A records for the same name give round-robin DNS, a crude load balancing that has no health checking; negative answers are cached according to the SOA minimum field; and dig is the tool of choice for debugging, with dig +short for the answer, and dig @8.8.8.8 to bypass your local resolver and compare results.

Code examples

Querying record types with dig

$ dig +short A internhack.xyz
203.0.113.10

$ dig +short MX gmail.com
10 alt1.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.

$ dig +short TXT internhack.xyz
"v=spf1 include:_spf.google.com ~all"

$ dig www.example.com | grep -A1 'ANSWER SECTION'
www.example.com.  3600  IN  A  93.184.216.34

The 3600 in the last output is the TTL still remaining in seconds; it counts down as you re-run the query against a caching resolver.

Key points

Concepts covered

DNS Records, A and AAAA, CNAME, MX, TTL