Home › Guides › DNS Records Explained

DNS Records, Explained

DNS records are the building blocks of how the internet finds anything by name. This guide walks through every common record type, explains what they're for, and shows how to verify them in production with the WhereIsDNS lookup tool. Use it as a reference when you're setting up a new domain, migrating to a new DNS provider, or chasing down a propagation issue.

What DNS actually does

DNS — the Domain Name System — is a globally distributed key-value store. Names like example.com map to one or more answers: an IP address, a mail server, a key, a policy, or a pointer to another name. Every time your browser, app, or operating system needs to talk to something on the internet, it asks a recursive resolver for the relevant record, the resolver walks the DNS hierarchy if needed, and returns the answer.

The "globally distributed" part is what makes DNS interesting. There's no central database and no single source of truth — the answer to "what's the A record for example.com?" depends on who you ask, what they have cached, and how recently the authoritative source was updated. Most DNS troubleshooting is really troubleshooting caching.

The records you'll actually use

There are dozens of DNS record types, but a handful do most of the real work. Here's how the common ones break down by purpose.

Addressing — A, AAAA, CNAME

These three answer the question "where do I connect?"

• A records map a hostname to an IPv4 address. The most common record type on the public internet. A domain can have multiple A records — most clients pick one at random, giving you simple round-robin load balancing for free.
• AAAA records are the IPv6 equivalent. Modern services publish both A and AAAA so dual-stack clients can use whichever protocol works. Most clients prefer IPv6 when available, falling back to IPv4 via "Happy Eyeballs."
• CNAME records point one hostname at another. When the resolver sees a CNAME it has to do a second lookup against the target. CNAMEs are how you point a custom subdomain (www, app) at a managed service like a CDN or SaaS app. CNAMEs cannot exist at the apex of a zone, and a hostname with a CNAME can't have any other records.

Email — MX, TXT (SPF/DKIM/DMARC), PTR

Email is its own infrastructure on top of DNS. Four record types do the heavy lifting.

• MX records tell sending mail servers which host accepts incoming mail for your domain. Each MX has a priority — lower is preferred, higher is fallback. After switching email providers (Google Workspace, Microsoft 365, Fastmail), checking MX from multiple resolvers is the first thing to do.
• TXT records hold free-form text and carry the entire email-authentication stack: SPF (which servers can send mail), DKIM (cryptographic signature on outgoing mail), and DMARC (policy for what to do when SPF or DKIM fails).
• PTR records are reverse DNS — they map an IP back to a hostname. Many receiving mail servers reject mail from IPs without proper PTR records, so anyone running an outbound mail server needs to set this up.

Delegation and authority — NS, SOA

These two define the structure of a DNS zone.

• NS records say "these are the authoritative nameservers for this zone." Changing NS records at the registrar is what moves a domain from one DNS provider to another. NS changes propagate slowly because the parent zone (the TLD) typically uses long TTLs — 24 to 48 hours is normal.
• SOA records sit at the apex of every zone and carry administrative metadata: primary nameserver, contact email, and zone-wide timing parameters including the all-important minimum TTL for negative (NXDOMAIN) caching.

Security — CAA, DNSKEY, DS

Three record types that exist to harden the DNS chain itself.

• CAA records tell certificate authorities which of them are allowed to issue TLS certificates for your domain. A CAA record like 0 issue "letsencrypt.org" blocks every other CA from minting a cert for your domain — even if they're tricked into validation.
• DNSKEY records publish a zone's public key for DNSSEC, which lets resolvers verify that DNS answers haven't been tampered with.
• DS records live at the parent zone and contain a hash of the child's DNSKEY. They're the link in the DNSSEC chain of trust between a zone and its parent. A common pitfall: enabling DNSSEC at the DNS provider but forgetting to upload the DS record at the registrar — the chain breaks and validating resolvers return SERVFAIL.

Service binding — SRV, HTTPS, SVCB

These records describe how to reach a service, not just where.

• SRV records let a service publish a host + port for discovery — used by SIP, XMPP, Microsoft 365 autodiscover, Minecraft servers, and many more. Queried at _service._proto.host.
• HTTPS records are the modern (RFC 9460) way to advertise a service's capabilities — ALPN protocols, alternate ports, Encrypted Client Hello (ECH) public keys. Browsers use HTTPS records to upgrade to HTTP/3 without an Alt-Svc round-trip.
• SVCB records are the generic version of HTTPS — same wire format, different type code. For service binding on protocols other than HTTPS.

How DNS propagation actually works

When you change a record at your DNS provider, the change is live at the authoritative nameserver immediately. But the world doesn't see it immediately, because every recursive resolver between you and the world is still serving its cached copy. The cache lifetime is the record's TTL, set when you publish it.

Practical implication: plan changes around TTL. Lower the record's TTL well before the change (24 hours in advance is standard for stable records), make the change, watch propagation in real time, then raise the TTL back up afterward. WhereIsDNS shows how 12 different public resolvers see your record — once consensus is reached across operators in different regions, the change is essentially "global."

Some ISP resolvers ignore short TTLs and cache aggressively. There's no way to force someone else's resolver to drop its cache early — you can only wait it out, or contact the operator if it's truly stuck.

Common problems and how to diagnose them

Most DNS issues fit a small number of patterns. The pattern is usually visible from a propagation check across multiple resolvers.

• Most resolvers say NXDOMAIN, a few say "ok" → the record was just created. Cached negative responses haven't expired yet. Wait one minimum-TTL window (typically the SOA minimum, often 1 hour).
• Most resolvers say "ok," a few say NXDOMAIN → those resolvers cached a stale "doesn't exist" answer from before the record existed. Same fix: wait it out.
• All resolvers return the same answer, but you expected something different → either you're editing the wrong zone (check NS records to confirm which DNS provider is authoritative), the change didn't actually save, or you're looking at the wrong record type.
• Different resolvers return different IPs, all of which look "yours" → probably GeoDNS doing its job: returning region-specific answers. Not a bug.
• Resolvers return SERVFAIL → DNSSEC validation failure, broken delegation ("lame delegation"), or the authoritative nameservers are unreachable. Check the DNSKEY against the parent's DS records.

Where to go from here

• Run a propagation check on the home page: WhereIsDNS lookup tool.
• Skim the DNS glossary for term-by-term definitions.
• Hit the per-record-type pages directly when you know what you're checking — start with A, MX, or TXT.