Record types, TTL, and caching

What is actually stored in a zone

A zone is the set of records for a domain, and each record is a tuple of name, TTL, class, type, and value. The class is always IN for internet, so the type is the interesting part.

Two record types have rules people trip over constantly.

CNAME cannot coexist with other records at the same name. If www is a CNAME, it cannot also have an MX or a TXT record. The reason is mechanical: a CNAME means "this name is that other name", so any other record at the name would be contradictory.

That rule collides with the zone apex, the bare domain example.com, which must always carry NS and SOA records. Therefore the apex can never be a CNAME, which is unfortunate because CDNs and load balancers hand you a name rather than an address. Providers solved it with a nonstandard record, called ALIAS or ANAME or a flattened CNAME depending on the vendor, which behaves like a CNAME but is resolved by the DNS provider and served as a plain A record.

Reading a full answer

dig example.com MX

;; QUESTION SECTION:
;example.com.            IN  MX

;; ANSWER SECTION:
example.com.     3600 IN MX 10 mail1.example.com.
example.com.     3600 IN MX 20 mail2.example.com.

;; AUTHORITY SECTION:
example.com.    172800 IN NS ns1.example.com.

;; ADDITIONAL SECTION:
mail1.example.com. 3600 IN A 203.0.113.10

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; flags: qr rd ra

Four sections, each with a job. Question echoes what was asked. Answer holds the records that answer it. Authority names the servers responsible. Additional contains records the server volunteered because you will probably need them next, here the address of a mail server, which is called glue.

The MX preference numbers, 10 and 20, are a priority where lower is preferred, so mail goes to mail1 and falls back to mail2. And in the flags line, aa would mean the answer came from an authoritative server. Its absence here means this answer came out of a cache.

TTL and the caching layers

Every record carries a TTL (time to live) in seconds, which is permission to cache it for that long. TTL is the only propagation control DNS has, and it is where most operational surprises live.

An answer can be cached in several places at once:

Choosing a TTL is a straight trade.

- Short TTL, 60 to 300 seconds, means changes take effect quickly and every cache asks again often, which raises query volume and makes the authoritative servers a more critical dependency. - Long TTL, hours to a day, means fewer queries and better resilience if the authoritative servers go down, at the cost of slow changes.

Negative caching is the part people forget. An NXDOMAIN is also cached, for a duration set by the SOA record's minimum field. So creating a record that somebody already queried by mistake can appear to do nothing for a while, and the fix is to wait out the negative TTL rather than to keep recreating the record.

The phrase "DNS propagation" is misleading, because nothing is pushed anywhere. Authoritative servers are updated immediately, and the delay you observe is entirely caches expiring on their own schedules. Which gives the correct procedure for a planned change:

1. Days before, lower the TTL on the record to 300 seconds and wait for the old, longer TTL to expire everywhere. 2. Make the change. It now takes effect within about 5 minutes. 3. Keep the old target serving traffic for a while anyway, since some resolvers ignore TTLs and some clients cache indefinitely. 4. Once traffic to the old target stops, raise the TTL back up.

Skipping step 1 is why cutovers occasionally take a day to complete.

Two more behaviors worth knowing

Round robin and load distribution. A name can hold several A records, and a server may return them in a rotating order. Clients generally use the first, so this spreads load roughly. It is not load balancing, because DNS knows nothing about server health or capacity, and a cached answer keeps pointing at a dead server until the TTL expires. Real load balancing happens at layer 4 or layer 7, behind a single name.

example.com. 60 IN A 203.0.113.10
example.com. 60 IN A 203.0.113.11
example.com. 60 IN A 203.0.113.12

Reverse DNS maps an address back to a name using PTR records in the special in-addr.arpa zone, with the octets reversed, because names get more specific right to left while addresses get more specific left to right.

dig -x 93.184.216.34 +short

;; the query is really for 34.216.184.93.in-addr.arpa
example.com.

Reverse records are controlled by whoever owns the address block, not by whoever owns the domain, so they often do not exist or do not match. Mail servers check them as a spam signal, which is the main place a missing PTR record causes real trouble.