DNS Record Debugging: A, AAAA, CNAME, TXT, MX, and CAA Explained

DNS is easy to ignore while it works. Then a domain migration sends half of your users to the old server, email starts bouncing after an MX edit, or an automated certificate renewal fails even though the website still loads. At that point, changing application code will not help: the client may never reach the intended service.

Effective DNS debugging is less about memorizing record definitions and more about asking the system in the right order. First prove which nameservers are authoritative. Then query those servers directly. Only after authority agrees should you compare recursive resolver caches, local operating-system caches, and application behavior.

The DNS debugging model: delegation, authority, cache, client

The phrase “DNS propagation” is convenient but imprecise. Editing an A record does not push that record into every resolver on the internet. Your authoritative DNS provider publishes the new answer, while recursive resolvers continue serving previously cached answers until their TTLs expire or local policy causes a refresh.

There can still be real replication time inside a managed authoritative DNS platform, and nameserver changes require the parent zone or registry to publish new delegation data. But most ordinary post-change disagreement is about cache state, not a single database slowly copying itself around the world.

Anycast does not mean every resolver has one shared cache

Public resolver addresses such as Cloudflare's 1.1.1.1 and Google's 8.8.8.8 are commonly reached through anycast: the same IP address is announced from multiple network locations, and routing usually sends a query to a nearby service site. Anycast improves availability and latency, but it does not prove that every service location has identical cache state at every instant.

Teams in New York, Toronto, and London can therefore observe different answers without a single global DNS database being “stuck.” Differences may reflect remaining TTL, geo-aware authoritative responses, EDNS Client Subnet behavior, split-horizon DNS, resolver filtering, or inconsistent authoritative servers. Compare answers, TTLs, flags, and the responding server—not only the returned IP address.

Record-by-record debugging map

Trap 1: the CNAME apex conflict

A CNAME says that its owner name is an alias and that the canonical data lives at another name. DNS rules require a CNAME not to coexist with other data at the same owner. That is why a conventional CNAME works for www.example.com but conflicts at the zone apex example.com, where SOA and NS data must exist. The apex may also need MX, TXT, and CAA records.

# Valid at a non-apex owner when no other data shares the name
www.example.com. 300 IN CNAME app.hosting.example.

# Not a standards-compliant apex combination
example.com. 300 IN CNAME app.hosting.example.
example.com. 300 IN MX 10 mail.example.com.

Provider-specific ALIAS and ANAME records, or CNAME flattening, solve the product need by returning address data to clients rather than exposing a conflicting CNAME RRset at the apex. These are authoritative-provider features, not portable DNS record types with one universal behavior. Confirm how your provider handles TTLs, target refresh, DNSSEC, and failures when the final target has no A or AAAA records.

If flattening returns no address, query the target chain directly. A dangling target can look like a propagation problem even when the apex feature is working exactly as designed.

CNAME loops and chains

A CNAME can also fail away from the apex. Check that its target exists, that the chain does not loop back to an earlier name, and that the final name returns the required address records. Long chains add resolution work and create more dependencies.

dig www.example.com CNAME
dig app.hosting.example A
dig app.hosting.example AAAA

Trap 2: A works but AAAA sends users somewhere else

Publishing both A and AAAA creates a dual-stack service. A correct IPv4 endpoint does not compensate for an IPv6 address that routes to an old server, drops traffic at a firewall, lacks the virtual host, or presents the wrong TLS certificate.

Many modern clients implement Happy Eyeballs-style connection racing or fallback to reduce the user-visible impact of a broken address family. That means the outline's blanket claim that a bad AAAA record always prevents the site from loading is too strong. Some clients fall back quickly; others pause, time out, or fail due to implementation and network conditions. The result can still be a serious regional or mobile-only incident.

dig example.com A +short
dig example.com AAAA +short

# Test each family independently
curl -4 -I https://example.com/
curl -6 -I https://example.com/

Do not delete AAAA reflexively. Verify the IPv6 route, security group or firewall, load balancer listener, origin binding, certificate, and HTTP response. Remove the record only if the service is intentionally IPv4-only and there is no working IPv6 endpoint to publish.

