UseToolSuite UseToolSuite

DNS Records Explained: What Every Developer Should Know

A practical guide to DNS records: A and AAAA resolution, the CNAME apex constraint, SPF/DKIM/DMARC email authentication, TTL strategy, and DNSSEC.

Necmeddin Cunedioglu Necmeddin Cunedioglu 6 min read
Part of the HTTP Status Codes: The Complete Guide for Developers series

Practice what you learn

DNS Lookup

Try it free →

DNS Records Explained: What Every Developer Should Know

Here’s a DNS mistake that takes down email for a whole company. Someone moves the production domain to a new AWS load balancer with a CNAME record — but puts the CNAME on the apex domain (example.com instead of www.example.com). That conflicts with the existing MX records, and email silently stops working over the weekend. Nobody notices until Monday.

DNS looks simple until it breaks, and when it breaks the symptoms are strange: a site loads fine in New York but fails in London, emails vanish without bounce-backs, or SSL renewals suddenly fail validation.

Understanding how DNS records work at the protocol level prevents these incidents and makes troubleshooting much faster when they do happen.

Stop guessing at your DNS. Run recursive queries against any domain with our DNS Lookup tool. It checks A, AAAA, MX, CNAME, TXT, and NS records using DNS-over-HTTPS (DoH) — private, with no terminal required.

1. How DNS Resolution Works

When a user types https://api.example.com, a distributed hierarchical lookup runs in about 50 milliseconds:

