📋 Record type cheat sheet

Every record type you might encounter, what it's for, and whether you will ever actually use it. Sorted by "you will see this often" to "you will never see this."

Each "daily-use" and "modern essentials" type below has its own page with dig examples and, where available, DoH/DoT query examples.

Daily-use types#

Modern essentials#

DNSSEC mechanics (you don't write these, but you see them)#

These types are part of the DNSSEC chain. You will encounter them when debugging signature failures with dnssec-troubleshooting or visualizing a zone with dnsviz.

Less common, still useful#

Effectively dead#

Try it now#

The commands below query live records so you can see each type in the wire. Every name resolves today, and every one except the PTR example carries DNSSEC signatures (the ad flag in the response means the resolver validated the chain). The PTR example's reverse zone, 1.1.1.in-addr.arpa, is unsigned (no DS at its parent), so that answer comes back without ad.

A record (IPv4 address):

dig @1.1.1.1 example.isitdns.net A

example.isitdns.net.    300    IN    A    192.0.2.1

nslookup example.isitdns.net 1.1.1.1

Name:    example.isitdns.net
Address: 192.0.2.1
Name:    example.isitdns.net
Address: 2001:db8::1

Bare nslookup with no -type= asks for both A and AAAA, which is why the IPv6 address shows up too.

AAAA record (IPv6 address):

dig @1.1.1.1 example.isitdns.net AAAA

example.isitdns.net.    300    IN    AAAA    2001:db8::1

nslookup -type=AAAA example.isitdns.net 1.1.1.1

Name:    example.isitdns.net
Address: 2001:db8::1

Format from a current BIND nslookup (9.18); older builds print example.isitdns.net has AAAA address 2001:db8::1 instead.

TXT record (arbitrary text, SPF/DKIM/DMARC/verification):

dig @1.1.1.1 txt.example.isitdns.net TXT +short

"It was DNS. It is always DNS."

nslookup -type=TXT txt.example.isitdns.net 1.1.1.1

txt.example.isitdns.net    text = "It was DNS. It is always DNS."

MX record (mail exchange):

dig @1.1.1.1 cloudflare.com MX +short

5 mxa-canary.global.inbound.cf-emailsecurity.net.
5 mxb-canary.global.inbound.cf-emailsecurity.net.
10 mxa.global.inbound.cf-emailsecurity.net.
10 mxb.global.inbound.cf-emailsecurity.net.

nslookup -type=MX cloudflare.com 1.1.1.1

cloudflare.com    mail exchanger = 5 mxa-canary.global.inbound.cf-emailsecurity.net.
cloudflare.com    mail exchanger = 5 mxb-canary.global.inbound.cf-emailsecurity.net.
cloudflare.com    mail exchanger = 10 mxa.global.inbound.cf-emailsecurity.net.
cloudflare.com    mail exchanger = 10 mxb.global.inbound.cf-emailsecurity.net.

Multi-record answers (MX here, NS below) come back in rotating order between queries. For MX, only the preference number decides priority, never the position in the list.

NS record (authoritative nameservers):

dig @1.1.1.1 isitdns.net NS +short

coleman.ns.cloudflare.com.
hera.ns.cloudflare.com.

nslookup -type=NS isitdns.net 1.1.1.1

isitdns.net    nameserver = coleman.ns.cloudflare.com.
isitdns.net    nameserver = hera.ns.cloudflare.com.

SOA record (zone metadata):

dig @1.1.1.1 isitdns.net SOA +short

coleman.ns.cloudflare.com. dns.cloudflare.com. 2409741473 10000 2400 604800 1800

The serial (2409741473 above) increments with every zone change; your output will show a different value.

nslookup -type=SOA isitdns.net 1.1.1.1

isitdns.net
        origin = coleman.ns.cloudflare.com
        mail addr = dns.cloudflare.com
        serial = 2409741473
        refresh = 10000
        retry = 2400
        expire = 604800
        minimum = 1800

The serial increments with every zone change; your output will show a different value.

CNAME record (alias):

dig @1.1.1.1 cname.example.isitdns.net CNAME +short

example.isitdns.net.

nslookup -type=CNAME cname.example.isitdns.net 1.1.1.1

cname.example.isitdns.net    canonical name = example.isitdns.net.

PTR record (reverse DNS, IP to name):

dig @1.1.1.1 -x 1.1.1.2

2.1.1.1.in-addr.arpa.    1800    IN    PTR    security.cloudflare-dns.com.

1800 is the TTL fresh from Cloudflare's authoritative server; a cached answer shows it counting down.

nslookup 1.1.1.2 1.1.1.1

2.1.1.1.in-addr.arpa    name = security.cloudflare-dns.com.

nslookup has no dedicated printer for CAA, SSHFP, TLSA, HTTPS/SVCB, or the DNSSEC RRTYPEs. It still decodes the record data, but labels it with a generic rdata_N = (the type number, e.g. rdata_257 for CAA) instead of the type name. Use dig if you want types called by name. See nslookup-and-dig for the full comparison.

DS record (DNSSEC chain link to parent zone):

dig @1.1.1.1 isitdns.net DS +short

2371 13 2 2DF8E1D4E0855DF60F2A8B51C914F2F2866ED1E3344F74F9682DAC4D 42D18802

nslookup prints this one as rdata_43 = 2371 13 2 ... rather than naming the DS type; dig is clearer.

The keytag 2371, algorithm 13 (ECDSAP256SHA256), and digest type 2 (SHA-256) tell a resolver how to verify the child zone's KSK is the one the parent trusts. See dnssec for what that chain means end-to-end.

CAA record (allowed certificate authorities):

dig @1.1.1.1 caa.example.isitdns.net CAA +short

0 issue "letsencrypt.org"

This queries the controlled single-record demo name. The isitdns.net apex carries a full multi-CA policy set that may drift over time; see caa for the live apex walkthrough and field semantics. nslookup prints this as rdata_257 = 0 issue "letsencrypt.org" rather than naming the CAA type. Use dig.

Cheat sheet TL;DR#

A      -> IPv4
AAAA   -> IPv6
CNAME  -> alias
MX     -> mail
NS     -> authoritative nameserver
SOA    -> zone metadata
TXT    -> policies (SPF/DKIM/DMARC, verification)
CAA    -> who can mint your certs
PTR    -> reverse
SRV    -> port + host for a named service
HTTPS  -> web hints (modern)
DS     -> DNSSEC chain link to your parent

See also: dig-along for hands-on every type · dig-flags for flag reference · nslookup-and-dig for tool comparison · query-types for recursive vs authoritative · fundamentals · reverse-dns for the .arpa story · dnssec for the signing chain