DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS, and More

DNS (Domain Name System) is the internet's phone book. When you type github.com into a browser, DNS translates that human-readable domain into the IP address your computer needs to connect. But DNS does much more than simple name-to-IP translation — different record types enable email routing, domain verification, service discovery, and more.

This guide covers every DNS record type you'll encounter as a developer, DevOps engineer, or sysadmin.

How DNS Works

Before diving into record types, a quick overview of how DNS resolution works:

1. Your browser asks your local DNS resolver (usually your ISP or a public resolver like 8.8.8.8)
2. The resolver asks a root nameserver which TLD (.com, .io, etc.) nameserver to ask
3. The TLD nameserver points to the authoritative nameserver for the domain
4. The authoritative nameserver returns the requested records
5. Results are cached for the record's TTL (Time To Live) duration

DNS queries happen in milliseconds, but the underlying system is beautifully distributed — no single server knows all records for all domains.

Core Record Types

A Record — IPv4 Address

The most fundamental DNS record. Maps a hostname to an IPv4 address.

example.com.     IN  A  93.184.216.34
www.example.com. IN  A  93.184.216.34

Use cases:

• Point a domain or subdomain to a server's IP address
• Load balancing: multiple A records for the same hostname (round-robin DNS)
• Failover: update the A record IP when migrating servers

Important: An A record only points to IPv4 addresses (32-bit, like 192.168.1.1).

AAAA Record — IPv6 Address

The IPv6 equivalent of the A record. Maps a hostname to a 128-bit IPv6 address.

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

Most modern domains should have both A and AAAA records. Clients prefer IPv6 when available (RFC 6724). Many ISPs, mobile networks, and cloud providers assign IPv6 addresses.

# Check if a domain has AAAA records
dig example.com AAAA

CNAME Record — Canonical Name (Alias)

Points one hostname to another hostname, which then resolves to an IP. Think of it as a DNS redirect.

www.example.com. IN CNAME example.com.
blog.example.com. IN CNAME myblog.hosted-platform.com.

When to use CNAME:

• www subdomain pointing to the apex domain
• Subdomain pointing to a CDN, hosting platform, or SaaS service
• Creating multiple names for the same service

Critical restriction: CNAME records cannot exist at the zone apex (root domain). You cannot have a CNAME for example.com itself — only for subdomains like www.example.com. This is because the apex domain must have SOA and NS records, which can't coexist with a CNAME.

Many DNS providers work around this with ALIAS or ANAME records (flattening the CNAME at the apex). AWS Route 53 calls them "Alias records."

Another restriction: A CNAME cannot coexist with other records for the same name. www.example.com can be either a CNAME or have A/AAAA records, not both.

MX Record — Mail Exchange

Directs email for a domain to the correct mail servers, with priority.

example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.

The number (10, 20) is the priority — lower numbers are preferred. If the primary mail server (priority 10) is unavailable, email falls to the backup (priority 20).

Common MX configurations:

Google Workspace:

@ IN MX 1  aspmx.l.google.com.
@ IN MX 5  alt1.aspmx.l.google.com.
@ IN MX 5  alt2.aspmx.l.google.com.
@ IN MX 10 alt3.aspmx.l.google.com.
@ IN MX 10 alt4.aspmx.l.google.com.

Microsoft 365:

@ IN MX 0 yourdomain-com.mail.protection.outlook.com.

After changing MX records, email delivery updates based on the old record's TTL. Lower the TTL before migrating (to 300 seconds / 5 minutes) at least 24-48 hours in advance.

TXT Record — Text Data

Stores arbitrary text data. Originally designed for human-readable information, TXT records are now used extensively for machine-readable verification and authentication.

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

Common TXT record uses:

SPF (Sender Policy Framework): Specifies which mail servers can send email for your domain. Helps prevent spoofing.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

DKIM (DomainKeys Identified Mail): Public key for verifying email signatures.

selector._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

DMARC (Domain-based Message Authentication): Policy for handling emails that fail SPF/DKIM.

_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Domain verification: Proving you own a domain to Google Search Console, GitHub, AWS, etc.

@ IN TXT "google-site-verification=abc123xyz"

ACME challenge: Let's Encrypt uses TXT records for wildcard certificate validation.

_acme-challenge IN TXT "abc123challengevalue"

NS Record — Name Server

Specifies the authoritative nameservers for a domain. NS records tell DNS resolvers which servers have the authoritative answers for a zone.

example.com. IN NS ns1.registrar.com.
example.com. IN NS ns2.registrar.com.

When you register a domain, your registrar's nameservers are set by default. To use Cloudflare, AWS Route 53, or another DNS provider, you update the NS records at your registrar to point to the new provider's nameservers.

Important: NS records at the apex of a zone are delegated from the parent zone (the TLD). They cannot be changed directly — you update them at your domain registrar.

