Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

General DNS issues

In web browsers such as Safari or Chrome, there are several commonly observable DNS errors:

Common causes and resolutions

Below are the most common causes for DNS resolution errors along with suggested solutions.

Mistyped domain or subdomain

Verify that the domain or subdomain was correctly spelled in the request URL.

Missing DNS records

Ensure that you have the necessary DNS records for the domain or subdomain that is presenting the error.

Go to Records

This includes having the following records:

  • The zone apex (e.g., example.com) record.
  • Existing subdomains (www.example.com, blog.example.com) records.

DNSSEC was not disabled before the domain was added to Cloudflare

DNS resolution failures occur if DNSSEC is not disabled at your domain provider before you add the domain to Cloudflare.

Nameservers no longer point to Cloudflare

If you manage DNS records via the Cloudflare dashboard and your domain stops pointing to Cloudflare's nameservers, DNS resolution will stop functioning.

This can occur if your domain registrar switches the nameservers for your domain to point to their default nameservers. To confirm if this is the problem, check whether your domain uses Cloudflare's nameservers.

Unresolved IP address

In rare cases, the DNS resolver in the client requesting the URL might fail to resolve a DNS record to a valid IP address.

Reload the page after a short wait to note if the problem disappears. This issue is unrelated to Cloudflare, but using Cloudflare's DNS resolver may help. Contact your hosting provider for additional help with your current DNS resolver.

Newly created record still does not resolve

If you recently created a DNS record and resolvers still return NXDOMAIN (Non-Existent Domain) or no answer, it is likely because a negative response is currently stored in the resolver's cache.

When a resolver is queried for a hostname that has no DNS records yet, it caches the empty response so it does not have to ask the authoritative nameserver again immediately. This is known as negative caching.

For newly created records:

  • The resolver might not have cached the new record yet. Instead, it is using a prior NXDOMAIN cache entry that says "this record does not exist," which was generated if the hostname was queried before you created the record.
  • The duration of this negative cache is determined by the MINIMUM field in your zone's SOA record (per RFC 2308 ↗), not the TTL of the record you just created. Different resolvers may cache for varying durations.

This means:

  • Lowering the TTL on your new record will not speed up resolution if a negative cache entry already exists; the resolver will only see your new TTL after the old negative entry expires.
  • Flushing your local DNS cache only affects your specific device; the upstream recursive resolver (for example, your ISP or a public provider) still holds the negative result.
  • Propagation appears uneven because different resolvers may have queried the name at different times, apply different negative cache TTLs, or have no negative cache entry at all.

The exact behavior differs per resolver, but to estimate how long you need to wait, query your zone's SOA record and look at the last value (the MINIMUM field). You must wait for that interval to pass since the last NXDOMAIN query before the new record will consistently resolve.

You can check if a negative cache entry is active by querying for the non-existent (or newly created) hostname:

Terminal window
dig +noall +answer +authority mynewrecord.example.com

If the record is still negatively cached, the response will include the zone's SOA record in the authority section with a TTL indicating how many seconds remain before the entry expires:

example.com.    256  IN  SOA  ...

In this example, the negative cache response will continue for 256 more seconds.

To verify the record resolves correctly, you can purge the cache for public resolvers and query the record. If this works, other resolvers will eventually start resolving as well:

Further debugging

To verify the record was correctly created, query Cloudflare's authoritative nameservers directly:

Terminal window
# Find the authoritative nameservers for your zone
dig @1.1.1.1 example.com NS +short
Terminal window
# Query the authoritative nameserver for your new record
dig @hera.ns.cloudflare.com mynewrecord.example.com A

Querying the authoritative nameserver directly bypasses resolver caching. If the record is returned, resolvers will eventually start returning it as well. If the record does not appear, verify the record exists in the Cloudflare dashboard and that the hostname matches exactly.

Account recovery

If you are locked out of the Cloudflare account that contains your DNS configuration, refer to Account recovery.