In short
A DNS record can be present in a control panel and still be invisible because the domain delegates to different authoritative nameservers, the record was added under the wrong name or type, a cache holds an earlier negative answer, DNSSEC fails validation, or a CNAME conflicts with other data. Check in that order.
Key takeaways
- Public DNS uses the domain’s delegated authoritative nameservers, not whichever control panel was edited most recently.
- A service checks an exact owner name and record type, so a correct value in the wrong location is still missing.
- When every authoritative server has the correct record, older positive or negative answers may remain cached until their TTL expires.
- SERVFAIL does not prove that a record is absent; it can indicate an authoritative-server or DNSSEC validation failure.
- A CNAME cannot share its owner name with ordinary A, AAAA, MX or TXT data.
Table of contents
- What does a DNS record not found result mean?
- What should you check first?
- Did you add the record at the exact name and type?
- Do all authoritative nameservers return the same answer?
- Could caching still be hiding a fixed record?
- Is DNSSEC causing SERVFAIL?
- Is another record preventing publication?
- What if only one device or network fails?
- What else do people ask about missing DNS records?
- What should you do next?
Start with the public DNS chain, not the browser cache. A website, mail platform or verification service normally asks for one specific DNS name and record type, so each check should use that same name and type.
What does a “DNS record not found” result mean?
A “DNS record not found” message does not identify one fault. It says the querying system did not receive the expected record, so the response code and requested record type come first.
As of September 2026, RFC 9499, the current IETF DNS terminology standard, defines authoritative servers, recursive resolvers, delegation and negative caching as separate parts of DNS. That distinction matters because a record may exist in an editor while remaining absent from the authoritative servers used by the public Internet. (rfc-editor.org)
What does the response actually say?
| Result | What it means | What to check next |
|---|---|---|
NXDOMAIN | The queried DNS name does not exist in the responding view of DNS. | Check spelling, delegation and the complete owner name. |
NOERROR with no answer | The name may exist, but the requested record type was not returned. | Query the exact A, AAAA, CNAME, MX or TXT type. |
SERVFAIL | Resolution failed before a usable answer could be returned. | Check authoritative-server health and DNSSEC. |
Timeout or REFUSED | The server or network path did not provide an answer. | Try an authoritative server and a different network path. |
RFC 2308, published in 1998, distinguishes NXDOMAIN from a no-data response. NXDOMAIN applies when the queried name does not exist, while a no-data response can mean that the name exists but does not have the requested record type. (rfc-editor.org)
Treat the response code as evidence: NXDOMAIN, an empty answer, SERVFAIL and a timeout point to different next steps.
Performance you can feel, backed by clients who depend on it. Read how our support and uptime create long‑term customer success.Power Your Business with Better Hosting
What should you check first?
The first check is whether the domain delegates to the DNS service whose panel was edited. If the delegated NS records point elsewhere, the new record is sitting in a zone that public resolvers never ask.
Delegation occurs through NS records in the parent zone, according to RFC 9499. An authoritative server can contain a copy of a zone without being the server that the parent has actually delegated, which is why opening a familiar DNS editor is not enough. (rfc-editor.org)
What is the fixed checking order?
Use this order and stop as soon as a check fails:
- Read the response code and confirm the requested record type.
- Trace the domain’s public nameserver delegation.
- Check the record’s exact owner name, type and value.
- Query every delegated authoritative nameserver directly.
- Only then investigate caching, DNSSEC, conflicts and local filtering.
Start with these commands where dig is available:
“text dig NS example.com +short dig +trace example.com A “
Replace example.com and A with the domain, hostname and type involved in the failure. The BIND documentation for dig +trace explains that tracing follows delegation referrals from the root towards the authoritative servers instead of relying only on a recursive resolver’s cache. (kb.isc.org)
The names at the end of the trace should belong to the DNS environment where the record was added. If they do not, find the panel that manages those nameservers or update the domain’s delegation through its registrar. If the trace shows no usable delegation, verify the domain’s registration and nameserver settings before editing individual records.
Public DNS only sees records published by the nameservers in the domain’s active delegation.
Did you add the record at the exact name and type?
Services look for an exact pair: an owner name and a record type. A correct value placed at the wrong owner name or saved as another type is still missing.
The 1987 DNS implementation specification, RFC 1035, defines every resource record with a name, type, class, TTL and type-specific data. A lookup for a TXT record does not become successful because an A or CNAME record exists at the same name. (rfc-editor.org)
Check the saved record for these common location errors:
- Apex versus subdomain:
example.comis different fromwww.example.comand_service.example.com. @versus a blank name: DNS panels commonly use one of these to represent the zone apex. Confirm how the saved record is displayed after submission.- A duplicated domain suffix: Entering
verify.example.cominto a panel that automatically appendsexample.comcan createverify.example.com.example.com. - The wrong type: Verification usually requires the stated TXT or CNAME type. Website addressing may require A, AAAA or CNAME. Mail routing requires MX.
- The wrong side of a record: The owner or host field says where the record lives. The target, content or value field says what it points to or contains.
Query the exact name and type rather than the domain alone:
“text dig example.com A +noall +answer +authority dig www.example.com CNAME +noall +answer +authority dig example.com MX +noall +answer +authority dig _service.example.com TXT +noall +answer +authority “
Mail checks are a special case because an A-record lookup does not confirm mail routing. See how MX records route domain email when the missing record affects incoming mail.
A correct DNS value cannot compensate for an incorrect owner name or record type.
Host your website with our 5-star rated, cPanel website hosting plans.
Super fast servers, with security included and hosted in your choice of Australian Data Center.
View cPanel Plans
Do all authoritative nameservers return the same answer?
Every delegated authoritative nameserver should be tested with the same query. If one server has the record and another does not, users and verification services can receive different answers depending on which authoritative server is reached.
First list the nameservers, then query each one directly:
“`text dig NS example.com +short
dig @ns1.provider.example _service.example.com TXT +noall +answer +authority +comments dig @ns2.provider.example _service.example.com TXT +noall +answer +authority +comments “`
Replace the placeholder nameservers with the real NS results. In a successful direct response, look for the expected owner, type and value. The response header should also indicate an authoritative answer.
If every authoritative server omits the record, return to the DNS editor and confirm that the change was saved in the correct zone. If only one server differs, the DNS operator may have a zone distribution or synchronisation problem. Waiting for a laptop cache to clear will not repair a nameserver that is serving different authoritative data.
A record is not reliably published until every delegated authoritative nameserver returns the expected answer.
Could caching still be hiding a fixed record?
Yes. Once the authoritative servers return the correct record, a recursive resolver can still return an older positive or negative answer until the applicable cache lifetime expires.
RFC 1035 defines TTL as the interval for which a resource record may be cached before its source is consulted again. RFC 2308 also requires caching of authoritative negative answers, so a resolver that previously received NXDOMAIN or no data may continue returning that result for the zone’s negative-cache TTL. (rfc-editor.org)
How do cached and authoritative answers differ?
Compare a direct authoritative query with an ordinary recursive query:
“text dig @ns1.provider.example _service.example.com TXT dig _service.example.com TXT “
The first asks a named authoritative server. The second normally asks the resolver configured on the device or network. If the authoritative answer is correct but the recursive answer is old or empty, stop editing the record. Further changes make the timeline harder to understand and do not force remote caches to refresh.
Check the remaining TTL shown in the recursive response, or inspect the SOA data associated with a negative answer. A local cache reset can help when only the affected device is stale, but flushing the DNS cache on the affected device cannot clear a remote verification service’s cache or every recursive resolver on the Internet.
DNS changes do not need a universal 24 or 48 hours. The relevant wait is the remaining TTL on the cached positive or negative answer.
Once authoritative answers are correct, use TTL evidence instead of repeatedly editing the record.
Is DNSSEC causing SERVFAIL?
DNSSEC should be checked when the result is SERVFAIL, especially after changing nameservers or DNS signing settings. SERVFAIL means that resolution failed; it does not mean the requested record has been proved absent.
The DNSSEC standards RFC 4033 and RFC 4035, both published in March 2005, state that data which fails validation can be treated as bogus and returned to the client as server failure. A DS record at the parent that no longer matches the child zone’s DNSKEY can break the validation chain. (rfc-editor.org)
Inspect the relevant records with:
“text dig example.com DS +dnssec dig example.com DNSKEY +dnssec “
The DS record is published on the parent side of the delegation, usually through the registrar. DNSKEY and signatures come from the authoritative DNS operator. Matching them correctly requires more than comparing whether both outputs contain numbers, so collect the results and ask the registrar or DNS operator to confirm the chain.
Do not remove a DS record at random. If DNSSEC is intended to remain enabled, the keys, signatures and parent DS need to agree. If signing was intentionally removed or the DNS operator changed, the stale parent-side configuration must be corrected through the responsible provider.
SERVFAIL after a DNS change is a validation or resolution clue, not proof that the record was never added.
Register your new domain name at competitive market prices including free domain add-ons like privacy, DNS Hosting, Custom Nameservers and Forwarding.
Always the best price and no nasty renewal price hikes.
Register A Domain Name
Is another record preventing publication?
Yes. The most important conflict is a CNAME at the same owner name as another ordinary record, because a CNAME defines that name as an alias rather than a location for independent A, AAAA, MX or TXT data.
RFC 1034 states that when a CNAME is present at a node, other ordinary data should not be present there. A conventional CNAME is also unsuitable at the zone apex because the apex must hold records such as SOA and NS. (rfc-editor.org)
Which conflicts should you check before deleting anything?
- Search the exact owner name for an existing CNAME.
- Confirm that the DNS panel did not expand the owner into an unintended full domain name.
- Query A, AAAA, CNAME, MX and TXT separately where relevant.
- Review any validation error shown when the record is saved.
- Check whether a provider-specific apex alias feature is being mistaken for a standard CNAME.
- Preserve legitimate multiple values until their purpose is known.
Multiple A records, MX records or TXT strings can be intentional. Do not delete every duplicate-looking entry merely because a service reports one missing record. Compare the exact owner, type and expected value first.
Check the record model before deleting data: CNAME conflicts are strict, while multiple values in other record sets may be valid.
What if only one device or network fails?
If authoritative queries are correct and the failure affects only one device, router or network, the public record may already be working. The remaining suspects are a local cache, an unavailable recursive resolver, DNS filtering, firewall rules or a browser-level cache.
Use simple comparisons:
- Test a second device on the same network.
- Test the affected device on another network.
- Compare the configured recursive resolver with a second resolver.
- Query an authoritative nameserver directly.
- Record whether the result is NXDOMAIN, SERVFAIL, timeout or a different address.
If every device on one network fails while another network succeeds, continue with these DNS server troubleshooting steps. If an authoritative query works but one recursive resolver times out or returns a policy-modified result, filtering or blocking is possible, although the comparison does not prove why the resolver behaved differently.
A browser showing the old website is not necessarily a DNS failure. If DNS tools already return the new address, use our guide to 304 code http to check whether browser or HTTP caching is reusing older content.
If only one path fails, compare devices, networks and resolvers before changing the authoritative DNS zone again.
Experience Microsoft 365 Business Standard for free for 30 days.
Up to 25 users with full access to email, OneDrive and Teams. Includes full versions of desktop apps of Outlook, Word, Excel, PowerPoint and more.
Try Microsoft 365
What else do people ask about missing DNS records?
The following questions cover the most common ways people describe this problem. Each answer assumes that the domain owner can inspect the DNS zone or ask the responsible provider to do so.
How to fix DNS not found?
Fix DNS not found by first identifying the exact record name, type and response code. Confirm the domain’s delegated nameservers, query each authoritative server directly, then correct the owner name or value. If authoritative answers are correct, allow cached positive or negative responses to expire before changing the record again.
How to tell if DNS is being blocked?
Query an authoritative nameserver directly, then compare that answer with the result from the affected network and a second recursive resolver. If the authoritative answer is correct but one resolver times out, refuses the query or returns a different policy result, filtering or blocking is possible, although the comparison alone does not prove intent.
What does "no DNS record" mean?
No DNS record means the requested DNS name or record type was not returned. NXDOMAIN means the queried name does not exist, while a successful response with an empty answer can mean the name exists but that record type does not. SERVFAIL means resolution failed and should not be treated as proof of absence.
What causes a DNS problem?
DNS problems can come from wrong nameserver delegation, a record saved under the wrong owner name or type, an unsynchronised authoritative server, cached old or negative answers, DNSSEC validation failures, CNAME conflicts, a registration or delegation problem, network filtering or an unavailable resolver. The response code and direct authoritative query narrow the cause.
The error label matters more than the broad phrase “DNS problem” because each result points to a different layer.
What should you do next?
Work from authority outward: confirm delegation, query the exact owner and type on every authoritative server, then investigate caches, DNSSEC and the local network. Save the commands, responses and a timestamp so a support technician can see which layer failed without repeating the first checks.
For a new domain or a domain that needs simpler registration and DNS management, review Up Time Web Hosting’s domain name registration and management options.
The direct authoritative answer is the evidence worth keeping because it shows whether the record exists before recursive caches, networks and browsers become involved.