SOA Record — Start of Authority

Contains administrative information about a DNS zone: the primary nameserver, responsible party's email, and several timing parameters.

example.com. IN SOA ns1.registrar.com. hostmaster.example.com. (
  2024030101  ; Serial (usually YYYYMMDDNN)
  3600        ; Refresh — how often secondary NS checks for updates
  900         ; Retry — how long to wait before retrying failed refresh
  604800      ; Expire — how long secondary NS keeps zone data if primary is down
  300         ; Negative TTL — how long to cache "record not found" responses
)

The SOA record is automatically managed by your DNS provider. You rarely need to edit it directly, but the serial number increments with every zone change.

PTR Record — Pointer (Reverse DNS)

Maps an IP address back to a hostname. PTR records are the reverse of A records.

34.216.184.93.in-addr.arpa. IN PTR example.com.

Reverse DNS (rDNS) lookups are critical for:

• Email deliverability — many mail servers reject email from IPs without PTR records
• Network troubleshooting — traceroute and mtr use PTR records to show hostnames
• Logging and auditing — PTR records make IP addresses in logs human-readable

PTR records live in the in-addr.arpa. zone (for IPv4) or ip6.arpa. zone (for IPv6). They're controlled by whoever owns the IP address allocation — typically your server hosting provider, not your domain registrar.

For cloud servers, set PTR records (called "reverse DNS" or "rDNS") in your hosting provider's control panel.

SRV Record — Service

Defines location (hostname and port) for specific services. Enables service discovery without hardcoded ports.

_service._proto.name. TTL IN SRV priority weight port target.
_xmpp-client._tcp.example.com. IN SRV 10 5 5222 xmpp.example.com.
_sip._tcp.example.com. IN SRV 10 20 5060 sip.example.com.

The format:

• _service — service name (e.g., _xmpp-client, _sip, _ldap)
• _proto — protocol (_tcp or _udp)
• priority — lower = more preferred (like MX)
• weight — load balancing weight at same priority
• port — port number the service runs on
• target — hostname of the server

Common uses:

• Microsoft Teams/Skype for Business SIP records
• Kubernetes etcd cluster discovery
• XMPP/Jabber chat server locations
• Active Directory LDAP/Kerberos service locations

CAA Record — Certification Authority Authorization

Specifies which Certificate Authorities are authorized to issue SSL/TLS certificates for your domain.

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 iodef "mailto:security@example.com"

CAA records are a security control — a CA must check CAA records before issuing a certificate. If example.com only allows Let's Encrypt, no other CA should issue certificates for it.

The iodef tag specifies where to report issuance attempts that violate the CAA policy.

TTL: Time To Live

Every DNS record has a TTL value (in seconds) that controls how long resolvers cache the record.

DNS propagation: When you change a record, the change propagates based on the old record's TTL. If TTL was 86400, changes can take up to 24 hours to reach all resolvers worldwide.

Best practice before migrations:

1. Lower TTL to 300 (5 minutes) at least 24-48 hours before the migration
2. Make the DNS change
3. Wait for propagation (5-10 minutes now instead of hours)
4. After stable, raise TTL back to 3600+

DNS Troubleshooting

Check records from the command line

# Query a specific record type
dig example.com A
dig example.com MX
dig example.com TXT

# Query a specific DNS server (e.g., Google's 8.8.8.8)
dig @8.8.8.8 example.com A

# Full response with TTL and flags
dig +ttl example.com NS

# Trace the full DNS resolution chain
dig +trace example.com

Common DNS problems

"Record not found" after update: The old record is still cached. Wait for TTL expiration, or test against the authoritative nameserver directly:

# Find the authoritative NS
dig example.com NS
# Query it directly
dig @ns1.example.com example.com A

Email not delivering after MX change: Check that MX records propagated and that the mail server's PTR record matches its A record.

SSL certificate issued for wrong hostname: Check CAA records. Use our SSL Checker to verify the certificate chain.

Subdomain not resolving: Verify the CNAME target resolves. Check for CNAME + other record conflicts.

Browser-based DNS lookup

Use our DNS Lookup tool to query any DNS record type for any domain using Google's DNS-over-HTTPS service. It queries authoritative DNS in real-time, bypassing any local resolver cache, so you see current DNS state.

DNS Security: DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses, allowing resolvers to verify that records haven't been tampered with. It protects against DNS cache poisoning and man-in-the-middle attacks.

DNSSEC adds new record types:

• RRSIG — cryptographic signature over a record set
• DNSKEY — public keys for verifying RRSIG records
• DS — delegation signer, links parent and child zone keys
• NSEC/NSEC3 — authenticated denial of existence

Many major TLDs and DNS providers support DNSSEC. Enable it if your registrar and hosting provider both support it.

Summary

Use our DNS Lookup tool to inspect any of these records for any domain, in real-time, without installing any software.