DNS record types explained

DNS is a distributed database, and a record type is simply the kind of answer you are asking for. Query the same name twice with different types and you get entirely different results — which is why "the DNS is broken" is rarely a useful description of a problem.

The records that point at machines

A and AAAA

An A record maps a name to an IPv4 address; AAAA does the same for IPv6. They are the records almost everything ultimately resolves to.

A name can hold several of each. Resolvers hand them out in varying order, which is a crude but genuinely used form of load distribution. If a site works for some people and not others, multiple A records with one bad address is a classic cause — and one you can see immediately by checking the record rather than the site.

CNAME

A CNAME points one name at another name rather than at an address. The resolver follows the chain until it reaches an A or AAAA record.

The rule that catches people out: a CNAME cannot coexist with any other record at the same name. That makes it illegal at a root domain, which must also carry NS and SOA records. Providers work around this with ALIAS or ANAME records, which resolve like a CNAME but return an address in the answer so the restriction does not apply.

The records that route mail

MX

MX records name the servers that accept mail for a domain, each with a priority number. Lower numbers are tried first; equal numbers are balanced between. The priority is a preference, not a ranking of quality, and the numbers themselves are arbitrary — 10 and 20 are conventional, but 1 and 2 work identically.

An MX record must point at a name, never at an IP address. A record pointing straight at an address is a common misconfiguration that some receiving servers tolerate and others reject outright.

TXT

TXT records hold free text, and mail authentication has made them one of the busiest record types on most domains:

• SPF — lists which servers may send mail as your domain. One SPF record per domain; a second one invalidates both.
• DKIM — publishes the public key that signs your outgoing mail, on a selector subdomain.
• DMARC — at _dmarc.yourdomain, tells receivers what to do when SPF and DKIM fail.
• Domain verification — the strings services ask you to add to prove you control the domain.

When mail is being rejected for authentication rather than routing, TXT is the record to read.

The records that describe the zone

NS

NS records name the authoritative servers for a domain — the servers that hold the real answers. They exist in two places: at the registry, which is what the world follows, and inside the zone itself. When those two disagree, changes appear to take effect for some people and not others, which is one of the more confusing failure modes in DNS.

SOA

The SOA record — start of authority — carries the zone's administrative settings: the primary nameserver, a contact address, a serial number, and the timers governing how secondaries refresh and how long a negative answer may be cached.

The serial number is the field worth knowing. Secondary servers only pull a new copy of the zone when the serial increases. A change that will not propagate, on a zone with secondaries, is very often a serial that was never incremented.

CAA

CAA records restrict which certificate authorities may issue certificates for your domain. Authorities are required to check them before issuing. With no CAA record, any authority may issue — so adding one narrows the set of parties who could mistakenly or maliciously obtain a certificate in your name.

Which record answers which problem

TTL, and why changes seem slow

Every record carries a time to live: how long a resolver may cache the answer. A record with a TTL of 3600 can legitimately be served from cache for an hour after you change it, and there is no way to force that cache to clear.

The practical technique is to lower the TTL before a planned change — to 300 seconds, say — wait out one full period of the old value, make the change, then raise it again. Doing it the other way round achieves nothing, because the old TTL is what governs the copies already cached.

You can read the current records and their TTLs with the DNS checker, and compare what several public resolvers are answering with the DNS propagation checker — which is how you tell a change that has not spread from one that never applied.