Why Your Subdomain Returns NXDOMAIN Even Though the Record Is Saved

You add a record for shop.example.com in your DNS panel. It saves without errors and shows up in the list. Yet dig shop.example.com comes back with status: NXDOMAIN, and the browser says the site can't be reached. NXDOMAIN is a specific answer. It means the server that replied believes the name does not exist at all. So the useful question is not whether the record is saved, but which server gave that answer and why it disagrees with your panel.

Start by reading the status, not just the result

Before changing anything, check what kind of failure you have. People often treat every DNS failure as the same thing, but there are three different ones.

NXDOMAIN means the name doesn't exist in the zone that was consulted.
NOERROR with an empty answer section means the name exists, but has no record of the type you asked for. A common case is an A record existing while you queried AAAA.
SERVFAIL means the resolver couldn't get a usable answer. That points at broken delegation, DNSSEC, or an unreachable nameserver rather than a missing record.

This article is about the first case. The commands below cover every check in the list that follows. They are read-only and safe to run. Replace the domain and nameserver names with your own.

BASH

# 1. Which nameservers does the internet use for this domain?
dig NS example.com +short

# 2. Follow the delegation from the root down to the answer
dig +trace shop.example.com A

# 3. Ask an authoritative server directly, bypassing caches
dig @ns1.your-dns-provider.example shop.example.com A +norecurse

# 4. Check for a doubled name caused by a missing trailing dot
dig @ns1.your-dns-provider.example shop.example.com.example.com A +norecurse

# 5. Compare the SOA serial on each authoritative server
dig @ns1.your-dns-provider.example example.com SOA +short
dig @ns2.your-dns-provider.example example.com SOA +short

# 6. Normal lookup through your resolver; check the status and authority section
dig shop.example.com A

The checklist, most likely cause first

You edited a zone that isn't authoritative. This is the most common cause on hosting accounts. A control panel like cPanel keeps a DNS zone for every domain on the server, whether or not the domain actually uses that server's nameservers. If the domain is delegated to a registrar's DNS, a CDN, or a separate DNS provider, your panel edit lands in a zone that nobody asks. Compare the output of command 1 with where you made the change. If they don't match, add the record at the provider those nameservers belong to. Command 2 (+trace) shows the delegation the parent registry hands out, which is what matters. The NS records inside your own zone file don't decide this.
The name got doubled because of a missing trailing dot. In zone file syntax, a name without a trailing dot is relative and gets the zone name appended. So shop.example.com typed into a field that expects a relative name can be stored as shop.example.com.example.com. Some panels detect and fix this for you, and some don't. That is why command 4 is worth running. If the doubled name answers, you've found the problem. Re-enter the record as just shop, or as the full name with a trailing dot, whichever your panel expects.
The record is a CNAME, and its target doesn't exist. When shop is a CNAME, the resolver follows it to the target name. If the target doesn't resolve, the overall status is NXDOMAIN, even though your CNAME is perfectly fine. Look at the answer section. If your CNAME appears there and the status is still NXDOMAIN, the problem is at the target. Typical reasons are a typo, a platform that hasn't set up the hostname on its side yet, or the trailing-dot issue again. A target like shops.platform.example entered without a dot can become shops.platform.example.example.com.
A resolver cached the earlier 'does not exist' answer. Resolvers cache negative answers too. If anything looked up the name before the record existed, recursive resolvers may keep returning NXDOMAIN for a while after you add it. That includes you, a monitoring check, a browser, or an SSL validation attempt. Per RFC 2308, the cache time comes from the zone's SOA record, using the lower of the SOA's own TTL and its MINIMUM field. In command 6, the SOA in the authority section shows a TTL that counts down on repeated queries, which tells you roughly how long is left. If command 3 returns the correct answer from the authoritative server, the DNS itself is fine and you are waiting on caches. Lowering the SOA values now won't shorten answers that are already cached. Your OS and browser may also hold their own caches, so test from another network or resolver before assuming the change failed.
A CNAME is clashing with other records at the same name. A CNAME can't share a name with any other record type. If shop already has an A, MX, or TXT record and you add a CNAME, what happens depends on the panel and the DNS software. The panel may reject the change, silently replace the old record, or write a zone the server refuses to load. When a reload fails, some servers, BIND for example, keep serving the last version that loaded successfully. That older zone doesn't contain your new record, so you get NXDOMAIN while the panel shows the record as saved. Remove the conflicting records so only the CNAME remains. If you need this at the bare domain, where a CNAME isn't allowed at all, see CNAME Flattening, ALIAS, or a Plain A Record for Your Root Domain?.

Less common causes worth ruling out

If the five checks above come back clean, a few rarer cases are left. Nameservers disagree with each other. With a primary and one or more secondary servers, secondaries only pull a new copy of the zone when the SOA serial number goes up. Control panels usually bump the serial on save, but hand-edited zone files depend on you doing it. Compare serials with command 5. If one server is behind, resolvers that happen to query it get the old zone and return NXDOMAIN, while others see the record. This shows up as the record working from some places and not others. The subdomain is delegated somewhere else. If the parent zone has NS records for shop, or for a level above it such as store.example.com when you're adding shop.store.example.com, that part of the namespace belongs to a different zone. Records you add for it in the parent zone are ignored. +trace makes this visible because the delegation steps one level further than you expect. Local overrides. A leftover entry in /etc/hosts or the Windows hosts file usually causes a wrong address rather than NXDOMAIN. Still, a local DNS filter, VPN resolver, or corporate split-horizon setup can return NXDOMAIN for names it doesn't know about. If dig against a public resolver works but your machine doesn't, look at the local resolver path before touching the zone. From the support side, a pattern is worth knowing. Customers almost always say 'the record is there, I can see it'. They're telling the truth. The record really is there, just in a zone, under a name, or behind a cache that isn't the one being asked. Asking the authoritative server directly settles most of these quickly.

Making it a habit

When a saved record returns NXDOMAIN, work in this order. Confirm which nameservers are authoritative. Query one of them directly with +norecurse. Then compare that answer with what your resolver says. If the authoritative server is right and the resolver is wrong, it's caching, and time fixes it. If the authoritative server is also wrong, the problem is in the zone itself: wrong place, wrong name, broken CNAME target, or a conflict that stopped the zone from loading. One more habit prevents most of the caching cases. Add the record first, then point anything at it, so nothing gets a chance to cache a negative answer in the meantime.