Sign in Subscribe
DNS

Understanding DNS Record Types

Demystify DNS records and be fluent in their use.

North Engineer

North Engineer

— 6 min read
Understanding DNS Record Types
Photo by Jametlene Reskp / Unsplash

DNS is the translation layer between human-readable domain names and the IP addresses computers use to route traffic. It's simultaneously one of the simplest and most frustrating systems in information technology. When something breaks, there's a reason the saying "it's always DNS" exists.

DNS in layman's terms can be described as the phone book of the internet. You know the name of what you want to reach out to, but you need to know the number.

This guide covers the DNS record types you'll actually encounter when managing your own infrastructure: A, AAAA, CNAME, TXT, MX, TLSA, and SMIMEA. I'll show you how to query each using dig, the standard tool for DNS troubleshooting.

Why dig Instead of nslookup

While nslookup works, dig (Domain Information Groper) provides more detailed output and is the preferred tool among infrastructure engineers. It shows you exactly what's happening: the query type, response flags, TTL values, and which DNS server answered your request.

Reading dig Output

Before diving into record types, let's understand what dig shows you. Here's a basic query:

dig north.engineer

┌[ north@os ] ~
└➤ dig north.engineer

; <<>> DiG 9.10.6 <<>> north.engineer
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52565
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;north.engineer.			IN	A

;; ANSWER SECTION:
north.engineer.		300	IN	A	212.132.93.42

;; Query time: 230 msec
;; SERVER: 2606:4700:4700::1112#53(2606:4700:4700::1112)
;; WHEN: Tue Feb 03 19:10:46 EST 2026
;; MSG SIZE  rcvd: 59

The output includes several sections:

  • HEADER: Shows the query ID, flags (like QR for query response, AA for authoritative answer), and response codes
  • QUESTION SECTION: What you asked for
  • ANSWER SECTION: The actual DNS records returned
  • Query time: How long the lookup took in milliseconds
  • SERVER: Which DNS server answered (useful for troubleshooting caching issues)
  • MSG SIZE: The response size in bytes

The TTL (Time To Live) value appears before each record, showing how many seconds the record should be cached before re-querying. In the example it's 300 seconds.

For cleaner output when you just need the answer, use:

dig +short north.engineer

┌[ north@os ] ~
└➤ dig +short north.engineer
212.132.93.42

A Records

An A record maps a domain name to an IPv4 address. This is the most fundamental DNS record type.

Query an A record:

dig north.engineer A

Simplified output:

dig +short north.engineer A

┌[ north@os ] ~
└➤ dig +short north.engineer A
212.132.93.42

What this does: Returns the IPv4 address associated with the domain. Without an A record, nothing can find your server using that domain name.

AAAA Records

AAAA records serve the same purpose as A records, but for IPv6 addresses. As IPv6 adoption continues, having AAAA records ensures your services remain accessible to users on IPv6-only networks.

Query an AAAA record:

dig north.engineer AAAA

Simplified output:

dig +short north.engineer AAAA

┌[ north@os ] ~
└➤ dig +short north.engineer AAAA
2a02:247a:20b:d600:3::1

CNAME Records

A CNAME (Canonical Name) record creates an alias from one domain name to another. This is useful when you want multiple subdomains pointing to the same destination without maintaining separate A/AAAA records for each.

Query a CNAME record:

dig autodiscover.north.engineer CNAME

Simplified output:

dig +short autodiscover.north.engineer CNAME

┌[ north@os ] ~
└➤ dig +short autodiscover.north.engineer CNAME
mail.north.engineer.

What this does: Shows you what domain the alias points to. CNAMEs must always point to another domain name, never directly to an IP address.

Important limitation: You should not have a CNAME at the zone apex (the bare domain like north.engineer). CNAMEs can only exist on subdomains.

TXT Records

TXT records hold arbitrary text data. They're most commonly used for domain verification and email authentication (SPF, DKIM, DMARC), but can store any text information you need to publish via DNS.

Query TXT records:

dig north.engineer TXT

Simplified output:

dig +short north.engineer TXT

┌[ north@os ] ~
└➤ dig +short north.engineer TXT
"v=spf1 mx -all"
"openpgp4fpr:e589c9c0fe6e653e00ac8781ddabba029bcff4e7"

Common TXT record uses:

  • SPF: Defines which servers can send email for your domain
  • DKIM: Publishes public keys for email signature verification
  • DMARC: Specifies email authentication policies
  • Domain verification: Services like Google, Microsoft, and Let's Encrypt use TXT records to verify domain ownership
  • AT Protocol (Bluesky): "did=did:plc:xxxxx" links your domain to your decentralized identity
  • OpenPGP: "openpgp4fpr:xxxxx" publishes your PGP key fingerprint

MX Records

MX (Mail Exchange) records tell other mail servers where to deliver email addressed to your domain. Without MX records, email sent to @yourdomain.com has nowhere to go.

Query MX records:

dig north.engineer MX

Simplified output:

dig +short north.engineer MX

┌[ north@os ] ~
└➤ dig +short north.engineer MX
10 mail.north.engineer.

