4. Records

There are over eighty registered record types. About a dozen carry essentially all the traffic, and knowing precisely what each one promises removes most DNS configuration mistakes.

   NAME         TTL  CLASS TYPE  RDATA
   www.example.com. 300 IN  A     192.0.2.1
   └── owner ───┘   └┬┘ └┬┘ └┬┘   └── value
                     │   │   └ what KIND
                     │   └──── always IN
                     └──────── cache seconds

The addresses

   A      an IPv4 address. 4 octets.
   AAAA   an IPv6 address. 16 octets.
          ("quad-A", because it is four
           times the size)

dig +short example.com A
dig +short example.com AAAA
dig +short example.com A example.com AAAA     # both in one invocation

   MULTIPLE A RECORDS ARE A SET, NOT A
   PREFERENCE.

   example.com. 60 IN A 192.0.2.1
   example.com. 60 IN A 192.0.2.2
   example.com. 60 IN A 192.0.2.3

   THE CLIENT PICKS. most resolvers rotate
   the order; most clients take the first;
   `getaddrinfo` applies RFC 6724 sorting;
   browsers try several in parallel.

   THIS IS ROUND-ROBIN DNS, AND IT IS NOT
   LOAD BALANCING — there is no health
   check, no weighting and no failover.

Chapter 11 covers what it is actually good for, which is distributing load across already healthy endpoints and nothing more.

CNAME, and its three hard rules

A CNAME says “this name is an alias; start over with that name instead”.

   blog.example.com. CNAME hosting.example.net.

   A RESOLVER ASKED FOR blog.example.com A
   GETS BOTH:
     blog.example.com.    CNAME hosting.example.net.
     hosting.example.net. A     203.0.113.9

   RULE 1. A CNAME CANNOT COEXIST WITH ANY
   OTHER RECORD AT THE SAME NAME.
     not an A, not an MX, not a TXT.
     (DNSSEC's RRSIG/NSEC are the only
      exceptions.)

   RULE 2. THEREFORE A CNAME CANNOT BE AT
   THE ZONE APEX.
     the apex MUST have SOA and NS records,
     so it can never have a CNAME.

   RULE 3. A CNAME TARGET MAY BE ANOTHER
   CNAME, BUT CHAINS COST ROUND TRIPS AND
   RESOLVERS CAP THEM (typically 8–16).

Caution

Rule 2 is the apex problem, and it is the single most-asked DNS question in existence. example.com cannot be a CNAME to a load balancer’s hostname. The answers are ALIAS/ANAME/CNAME-flattening (a provider-side synthetic record — Route 53’s alias, Cloudflare’s flattening, DNSimple’s ALIAS), or plain A records if the target has stable addresses. There is no standard record that solves it; chapter 12 covers the options.

DNAME, the one nobody uses

   DNAME redirects an entire SUBTREE.

   old.example.com. DNAME new.example.net.
     → a.old.example.com becomes
       a.new.example.net
     → b.c.old.example.com becomes
       b.c.new.example.net

   genuinely useful for domain migrations
   and IPv6 reverse delegation. supported
   by most resolvers. offered by almost no
   managed provider.

Mail

   MX   mail exchange, with a PREFERENCE
        example.com. MX 10 mail1.example.com.
        example.com. MX 20 mail2.example.com.

        LOWER NUMBER = TRIED FIRST.
        equal numbers = pick at random
        (that is the load-balancing
         mechanism)

   MX TARGETS MUST BE HOSTNAMES WITH A/AAAA
   RECORDS. NOT an IP. NOT a CNAME — RFC
   2181 forbids it and many senders enforce
   it.