1. Browser cache check → MISS
   Chrome checks its internal DNS cache (chrome://net-internals/#dns).

2. OS cache check → MISS
   The OS checks its local cache (e.g., macOS mDNSResponder).

3. Recursive resolver query
   The query hits the configured recursive resolver (the ISP's, or a public one like Cloudflare 1.1.1.1 or Google 8.8.8.8).

4. Root server query
   The resolver asks a root nameserver: "Who handles the '.com' TLD?"

5. TLD server query
   The root replies: "Ask the .com TLD nameservers."
   The resolver asks the TLD: "Who handles 'example.com'?"

6. Authoritative server resolution
   The TLD replies: "example.com is delegated to 'ns1.route53.aws.com'."
   The resolver asks Route 53: "What's the 'A' record for 'api.example.com'?"

7. Final delivery
   Route 53 responds: "93.184.216.34, with a TTL of 3600 seconds."
   The resolver caches the result and hands it to the browser, and the TCP connection begins.

Each response includes a TTL (Time To Live) — how many seconds downstream resolvers may cache the result. This is why DNS changes don’t take effect instantly worldwide: stale records stay cached in ISP servers until their TTL expires.

2. The Core Record Types

A record (IPv4 address)

The most fundamental record. It maps a domain name to a 32-bit IPv4 address.

example.com.        A    93.184.216.34
api.example.com.    A    93.184.216.34

You can set multiple A records for one domain (round-robin DNS). The resolver returns all the IPs and the client picks one — a basic form of load balancing.

api.example.com.    A    10.0.1.1
api.example.com.    A    10.0.1.2
api.example.com.    A    10.0.1.3

AAAA record (IPv6 address)

Same idea as an A record, but for 128-bit IPv6 addresses. The “quad-A” name comes from IPv6 addresses being four times longer than IPv4.

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

Recommendation: for a modern service, configure both A and AAAA records. Global IPv6 adoption is above 40%, and many 5G mobile networks are IPv6-only. Omit the AAAA record and mobile users hit latency from carrier NAT64 translation.

CNAME record (canonical name)

Creates an alias pointing to another domain name rather than an IP. When the resolver hits a CNAME, it follows the chain to find the terminating IP.

www.example.com.    CNAME    example.com.
blog.example.com.   CNAME    my-tenant.netlify.app.

The golden rule: never put a CNAME on the apex domain (the root/naked domain, e.g., example.com). The DNS spec says a CNAME can’t coexist with other records at the same level. Since the apex must have SOA and NS records, a CNAME there violates the protocol.

# ❌ Breaks MX records and NS delegation
example.com.    CNAME    my-load-balancer.aws.com.

# ✅ Use A records on the apex, CNAMEs on subdomains
example.com.       A       93.184.216.34
www.example.com.   CNAME   example.com.

The ALIAS/ANAME solution: providers like Route 53, Cloudflare, and DNSimple offer “ALIAS” or “ANAME” records to solve the apex problem. They act like CNAMEs in the dashboard, but at query time the provider resolves the target to an IP and returns a standard A record, sidestepping the restriction.

MX record (mail exchange)

Specifies which SMTP servers handle incoming email for the domain. Each MX record has a priority integer — lower numbers mean higher priority.

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

Mail is delivered to the lowest-priority server first. If it’s unreachable, the sending server falls back to the next one. That’s how email gets built-in redundancy.

TXT record (text strings)

Originally for human-readable notes in the zone file, TXT records are now the Swiss Army knife of DNS, used for email authentication, domain verification, and security policies.

SPF (Sender Policy Framework):

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

Tells receiving servers which IPs and platforms are allowed to send email for your domain. Without SPF, attackers can forge phishing emails that appear to come from your CEO.

DKIM (DomainKeys Identified Mail):

google._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQE..."

Provides a public key that receiving servers use to verify the signature on outgoing email — proof the message wasn’t altered in transit.

DMARC (Domain-based Message Authentication):

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

The enforcement layer. DMARC tells receiving servers what to do when an email fails SPF or DKIM.

  • p=none: monitor only — deliver but send a report.
  • p=quarantine: send the failing email to spam.
  • p=reject: drop the failing email before it reaches the user.

NS record (nameserver delegation)

Identifies the authoritative nameservers for the domain. These are set at your registrar (Namecheap, GoDaddy) and delegate control to your DNS host (Cloudflare, Route 53).

example.com.    NS    ns1.cloudflare.com.
example.com.    NS    ns2.cloudflare.com.

3. TTL (Time To Live)

Every record has a TTL in seconds. When a resolver caches a record, it won’t query your authoritative server again until that TTL expires.

TTLDurationUse case
601 minuteDuring active migrations or failover
3005 minutesDynamic load balancers or frequently changing IPs
36001 hourThe baseline for most static A/CNAME records
8640024 hoursStable records (NS, MX)

The migration strategy: lower the TTL to 60 seconds 24–48 hours before a server migration, so global caches pick up the short TTL. When you update the IP during the migration window, propagation takes 60 seconds instead of 24 hours. Once the new setup is stable, raise the TTL back to 3600.

4. Command-Line Debugging

When DNS fails, use dig to query the hierarchy directly.

# 1. See what your local resolver returns
dig api.example.com A +short

# 2. Bypass local caches and query Google's public resolver
dig @8.8.8.8 api.example.com A

# 3. Query the authoritative nameserver to confirm your changes saved
dig @ns1.cloudflare.com api.example.com A

# 4. Trace recursively from the root servers down to authoritative
# The best command for finding broken delegation chains
dig +trace api.example.com

5. DNSSEC: Cryptographic Integrity

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, preventing cache-poisoning attacks where an attacker returns fake DNS responses.

Without DNSSEC:

Browser → "Where is secure-bank.com?" → ISP Resolver → Authoritative server
        ← "It's at 104.22.5.1" ← (Can be intercepted and altered)

With DNSSEC:

Browser → "Where is secure-bank.com?" → ISP Resolver → Authoritative server
        ← "It's at 104.22.5.1, signed with cryptographic key XYZ" 

DNSSEC uses a Key Signing Key (KSK) and a Zone Signing Key (ZSK) to build a chain of trust up to the root zone. It’s complex to deploy by hand, but providers like Cloudflare let you enable it with one click.

Further Reading


Stop guessing why your subdomains won’t resolve. Our DNS Lookup tool queries all record types over DNS-over-HTTPS (DoH) — private and accurate, right in your browser. When verifying Nginx configs, use the SSL Certificate Checker to catch certificate-chain issues.

Necmeddin Cunedioglu
Necmeddin Cunedioglu Author
6 min read
-- views

Software developer and the creator of UseToolSuite. I write about the tools and techniques I use daily as a developer — practical guides based on real experience, not theory.