What this does: Returns the mail servers responsible for your domain, along with their priority values. Lower priority numbers are tried first. If you have 10 mail1.example.comand 20 mail2.example.com, sending servers will try mail1 first, falling back to mail2 if mail1 is unavailable.

Note: MX records point to domain names, not IP addresses. Those domain names need their own A/AAAA records.

TLSA Records

TLSA records are part of DANE (DNS-based Authentication of Named Entities), which allows you to publish your TLS certificate information in DNS. This provides an additional layer of verification beyond traditional certificate authorities.

Query a TLSA record:

dig _25._tcp.mail.north.engineer TLSA

Simplified output:

dig +short _25._tcp.mail.north.engineer TLSA

┌[ north@os ] ~
└➤ dig +short _25._tcp.mail.north.engineer TLSA
2 0 1 83624FD338C8D9B023C18A67CB7A9C0519DA43D11775B4C6CBDAD45C 3D997C52
2 0 2 3565CD99FB0BCCF03019E4D2276CA5D7C913A3AF1AD58A95A8CAD181 699364F22FB6DC6CC01E071847DB3336AE9A122B968D31C5BE9A4443 E145DABA2A1782C6
2 1 1 885BF0572252C6741DC9A52F5044487FEF2A93B811CDEDFAD7624CC2 83B7CDD5
2 1 2 89D8F1D26D16E94600405C8585E40AD1ECDE0023CD447E8B39FD90BC 8B482C7BD68D963156E5037023B144EC4CAA03AF8213296F3A498F69 DEE691A95A92D722
3 0 1 7BE8B2DFA7721C0C66FF06C1B1E0B24660263BB34F079CD763C7CA62 40F07B9D
3 0 2 26431D25E78102EFB708D402E5F995B41101FAB696147900DA7BAC97 4401FEC9750317202623EE5EE405EC8C43A3F295267888168EA43452 C067FD21F37AA9A6
3 1 1 BBCC041818B99707A76D5C8ADB5CD10AA1CCC0028FB37CA4661CB4CF 84C47E05
3 1 2 73906D68BAE234D48452CB1FFC4A48E70F951C49CFDEACA5CC4DF336 B313B11F1C70CB06E4618865042AFBA961F0AA9047EF834571952275 986F0DAF3DE34DDF

Understanding the format: TLSA records follow the pattern _port._protocol.hostname. For SMTP (email), port 25 over TCP becomes _25._tcp.mail.example.com.

The record contains four fields:

  1. Certificate Usage (0-3):
    • 0 (PKIX-TA): Must be issued by a CA in the record
    • 1 (PKIX-EE): Certificate must match exactly
    • 2 (DANE-TA): Must be issued by a CA whose key is in the record
    • 3 (DANE-EE): Public key must match exactly (most common for self-managed infrastructure)
  2. Selector (0-1):
    • 0: Full certificate
    • 1: Public key only (recommended)
  3. Matching Type (0-2):
    • 0: Exact match
    • 1: SHA-256 hash (recommended)
    • 2: SHA-512 hash
  4. Certificate/Key Data: The hexadecimal hash or full certificate data

Important: TLSA records only provide security if your domain has DNSSEC enabled. Without DNSSEC, an attacker who can spoof your DNS could also spoof your TLSA records.

Querying Specific DNS Servers

Sometimes you need to check what a specific DNS server returns, either for troubleshooting propagation or to verify authoritative records:

dig @8.8.8.8 +short north.engineer A

┌[ north@os ] ~
└➤ dig @8.8.8.8 +short north.engineer A
212.132.93.42

What this does: Queries Google's public DNS (8.8.8.8) instead of your local resolver. Useful for checking whether DNS changes have propagated globally.

Common DNS servers for testing:

  • 8.8.8.8 - Google
  • 1.1.1.1 - Cloudflare
  • 9.9.9.9 - Quad9

Reverse DNS Lookups

To find the domain name associated with an IP address (PTR records):

dig -x 212.227.74.145

┌[ north@os ] ~
└➤ dig -x 212.227.74.145

; <<>> DiG 9.10.6 <<>> -x 212.227.74.145
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29852
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;145.74.227.212.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
145.74.227.212.in-addr.arpa. 7200 IN	PTR	mail.north.engineer.

;; Query time: 156 msec
;; SERVER: 2606:4700:4700::1112#53(2606:4700:4700::1112)
;; WHEN: Tue Feb 03 19:41:06 EST 2026
;; MSG SIZE  rcvd: 89

What this does: Performs a reverse DNS lookup. This is particularly important for email servers, as many receiving servers verify that your sending IP's PTR record matches your claimed domain.

Closing Thoughts

DNS underpins everything on the internet. Understanding how to query and interpret DNS records gives you the foundation to troubleshoot connectivity issues, configure email authentication, and implement advanced security features like DANE.

When something breaks and you're not sure where to start, remember: it's always DNS. Now you have the tools to prove it.

Footnotes:

[1] dig command documentation: https://linux.die.net/man/1/dig
[2] DANE protocol (RFC 6698): https://datatracker.ietf.org/doc/html/rfc6698
[3] SMIMEA records (RFC 8162): https://datatracker.ietf.org/doc/html/rfc8162

Read more