Enter a domain name without protocol (e.g., google.com)
DNS Records for

DNS Record Types: Complete Reference for System Administrators

Every DNS zone contains multiple record types that serve specific functions. Understanding each type is essential during migrations, email configuration, CDN setup, and incident response.

TypePurposeExample ValueCommon Pitfall
AMaps hostname to IPv4 address93.184.216.34Multiple A records provide round-robin load distribution, not automatic failover
AAAAMaps hostname to IPv6 address2606:2800:220:1:248:1893:25c8:1946If your server has no IPv6 connectivity, omit AAAA — broken IPv6 breaks dual-stack clients
CNAMEAlias one name to anotherwww.example.com. → example.com.Cannot coexist with other records at the same name. CNAME at zone apex violates RFC 1912
MXMail exchanger with priority10 mail.example.com.Lower priority number = higher preference. MX target must be an A/AAAA record, never a CNAME
TXTArbitrary text data"v=spf1 include:_spf.google.com ~all"Single TXT string max 255 characters. SPF flattening needed when include chains exceed 10 lookups
NSAuthoritative nameserversns1.jokercms.com.NS records at apex must match parent zone delegation at registrar or queries break silently
PTRReverse DNS (IP to hostname)34.216.184.93.in-addr.arpa. → example.com.Your ISP or hosting provider controls PTR — editing your DNS zone file does not change it
SOAStart of Authority — zone metadatans1.example.com. admin.example.com. 2026061001 3600 900 1209600 86400Serial number must increment with every zone change or secondary servers never sync
SRVService locator0 5 5060 sip.example.com.Used for SIP, LDAP, XMPP. Priority and weight control load distribution and failover
CAACertificate Authority Authorization0 issue "letsencrypt.org"Restricts which CAs can issue certificates. Missing CAA means any CA can issue for your domain

How DNS Resolution Works Under the Hood

When you type a domain into a browser, a multi-step chain fires in milliseconds. Understanding each hop helps diagnose "it works for me but not for you" problems during DNS migrations.

  1. Stub resolver (OS): Your operating system checks /etc/hosts (Linux/Mac) or the local DNS cache. If the hostname is found, resolution stops here — DNS servers are never queried.
  2. Recursive resolver: If not cached locally, the query goes to your configured DNS server (8.8.8.8, 1.1.1.1, or your ISP's resolver). This resolver performs the heavy lifting on your behalf.
  3. Root nameservers: The recursive resolver queries a root server (a.root-servers.net through m.root-servers.net). Root responds with the TLD nameservers for .com, .org, etc.
  4. TLD nameservers: The resolver asks the .com servers "who handles example.com?" TLD responds with the domain's authoritative nameservers and their glue records.
  5. Authoritative nameserver: The resolver queries the domain's authoritative nameserver directly. This server returns the actual A, AAAA, MX, or other record from the zone file.
  6. TTL caching: Every DNS answer includes a Time-To-Live (TTL) in seconds. The recursive resolver caches the answer and serves it to all subsequent queries until the TTL expires. This is why DNS changes are not instant.
Key insight: If you changed DNS records but still see old values, the problem is either your local cache (ipconfig /flushdns on Windows), your ISP's resolver cache, or the old TTL has not expired. Use the DNS Propagation Checker to verify from multiple global resolvers.

3 Common DNS Troubleshooting Workflows

Scenario 1: Website Not Loading After DNS Change

  1. Run a DNS Lookup — verify the A record points to the correct IP address
  2. Check the record TTL — if high (3600+), old cached records may persist for an hour
  3. Use the DNS Propagation Checker to see global resolution status
  4. Test directly against the authoritative nameserver: dig +short example.com @ns1.yourhost.com
  5. Clear your local DNS cache: ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (Mac)

Scenario 2: Email Not Arriving (MX Issues)

  1. Run DNS Lookup — check that MX records exist and have the correct priority values
  2. Verify the MX target resolves to a valid A record (MX pointing to a CNAME violates RFC 2181)
  3. Run the Email Authentication Checker — SPF, DKIM, and DMARC must be aligned
  4. Use the SMTP Tester to verify the mail server responds on port 25
  5. Check if your mail server IP is on any DNS blacklists

Scenario 3: Subdomain Not Resolving

  1. Verify the subdomain has an explicit A, AAAA, or CNAME record in the zone file
  2. Wildcard records (*.example.com) do not cover nested subdomains like api.staging.example.com
  3. If the subdomain is delegated to different nameservers, NS records must exist at the parent zone level
  4. Query the authoritative server directly: dig +short sub.example.com @ns1.yourhost.com
  5. Check for DNSSEC issues — expired RRSIG signatures cause SERVFAIL for subdomains in signed zones

5 DNS Gotchas That Break Production Environments

1. CNAME at zone apex: example.com CNAME other.example.com. violates RFC 1912. The apex requires A/AAAA records. Use ALIAS, ANAME, or a simple HTTP redirect instead.
2. Glue record mismatch: When your nameserver is ns1.example.com and lives inside example.com, the registrar must provide glue records (A/AAAA for the NS hostnames). Without them, resolvers enter a circular dependency loop.
3. Missing trailing dot in zone files: www.example.com without a trailing dot gets the zone origin appended, becoming www.example.com.example.com.. Always use fully qualified domain names with a trailing dot in zone files.
4. DNSSEC chain break: If you enable DNSSEC and then change nameservers without updating DS records at the registrar, validating resolvers see a broken chain of trust and return SERVFAIL for your entire domain.
5. SPF 10-lookup limit: RFC 7208 limits SPF to a maximum of 10 DNS lookups. Each include:, a:, mx:, and ptr: mechanism counts. Exceeding 10 results in a permanent error and mail rejection. Use the SPF Flattener to resolve this.

CLI Equivalent

If you have shell access, use the dig command for the same results:

# Query all common record types
dig +short example.com A
dig +short example.com AAAA
dig +short example.com MX
dig +short example.com TXT
dig +short example.com NS
dig +short example.com CNAME
# Query a specific resolver
dig +short example.com A @8.8.8.8

Next Steps: Related Tools

After verifying DNS records, check propagation status, test email authentication, or look up domain ownership data.

A DNS record is an entry in a zone file that tells DNS resolvers how a domain should map to IP addresses, mail servers, verification tokens, aliases, or nameservers. Common types include A (IPv4), AAAA (IPv6), MX (mail), TXT (SPF/DKIM/verification), and CNAME (alias).

An MX (Mail Exchanger) record tells other mail servers where to deliver email for a domain. Each MX record has a priority number — a lower number means higher priority. The target must be an A or AAAA record, never a CNAME. If your MX record is missing or incorrect, incoming email delivery stops entirely.

TXT records store text data used for SPF (sender policy), DKIM (signing keys), DMARC (policy), domain ownership verification (Google, Microsoft, Facebook), and other service configuration. Multiple TXT records can exist at the same name — resolvers return all of them.

TTL (Time to Live) is the number of seconds a DNS resolver may cache a record before querying the authoritative server again. Lower TTLs (60-300 seconds) help during migrations because changes appear faster. Higher TTLs (3600-86400 seconds) reduce query load but delay propagation of changes.

DNS propagation delay happens because recursive resolvers cache records based on the TTL value. Your ISP, corporate network, or local browser DNS cache may still hold outdated entries even after the TTL expires. Use the DNS Propagation Checker to see how your change resolves from multiple geographic locations simultaneously.