Trap 3: TXT records are valid, but the policy inside is not

DNS allows multiple TXT records at the same owner name. Google verification, Microsoft verification, and an SPF policy can coexist at example.com. The problem is not “multiple TXT records” in general; it is multiple records that claim to be the same singleton policy, or text published at the wrong owner name.

SPF: one applicable v=spf1 record per owner

RFC 7208 treats multiple SPF records found for the same name as a permanent error. Merge authorized senders into one policy instead of publishing two v=spf1 records:

# Wrong: two competing SPF policies
example.com. TXT "v=spf1 include:_spf.google.com -all"
example.com. TXT "v=spf1 include:spf.protection.outlook.com -all"

# Structurally one SPF policy; still audit lookup limits and authorization
example.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Combining text is only the first step. Check SPF's DNS-lookup limit, include chains, redirect behavior, duplicate mechanisms, and whether the final policy actually authorizes every legitimate sender.

Long TXT data: one RR can contain multiple strings

A single TXT resource record can contain multiple character strings. This is used for values that exceed the 255-octet limit of one character-string. DNS clients concatenate the strings within that RR for SPF evaluation. Do not confuse multiple strings inside one TXT RR with multiple competing SPF RRs.

selector1._domainkey.example.com. TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
  "continued-public-key-data..."
)

Hosted DNS interfaces handle quoting and splitting differently. Inspect the published answer with dig rather than judging only the dashboard representation.

SPF, DKIM, and DMARC use different owner names

# SPF at the sending domain
dig example.com TXT

# DKIM at a selector-specific owner
dig selector1._domainkey.example.com TXT

# DMARC at _dmarc
dig _dmarc.example.com TXT

A correct DKIM public key at the root domain is still in the wrong place if the message signs with s=selector1. Read the selector and signing domain from a real message header, then query that exact name.

Trap 4: MX targets, priorities, and trailing dots

An MX record contains a preference number and a target hostname. Lower preference numbers are preferred. The target should resolve to address records and should not itself be a CNAME alias. It is not an IP address and does not include a port.

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

mail1.example.net. 3600 IN A 192.0.2.25
mail1.example.net. 3600 IN AAAA 2001:db8::25

In a BIND-style zone file with an origin of example.com., an unqualified target such as mail.example.net is relative and can become mail.example.net.example.com.. A trailing dot marks a fully qualified name. But provider dashboards are not raw zone files: many automatically treat the input as fully qualified or strip the dot. Follow the provider's documented format and verify the answer actually published.

dig example.com MX +noall +answer
dig mail1.example.net A +short
dig mail1.example.net AAAA +short

If a domain intentionally accepts no email, use a properly configured Null MX according to your mail policy rather than pointing at a nonexistent host by accident. A normal MX target that returns NXDOMAIN is an outage, not a spam-control technique.

Trap 5: CAA silently blocks certificate issuance

CAA records publish which certificate authorities are authorized to issue publicly trusted certificates for a domain. If no relevant CAA record exists, public CAs may issue after completing their normal validation. Once a CAA policy exists, a CA must evaluate whether it is authorized before issuance.

# Authorize Let's Encrypt for ordinary certificates
example.com. 300 IN CAA 0 issue "letsencrypt.org"

# Authorize Let's Encrypt for wildcard certificates
example.com. 300 IN CAA 0 issuewild "letsencrypt.org"

# Optional incident-reporting contact
example.com. 300 IN CAA 0 iodef "mailto:[email protected]"

If the relevant CAA RRset authorizes only another issuer, Let's Encrypt must refuse issuance. This is a standards and CA-policy control, not merely a warning, but calling it “legally barred” is imprecise. The operational result is still the same: the ACME renewal cannot complete until the CAA policy authorizes the issuer or is removed.

CAA can be inherited from a parent name

CAA processing searches the requested name and then ascends the DNS tree until it finds the relevant CAA RRset, following aliases as specified. A restrictive record on example.com can therefore affect api.example.com when the subdomain has no closer CAA policy. Query the exact certificate name and its parents.

