The Domain Name System (DNS) is the backbone of the internet, translating human-readable domain names into machine-readable IP addresses and routing information. Understanding DNS record types is essential for web developers, system administrators, and anyone managing domains. This comprehensive guide covers every major DNS record type with real-world examples, dig/nslookup commands, and practical configuration tips.
1. How DNS Works
When you type a domain name like example.com into your browser, a complex resolution process occurs behind the scenes. Understanding this flow is key to diagnosing DNS issues.
DNS Resolution Flow:
Browser Cache â OS Cache â Recursive Resolver â Root Server â TLD Server â Authoritative Server
â â â
"Ask .com" "Ask ns1. "Here is
TLD server" example.com" 93.184.216.34"
Example: Resolving www.example.com
ââââââââââââ ââââââââââââââââ âââââââââââââââ ââââââââââââ ââââââââââââââââ
â Browser âââââ>â Recursive âââââ>â Root â â .com â â Authoritativeâ
â (client) â â Resolver â â Server â â TLD NS â â NS â
â â<âââââ (8.8.8.8) â<âââââ(.root-serversâââââ>â(gtld- âââââ>â(ns1.example â
â â â â â .net) â âservers) â â .com) â
ââââââââââââ ââââââââââââââââ âââââââââââââââ ââââââââââââ ââââââââââââââââ
A: 93.184.216.34 Caches result "Go ask "Go ask "A 93.184.216.34
(TTL: 300s) (TTL-based) .com TLD" ns1.example.com" TTL 300"Recursive Resolver: Performs the full lookup on behalf of the client. Examples: Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), your ISP DNS.
Authoritative Nameserver: Holds the actual DNS records for a domain. It is the source of truth. Examples: ns1.example.com, Cloudflare nameservers, AWS Route 53.
The entire process typically completes in under 100ms. Caching at every level (browser, OS, resolver) dramatically reduces lookup times for subsequent requests.
2. A Record (Address Record)
The A record is the most fundamental DNS record type. It maps a domain name directly to an IPv4 address. Every website needs at least one A record (or AAAA record for IPv6).
Format: <domain> <TTL> IN A <IPv4-address>
example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN A 93.184.216.34
api.example.com. 60 IN A 203.0.113.50
# Multiple A records for load balancing:
example.com. 300 IN A 93.184.216.34
example.com. 300 IN A 93.184.216.35
example.com. 300 IN A 93.184.216.36TTL (Time to Live): Measured in seconds. A TTL of 300 means resolvers cache this record for 5 minutes. Lower TTLs (60-300) allow faster changes but increase DNS query load. Higher TTLs (3600-86400) reduce load but make changes slower to propagate.
You can set multiple A records for the same domain for round-robin load balancing. DNS resolvers will rotate through the addresses.
Tip: Before migrating servers, lower your A record TTL to 60 seconds 24-48 hours in advance. After migration, you can raise it back to 3600 or higher.
3. AAAA Record (IPv6 Address Record)
The AAAA record (pronounced "quad-A") is the IPv6 equivalent of the A record. As IPv6 adoption grows, AAAA records become increasingly important.
Format: <domain> <TTL> IN AAAA <IPv6-address>
example.com. 300 IN AAAA 2606:2800:0220:0001:0248:1893:25c8:1946
www.example.com. 300 IN AAAA 2606:2800:0220:0001:0248:1893:25c8:1946
# Shortened IPv6 notation:
example.com. 300 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
# Full form: 2606:2800:0220:0001:0248:1893:25c8:1946
# Dual-stack configuration (A + AAAA):
example.com. 300 IN A 93.184.216.34
example.com. 300 IN AAAA 2606:2800:220:1:248:1893:25c8:1946IPv6 addresses are 128 bits long, written as eight groups of four hexadecimal digits separated by colons. Leading zeros can be omitted, and consecutive groups of zeros can be replaced with ::.
Best practice: Configure both A and AAAA records (dual-stack) so your domain is accessible over both IPv4 and IPv6. Most modern CDNs and hosting providers support dual-stack configurations automatically.
4. CNAME Record (Canonical Name)
A CNAME record creates an alias from one domain name to another (the "canonical" name). When a resolver encounters a CNAME, it restarts the lookup using the target domain name.
Format: <alias> <TTL> IN CNAME <canonical-name>
www.example.com. 300 IN CNAME example.com.
blog.example.com. 300 IN CNAME mysite.wordpress.com.
shop.example.com. 300 IN CNAME shops.myshopify.com.
# Resolution chain:
# Query: blog.example.com
# â CNAME: mysite.wordpress.com
# â A: 192.0.78.12 (WordPress resolves the final IP)When to use CNAME: Point subdomains to third-party services (CDNs, SaaS platforms, hosting providers). Point www to the apex domain. Create convenient aliases for long hostnames.
Limitation 1 (Root Domain): A CNAME record CANNOT be set on the zone apex (root domain). For example, you cannot create a CNAME for example.com â only for subdomains like www.example.com. This is because CNAME records cannot coexist with other record types, and the root domain must have SOA and NS records.
Limitation 2 (No Coexistence): A CNAME record cannot coexist with any other record type for the same name. If blog.example.com has a CNAME, you cannot also add an MX or TXT record for blog.example.com.
Workaround: Some DNS providers offer ALIAS or ANAME records (non-standard) that function like CNAME at the zone apex. Cloudflare calls this "CNAME flattening." AWS Route 53 uses "Alias" records.
5. MX Record (Mail Exchange)
MX records specify which mail servers accept email for a domain. They are essential for email delivery. Each MX record includes a priority value â lower numbers indicate higher preference.
Format: <domain> <TTL> IN MX <priority> <mail-server>
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
example.com. 3600 IN MX 30 mail3.example.com.Priority: Mail servers try to deliver to the lowest-priority (highest-preference) server first. If it is unavailable, they fall back to the next. In this example, mail1 is tried first, then mail2, then mail3.
Google Workspace MX records:
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.
example.com. 3600 IN MX 10 ALT3.ASPMX.L.GOOGLE.COM.
example.com. 3600 IN MX 10 ALT4.ASPMX.L.GOOGLE.COM.Microsoft 365 MX records:
example.com. 3600 IN MX 0 example-com.mail.protection.outlook.com.Important: MX records must point to a hostname (A/AAAA record), NEVER to an IP address or CNAME. The target hostname must have its own A record.
6. TXT Record (Text Record)
TXT records store arbitrary text data associated with a domain. They are widely used for email authentication (SPF, DKIM, DMARC), domain ownership verification, and security policies.
Format: <domain> <TTL> IN TXT "<text-string>"
SPF (Sender Policy Framework):
SPF specifies which mail servers are authorized to send email on behalf of your domain. It helps prevent email spoofing.
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"v=spf1 â SPF version 1. include: â authorize these third-party senders. -all â reject (hard fail) all other senders. ~all â soft fail (mark as suspicious). ?all â neutral.
DKIM (DomainKeys Identified Mail):
DKIM adds a digital signature to outgoing emails. The receiving server verifies the signature using a public key published in DNS.
google._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."DMARC (Domain-based Message Authentication):
DMARC tells receiving mail servers what to do when SPF and DKIM checks fail. It also enables reporting.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"Domain Verification:
Many services require you to add a TXT record to prove domain ownership:
# Google: google-site-verification=xxxxxxxxxxxx
example.com. 3600 IN TXT "google-site-verification=Abc123XyZ..."
# Let's Encrypt: _acme-challenge.example.com TXT "random-token-string"
_acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"
# Microsoft 365: MS=ms12345678
example.com. 3600 IN TXT "MS=ms12345678"
# Facebook: facebook-domain-verification=xxxxxxxxxxxx
example.com. 3600 IN TXT "facebook-domain-verification=abc123def456"7. NS Record (Nameserver)
NS records specify which nameservers are authoritative for a domain. They delegate DNS resolution to the designated servers. Every domain must have at least two NS records for redundancy.
Format: <domain> <TTL> IN NS <nameserver>
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.
# Common DNS provider nameservers:
# Cloudflare: anna.ns.cloudflare.com, bob.ns.cloudflare.com
# AWS Route53: ns-123.awsdns-45.com, ns-678.awsdns-90.net
# Google: ns-cloud-a1.googledomains.com, ns-cloud-a2.googledomains.comNS records are also used for subdomain delegation. You can delegate a subdomain to different nameservers:
# Subdomain delegation:
dev.example.com. 86400 IN NS ns1.dev-team.com.
dev.example.com. 86400 IN NS ns2.dev-team.com.
# This means all DNS queries for *.dev.example.com
# will be handled by ns1/ns2.dev-team.comNS records typically have high TTLs (86400 = 24 hours) because nameserver changes are infrequent. When migrating DNS providers, the registrar-level NS records must also be updated.
8. SOA Record (Start of Authority)
Every DNS zone has exactly one SOA record. It contains administrative information about the zone, including the primary nameserver, responsible person's email, and timing parameters for zone transfers.
Format: <domain> <TTL> IN SOA <primary-ns> <admin-email> (<serial> <refresh> <retry> <expire> <minimum-ttl>)
example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
2024121501 ; Serial number (YYYYMMDDNN)
7200 ; Refresh (2 hours)
3600 ; Retry (1 hour)
1209600 ; Expire (14 days)
300 ; Minimum TTL (5 minutes, negative caching)
)
# Note: admin.example.com. means admin@example.com
# (the first dot replaces the @ symbol)Serial Number: A version number for the zone. Increment it every time you make a change. Common format: YYYYMMDDNN (e.g., 2024121501). Secondary nameservers compare serial numbers to decide whether to perform a zone transfer.
Refresh (7200 = 2 hours): How often secondary nameservers check the primary for updates.
Retry (3600 = 1 hour): How long a secondary waits before retrying a failed refresh.
Expire (1209600 = 14 days): How long a secondary continues serving the zone if it cannot contact the primary. After this, it stops responding.
Minimum TTL (300 = 5 minutes): The default TTL for negative caching (NXDOMAIN responses). This tells resolvers how long to cache the fact that a record does not exist.
9. SRV Record (Service Record)
SRV records specify the location of services. They include protocol, priority, weight, port, and target host information. SRV records enable service discovery without hardcoding ports or hostnames.
Format: _service._protocol.<domain> <TTL> IN SRV <priority> <weight> <port> <target>
# SIP service over TCP:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
# XMPP client service:
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 xmpp.example.com.
# Minecraft server:
_minecraft._tcp.mc.example.com. 3600 IN SRV 0 5 25565 mc.example.com.
# Format breakdown:
# _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
# | | priority weight port target
# | âââ Protocol (TCP/UDP)
# âââ Service nameFields: Priority (lower = preferred), Weight (for load balancing among same-priority servers), Port (the service port number), Target (the hostname providing the service).
Common uses: Microsoft Active Directory, SIP/VoIP, XMPP/Jabber, Minecraft servers, CalDAV/CardDAV, LDAP.
SRV records are queried by applications that support the protocol. Web browsers do not use SRV records for HTTP â that is handled by A/AAAA/CNAME records.
10. PTR Record (Pointer / Reverse DNS)
PTR records map an IP address back to a domain name â the reverse of an A record. They are stored in a special zone under in-addr.arpa (IPv4) or ip6.arpa (IPv6). Reverse DNS is critical for email deliverability and network diagnostics.
Format: <reversed-IP>.in-addr.arpa. <TTL> IN PTR <domain>
# IPv4 reverse DNS:
34.216.184.93.in-addr.arpa. 3600 IN PTR example.com.
# How the IP is reversed:
# IP: 93.184.216.34
# Reversed: 34.216.184.93
# Full PTR name: 34.216.184.93.in-addr.arpa.
# IPv6 reverse DNS (each hex digit is separated):
# IP: 2001:0db8::1
# PTR: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
# Real-world example:
# $ dig -x 8.8.8.8
# 8.8.8.8.in-addr.arpa. IN PTR dns.google.Email and PTR: Most mail servers perform a reverse DNS lookup on the connecting server's IP. If no PTR record exists, or it does not match the forward (A record) lookup, the email may be rejected or flagged as spam.
PTR records are managed by the owner of the IP address block (usually your hosting provider or ISP). To set a PTR record, you typically need to contact them or use their control panel.
11. CAA Record (Certificate Authority Authorization)
CAA records specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for a domain. They provide an additional layer of security against mis-issuance.
Format: <domain> <TTL> IN CAA <flags> <tag> <value>
# Allow only Let's Encrypt to issue certificates:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
# Allow Let's Encrypt to issue wildcard certificates:
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
# Report violations via email:
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
# Allow multiple CAs:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "amazon.com"
example.com. 3600 IN CAA 0 issue "digicert.com"Tags: issue â authorize a CA to issue certificates for this domain. issuewild â authorize a CA to issue wildcard certificates. iodef â specify a URL or email to receive violation reports.
If no CAA records exist, any CA can issue a certificate for the domain. CAs are required to check CAA records before issuance (per RFC 8659). Setting CAA records is a recommended security best practice.
12. DNS Record Types Comparison Table
This table summarizes all major DNS record types, their purposes, example values, and typical TTL settings.
| Record Type | Purpose | Example Value | Typical TTL |
|---|---|---|---|
A | Maps domain to IPv4 address | 93.184.216.34 | 300-3600 |
AAAA | Maps domain to IPv6 address | 2606:2800:220:1:248:1893:25c8:1946 | 300-3600 |
CNAME | Creates domain alias | www.example.com -> example.com | 300-3600 |
MX | Specifies mail servers | 10 mail.example.com. | 3600 |
TXT | Stores text data (SPF, DKIM, etc.) | "v=spf1 include:_spf.google.com -all" | 3600 |
NS | Delegates nameservers | ns1.example.com. | 86400 |
SOA | Zone authority information | ns1.example.com. admin.example.com. 2024121501 ... | 86400 |
SRV | Service discovery (port & protocol) | 10 60 5060 sipserver.example.com. | 3600 |
PTR | Reverse DNS lookup (IP to domain) | example.com. | 3600 |
CAA | Certificate Authority authorization | 0 issue "letsencrypt.org" | 3600 |
13. DNS Lookup Tools & Commands
These command-line tools help you query and debug DNS records. Every system administrator should be familiar with them.
dig (Domain Information Groper):
The most powerful DNS lookup tool. Available on Linux/macOS. Install on Windows via BIND tools.
# Query A record
$ dig example.com A
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34
# Query MX records
$ dig example.com MX
;; ANSWER SECTION:
example.com. 3600 IN MX 10 mail.example.com.
# Query TXT records (SPF, DKIM, DMARC)
$ dig example.com TXT
;; ANSWER SECTION:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com -all"
# Query specific nameserver
$ dig @8.8.8.8 example.com A
# Query all record types
$ dig example.com ANY
# Short output (just the answer)
$ dig +short example.com A
93.184.216.34
# Trace the full resolution path
$ dig +trace example.com A
# Query CNAME
$ dig www.example.com CNAME
;; ANSWER SECTION:
www.example.com. 300 IN CNAME example.com.
# Reverse DNS lookup
$ dig -x 93.184.216.34nslookup:
Available on all platforms (Windows, Linux, macOS). Simpler than dig but less detailed.
# Basic A record lookup
$ nslookup example.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
# Query specific record type
$ nslookup -type=MX example.com
example.com mail exchanger = 10 mail.example.com.
$ nslookup -type=TXT example.com
example.com text = "v=spf1 include:_spf.google.com -all"
# Use specific DNS server
$ nslookup example.com 1.1.1.1
# Query NS records
$ nslookup -type=NS example.com
example.com nameserver = ns1.example.com.
example.com nameserver = ns2.example.com.host:
A simplified DNS lookup tool available on Linux/macOS. Good for quick lookups.
# Basic lookup
$ host example.com
example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 10 mail.example.com.
# Query specific type
$ host -t MX example.com
example.com mail is handled by 10 mail.example.com.
$ host -t TXT example.com
example.com descriptive text "v=spf1 include:_spf.google.com -all"
# Reverse lookup
$ host 93.184.216.34
34.216.184.93.in-addr.arpa domain name pointer example.com.
# Verbose output
$ host -v example.comOnline tools: Our IP Calculator tool can help you understand network configurations alongside your DNS setup.
Try our IP Calculator tool for network analysis
IP Calculator âFAQ
What is the difference between an A record and a CNAME record?
An A record maps a domain directly to an IPv4 address (e.g., 93.184.216.34), while a CNAME record maps a domain to another domain name (an alias). A records are used for the final destination, while CNAMEs are used to point one name to another. CNAMEs cannot be used on the root domain (zone apex).
Can I use a CNAME record for my root domain (example.com)?
No. Per the DNS specification (RFC 1034), a CNAME cannot coexist with other record types, and the root domain must have SOA and NS records. Some DNS providers offer proprietary workarounds like ALIAS records (DNS Made Easy), ANAME records (Route 53), or CNAME flattening (Cloudflare) that achieve a similar effect.
What MX records do I need for Google Workspace?
Google Workspace requires five MX records: ASPMX.L.GOOGLE.COM (priority 1), ALT1.ASPMX.L.GOOGLE.COM (priority 5), ALT2.ASPMX.L.GOOGLE.COM (priority 5), ALT3.ASPMX.L.GOOGLE.COM (priority 10), and ALT4.ASPMX.L.GOOGLE.COM (priority 10). These provide redundancy across multiple Google mail servers.
How do SPF, DKIM, and DMARC work together?
SPF specifies which servers can send email for your domain. DKIM adds a cryptographic signature to emails that recipients can verify via a DNS-published public key. DMARC ties SPF and DKIM together by telling receivers what to do when checks fail (none, quarantine, or reject) and where to send reports. All three should be configured for proper email authentication.
How long does it take for DNS changes to propagate?
DNS propagation depends on the TTL (Time to Live) of the record being changed. If the old record had a TTL of 3600 (1 hour), it may take up to 1 hour for all resolvers to pick up the change. In practice, most changes propagate within 1-48 hours globally due to caching at various levels. To speed up propagation, lower the TTL well in advance of making changes.