DNS record types, explained

If a site is unreachable and the domain is registered and delegated, the A record is the first thing to look at. Changing it is how a site moves hosts, and because resolvers cache the old answer for the length of its TTL, the move is not instant for everyone. Multiple A records on one name are normal and give a simple form of load spreading.

A name can carry both A and AAAA records, and clients on IPv6 networks will usually prefer the AAAA. That makes a stale or wrong AAAA a nasty failure mode: the site works for most people and is broken for everyone on IPv6, which looks like an intermittent fault rather than a DNS error.

CNAME is how you hand a name over to a service whose addresses you do not control, which is why CDN and SaaS setup instructions almost always ask for one. Two rules trip people up: a name with a CNAME may hold no other records, and that includes MX, so a root domain carrying mail cannot be a CNAME. Providers work around the second with proprietary flattening at the zone level.

No MX record means no inbound mail, and the bounce a sender gets will usually blame the recipient rather than the zone. MX records are also the first casualty of a hosting migration, because moving a site's A record at a provider that manages the whole zone can quietly take the mail with it. The priority numbers are preference only: they have no effect on delivery order beyond which host is attempted first.

NS records are the one part of DNS that lives in two places: at the registry, set through your registrar, and inside the zone itself. When those two disagree, resolution becomes unpredictable in ways that look random. Changing nameservers is the single most disruptive DNS change you can make, because it hands the entire zone to a different provider at once. If the new provider does not already hold a copy of every record, the ones you forgot disappear the moment delegation changes.

SPF, DKIM and DMARC are all published as TXT records, as are most domain ownership verifications. Because anything can be stored there, a zone accumulates them, and old verification strings from services you no longer use are the commonest zone clutter. Two live SPF records or two DMARC records at the same name are worse than clutter: receivers apply neither, so the policy silently stops working.

You rarely edit an SOA, but it tells you things nothing else does. Its serial number changes whenever the zone is edited, so comparing serials across nameservers shows whether they are in sync. Its negative caching TTL decides how long a resolver remembers that a name does not exist, which is why a newly added record can appear to be ignored for longer than its own TTL would suggest.

CAA is a cheap and underused control against mis-issuance: with one in place, a CA that is not named must refuse. The trade-off is operational. If you add a CAA for one provider and later move to another, issuance fails with an error that points at the CA rather than at your zone, and renewals break at the worst moment. Include every authority you actually use, including the one behind your hosting platform.

SRV lets a client discover where a service runs without the port being hardcoded, which is how SIP, XMPP and various Microsoft services find their endpoints. Its name format is strict and easy to get wrong, and a typo in the service or protocol label produces a record that resolves to nothing rather than an error.

The DS record is the link in the chain of trust, and it is the only DNS record that does not live in your own zone: you hand it to your registrar, the registry publishes it above you. That split is why DNSSEC breaks the way it does. Move DNS provider and the new provider signs with a new key, but the old DS record is still pointing at the old one, so every validating resolver concludes the answers are forged and refuses them. The domain does not resolve slowly, it stops resolving, and only for the roughly a third of the internet behind a validating resolver, which makes it look intermittent. The safe order is to publish the new key, add the new DS record, wait for the old one to age out of caches, and only then retire the old key.

Nothing is actually propagating: authoritative servers have the new value immediately, and every other resolver keeps the old one until the TTL it was handed expires. That is why lowering a record's TTL a day before a planned change is the only thing that genuinely shortens the window, and why checking from one machine tells you almost nothing. Compare several independent resolvers instead.