dig api.example.com CAA
dig example.com CAA
dig api.example.com CNAME

Also distinguish “not authorized” from a CAA lookup failure. SERVFAIL, DNSSEC validation errors, timeouts, and inconsistent authoritative answers can stop a CA from obtaining a trustworthy policy result. Read the ACME client's detailed error and test the CAA query through validating resolvers.

Trap 6: authoritative nameservers disagree

If one authoritative server publishes the old record while another publishes the new one, recursive resolvers can cache either answer. Waiting for the recursive TTL will not repair the source inconsistency; each refresh can retrieve a different value again.

dig NS example.com +short

dig @ns1.provider.example example.com A +norecurse
dig @ns2.provider.example example.com A +norecurse
dig @ns3.provider.example example.com A +norecurse

dig @ns1.provider.example example.com SOA +norecurse
dig @ns2.provider.example example.com SOA +norecurse

Compare serial numbers, answer data, TTLs, and authoritative flags. Common causes include a failed secondary-zone transfer, editing the wrong provider account, an incomplete nameserver migration, or parent delegation that still lists retired servers.

Trap 7: negative caching survives after you create the record

DNS caches absence as well as presence. If a resolver queried new.example.combefore you created it, it may cache NXDOMAIN or NODATA based on the zone's SOA negative caching values. Adding an A record with a 300-second TTL does not erase the earlier negative answer from that resolver.

dig new.example.com A
dig example.com SOA +noall +answer

# Compare a resolver with authority
dig @1.1.1.1 new.example.com A
dig @ns1.provider.example new.example.com A +norecurse

This is one reason “the new TTL is five minutes” is not a complete migration forecast. Record creation, deletion, and type changes can interact with negative caches in ways that an ordinary positive-answer TTL does not describe.

Trap 8: DNSSEC turns a data mistake into SERVFAIL

With DNSSEC, a validating resolver checks the chain of trust and signatures. A mismatch between the DS record at the parent and DNSKEY data in the child zone, expired signatures, or incorrect denial-of-existence proofs can make data that appears present return SERVFAIL to validating clients.

dig example.com A +dnssec
dig example.com DNSKEY +dnssec
dig example.com DS +trace

Comparing a validating resolver with a non-validating diagnostic path can help classify the issue, but disabling validation is not the production fix. Repair the DS/DNSKEY/signature chain and confirm the rollover state with your registrar and authoritative provider.

The dig toolkit: commands that answer different questions

A web lookup is useful for a quick comparison. dig becomes more powerful when each command is tied to one hypothesis.

1. Inspect the system's configured recursive answer

dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com CAA

Read the status, flags, answer section, TTL, and SERVER line. +short is good for scripts but hides context that matters during diagnosis.

2. Compare named public recursive resolvers

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A

A difference shows that these resolver endpoints returned different answers. It does not, by itself, prove which answer is correct or that every user of that resolver sees the same result. Next query authority.

3. Discover and query authoritative nameservers

dig NS example.com +short
dig @ns1.provider.example example.com A +norecurse
dig @ns1.provider.example example.com SOA +norecurse

Replace the placeholder nameserver with each actual authoritative server. The SOA serial is a useful comparison signal, but managed DNS platforms do not all expose change state in the same operational way. Compare the answer itself as well.

4. Trace delegation from the root

dig example.com A +trace

+traceperforms an iterative-style walk from root servers through the TLD and authoritative delegation. It is valuable for lame delegation, missing glue, and parent/child mismatch. It does not reproduce the exact cache, filtering, or routing behavior of a user's ordinary recursive resolver.

5. Inspect the full answer without extra noise

dig example.com MX +noall +answer +authority +additional
dig example.com CAA +noall +answer +authority

The additional section may include convenient address data, but do not treat it as a substitute for directly querying a target when correctness matters.

How to interpret common DNS response states

TTL planning without the five-minute myth

