See if these steps describe the situation you are seeing:
- You ran a query against a DNS record (‘A’ record, for example) via your ISP (or other recursive DNS provider) and received no response (e.g. a NXDOMAIN, Non-existent domain or similar.)
- You realized that the record did not exist in your zone, which is why it did not resolve, so you added it.
- You now ran a query for that same DNS record, but you are still getting no response, even though you know it is there!
- Perhaps you ran a nslookup directly against Total Uptime name servers and see that a correct response is provided.
What you are probably experiencing is negative caching. If a recursive DNS resolver asks an authoritative DNS server for a record that does not exist, it can cache a negative response (the fact that it did not exist) and save that response to serve to other queries for the same record. This is by design. It does this to save time and compute power having to constantly go to the authoritative DNS server to look up a record it does not have when it knows that just recently that record did not exist. This can also minimize the effect of a DNS attack on a recursive server for a record that the attacker knows does not exist.
How long will it cache this negative response? Since the record did not exist in order to provide its own TTL value, it generally uses the Minimum TTL value it was returned in the SOA record.
How can I prevent this negative caching from happening? There isn’t much you can do to fix the issue at hand. You just have to wait for the cache to clear. But to prevent long negative caching in the future, you can change the SOA MIN TTL value to something low, such as 60 seconds, for example. That would ensure the recursive resolver wouldn’t cache it for very long.
You can learn more in RFC 2308 – Negative Caching of DNS Queries (DNS NCACHE)