DNS Record Types and What They Are For

An A record maps a name to an IPv4 address; an AAAA record (four times 32 bits) maps it to an IPv6 address. A name may have several of each: a resolver returns all of them, typically rotating the order, and clients take the first or race them. That is round-robin DNS, the cheapest load distribution there is — and the crudest, because DNS has no idea whether the addresses are alive. Real failover needs health-checked DNS (Load Balancers: L4 vs L7 and CDNs: The Networking View are what usually sit behind an A record).

Modern clients ask for A and AAAA at the same time and try IPv6 first with a short head start (Happy Eyeballs, RFC 8305), so publishing a AAAA that points at a host whose IPv6 is broken produces "slow to connect" rather than "cannot connect": each connection waits out the IPv6 attempt before falling back. Publish AAAA only for addresses you monitor.

A CNAME says "this name is another name; look that one up instead". www.engineer-atlas.dev CNAME engineer-atlas.dev means the resolver restarts the query for the target and returns both records. It is how you point at something whose address you do not control — a CDN, a hosted platform, a load balancer whose IPs change — and it is the correct tool for that.

The rule that bites: a name with a CNAME may not have any other records. The RFCs say the alias replaces the name entirely, and resolvers and servers enforce it. The zone apex (engineer-atlas.dev itself) must carry SOA and NS records, so it cannot be a CNAME. That is why you cannot simply point a bare domain at your CDN, and why every DNS provider offers a non-standard workaround — ALIAS, ANAME, "CNAME flattening" — in which the provider resolves the target itself and synthesises A/AAAA answers. Those work but are provider-side magic: the resolver sees plain address records with the provider’s TTL.

CNAMEs chain: www → site.platform.example → lb-42.cdn.example → .... Each link the resolver does not already have cached is another lookup, potentially against a different authoritative server. Three links can be three extra round trips on a cold cache. Chains also hide who is actually answering, which matters when the last link is another company’s zone with its own TTL and outages. Keep chains short and know where they end.

MX records say where mail *for* a domain is delivered: a priority and a host name (never an IP — the host must have its own A/AAAA). Sending servers try the lowest priority first and fall back. A domain with no MX record has mail delivered to its A record, which is almost never what you want; a domain that should receive no mail should say so with a null MX (0 .).

TXT records started as free-form notes and became the universal extension point. SPF (v=spf1 …) lists which servers may send mail claiming to be from the domain. DKIM publishes the public key that signs outgoing mail, at selector._domainkey.domain. DMARC at _dmarc.domain tells receivers what to do when SPF and DKIM fail. And every SaaS provider proves you own a domain by asking you to publish a random token in a TXT record — which is why real zones accumulate dozens of google-site-verification= strings. TXT answers are the ones most likely to exceed the UDP size and trigger the TCP fallback described in DNS: Why Names Need a Distributed Database.

NS records name the servers authoritative for a zone. They appear twice: in the parent zone (the delegation the registry holds) and in the child zone itself, and they should agree. When they do not, resolvers that started from the parent reach one set of servers and resolvers that cached the child’s NS reach another — the split-brain of DNS Failure Modes: What Each One Looks Like. Changing DNS providers means changing NS records at the *registrar*, not just in the zone, and the old provider must keep serving until the old NS TTL (often two days) has expired everywhere.

The SOA record is the zone’s header: the primary server, the administrator contact (with the @ turned into a dot), a serial that secondaries compare to decide whether to re-transfer the zone, refresh/retry/expire timers for those secondaries, and the minimum field, which since RFC 2308 means the negative-caching TTL. If your zone’s SOA minimum is 86400, every typo and every not-yet-created name is remembered as non-existent for a day.

SRV records (_service._proto.name) map a service to a priority, a weight, a port and a target host. They are DNS’s built-in service discovery: SIP, XMPP, LDAP, Minecraft and Kubernetes headless services use them. Web browsers never did, which is why HTTP still needs the port in the URL. The newer SVCB/HTTPS records fill that gap for the web and also advertise HTTP/3 support and ECH keys.

PTR records go the other way: from an address to a name, in the special zones in-addr.arpa (IPv4, octets reversed: 10.113.0.203.in-addr.arpa) and ip6.arpa (nibbles reversed). They are delegated by whoever owns the address block — usually your cloud or hosting provider — so you cannot set them in your own zone. Mail servers reject or downgrade mail from addresses whose PTR does not match their forward name; and sshd, syslog and some databases do reverse lookups on connect, which is why a broken reverse DNS makes logins take exactly one resolver timeout.

A TTL is the maximum time the world may serve the old answer after you change it. High TTLs (hours, a day) mean fewer queries to your authoritative servers, faster resolution for clients, and resilience if your servers are briefly down. Low TTLs (30–300 s) mean fast failover and fast migrations at the cost of more queries and more exposure to authoritative outages. Records that a failover system flips should be low; records that never change (NS, MX) can be high.

The migration playbook follows from the countdown. If the record currently has a 1-hour TTL, lowering it to 60 seconds does nothing for the next hour — caches holding the old record keep it, with the *old* TTL, until it expires. So: lower the TTL at least one old-TTL period before the change (a day before, if the old TTL was a day), make the change, verify from several resolvers, keep the old destination serving until the *new* low TTL has expired plus a margin for misbehaving caches, then raise the TTL again. Skipping the first step is the most common reason a "five-minute migration" takes a day.