dig +short example.com MX
dig +short example.com TXT
dig +short _dmarc.example.com TXT
dig +short selector1._domainkey.example.com TXT

   AND THE FOUR TXT RECORDS MODERN MAIL
   REQUIRES

   SPF     example.com TXT
           "v=spf1 include:_spf.google.com -all"
           WHICH SERVERS MAY SEND AS YOU.
           ONE SPF RECORD PER NAME. two is
           a permanent error.
           10-lookup limit on `include`.

   DKIM    sel._domainkey.example.com TXT
           "v=DKIM1; k=rsa; p=MIGf…"
           a public key. signatures are in
           the message headers.

   DMARC   _dmarc.example.com TXT
           "v=DMARC1; p=reject; rua=mailto:…"
           what to do when SPF and DKIM
           disagree with the From header.

   MTA-STS _mta-sts.example.com TXT
           + an HTTPS policy file. forces
           TLS for inbound mail.

The SPF ten-lookup limit is the one that bites in practice: every include: and a: and mx: mechanism costs a DNS lookup, nested ones count too, and exceeding ten produces permerror, which many receivers treat as a failure. SPF flattening services exist entirely because of this limit.

TXT, and its overload

   TXT IS A BAG OF STRINGS, AND IT BECAME
   THE UNIVERSAL EXTENSION POINT.

   mail policy          SPF, DKIM, DMARC
   domain ownership     google-site-
                        verification=…,
                        MS=…, stripe-
                        verification=…
   ACME DNS-01          _acme-challenge
                        TXT "token"
   service config       app-specific
                        key=value

   A SINGLE TXT STRING IS ≤255 OCTETS.
   longer values are MULTIPLE strings,
   concatenated by the consumer — which
   is why a long DKIM key appears as
   ("abc" "def") in a zone file.

dig +short _acme-challenge.example.com TXT
dig TXT example.com | grep -c '"'

The ACME DNS-01 challenge is worth noting because it is the only way to obtain a wildcard certificate from Let’s Encrypt, and it requires API-driven TXT updates — which makes your DNS provider part of your certificate renewal path, and a provider without a usable API a genuine blocker.

Service location

   SRV   _service._proto.name TTL IN SRV
         priority weight port target

   _sip._tcp.example.com. 300 IN SRV
       10 60 5060 sip1.example.com.
       10 40 5060 sip2.example.com.
       20  0 5060 sip-backup.example.com.

   priority  lower first, like MX
   weight    proportional share WITHIN a
             priority
   port      the actual thing SRV adds
             over MX and A
   target    a hostname. never an IP.

   SRV IS THE RIGHT ANSWER AND LOST ANYWAY.

   USED BY: SIP, XMPP, LDAP, Kerberos,
     Minecraft, Active Directory,
     Kubernetes headless services,
     Consul
   NOT USED BY: HTTP. browsers never
     adopted it, and HTTPS/SVCB is the
     replacement that finally might.

dig +short _ldap._tcp.example.com SRV
dig +short _etcd-server._tcp.example.com SRV

HTTPS and SVCB

   THE MODERN REPLACEMENT, RFC 9460 (2023)

   example.com. HTTPS 1 . alpn="h3,h2"
       ipv4hint=192.0.2.1 ech=…

   WHAT IT SOLVES
     − the apex-CNAME problem: an HTTPS
       record with a target IS an alias
       that may sit at the apex
     − advertising HTTP/3 without an
       Alt-Svc round trip
     − Encrypted Client Hello keys
     − address hints, saving a lookup

   SUPPORTED BY: Chrome, Firefox, Safari,
     curl, Cloudflare, Apple. widely
     deployed and still arriving.

This is the most significant addition to DNS in a decade, and the part worth watching is the alias form: it is the first standardised answer to the apex problem that does not depend on a provider’s proprietary record type.

The structural records

   SOA   at every zone apex, exactly once.
         primary-ns admin-email serial
         refresh retry expire minimum
         → chapter 8

   NS    which servers are authoritative.
         at the apex (for this zone) and at
         each delegation point (for the
         child).

   PTR   reverse mapping. in-addr.arpa /
         ip6.arpa only, in practice.

   CAA   which certificate authorities may
         issue for this name.
         example.com. CAA 0 issue
           "letsencrypt.org"
         CHECKED BY CAs AT ISSUANCE TIME,
         not by browsers. it is a
         pre-issuance control.

   TLSA  a certificate or key, pinned in
         DNS (DANE). requires DNSSEC to
         mean anything. used for SMTP,
         essentially nowhere else.

