Error guide / Subdomain not resolving
Subdomain not resolving
A subdomain such as blog.example.com is a separate hostname with its own DNS record, so example.com working says nothing about it. Strictly, "not resolving" means the lookup for that exact name came back empty: the browser never got an IP address and never reached your server, which appears as DNS_PROBE_FINISHED_NXDOMAIN in Chrome, "server not found" in Firefox, or "Could not resolve host" from curl. People also use the phrase loosely when the name does resolve but the wrong site, a blank hosting placeholder or a certificate warning comes up, which is a different problem living on the server. The check on this page separates the two in one step, because it looks up A, AAAA and CNAME for the exact hostname you type in.
Check your site
What causes it
By far the most common cause is that no record exists for that exact name, or it was added in the wrong zone: at a registrar or an old provider whose nameservers no longer answer for the domain. Second is timing, since a record you just created or changed is still cached elsewhere with its old value, and until the previous TTL expires part of the internet keeps seeing nothing. When the record does exist, the cause moves to the server: no site is configured for that hostname, so you get a default page, someone else's site or a 404, and several panels create the DNS entry without creating the virtual host, so correct DNS proves nothing about the site. Less common but easy to miss are a CNAME sitting at the same name as other records (invalid, and answers become unpredictable), a wildcard *.example.com being overridden by a stale specific record, and a certificate issued for example.com and www only, which produces a security warning rather than a lookup failure.
How to fix it
- Run the check on this page for the full hostname, blog.example.com and not example.com: if A, AAAA and CNAME all come back empty, the record does not exist or has not propagated yet and the fix is in DNS (steps 2 to 4); if any of them returns a value, DNS is fine and the fix is on the server (steps 5 and 6).
- Add or correct the record in the zone your nameservers actually serve: compare the NS records the check returns with the provider whose DNS panel you are editing, because a record added in an abandoned zone is never read. Point A (and AAAA if you use IPv6) at the server IP, or use a CNAME to the target hostname. On Cloudflare the record must exist in the Cloudflare dashboard, and a proxied record correctly returns Cloudflare addresses instead of your server IP.
- Keep one kind of record per name: a CNAME must be the only record at that name, so no A, MX or TXT may sit next to it. If you rely on a wildcard *.example.com, delete any stale specific record for that subdomain, because a specific record always wins over the wildcard, and many providers apply wildcards only one level deep.
- Wait out the TTL before drawing conclusions: after editing DNS, re-run the check in 5 to 30 minutes, test from mobile data as well, and clear your own cache with ipconfig /flushdns (Windows), dscacheutil -flushcache (macOS) or chrome://net-internals/#dns. Changing the domain's nameservers, rather than one record, takes noticeably longer.
- If the check returns a record, open the subdomain and read what the server actually replies: a default hosting page, another site or a 404 means no virtual host answers for that name. Add the subdomain in your hosting control panel, or add the hostname to the vhost ServerName/server_name and reload the web server, and confirm its document root points at the right folder.
- If the browser complains about the certificate instead, the certificate does not cover this name: reissue it with the subdomain included or use a wildcard certificate. Where SSL is issued automatically, request it only after the DNS record resolves, because validation needs the name to be live.