DNS Lookup Troubleshooting Guide

Use a DNS lookup to debug A, CNAME, MX, CAA, TXT, and DNSSEC failures. A resolver-first checklist with dig commands, TTLs, and safe next steps.

A DNS failure is often blamed on “propagation,” but that word hides several different states. The name might not exist, the name might exist without the record type you asked for, a recursive resolver might still hold an older answer, or the authoritative server might be returning an error. Start with the DNS lookup tool, which checks common record types over DNS-over-HTTPS and displays TTLs, response codes, DNSSEC’s AD bit, and plain-English checks for mail and certificate records.

The goal is not to make every resolver answer immediately. The goal is to identify which layer is answering, what it is allowed to cache, and whether the answer is authoritative for the name you are testing.

Ask one precise DNS question first

A DNS query has at least four useful coordinates: the fully qualified name, the record type, the resolver, and the transport. “The domain is down” is not a query. These are:

dig example.com A
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig _dmarc.example.com TXT

The name matters because example.com, www.example.com, and _dmarc.example.com can be served by different labels in the same zone. The type matters because an existing name can have no answer for the requested type. A resolver returning NOERROR with an empty answer section is not the same as returning NXDOMAIN: the first says the name exists but has no record of that type; the second says the name does not exist in the queried namespace. RFC 2308 defines the negative-caching behavior for both kinds of response.

Query a known public resolver as a comparison, but do not treat it as the authority:

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

A public resolver is useful for seeing what a typical user may receive. It can still have a cached answer. The AUTHORITY section, the response code, and the TTL tell you more than a single green checkmark. If you need to inspect the transport used by this site’s tool, RFC 8484 specifies the DNS-over-HTTPS exchange, while the Cloudflare 1.1.1.1 documentation describes its JSON and wire-format endpoints.

Read the answer, not only the address

A useful lookup review records these fields:

An A record points a name to an IPv4 address; an AAAA record does the same for IPv6. A CNAME does not add another address to the same owner name. It aliases that name to another name, which must then be resolved. If www.example.com has a CNAME to a vendor hostname, check the vendor hostname as a separate query. Do not add an A record at the same owner name merely because a browser test used IPv4 and the CNAME looked unfamiliar.

TTL is a cache instruction, not a promise that every resolver will refresh at the exact same second. After a change, query the authoritative server and at least two recursive resolvers. If the authority is correct but a recursive answer is old and its TTL is still counting down, waiting is the safe fix. If the authority itself is wrong, waiting cannot repair the zone.

Negative answers have a TTL too. A resolver can cache the fact that a name or record is absent, so creating the record immediately after an NXDOMAIN may not make it visible to the resolver that already stored the negative result. The SOA in the authority section is part of the evidence for that negative cache. This is why a failed lookup followed by an instant record change can produce apparently contradictory results from two networks.

Follow delegation before editing the zone

If the answer differs between resolvers, inspect the delegation path:

dig +trace example.com A

+trace asks each step from the root toward the authoritative name server. It can show a stale parent delegation, a missing DS record, a nameserver that does not answer, or an authoritative server that serves different zone data from its sibling. The trace is a map of the path, not a replacement for checking the provider’s zone editor.

Compare the nameservers returned for the parent with the nameservers configured at your registrar. Then query each authoritative server directly:

dig NS example.com
dig @ns1.example-dns.com example.com SOA
dig @ns2.example-dns.com example.com SOA

The SOA serial is a quick consistency check. If the serial or answer differs between authoritative servers after a change, the provider’s transfer or publication process is not finished. If all authoritative servers agree and recursive answers differ, cache is the more likely explanation.

Do not “fix” a delegation mismatch by changing several nameservers at once. Record the current delegation, identify the intended provider, and make one controlled change. A nameserver change can affect every record in the zone, including mail and certificate validation.

Treat DNSSEC as a chain, not a green badge

DNSSEC authenticates DNS data; it does not prove that the address is the one you wanted. The DNSSEC protocol description defines how a validating resolver uses signatures and the chain of trust. The AD flag means the resolver validated the answer. It does not mean that every resolver on the Internet will validate it, and it does not make an unsigned zone malicious.