dig +short example.com CAA
dig +short _25._tcp.mail.example.com TLSA
dig +short example.com SOA

Note

CAA is cheap and underused. A single record naming the CAs you actually use prevents any other CA from issuing a certificate for your domain, which closes off a real attack path for the cost of one line. It is checked at issuance, so it protects against future mis-issuance rather than existing certificates.

Where the types are registered

   IANA KEEPS THE LIST. ~90 TYPES, EACH
   WITH A NUMBER.

   1   A          28  AAAA
   2   NS         33  SRV
   5   CNAME      41  OPT    (EDNS0 pseudo)
   6   SOA        43  DS
   12  PTR        46  RRSIG
   15  MX         47  NSEC
   16  TXT        48  DNSKEY
   17  RP         50  NSEC3
   24  SIG        52  TLSA
   25  KEY        64  SVCB
   39  DNAME      65  HTTPS
   250 TSIG       257 CAA
   251 IXFR       255 ANY
   252 AXFR

dig example.com TYPE65          # by number, if your dig is old
dig example.com HTTPS
dig +short example.com TYPE257  # == CAA

Knowing the numbers is occasionally necessary because tooling lags the registry: a dig from a distribution released before RFC 9460 will not recognise HTTPS by name, and TYPE65 is how you ask anyway. The same trick works for any record type a server supports and a client has never heard of, because the wire format carries only the number and an opaque RDATA blob.

Unknown record types pass through

   RFC 3597: A SERVER MUST SERVE A TYPE IT
   DOES NOT UNDERSTAND.

   example.com. 300 IN TYPE65
       \# 23 0001000001000302683302683200…

   THAT SYNTAX — `\#` then a length then
   hex — IS HOW A ZONE FILE EXPRESSES A
   TYPE THE SERVER HAS NEVER HEARD OF.

This is why new record types can be deployed at all: an authoritative server from 2015 can serve HTTPS records to a resolver from 2024, with neither understanding the contents. It is the quiet mechanism behind every extension in this guide.

Records you will meet and should not use

   SPF (type 99)     deprecated in 2014.
                     use TXT.
   ANY               not a type, a
                     meta-query. mostly
                     REFUSED now, because
                     it was a DDoS
                     amplifier.
   WKS, HINFO, MINFO obsolete
   NULL              reserved
   APL, LOC          real, delightful,
                     unused
   RP, AFSDB         historical
   NAPTR             ENUM and SIP
                     discovery; alive but
                     specialised

What to take from this chapter

• A record is owner, TTL, class, type and RDATA. The type is part of the lookup key, so one name answers differently per type.
• Multiple A records are a set, not a preference. The client chooses. Round-robin DNS has no health checking, weighting or failover.
• CNAME has three hard rules: it cannot coexist with any other record at the same name, therefore it cannot be at the zone apex, and chains cost round trips and are capped.
• The apex problem has no standard solution — only provider-side ALIAS/ANAME/flattening, plain A records, or the new HTTPS record’s alias form.
• MX targets must be hostnames with address records, never an IP and never a CNAME. Lower preference is tried first; equal values are the load-balancing mechanism.
• Modern mail needs four TXT-shaped things: SPF (one record only, ten-lookup limit), DKIM, DMARC and optionally MTA-STS. The SPF lookup limit is why flattening services exist.
• TXT became the universal extension point. A single string is ≤255 octets, so long keys are multiple concatenated strings. ACME’s DNS-01 makes your DNS provider’s API part of your certificate renewal path.
• SRV adds a port and a weight — the right design, adopted by everything except HTTP.
• HTTPS/SVCB (RFC 9460) is the significant recent addition: HTTP/3 advertisement, ECH keys, address hints, and the first standard alias that may sit at the apex.
• CAA is cheap and underused: it restricts which CAs may issue for your name, checked at issuance time.
• ANY is a meta-query, not a type, and is now widely refused because it was a DDoS amplifier.

Next: a lookup traced — one getaddrinfo call followed from the application through every cache and server to the answer.