DNS Record Types, Explained

Every time you open a site, send an email, or connect to a server, your device quietly asks DNS a question: where does this name actually live? The answer comes out of a zone file — a plain-text list of entries called resource records. Each record is a small instruction: point this name at that address, send this domain's mail there, prove I own this, treat my signatures as valid.

There are a few dozen record types, but you only meet a handful in day-to-day work. This guide walks through the ones that matter, what each is for, the syntax, and the mistakes that bite people. You can run any of them against a real domain with the all-records lookup as you read.

The shape of a record

Strip away the type-specific detail and every record is the same five fields, defined back in RFC 1035:

A single line looks like this:

example.com.        3600    IN    A    93.184.216.34

One trap worth knowing before you touch a raw zone file: the trailing dot. A fully-qualified name ends with a dot (app.example.com.) that marks the DNS root. Leave it off in a raw zone and the server helpfully appends the origin, turning app.example.com into app.example.com.example.com. Most hosting dashboards hide this from you; raw zone edits do not.

Pointing a name somewhere: A, AAAA, CNAME

The everyday job of DNS is turning a name into a destination.

An A record maps a name to a 32-bit IPv4 address; an AAAA record does the same for a 128-bit IPv6 address. Both may appear at the domain apex, and you can list several of each — resolvers rotate the order (round-robin) for basic load spreading, though plain DNS has no idea whether a server is actually up.

example.com.        3600    IN    A       93.184.216.34
example.com.        3600    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Most serious sites run dual-stack — matching A and AAAA on the same host. Modern clients try IPv6 first and fall back to IPv4 if it stalls (the "Happy Eyeballs" algorithm), so you get IPv6 reach without stranding anyone.

A CNAME is different: instead of an address it points at another name, and the resolver starts its lookup over at that target. It is the right tool for aliasing a subdomain onto a CDN or SaaS host:

shop.example.com.    3600    IN    CNAME    shops.myshopify.com.

Two rules save a lot of grief. A CNAME cannot sit at the apex (example.com), and it cannot coexist with any other record for the same name. The apex must already carry SOA and NS records, so a CNAME there breaks the zone — mail stops, transfers fail, traffic drops. When you need apex-level aliasing, managed providers offer ALIAS / ANAME / CNAME-flattening: not real record types, but the provider resolves the target's A/AAAA at query time and hands back plain addresses, keeping the zone valid.

Who is in charge: NS and SOA

Two records decide who answers for a zone and how that answer is kept in sync.

NS records delegate a zone to its authoritative name servers. The root delegates .com, .com delegates example.com, and you can delegate a subdomain like dev.example.com onward to a separate server.

example.com.        86400    IN    NS    ns1.dnsprovider.com.
example.com.        86400    IN    NS    ns2.dnsprovider.com.

Glue records. If a zone's name servers live inside that same zone (delegating example.com to ns1.example.com), you get a chicken-and-egg problem: you need the zone to find the name server that serves the zone. The parent breaks the loop by storing glue — plain A/AAAA records giving the name server's IP directly alongside the delegation.

Every zone also carries exactly one SOA record at its apex, holding the zone's metadata and the timers that govern replication to secondary servers:

@   IN   SOA   ns1.example.com. admin.example.com. (
              2026072401 ; serial (YYYYMMDDnn) — bump on every change
              7200       ; refresh — how often secondaries check in
              3600       ; retry — wait after a failed check
              1209600    ; expire — stop serving if the primary vanishes
              3600       ; minimum — how long an NXDOMAIN is cached
              )

The two names at the top are the primary server (MNAME) and the admin's email with the @ written as a dot (RNAME) — so admin.example.com means [email protected]. The serial is the one field you touch by hand: secondaries only pull a fresh copy when it goes up, so forgetting to bump it is a classic "why won't my change propagate" bug.

Getting mail to the right place: MX and TXT

MX records route inbound email. Each points at a mail server hostname (never an IP, never a CNAME) and carries a priority — lower numbers are tried first:

example.com.    3600    IN    MX    10  mail-primary.example.com.
example.com.    3600    IN    MX    20  mail-backup.example.com.

If the priority-10 server is unreachable, senders fall to priority 20. Equal numbers share the load.

The TXT record started life as a place for free-form notes and quietly became the backbone of email security and domain verification. A single string maxes out at 255 characters; longer values are split into quoted chunks. Its three big jobs for email are checked by receivers in order:

