Subdomain Not Resolving? DNS Record Is There, Here's Why

Step 1: The 30-Second Fix — Check Propagation and Cache

First thing: wait a bit. If you just added the record, DNS propagation can take minutes to hours depending on TTL. I've seen folks panic and break things that just needed 15 more minutes.

Quick test: open a command prompt or terminal and run:

nslookup subdomain.yourdomain.com

If you get "Non-existent domain" or just nothing, it's likely still propagating. Use a public DNS checker like What's My DNS to see if the record shows up globally. If it does but your local machine doesn't see it, clear your local DNS cache:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux: sudo systemd-resolve --flush-caches or sudo service nscd restart

If it's still not working after 30 minutes and you've flushed cache, move to step 2.

Step 2: The 5-Minute Fix — Verify Your Record Type

The culprit here is almost always a record type mismatch. People often add an A record for a subdomain when they should use CNAME, or vice versa.

Here's the rule:

Big no-no: you can't have a CNAME record and ANY other record for the same subdomain. That includes A, AAAA, TXT — nothing else allowed. CNAME means "this name is an alias" and DNS won't let you have other records there. If you need both, use an A record and handle the alias on the web server side.

Also check if you accidentally used a URL redirect instead of a proper DNS record. Many hosting dashboards have both options, and they're not the same thing. DNS record lives in your zone file, redirect is at the web server level.

Step 3: The 15+ Minute Fix — Dig Deeper and Check Server Config

If the record type is right and propagation should be done, it's time to get specific. Use dig to see exactly what your DNS server is returning:

dig subdomain.yourdomain.com @ns1.yourdnsprovider.com

If dig returns the correct record but nslookup doesn't, your local resolver is caching something stale. If dig also says NXDOMAIN, your DNS provider didn't actually save the record. Log back into your registrar or DNS host and double-check. I've seen cases where the UI showed the record saved, but the API never wrote it to the zone file. Remove and re-add the record.

Still stuck? Check these less common but real issues:

• Zone file corruption: Some providers let you export your zone file. If you see garbage or missing entries, that's your problem. Contact support.
• DNSSEC validation failure: If your domain has DNSSEC enabled and the subdomain record isn't signed properly, resolvers will silently drop it. Check your provider's DNSSEC settings. You might need to copy the DS record correctly.
• Web server misconfiguration: The DNS might be fine, but your web server (Apache, Nginx, IIS) doesn't have a virtual host block for the subdomain. Test with curl -H "Host: subdomain.yourdomain.com" http://[IP]. If that works, your DNS is fine and your web server needs a new site config.
• Cloudflare or CDN proxy issues: If you use Cloudflare, check if the orange cloud is on. Sometimes the proxy causes issues with subdomains that have A records. Try turning it off (grey cloud) temporarily.

Real-world example: Last month a client had api.mycompany.com pointed to an EC2 instance. The A record was correct, I could ping the IP, but nslookup returned nothing. Turned out their registrar's DNS server had a bug — the record showed in their web UI but never propagated. Re-adding it from scratch fixed it in 2 minutes.

If you've done all three steps and it's still broken, open a ticket with your DNS provider. Give them the dig output. They can check if their nameservers actually have the record. Don't waste time rebuilding your entire zone — it's almost never necessary.