Subdomain DNS Not Resolving: Causes and How to Check

This article is a localized edition of the Japanese original. Read the Japanese original

When you have added a subdomain record but the name still does not resolve, the cause is usually not "waiting time." Most of the time you have either registered it in a DNS service that is not actually in use, made a typo in the record name, or the answer from a query made before you added it (a "does not exist" response) is cached. This article explains how to query the authoritative DNS server directly to determine whether "the registration is correct" or "the cache is just stale," and how to fix each cause.

First, Determine Whether It Is a Registration Problem or a Cache Problem

DNS has authoritative DNS servers, which hold the records, and caching DNS servers (resolvers), which look things up on behalf of users and remember the results for a certain time. When something seems "not to propagate," first find out which of the two it is stuck at.

# 1. Check the authoritative DNS servers (NS) for this domain
dig +short NS example.com

# 2. Query the authoritative DNS server directly (specify one of the NS above)
dig @ns1.example-dns.net blog.example.com A

# 3. Query public resolvers
dig @1.1.1.1 blog.example.com A
dig @8.8.8.8 blog.example.com A

In Windows PowerShell, you can do the same check with Resolve-DnsName blog.example.com -Server 8.8.8.8.

Here is how to read the results:

• Query 2 returns no answer: The registration itself has a problem. Check causes 1 to 3 below.
• Query 2 returns an answer, but query 3 or your own machine does not: The registration is correct, and an old response remains in a cache. Go to cause 4.
• Both 2 and 3 return the correct IP, but the site will not open in a browser: DNS has already propagated, and the problem is on the server side. See cause 5.

dig +trace blog.example.com shows the delegation being followed step by step from the root servers, so you can see at which stage the answer stops.

Cause 1: You Are Editing a DNS Service That Is Not Actually Used

This is the most common case. Both the registrar where you bought the domain and your hosting company or Cloudflare have DNS record editing screens, and the subdomain gets added on the one the NS records do not point to. For example, if you switch the NS to Cloudflare and then add a record in the registrar's DNS screen, resolvers around the world never look there.

The NS host names shown in step 1 tell you which service is acting as the authoritative DNS. Register the record again in that service's control panel.

Cause 2: A Typo in the Record Name

In many services, the zone name (example.com) is automatically appended to whatever you enter in the "Host name" field of the control panel. If you enter blog.example.com in this field, what actually gets created is blog.example.com.example.com. Whether a screen expects only the subdomain part, blog, or the full host name differs from screen to screen, so check the record list after registering.

If you write zone files directly, for example with BIND, you also need to watch the trailing dot (.). Names without a dot get the zone name appended.

; Correct example
blog        IN  A      203.0.113.10
shop        IN  CNAME  shops.example-platform.com.

; Wrong: no trailing dot, so it becomes shops.example-platform.com.example.com
shop        IN  CNAME  shops.example-platform.com

After editing a zone file, increment the SOA serial number before reloading. If the serial does not change, the zone is not transferred to the secondary DNS servers.

Resolution also becomes unreliable when a CNAME and another record exist for the same name. A CNAME cannot coexist with other records of the same name, so many control panels reject it at registration, but a hand-written zone may let it through.

Cause 3: The Subdomain Is Delegated to Another DNS Service

If a subdomain such as dev.example.com is delegated to another DNS service through NS records in the parent zone, records such as app.dev.example.com must be registered at the delegated service. Writing them in the parent zone has no effect.

If dig +short NS dev.example.com returns NS records different from the parent's, the subdomain is delegated. A delegation someone in your organization set up long ago may still be in place, so checking once, even if nothing comes to mind, gets you to the cause faster.

Cause 4: A “Does Not Exist” Response Is Cached

When the authoritative DNS answers correctly but your machine cannot resolve the name, the cause is often that you accessed it once before adding the record. That is because answers to queries for names that do not exist (NXDOMAIN) are also cached by resolvers. How long this negative cache is kept is determined by the zone's SOA record (the smaller of its last field and the TTL of the SOA itself).

dig blog.example.com A
# If an SOA appears in the AUTHORITY SECTION and status: NXDOMAIN, it is a negative response
# The last number on the SOA line is a guide to how many seconds the negative response is cached

In this case, either wait for the cache to expire or at least clear your local cache. The commands for each OS are as follows (they may differ depending on your environment).

# Windows (Command Prompt or PowerShell as administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (when using systemd-resolved)
resolvectl flush-caches

Browsers also cache DNS on their own. In Chrome, you can clear the host cache from chrome://net-internals/#dns. You cannot clear the cache of your ISP's or your company's resolvers from your machine, so when checking, use your smartphone's mobile connection or dig against a public resolver to see the result without waiting.

Also, if old test entries remain in your hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on macOS and Linux), they take precedence over DNS. Review it after a migration.

Cause 5: DNS Is Correct, but the Server Is Not Accepting the Requests

If dig returns the correct IP, your DNS work is done. If the site still does not open, the problem is on the server side.

• The web server has no virtual host for the subdomain: The default site or an error page is shown. Check server_name in Nginx, or ServerName / ServerAlias in Apache. On shared hosting, the site may not appear just by pointing DNS at it unless you also "add the subdomain" in the control panel.
• The SSL certificate does not include the subdomain: You get a certificate error. Issue a certificate for the subdomain or use a wildcard certificate. Automatic certificate issuance fails validation unless DNS is already pointing correctly, so mind the order.
• For WordPress Multisite (subdomain type): Instead of adding a record every time you add a site, it is common to set up a *.example.com wildcard record. If a name is registered individually, it takes precedence over the wildcard.

Checking the status code and response headers with curl -sI https://blog.example.com/ makes it easier to find where things stop beyond DNS.

How to Think About Propagation Time

A newly added record can normally be looked up immediately once it is registered on the authoritative DNS, as long as nobody has cached it yet. The "24 to 72 hours to propagate" rule of thumb mainly applies to NS changes (switching name servers) or to rewriting an existing record that still has a long TTL.

If you plan to change the IP of an existing subdomain, lower the TTL to around 300 seconds beforehand, for example the day before, and change the value after the old TTL has expired; the switchover then completes quickly. TTL values and minimums differ between DNS services (as of October 2026), so check the specifications of the service you use.

Summary

• First, query the authoritative DNS server directly with dig @NS to separate "registration problems" from "cache problems."
• For a registration problem, check that you are editing the service the NS points to, the input format of the host name field, trailing dots in zone files, and whether there is a delegation.
• If you accessed the name before adding it, a negative response is cached: clear your OS and browser caches and check with a public resolver.
• If DNS is correct but the site will not open, check the virtual host and the certificate, and for Multisite, the wildcard record.

• How to Investigate DNS with the dig Command
• How to Clear the DNS Cache on Each OS

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)