DNS Record Types

A DNS name is not just a pointer to an IP address — it is the owner of a set of typed data records, and the type is what turns the Domain Name System from an address book into the Internet’s general-purpose distributed key-value store. Each record (a Resource Record, or RR) is a tuple of NAME / TYPE / CLASS / TTL / RDLENGTH / RDATA (RFC 1035 §3.2.1); the TYPE field selects how the RDATA is interpreted. An A record’s RDATA is 32 bits of IPv4 address; an MX record’s is a priority plus a mail-server name; a TXT record’s is free-form text that email authentication has quietly turned into critical infrastructure. This note is a tour of the record types that matter in practice — what each holds, how they chain (an MX points at a name that needs an A), and the sharp edges (the CNAME-at-apex problem, the SOA timer semantics, the wildcard’s surprising match rules). It is the data-model companion to The Domain Name System (the protocol) and DNS Resolution Recursion and Iteration (the lookup); record caching is DNS Caching and Time to Live.

Mental Model — a Name Owns a Bag of Typed Records

The unit to think in is not “a record” but an RRset: all records of the same type at the same name. A query names an owner and a type (www.example.com, A) and gets back the whole RRset for that pair. RFC 2181 makes the RRset a first-class concept and requires that “the TTLs of all RRs in an RRSet must be the same” (RFC 2181 §5.2) — you cannot give two of a name’s A records different lifetimes; they age and expire together.

flowchart LR
  NAME["example.com<br/>(zone apex)"]
  SOA["SOA<br/>zone metadata + timers"]
  NS["NS x2<br/>authoritative servers"]
  A["A<br/>93.184.216.34"]
  MX["MX 10 mail.example.com"]
  TXT["TXT v=spf1 ...<br/>TXT google-site-verification=..."]
  CAA["CAA 0 issue letsencrypt.org"]

  NAME --- SOA
  NAME --- NS
  NAME --- A
  NAME --- MX
  NAME --- TXT
  NAME --- CAA
  MX -.->|"chases to"| MAILA["mail.example.com<br/>A 203.0.113.9"]

One name owning many typed RRsets. What it shows: the apex example.com simultaneously carries SOA, NS, A, MX, TXT, and CAA records — each a separate RRset answered by its own query type. The insight to take: DNS records chain. The dashed edge is the key one — an MX record does not contain an address; it names a host (mail.example.com) whose A/AAAA records must be looked up separately. Most real DNS bugs are broken chains: an MX, NS, or SRV that points at a name with no address record, or (worst of all) at a CNAME, which the specs forbid.

Address Records — A and AAAA

The A record is the original and most common: its RDATA is “a 32 bit Internet address”, and “hosts that have multiple Internet addresses will have multiple A records” (RFC 1035 §3.4.1). Multiple A records at one name are the simplest form of load distribution (“round-robin DNS”) — the resolver returns all of them and the client picks one (often the first, so servers rotate the order).

The AAAA record (“quad-A”) is its IPv6 counterpart, defined in RFC 3596 (“DNS Extensions to Support IP Version 6”, Internet Standard STD 88, October 2003). Its “IANA assigned value of the type is 28 (decimal)”, and “a 128 bit IPv6 address is encoded in the data portion … in network byte order (high-order byte first)” (RFC 3596). A dual-stack host publishes both an A and an AAAA; clients running “Happy Eyeballs” (RFC 8305) race both and use whichever connects first. The name AAAA is a pun — four times the bytes of an A.

CNAME — Aliasing, and the Apex Problem

A CNAME (Canonical Name) record makes one name an alias for another. Its RDATA is “a which specifies the canonical or primary name for the owner[;] the owner name is an alias” (RFC 1035 §3.3.1). When a resolver looks up www.example.com and finds CNAME shop.example.net, it restarts the lookup at shop.example.net and follows the chain to a real address. This is how www.example.com can point at a CDN’s ever-changing infrastructure without the domain owner tracking IPs.

CNAME carries a hard, frequently-violated rule: it must be the only record at its name. RFC 2181 §10.1 states that “for any label in the DNS (any domain name) exactly one of the following is true: one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs [DNSSEC], one or more records exist, none being CNAME records” (RFC 2181 §10.1). A name cannot have both a CNAME and an A, or a CNAME and an MX.

This collides head-on with the zone apex. The apex (example.com itself, with no host label) must carry an SOA and NS records to be a valid zone — so by the rule above it cannot be a CNAME. Yet operators constantly want exactly that: to point the bare example.com at a CDN or a platform-as-a-service endpoint the way they point www with a CNAME. There is no standard CNAME-at-apex.

