NXDOMAIN means the resolver asked an authoritative server and the name simply doesn't exist — for your resolver's view. Most cases are stale local cache, wrong record, or propagation lag.
Resolvers cache 'does not exist' answers. If you just created the record, your resolver may still be serving the cached miss. dig @1.1.1.1 <host> +short tests a different resolver's view.
An A record for app.example.com must live in the example.com zone. A typo in the zone file (missing trailing dot: 'app.example.com example.com.') silently creates a name like app.example.com.example.com.
dig NS example.com +short shows which nameservers the world is told to ask. If they don't match where you created the record, delegation is the problem.
dig example.com +nostats +authority # SOA in authority = record genuinely absent upstream
dig @<your-nameserver-ip> app.example.com +short # bypass caches entirely
# Chrome: chrome://net-internals/#dns | systemd: sudo resolvectl flush-caches | macOS: sudo dscacheutil -flushcache
dig NS example.com +short && dig example.com SOA +short
Negative caching honors the SOA minimum TTL — a fresh record can be 'invisible' for up to that long on some resolvers. dig +trace shows the full delegation chain from the root — the definitive propagation test.
Their resolver cached the NXDOMAIN answer before you created the record. It will expire on its own; you can verify correctness against the authoritative server with dig @<ns-ip> in the meantime.
There's no global answer: each resolver caches independently. Global propagation typically completes within hours because negative-cache TTLs for NXDOMAIN are short, but plan for up to a day.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.