• SPF lists which IPs and services may send as you. Build one with the SPF generator and check a live record with the SPF lookup.

  example.com.    IN    TXT    "v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all"
  

• DKIM publishes a public key under a selector so receivers can verify the signature on each message. Inspect one with the DKIM lookup.

  s2026._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
  

• DMARC ties the two together and tells receivers what to do on failure (none, quarantine, reject) and where to send reports. Build and read one with the DMARC generator and the DMARC lookup.

  _dmarc.example.com.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"
  

TXT records also carry ownership tokens — the google-site-verification=... strings that services ask you to publish to prove the domain is yours.

Reverse lookups and service discovery: PTR, SRV, CAA

A PTR record is the mirror image of an A/AAAA: it maps an IP back to a hostname (reverse DNS). PTRs live in special zones — in-addr.arpa for IPv4, ip6.arpa for IPv6 — with the address written backwards:

42.100.51.198.in-addr.arpa.    3600    IN    PTR    mail.example.com.

This matters most for mail: receiving servers routinely reverse-look-up the connecting IP, and a missing or mismatched PTR is a fast track to the spam folder.

An SRV record advertises where a service runs — host and port — so clients stop assuming default ports. It adds priority and weight for good measure:

_sip._udp.example.com.    3600  IN  SRV  10  60  5060  sip01.example.com.

That reads: for SIP over UDP, prefer sip01 on port 5060 at priority 10, weight 60. It is how VoIP, LDAP, XMPP and plenty of game servers get found.

A CAA record tells certificate authorities which of them may issue TLS certificates for your domain — a cheap guardrail against a rogue or mis-issued certificate:

example.com.    IN    CAA    0 issue "letsencrypt.org"
example.com.    IN    CAA    0 issuewild ";"
example.com.    IN    CAA    0 iodef "mailto:[email protected]"

Here only Let's Encrypt may issue, wildcards are banned outright (issuewild ";"), and violation attempts get reported to your security address.

Signing the whole thing: DNSSEC

Plain DNS answers are unsigned, which leaves them open to cache poisoning and man-in-the-middle spoofing. DNSSEC adds cryptographic signatures so a resolver can prove an answer is authentic and untampered. Four record types work together, and the point of all of them is a single unbroken chain of trust:

• DNSKEY holds the public keys: a Zone Signing Key that signs ordinary records, and a Key Signing Key that signs the DNSKEY set itself.
• RRSIG is the actual signature over a set of records; resolvers fetch it alongside the answer and validate it against the DNSKEY.
• DS lives in the parent zone (your .com registry entry) and is a hash of your Key Signing Key — the link that ties your zone to the one above it.
• NSEC / NSEC3 prove that a name does not exist without signing every possible non-name in real time. Plain NSEC lets someone walk the whole zone; NSEC3 hashes the names to stop that.

The fastest way to see whether a domain's chain validates end to end is the DNSSEC check.

The newer arrivals: HTTPS, NAPTR, SSHFP

A few record types you will meet less often but should recognise:

• HTTPS / SVCB (RFC 9460) is the biggest change to DNS transport in a decade. It lets a browser learn, before it even opens a connection, that a host speaks HTTP/3 (alpn="h3,h2"), which port to use, and the keys for Encrypted Client Hello — and it can alias the apex natively, sidestepping the old CNAME-at-root problem.

  example.com.  7200  IN  HTTPS  1 . ( alpn="h3,h2" port="443" ech="AEn+DQBF..." )
  

• NAPTR rewrites identifiers (often phone numbers) into service destinations using regex rules — the plumbing behind VoIP and ENUM systems.

• SSHFP stores SSH host-key fingerprints in DNSSEC-signed DNS, so an SSH client can trust a host key without the "are you sure you want to continue connecting?" prompt.

Quick reference

Habits worth keeping

• Drop TTLs before a migration. A day or two before changing an A/AAAA address, lower its TTL to ~300 seconds so resolvers worldwide let go of the old value quickly once you cut over.
• Never CNAME the apex. Reach for ALIAS/ANAME flattening or an HTTPS record instead.
• Publish the email trio. SPF, DKIM and a DMARC policy of at least p=quarantine — an unprotected domain is a spoofing target. The email health check reviews all three at once.
• Lock issuance with CAA, so a compromised CA cannot quietly mint a certificate for you.
• Turn on DNSSEC and submit the DS record to your registrar to shut down cache-poisoning attacks.

When in doubt, look before you leap: the all-records lookup shows a domain's full picture in one pass, with each record explained in plain language.