A hostname that doesn't resolve for a day because you asked too early
The wildcard record was correct at the registrar, the public resolvers answered it, and the router and Pi-hole still said NXDOMAIN. They had cached the failure from a lookup made before the record existed, for the zone's negative TTL. How to tell, and the flush order.
I had a wildcard record added at my DNS host. Once it was in, the public resolvers
returned the address. The router, and the Pi-hole behind it, kept answering
NXDOMAIN for the first name I’d tried, even after I flushed the Pi-hole.
That looks like a configuration problem on the local side, and it isn’t.
What was going on
I had looked the name up before the record existed. A resolver that gets NXDOMAIN caches it, and how long is set by the zone’s SOA record: the last field is the negative-caching TTL.
host -t SOA example.org
# ... 2026100400 3600 1800 1209600 86400 <- last field: 86400 s, a dayMine was a day. The router’s resolver held the NXDOMAIN, and the Pi-hole, which forwards to the router, asked again after my flush, was told “not found” again and cached that too. Flushing the downstream cache only refetches from the upstream cache.
Telling it from a real fault
Ask for a name nobody has ever asked for under the same wildcard:
host fresh-12345.example.org <router>
host fresh-12345.example.org <pihole>If that one resolves through both, the record and the whole path are fine and only the one name is stuck in a cache. Also ask the authoritative server and a public resolver directly, to confirm the record is out.
Flush order
Upstream first. On a UniFi gateway, killall -HUP dnsmasq over SSH clears the cache
without restarting anything; if the gateway forwards to your provider’s resolver,
that one may still hold the failure, and then only waiting or using a different
name helps. Then flush Pi-hole. Flushing in the other order does nothing, because
the Pi-hole just re-learns the stale answer.
And the habit that avoids it: don’t look a name up before its record exists.