The DNS Records That Actually Matter

Every time I get access to a client's DNS zone for the first time, it's the same pattern: a handful of records from services that were tried once and never removed, an SPF record that hasn't been updated since a mail provider was switched two providers ago, and often a missing or wrong record for something that's quietly causing problems right now. DNS zones accumulate cruft because removing a record feels riskier than leaving it, even when nobody can say what it's for. Here's the short list I actually check, in the order I check it.

A and AAAA: the basics, but check both

The A record (IPv4) is rarely missing, but AAAA (IPv6) is often either absent or, worse, present and pointing at an address that no longer exists. A stale AAAA record means dual-stack clients try IPv6 first, fail, and fall back to IPv4, adding a delay to every connection. If you're not actively running IPv6, it's better to have no AAAA record at all than a wrong one.

MX and the mail-related TXT records

If the domain sends or receives any mail, MX records point to the mail server, and SPF, DKIM, and DMARC, all TXT records, govern whether mail sent as that domain is trusted. I've written about setting these up properly in more depth, but the check here is simpler: do these records still describe reality? An SPF record listing a mail provider that was migrated away from two years ago is actively harmful, it doesn't just fail to help, it can cause legitimate mail from the current provider to fail SPF alignment.

NS records: do they match what the registrar thinks?

It sounds basic, but it's worth confirming that the NS records returned by the zone itself match what the domain registrar has configured. A mismatch here, often left over from a DNS provider migration that wasn't fully completed, means some resolvers see the old provider's records and some see the new one, depending on caching, which produces exactly the kind of "it works for me but not for them" issue that takes hours to track down if you don't check this first.

dig NS example.com
whois example.com | grep -i "name server"

CAA: an easy one that's almost always missing

CAA (Certification Authority Authorization) records specify which certificate authorities are allowed to issue certificates for your domain. Almost nobody sets this, and it's one TXT-like record:

example.com.  CAA  0 issue "letsencrypt.org"

It doesn't prevent every certificate-related attack, but it closes off a category of misissuance from CAs you've never used, for the cost of one record that needs updating only if you change certificate authorities. Low effort, genuinely useful, and a record that signals whoever set up this zone was being thorough.

TTL: low while changing things, higher once stable

This isn't a record type, but it trips people up constantly. A low TTL (300 seconds, say) during a migration means changes propagate quickly if something needs to be rolled back. Once things are stable, a higher TTL (a few hours to a day) reduces query load on your DNS provider and slightly speeds up resolution for end users, since their resolvers cache the answer longer. The mistake I see most often is a permanently low TTL left over from a migration that finished months ago, harmless, but also a sign that nobody's gone back to clean up after the dust settled.

The actual habit worth building

None of these records are exotic, and none of this requires special tools beyond dig and a few minutes. The value isn't in any single record, it's in treating a DNS zone as something that should reflect current reality, not an archaeological record of every service that's ever touched the domain. When I finish a project that touched DNS, removing the now-unused records takes thirty seconds and saves the next person (often me) from wondering, months later, whether that mysterious TXT record is safe to delete.