Lowering a record TTL before a planned change can reduce how long compliant recursive caches retain the old positive answer. A common migration value is 300 seconds, but it is not universally correct and does not guarantee that the internet updates in five minutes.

Lower the TTL early enough for the previous longer TTL to expire from caches before the cutover. If the existing TTL is 86,400 seconds, changing it to 300 seconds one hour before migration does not shorten a copy already cached for the original duration. Also account for:

• negative caching when names or record types were previously absent;
• parent-zone TTLs when changing nameserver delegation;
• authoritative provider update and replication behavior;
• resolver minimums, maximums, prefetch, and serve-stale behavior;
• application, operating-system, browser, proxy, and JVM caches;
• CDN and load-balancer configuration beyond DNS.

Keep the old origin healthy through the expected cache window when possible. After the migration stabilizes, raise the TTL again to a value that balances query load, resilience, and future change requirements.

A safer DNS migration runbook

1. Inventory the current parent delegation and authoritative nameservers.
2. Export or version-control the current zone before editing.
3. Identify the existing TTL and negative-cache behavior for each changed name.
4. Lower TTLs at least one old-TTL window before cutover when appropriate.
5. Preconfigure the new origin, including IPv4, IPv6, TLS, and host routing.
6. Test the new origin directly without changing public DNS.
7. Change the minimum record set; avoid unrelated DNS edits in the same window.
8. Query every authoritative nameserver until the source answers agree.
9. Compare several recursive resolvers and inspect remaining TTLs.
10. Monitor HTTP, TLS issuance, inbound mail, SPF/DKIM/DMARC, and user traffic.
11. Keep a rollback path and the old origin available through the cache window.
12. Restore the steady-state TTL after validation.

Tool workflow: DNS first, email authentication second

Use the DNS Record Lookup & Propagation Checker to inspect the exact owner name and record type, compare answers, and confirm whether the issue is authoritative data or recursive cache state. Do not use an “all records” view as proof that a name has no other DNS data; DNS does not provide one universal query that guarantees enumeration of every record type.

When the failure involves mail authentication, continue with the DMARC, SPF & DKIM Analyzer and Report Parser. It can help inspect authentication records and turn DMARC aggregate XML into readable findings. DNS presence alone does not prove alignment: SPF authenticates the envelope identity, DKIM signs with a domain and selector, and DMARC evaluates alignment with the visible From domain.

DNS cache and social-preview cache are different systems

Even after DNS is correct, LinkedIn, Slack, and Facebook may keep an older preview because social crawlers, CDNs, and origins have separate caches with separate keys and expiry rules. If the domain resolves correctly but the old social image remains, continue with Why Your Open Graph Image Still Isn't Updating. Do not keep changing DNS to solve an Open Graph cache problem.

Final debugging checklist

1. Query the exact FQDN and exact record type.
2. Confirm parent delegation before trusting the intended DNS dashboard.
3. Query every authoritative nameserver directly with recursion disabled.
4. Compare the answer data, SOA serials, TTLs, flags, and response status.
5. Follow CNAME chains to their final A and AAAA data.
6. Test IPv4 and IPv6 service paths independently.
7. Distinguish multiple TXT records from multiple strings in one TXT RR.
8. Verify MX targets, priorities, address records, and provider name syntax.
9. Query CAA at the certificate name and account for parent inheritance.
10. Check negative caching and DNSSEC before calling a failure propagation delay.
11. Compare recursive resolvers only after authority is known-good.
12. Test the actual HTTP, TLS, and mail services after DNS resolves.

Respect the old TTL—and verify authority

Treat DNS as production configuration: version it, review it, test it, and deploy the smallest safe change. The most important habit is to work from the authoritative source outward. If authority is wrong or inconsistent, waiting on caches cannot fix it. If authority is correct, the previous TTL and negative-cache state explain more than a generic “24 to 48 hours” promise.

Lower TTLs before planned migrations when the risk model supports it, but keep the old service available, verify all address families, and monitor the application above DNS. A correct record is necessary; it is not proof that the route, certificate, web server, or mail system behind it is healthy.