A missing subdomain can interrupt a website, VPN portal, VoIP service, application, or internal tool. DNS NXDOMAIN subdomain troubleshooting helps determine whether the name truly does not exist, the wrong DNS server answered, or a local resolver has cached an old result.
NXDOMAIN means “nonexistent domain.” A DNS resolver received an answer stating that the requested name does not exist. That differs from a timeout, SERVFAIL response, or an existing name with no address record. The distinction matters because each response points to a different investigation.
What NXDOMAIN tells you—and what it does not
When a user requests portal.example.com, the resolver follows DNS instructions. It may contact a recursive resolver, query the domain’s authoritative nameservers, and return the result to the device. An authoritative nameserver is the server responsible for the domain’s published zone data.
An NXDOMAIN response usually means the authoritative DNS path says the name is absent. However, a cached negative answer can make a recently created subdomain appear missing. Internal DNS can also return NXDOMAIN while public DNS returns a valid answer.
Do not begin by repeatedly changing records. First capture the exact name, record type, resolver, response, and time. A careful sequence prevents a temporary cache issue from becoming a larger DNS change.
Start with the exact hostname and record type
Typos cause many apparent DNS failures. Compare the name in the application, browser, configuration file, certificate request, and documentation. Check every label, hyphen, number, and domain suffix.
- Confirm that the requested name is exactly
portal.example.com, notportal.example.coorportal.example.com.with an unintended suffix added by software. - Check whether the application expects an A record, an IPv6 AAAA record, a CNAME, or another record type.
- Look for spelling differences such as
adminversusadmins. - Review search-domain behavior on laptops and servers. A short name may expand into an unexpected fully qualified name.
- Confirm that the record was created in the correct DNS provider and account.
A name can exist without the record type you expected. For example, an existing CNAME may answer differently from an absent A record. Therefore, inspect the complete name rather than testing only one record type. Careful DNS NXDOMAIN subdomain troubleshooting starts by separating a missing name from a missing record type.
Trace delegation before inspecting the zone
Delegation tells resolvers which nameservers hold authority for a domain or subdomain. The registrar may delegate example.com to one provider, while dev.example.com may delegate to separate nameservers.
Start at the parent domain. Check the NS records for example.com, then determine whether the requested subdomain has its own delegation. If dev.example.com has NS records at the parent, its records belong in the child zone. Adding portal.dev.example.com to the parent zone may not affect queries that follow the child delegation.
Next, query each listed authoritative server directly. Do not rely only on the resolver used by your workstation. Direct queries help separate published zone data from cached or locally overridden answers.
dig NS example.com
dig NS dev.example.com
dig portal.dev.example.com A @ns1.example-dns.net
dig portal.dev.example.com CNAME @ns1.example-dns.netReplace the example nameserver with the actual authoritative server. Some environments use provider-specific names, and not every server accepts every diagnostic query. Treat command output as evidence, not as a guarantee that all DNS systems use the same syntax.
For background on nameservers and domain delegation, see ICANN’s overview of the Domain Name System.
Check the authoritative zone contents
Once you identify the correct authority, inspect the zone where the record should live. Confirm the record name, type, value, and status. Many DNS control panels display a relative name. Entering the full domain there can accidentally create a name such as portal.dev.example.com.example.com.
Review these common errors:
- A record exists under a different zone.
- A CNAME conflicts with other data at the same name.
- The record was saved as a draft or disabled.
- The provider requires a trailing dot for a fully qualified target.
- An old or duplicate entry may be hidden by the panel.
- The child zone lacks the record even though the parent zone contains a similar name.
A CNAME points one DNS name to another name. It does not directly contain an address. If the CNAME target does not exist, the original name may resolve unsuccessfully, but that result is different from the name itself being absent. Review the related guidance on CNAME conflicts for subdomains when the record type is uncertain.
After correcting the zone, query the authoritative server again. The authoritative answer should show the intended record before you investigate public resolvers or application behavior. This direct check is a central step in DNS NXDOMAIN subdomain troubleshooting.
Distinguish authoritative answers from cached NXDOMAIN
Recursive resolvers cache both successful answers and certain negative answers. Negative caching stores information that a name or record was absent. Its duration depends on the authoritative zone’s SOA settings and the resolver’s rules.
This creates a common sequence. Someone tests a name before the record exists. A resolver caches NXDOMAIN. The administrator then creates the record, but that resolver continues returning the negative result until its cache expires.
Compare several views:
- Begin by querying the authoritative server directly.
- Use a known public recursive resolver for comparison.
- Check the resolver used by the affected office or VPN.
- Test from a separate network or device.
Record the response code, answer section, authority section, and TTL. The TTL is the remaining cache lifetime. A declining negative TTL can support a caching explanation, but it does not prove that the authoritative zone is correct.
For a broader testing method, use DNS testing from different locations. Avoid flushing every cache immediately. First preserve evidence, because cache behavior can explain why users see different results.
Investigate split-horizon DNS differences
Split-horizon DNS, also called split DNS, provides different answers based on the requester’s network. An internal resolver might answer portal.example.com with a private address. Public resolvers might return a public address—or NXDOMAIN if the internal-only name is not published.
Check whether the affected user is on the office network, connected through a VPN, using a security client, or relying on a home router. Each path may select a different resolver. Compare the configured nameserver on the device with the nameservers used by the application server.
Look for conditional forwarding rules. These rules send queries for selected domains to a specific internal DNS server. A missing forwarder, stale zone, or incorrect search suffix can produce an internal NXDOMAIN even when public DNS works.
Do not publish an internal hostname merely to make one test succeed. First decide whether the service should be reachable publicly, privately, or through both views. Then document the intended answer in each environment. Split-horizon comparisons often reveal the real scope of a DNS NXDOMAIN subdomain troubleshooting case.
Use a safe correction and verification sequence
After finding the cause, make the smallest necessary change. Correct the hostname, add the record to the authoritative zone, repair delegation, or update the internal DNS view. Avoid changing nameservers during an incident unless delegation itself is the confirmed problem.
Verify in this order:
- Query the authoritative server and confirm the intended answer.
- Check every authoritative server listed for the zone.
- Test the relevant internal resolver and public resolver.
- Wait for valid negative caches to expire when necessary.
- Test the actual application, certificate name, and network path.
- Record the final record, owner, purpose, and expected DNS view.
If authoritative servers disagree, stop and resolve that inconsistency first. It may indicate an incomplete zone update or multiple DNS providers serving different data. A resolver can select different authoritative servers, so inconsistent answers can create intermittent symptoms.
When NXDOMAIN is not the real application problem
Once the name resolves, the service can still fail. An address may point to the wrong host, a firewall may block access, or the web server may lack the correct virtual host. An HTTPS service also needs a certificate that covers the requested hostname.
Likewise, an internal service may resolve correctly but remain unreachable over a VPN. Keep DNS evidence separate from connection evidence. This prevents a valid DNS repair from hiding a routing, firewall, or server configuration issue.
If the response is SERVFAIL rather than NXDOMAIN, use a different diagnostic path. The issue may involve unreachable authoritative servers, malformed delegation, or DNSSEC validation. See the guide to DNS SERVFAIL troubleshooting for that case.
Build prevention into routine DNS operations
Maintain a simple inventory of zones, delegated subdomains, authoritative providers, internal views, and critical records. Include the record owner and the service that depends on it. This information reduces guesswork during an outage.
For important websites, VPN portals, and VoIP services, monitor authoritative answers as well as public resolution. Test from the networks that real users depend on. Alert on unexpected NXDOMAIN responses, delegation changes, and missing record types.
Google’s effective troubleshooting guidance also supports this evidence-first approach: define the symptom, test a clear hypothesis, and verify the fix.
DNS NXDOMAIN subdomain troubleshooting is usually manageable when you follow the chain from the exact name to delegation, authority, zone data, caches, and DNS views. If authoritative answers disagree or the service remains unavailable after DNS is correct, Tech Rescue Ops LLC can provide remote DNS and network support with a documented diagnostic trail.