DNS Records Explained: A, AAAA, CNAME, MX, TXT and NS
What Is DNS?
The Domain Name System (DNS) is the internet's directory service. It translates domain names like example.com into the numeric IP addresses that computers need to route traffic. Without DNS, you'd need to memorize IP addresses for every website you visit.
DNS works through a hierarchy of servers. When your browser needs to resolve a domain name, it queries a recursive resolver (usually operated by your ISP or a public provider like Google or Cloudflare). That resolver checks its cache, and if the answer isn't there, it walks the DNS hierarchy: root servers, then TLD servers (.com, .org), then the domain's authoritative nameservers which hold the actual records.
Those records are the core of DNS. Each record type serves a specific purpose. Understanding them is essential for anyone managing domains, configuring email, or deploying web applications.
A Record
The A record (Address record) maps a domain name to an IPv4 address. It is the most fundamental DNS record type.
example.com. 3600 IN A 203.0.113.10This tells resolvers: "When someone asks for example.com, send them to 203.0.113.10."
When to use an A record
- Pointing a domain to a web server's IPv4 address
- Pointing a subdomain (like
api.example.com) to a specific server - When your hosting provider gives you an IP address to configure
A domain can have multiple A records. This is called round-robin DNS and distributes traffic across several servers:
example.com. 300 IN A 203.0.113.10
example.com. 300 IN A 203.0.113.11AAAA Record
The AAAA record (often called "quad-A") is identical in purpose to the A record, but maps to an IPv6 address instead of IPv4.
example.com. 3600 IN AAAA 2001:db8::1IPv6 addresses are 128 bits (versus IPv4's 32 bits), written as eight groups of hexadecimal digits separated by colons.
When to use a AAAA record
- When your server supports IPv6 and you want dual-stack connectivity
- When targeting users or networks that prefer IPv6 (increasingly common on mobile networks)
Most domains should have both A and AAAA records. Clients that support IPv6 will use the AAAA record; clients that don't will fall back to the A record.
CNAME Record
A CNAME record (Canonical Name) creates an alias from one domain name to another. Instead of pointing to an IP address, it points to another domain name.
www.example.com. 3600 IN CNAME example.com.This says: "To find the address of www.example.com, look up example.com instead." The resolver then follows the chain and resolves example.com to its A/AAAA records.
Important limitations
- A CNAME cannot coexist with other record types at the same name. You cannot have a CNAME and an MX record on the same subdomain. This is the most common CNAME mistake.
- A CNAME cannot be placed at the zone apex (
example.comitself). This is an RFC restriction. Many DNS providers offer a workaround called ALIAS or ANAME records, but those are provider-specific extensions. - CNAME records add a resolution step, introducing a small amount of latency.
CNAME vs A record
Use an A record when you have a fixed IP address. Use a CNAME when you want a subdomain to follow another name—useful when the target IP might change (like CDN endpoints or cloud load balancers).
; CDN integration
cdn.example.com. 300 IN CNAME d1234.cloudfront.net.MX Record
The MX record (Mail Exchange) tells sending mail servers where to deliver email for your domain.
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.The number before the hostname is the priority (lower = higher priority). In this example, mail is delivered to mail1 first. If it's unreachable, senders fall back to mail2.
Key points
- MX records must point to a hostname (A/AAAA record), never directly to an IP address.
- MX records must not point to a CNAME.
- If you use Google Workspace, Microsoft 365, or another email provider, they'll give you specific MX records to configure.
; Google Workspace example
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.TXT Record
The TXT record stores arbitrary text associated with a domain. Originally designed for human-readable notes, TXT records are now critical infrastructure for email authentication and domain verification.
Common uses
SPF (Sender Policy Framework)
SPF declares which servers are authorized to send email for your domain:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"This tells receiving mail servers: "Accept email from Google's servers; treat all others with suspicion."
DKIM (DomainKeys Identified Mail)
DKIM uses a public key published in DNS to verify email signatures:
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjAN..."DMARC (Domain-based Message Authentication)
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Domain verification
Services like Google Search Console, Microsoft 365, and various SaaS platforms ask you to add a TXT record to prove you control the domain:
example.com. IN TXT "google-site-verification=abc123..."Other uses
- DNSBL/blocklist lookups for anti-spam
- CAA records (technically their own type, but sometimes confused with TXT)
- Custom application data for DNS-based service discovery
NS Record
The NS record (Name Server) declares which DNS servers are authoritative for a domain or subdomain.
example.com. 86400 IN NS ns1.dnsprovider.com.
example.com. 86400 IN NS ns2.dnsprovider.com.When you register a domain with a registrar and point it to a DNS provider (like Cloudflare, Route 53, or your hosting provider), you're setting NS records at the registry level.
Delegation
NS records can also delegate a subdomain to different nameservers:
internal.example.com. IN NS ns1.internal-dns.example.com.This is common in large organizations where different teams manage different parts of the DNS hierarchy.
Key points
- Every domain must have at least two NS records for redundancy.
- NS records typically have high TTLs (24–48 hours) because they change infrequently.
- Changing nameservers affects all records for the domain.
How DNS Records Work Together
A realistic domain configuration uses several record types simultaneously. Here's what a typical setup looks like:
; Nameservers
example.com. 86400 IN NS ns1.dnsprovider.com.
example.com. 86400 IN NS ns2.dnsprovider.com.
; Web server
example.com. 300 IN A 203.0.113.10
example.com. 300 IN AAAA 2001:db8::1
www.example.com. 300 IN CNAME example.com.
; Email
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
mail1.example.com. 3600 IN A 203.0.113.20
mail2.example.com. 3600 IN A 203.0.113.21
; Email authentication
example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.20 ip4:203.0.113.21 ~all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
; API on a separate service
api.example.com. 300 IN CNAME api-prod.loadbalancer.example.net.To inspect the records currently configured for any domain, you can query them individually by type using a DNS lookup tool.
TTL and DNS Caching
Every DNS record has a Time To Live (TTL), measured in seconds. TTL tells recursive resolvers how long to cache the record before asking the authoritative server again.
example.com. 300 IN A 203.0.113.10
^^^
TTL = 300 seconds (5 minutes)Common TTL values
- 60–300 seconds — Use before planned changes. Allows fast propagation after the change.
- 3600 seconds (1 hour) — A reasonable default for most records.
- 86400 seconds (24 hours) — Appropriate for stable records like NS records.
Why DNS changes aren't instant
When you update a DNS record, resolvers that already cached the old value will continue serving it until the old TTL expires. This is why DNS changes can take minutes to hours to become visible everywhere. If a DNS change looks correct at the authoritative server but users still see the old value, a DNS propagation checker can help determine which resolvers have updated and which are still serving the cached record.
Tip: Lower your TTL 24–48 hours before a planned change. After the change propagates, raise it back.
Common DNS Mistakes
1. CNAME at the zone apex
Setting a CNAME on example.com (without a subdomain) violates the DNS specification and breaks MX and TXT records. Use an A/AAAA record at the apex, or check if your DNS provider supports ALIAS/ANAME records.
2. CNAME coexisting with other records
If you have a CNAME on app.example.com, you cannot also add an MX or TXT record on app.example.com. The CNAME must be the only record at that name.
3. MX pointing to a CNAME or IP
MX records must point to a hostname with an A/AAAA record. MX 10 203.0.113.10 is invalid. MX 10 alias.example.com. where alias is a CNAME is also technically invalid and may cause delivery failures.
4. Missing trailing dot in zone files
In raw zone file syntax, example.com without a trailing dot is interpreted relative to the zone. example.com. with the dot is absolute. Most DNS provider UIs handle this automatically, but if you're editing zone files directly, a missing dot is a common source of broken records.
5. Forgetting to update SPF when changing email providers
If you switch from one email provider to another, update the SPF TXT record to include the new provider's servers and remove the old ones. Stale SPF records cause legitimate email to be flagged as spam.
6. Setting TTL too high before a change
If your record has a 24-hour TTL and you make a change, resolvers may serve the old value for up to 24 hours. Always lower the TTL in advance.
How to Troubleshoot DNS Changes
If you've changed a DNS record and it isn't working:
- Verify the change at the authoritative server. Query the authoritative nameserver directly to confirm the record is correct. This eliminates caching as a variable.
- Check the TTL of the old record. If the previous TTL was high, resolvers may still be caching the old value. Wait for the TTL to expire.
- Query from multiple locations. Different resolvers cache independently. Use a propagation checker to see which resolvers have the new value.
- Flush your local DNS cache. Your operating system and browser may cache DNS independently of network resolvers.
- Check for typos. DNS records are case-insensitive but whitespace-sensitive. Verify the record type, name, and value are correct.
- Verify nameserver delegation. If you recently changed nameservers, the delegation itself may still be propagating. NS record changes at the registry level can take up to 48 hours.
DNS Record Comparison
| Record | Purpose | Example Value | Common Use |
|---|---|---|---|
| A | Maps name to IPv4 | 203.0.113.10 |
Web server, API endpoint |
| AAAA | Maps name to IPv6 | 2001:db8::1 |
IPv6 web server, dual-stack |
| CNAME | Alias to another name | cdn.example.net. |
CDN, SaaS integration, subdomains |
| MX | Mail delivery | 10 mail.example.com. |
Email routing |
| TXT | Arbitrary text | "v=spf1 ..." |
SPF, DKIM, domain verification |
| NS | Authoritative servers | ns1.provider.com. |
Domain delegation |
Conclusion
DNS records are the configuration layer that makes domains work. A and AAAA records connect names to servers. CNAME records create flexible aliases. MX records route email. TXT records handle authentication and verification. NS records delegate authority.
Understanding these six record types covers the vast majority of DNS configuration tasks you'll encounter as a developer or system administrator. When something goes wrong, methodical troubleshooting—checking the authoritative server, verifying TTLs, and testing from multiple locations—will resolve most issues.