Vendors invented workarounds, marketed as ALIAS, ANAME, apex CNAME, or CNAME flattening. These are not new wire types; the authoritative server resolves the target’s address itself at query time and returns a synthesized A/AAAA for the apex, so ordinary resolvers see a normal address record. Route 53’s ALIAS, DNSimple’s ALIAS, and Cloudflare’s CNAME flattening all work this way. The IETF tried to standardize this as the ANAME record — “ANAME provides similar functionality to CNAME, but only for address queries … [and] can be present at any DNS node … enabling it to be present at a zone apex” (draft-ietf-dnsop-aname) — but the draft never reached RFC status and was overtaken. The modern standardized answer is the HTTPS/SVCB record family in RFC 9460 (“Service Binding and Parameter Specification via the DNS”, Proposed Standard, 2023), whose AliasMode “enables CNAME-like functionality at a zone apex (such as ‘example.com’) for participating protocols” (RFC 9460) — with the caveat that it only helps clients (browsers) that understand the new record.

MX — Mail Routing, and Record Chaining

The MX (Mail Exchanger) record directs email. Its RDATA has two fields: a 16-bit PREFERENCE — “the preference given to this RR among others at the same owner[;] lower values are preferred” — and an EXCHANGE, “a which specifies a host willing to act as a mail exchange for the owner name” (RFC 1035 §3.3.9). A sender delivering to alice@example.com looks up example.com MX, sorts the results by preference (lowest first), and tries them in order; equal preferences are load-balanced. So:

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  20  mail2.example.com.   ; backup, tried only if mail1 fails

MX is the canonical example of chaining: the EXCHANGE is a name, not an address, so the sender must then look up mail1.example.com A/AAAA. RFC 2181 §10.3 forbids the EXCHANGE (and an NS target) from being an alias: “the domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias” (RFC 2181 §10.3) — because a mailer or resolver that must also chase a CNAME to get the address suffers “extra queries, and extra network burden, on every query.” Point MX at a name with real address records, never at a CNAME.

NS — Delegation

The NS (Name Server) record names an authoritative server for a zone: its RDATA is “a which specifies a host which should be authoritative for the specified class and domain” (RFC 1035 §3.3.11). NS records do double duty. At the apex of a zone they list that zone’s own authoritative servers (authoritative data). In the parent zone, an NS RRset for a child name is the delegation that cuts a new zone and generates the referrals traced in DNS Resolution Recursion and Iteration — accompanied by glue address records when the name servers live inside the child. Like MX targets, NS targets must be real hostnames with address records, not aliases (RFC 2181 §10.3).

SOA — the Zone Apex Record

Every zone has exactly one SOA (Start of Authority) record at its apex, and it is the zone’s control panel. Its RDATA fields (RFC 1035 §3.3.13):

• MNAME — “the of the name server that was the original or primary source of data for this zone” (the primary master).
• RNAME — “the mailbox of the person responsible for this zone”, encoded as a domain name with the @ replaced by a dot (so hostmaster@example.com becomes hostmaster.example.com.).
• SERIAL — “the unsigned 32 bit version number of the original copy of the zone.” Secondaries compare serials to decide whether to re-transfer; you must bump the serial on every change or secondaries will not pick it up. The common convention is YYYYMMDDnn.
• REFRESH — “a 32 bit time interval before the zone should be refreshed”: how often a secondary re-checks the primary’s serial.
• RETRY — how long a secondary waits to retry “before a failed refresh.”
• EXPIRE — “the upper limit on the time interval that can elapse before the zone is no longer authoritative”: if a secondary cannot reach the primary for this long, it stops answering (better to go dark than serve stale data forever).
• MINIMUM — originally “the unsigned 32 bit minimum TTL field that should be exported with any RR from this zone”, but RFC 2308 redefined it as the negative-caching TTL — the lifetime for cached NXDOMAIN/NODATA answers, taken as “the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself” (RFC 2308). Its role in negative caching is covered in negative responses.

The SERIAL/REFRESH/RETRY/EXPIRE quartet is the entire primary-secondary replication protocol distilled into one record — a self-describing eventual-consistency scheme from 1987.

TXT — Free Text That Became Critical Infrastructure

The TXT record was defined almost as an afterthought: its RDATA is “one or more s … used to hold descriptive text” (RFC 1035 §3.3.14). That deliberate vagueness turned it into DNS’s extension point. Three uses dominate:

