A new record that still does not exist for some people: negative caching and the SOA

Domains & DNS·· 3 views· 4 min read

The short answer: resolvers do not only store answers that exist. When they ask for a name that does not exist (NXDOMAIN), or for a record type the name does not have (say, a TXT you have not created yet), they store the “no” as well. For how long: the smaller of two numbers from the zone’s SOA record, the SOA’s own TTL and its last field. If someone asked before the record existed, that resolver keeps saying “does not exist” for that long, even once the record is there.

Typical situations

What happened Why it still fails
You opened shop.asuaempresa.ao in the browser “to see if it works yet”, and only then created the record Your resolver stored the “does not exist” from the first try.
You created the verification TXT and the service says it cannot find it The service checked before the record existed, and its resolver stored “no TXT here”. See TXT verification records.
The zone editor appended the domain to the name, and the record ended up with the wrong name The right name never existed: whoever asked stored the “no”. After fixing it, those caches still have to expire.
You deleted a record by mistake and created it again Whoever asked in between stored “does not exist”.
The zone has a wildcard (*) record There is no NXDOMAIN here: the wildcard answers any name, and it is the wildcard’s answer that gets cached. See the wildcard record.

Seeing the stored “no”, and getting rid of it

1 Ask the source whether the record exists: dig @dns1.interweb.ao A shop.asuaempresa.ao +noall +answer if the zone is with us. If the source does not return the record, it is not a cache: the record does not exist, or it has another name.
2 Ask your own resolver and look at the header and the AUTHORITY section:dig A shop.asuaempresa.ao
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; AUTHORITY SECTION:
asuaempresa.ao. <seconds> IN SOA ...
The number on the SOA line counts down: it is how long that resolver will keep repeating the “no”.
3 Look at the zone’s SOA: dig SOA asuaempresa.ao +noall +answer. The last number on the line is the field that caps negative caching; the real time is the smaller of that number and the SOA’s own TTL.
4 Clear the caches you control (computer, browser, phone), as in the caches ipconfig does not reach, and test at another resolver, for example dig @1.1.1.1 A shop.asuaempresa.ao.
5 With a service that verifies your domain, wait for the negative caching time to pass and only then press “Verify” again. Pressing it earlier only makes its resolver repeat the “no” it has stored.
Create the record before anyone asks for it. Testing a subdomain that does not exist yet, or pressing “Verify” before saving the TXT, is what fills caches with “no”. Do not touch the SOA values unless you know what you are doing: on shared hosting the SOA is managed by the server.
The right order with a new service: save the record first, confirm at the source that it is there, and only then ask the service to verify. A resolver that never asked has nothing to forget.

Created the record and someone still gets “does not exist”? Tell us the full name and the record type.

Open a support ticket

SEE ALSO

DNS_PROBE_FINISHED_NXDOMAIN: what it means and what to check

A wildcard DNS record (*): what it does, and when it gets in the way

Proving the domain is yours: TXT verification records

Pointing a subdomain to another server or service: A record or CNAME

Asking different DNS resolvers: how to read a propagation checker without panic

What DNS propagation really is: caches that expire, not a change that travels

RECOMMENDED PRODUCT

Web hosting with cPanel

Domain and SSL included, daily backups and the panel you already know. from 5.940,00 Kz/mo (3-year plan, with coupon)

See plans
Was this answer helpful? Your answer helps us improve this article.