A broken signed delegation can produce SERVFAIL for validating resolvers while an unaware resolver returns an answer. That split is a strong signal to inspect the DS record at the parent, the DNSKEY at the child, and the signature’s validity window:

dig +dnssec example.com A
dig +dnssec example.com DNSKEY
dig +dnssec example.com SOA

Common causes include publishing a DS record for the wrong key, rotating the DNSKEY without updating the parent, or serving signatures that have expired. Make one side of a key rollover authoritative at a time and follow the DNS provider’s documented procedure. Do not remove DNSSEC as a first response to a single client failure; that trades a specific validation problem for a wider loss of authenticity.

The DNSSEC record reference and TLS certificate inspector cover adjacent layers. DNSSEC answers whether the DNS response was authenticated. TLS answers whether the service at the returned address presents a certificate for the hostname. You need both checks for a secure HTTPS diagnosis.

Check CAA before diagnosing ACME

Certificate Authority Authorization records limit which public CAs may issue for a name. RFC 8659 defines the issue, issuewild, and iodef properties. Query the exact name and its parent:

dig example.com CAA
dig sub.example.com CAA

An absent CAA record does not automatically mean issuance is forbidden. CAA policy is inherited from the closest relevant ancestor, and an explicit issue value can restrict issuers. A wildcard certificate is checked against the issuewild property when one is present; do not assume an issue "letsencrypt.org" rule also answers every wildcard case. The Let’s Encrypt CAA guidance explains the issuer value it expects and the DNS lookup behavior its validation performs.

A CAA change can itself be hidden by TTL. Before rerunning an ACME order, query the authoritative server, confirm the record value and parent path, then check the same name through a public resolver. Pair the result with the ACME renewal guide and inspect the certificate served on port 443 rather than trusting only the client exit code.

Audit mail records as a set

Mail authentication is three separate DNS questions that work together:

1. SPF is a TXT record at the envelope-from domain. RFC 7208 limits evaluation to ten DNS-querying mechanisms and modifiers. A long chain of include values can exceed that limit even when every individual provider record is valid; the result is a PermError, not a temporary propagation problem.
2. DKIM is a TXT record at <selector>._domainkey.example.com. The selector comes from the sending service, so a missing selector record can look like a broken domain when the base domain’s TXT record is healthy.
3. DMARC is a TXT record at _dmarc.example.com. RFC 7489 defines its policy and alignment model. A p=reject policy is an instruction to receivers, not proof that SPF and DKIM are aligned for every sender.

Use the DNS record reference to keep the owner names straight. Query TXT directly and check whether a long value is split into several quoted chunks. Those chunks are one logical character string; a parser or manual copy that drops a segment can invalidate the policy. The DNS lookup tool joins split TXT values and calls out SPF, DMARC, MX, and CAA details so you can compare the record with the sender’s configuration.

A fifteen-minute decision tree

1. Name and type: query the exact fully qualified name and record type. If the result is NOERROR with no answer, ask whether the type is absent. If it is NXDOMAIN, read the SOA and negative-cache evidence.
2. Authority: query each authoritative server and compare SOA serials, answers, and DNSSEC status. Fix the zone or delegation if the authority is inconsistent.
3. Resolver: query two public recursive resolvers. If only recursive answers are old, wait for the observed TTL rather than making another edit.
4. Chain: follow CNAME, delegation, and DNSSEC links. A successful lookup of the first name does not prove that the final target or signature is healthy.
5. Application: once DNS is correct, use the HTTP header inspector and TLS inspector to check the response and certificate at the returned address. Keep the DNS result, timestamp, resolver, and command output with the incident record.

A clean DNS answer is a boundary, not a full uptime test. It proves that a resolver found records; it does not prove that the IP accepts traffic, the reverse proxy selects the right host, or the certificate matches. Separating those checks prevents an application failure from turning into an unnecessary zone edit.

Read next

• Try the DNS lookup tool for A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, and DMARC checks.
• Read the CAA record reference before changing ACME policy.
• Use the TLS certificate inspector after DNS points at the intended service.
• Review why ACME renewal can fail quietly when the DNS answer looks correct.

Tags: #dns, #dnssec, #acme, #email, #tls-certs