• Domain verification. Countless services (“prove you own this domain”) ask you to publish a TXT record with a magic token — google-site-verification=..., MS=ms12345678, an ACME _acme-challenge token for Let’s Encrypt. The verifier queries for it; publishing it proves control of the zone.
• SPF (Sender Policy Framework). SPF authorizes which hosts may send mail for a domain. RFC 7208 (April 2014) mandates that “SPF records MUST be published as a DNS TXT (type 16) Resource Record” — the once-planned dedicated SPF RR type (99) was abandoned because “significant migration to the SPF RR type in the foreseeable future was very unlikely” (RFC 7208). An SPF record begins v=spf1 and lists mechanisms, e.g. v=spf1 +mx a:colo.example.com/28 -all (allow the MX hosts, allow that subnet, reject all else).
• DKIM and DMARC. DKIM (DomainKeys Identified Mail, RFC 6376, Internet Standard STD 76) publishes a signing public key as a TXT record under a _domainkey subdomain: for selector s1 and domain example.com, the key lives at s1._domainkey.example.com, formatted v=DKIM1; k=rsa; p=<base64 public key> (RFC 6376 §3.6.2.1). DMARC (RFC 7489, March 2015) ties SPF and DKIM to the visible From: domain and publishes policy as a TXT record at _dmarc.<domain>; the record “must appear first” with v=DMARC1 and carries a policy tag p=none | quarantine | reject telling receivers what to do with mail that fails alignment (RFC 7489). Together, SPF + DKIM + DMARC — all riding on TXT records — are the backbone of modern email anti-spoofing.

PTR — Reverse Lookups

A PTR (Pointer) record maps an address back to a name — the reverse of A/AAAA. Its RDATA “points to some location in the domain name space” (RFC 1035 §3.3.12). Reverse lookups work by encoding the address as a name in a special reverse-mapping domain. For IPv4 the domain is in-addr.arpa with the octets reversed: 93.184.216.34 becomes 34.216.184.93.in-addr.arpa (reversed because DNS names get more specific right-to-left, but IPv4 addresses get more specific left-to-right). For IPv6, RFC 3596 defines the ip6.arpa domain, where “an IPv6 address is represented … by a sequence of nibbles separated by dots … encoded in reverse order, i.e., the low-order nibble is encoded first”, each a hex digit (RFC 3596) — so a v6 address expands to 32 reversed nibble labels. Reverse DNS is load-bearing for mail: many receiving servers reject or downgrade mail from an IP whose PTR is missing or does not forward-confirm (the PTR name’s A must point back to the sending IP — “forward-confirmed reverse DNS,” FCrDNS).

SRV — Generalized Service Location

The SRV record (RFC 2782, February 2000) generalizes MX-style “find the server for a service” beyond email to any protocol. Its owner name is structured — _service._proto.name, e.g. _sip._tcp.example.com or _ldap._tcp.example.com — and its RDATA has four fields (RFC 2782):

• Priority — like MX preference; “a client MUST attempt to contact the target host with the lowest-numbered priority it can reach.”
• Weight — load-balancing among equal priorities; “larger weights SHOULD be given a proportionately higher probability of being selected” via a weighted-random algorithm.
• Port — “the port on this target host of this service” (SRV’s advantage over MX: it carries the port, so the service need not sit on a well-known one).
• Target — “the domain name of the target host[;] there MUST be one or more address records for this name.” A Target of . is a sentinel: “a Target of ’.’ means that the service is decidedly not available at this domain.”

SRV is what Microsoft Active Directory, XMPP, SIP, and Kubernetes headless services use to advertise endpoints. Its priority-then-weight scheme is a small, elegant load-balancing-and-failover protocol encoded in a record type. (HTTP notably never adopted SRV; the SVCB/HTTPS records of RFC 9460 finally fill that gap.)

CAA — Constraining Certificate Issuance

The CAA (Certification Authority Authorization) record (RFC 8659, 2019, obsoleting RFC 6844) lets a domain owner declare which Certificate Authorities may issue TLS certificates for the name — a defence against a rogue or tricked CA mis-issuing a certificate. Its RDATA is a flags octet, a tag, and a value (RFC 8659). The standard tags:

• issue — authorizes a CA to issue certificates: example.com. CAA 0 issue "letsencrypt.org".
• issuewild — authorizes issuance of wildcard certificates specifically.
• iodef — a URL/mailto where a CA should report a policy-violating request.

The teeth are in the CA’s obligation: “before issuing a certificate, a compliant CA MUST check for publication of a Relevant RRset”, and “the search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root ’.’ until a CAA RRset is found” (RFC 8659). So a CAA at example.com governs www.example.com too. CAA checking has been mandatory for CAs in the CA/Browser Forum baseline requirements since 2017. It connects to the broader PKI story in Certificate Transparency and Revocation and Public Key Infrastructure and Certificate Chains.

Wildcards — Synthesizing Records for Names That Do Not Exist

A wildcard is a record whose owner label is *, e.g. *.example.com. It synthesizes answers for queries that match no explicit name. RFC 4592 (“The Role of Wildcards in the Domain Name System”, 2006): “when the appropriate conditions are met, the name server creates RRs with an owner name equal to the query name and contents taken from the wildcard RRs” (RFC 4592). So *.example.com A 203.0.113.1 answers anything.example.com, random.example.com, etc.

Wildcards behave far less intuitively than most people assume, and RFC 4592 exists largely to correct the myths:

• A wildcard does not match names that do exist. If blog.example.com has its own explicit record, the wildcard never applies to it — wildcards only fill gaps. “Wildcard RRs do not apply when the query name or a name between the wildcard domain and the query name is known to exist” (RFC 4592).
• A wildcard does not match its own subdomains. “*.example. does not match all names in the example. zone; it fails to match the names below *.example.” (RFC 4592). *.example.com matches a.example.com but not b.a.example.com.
• Wildcards do not cross delegations and match at only one level. They are not a regex or a “match everything below.”

Because a wildcard is per-type, *.example.com MX ... synthesizes MX but not A; a query for the address of a nonexistent name would get NODATA, not the wildcard MX.

Failure Modes and Common Misunderstandings

• CNAME coexistence violations. Putting a CNAME alongside any other record (or at the apex) is the single most common DNS error; some servers reject it, others behave undefinedly. Use ALIAS/flattening or HTTPS records at the apex.
• Pointing MX/NS/SRV at a CNAME. Forbidden by RFC 2181 §10.3; causes extra lookups and, on strict mailers, delivery failure. Targets must be names with real A/AAAA.
• Forgetting to bump the SOA serial. A change that leaves the serial unchanged is invisible to secondaries — the classic “I updated DNS but nothing changed.”
• Confusing SOA MINIMUM with a default TTL. Since RFC 2308 it is the negative-caching TTL, not a positive default; a large MINIMUM makes NXDOMAIN results stick around a long time.
• Wildcard surprises. Expecting *.example.com to catch a.b.example.com, or to override an explicit blog.example.com, or to match the bare example.com — all wrong per RFC 4592.
• Missing AAAA on a dual-stack service. A service reachable only via A will silently exclude IPv6-only clients; publish both.

Alternatives and When to Choose Them

For apex aliasing, the choices are: a vendor ALIAS/CNAME-flattening feature (works with every client today, but is provider-specific and does the target resolution server-side, hiding the target’s own multiple addresses and geo-steering); or the standard HTTPS/SVCB record (RFC 9460) (interoperable and future-proof, but only honoured by newer clients). For service discovery, SRV vs a plain A/AAAA + well-known port: SRV when you need the port to be dynamic and want priority/weight failover (AD, SIP, headless Kubernetes Services); plain address records when the port is fixed and simplicity wins. The full IANA registry of RR types is far larger than this note (over 90 types — DNSKEY, RRSIG, NSEC, DS for DNSSEC; TLSA for DANE; NAPTR, LOC, HINFO); the ones above are the load-bearing set for everyday operations.

Production Notes

Email is where record chaining and correctness bite hardest: a working mail setup needs consistent MX → address records, an SPF TXT that lists every legitimate sender, DKIM keys under _domainkey, a _dmarc policy, and matching forward-confirmed PTR records — and a mistake in any one silently sends mail to spam. TLS automation (ACME/Let’s Encrypt) leans on TXT (the _acme-challenge DNS-01 method) and is gated by CAA. CDNs and PaaS platforms live on CNAME (and increasingly apex ALIAS/HTTPS records) to keep the domain owner decoupled from their churning IPs. The whole-system view of how these records are served, replicated, and cached at planet scale is Domain Name System Design; the caching that governs how fast a record change takes effect is DNS Caching and Time to Live.

See Also

• The Domain Name System — the RR wire format, message sections, and server roles these records live in
• DNS Resolution Recursion and Iteration — how NS/glue drive referrals and how SOA MINIMUM governs negative caching
• DNS Caching and Time to Live — how the per-record TTL controls propagation delay
• DNSSEC — the DNSKEY/RRSIG/DS/NSEC record family that signs these records
• Public Key Infrastructure and Certificate Chains and Certificate Transparency and Revocation — the PKI that CAA constrains
• Domain Name System Design — whole-system serving/replication of these records
• CoreDNS — how a concrete server publishes and answers for these types
• MOC: Networking and Protocols MOC §7