The direct answer
Bind a negative DNS result to its exact kind, lookup identity and remaining lifetime before reusing it. Missing data for one record type is not the same result as a missing name. Keep resolver evidence, service availability and application authority separate.
Ask what the missing answer actually means
A fictional AI integration receives a cached absence result for the A record of its configured endpoint. An operator concludes that the entire service name is unavailable, including every other record type. That conclusion needs a more precise result identity.
This worksheet selects historical ordinary DNS negative-answer semantics from RFC 2308 for one independently admitted ASCII absolute name Q-A and class IN, with no aliases. A and AAAA appear only as record-type labels. No hostname, query, packet, address, record, response, resolver or cache entry is constructed here.
This is not a diagnosis of any actual outage, prior Cloudflare connection failure or hosting configuration. It authorizes no DNS retry, cache flush, resolver change or alternate backend. The existing IPv4 fetch contract remains unchanged.
Separate name absence from a missing record type
RFC 2308, Standards Track, March 1998, distinguishes NXDOMAIN name error from NODATA: a valid name for the class with no records of the requested type. NODATA is inferred from response contents, not a dedicated RCODE. An empty answer alone is not a complete classifier.
Its negative-cache keys differ: NXDOMAIN uses QNAME and QCLASS; NODATA additionally uses QTYPE. Our no-alias profile keeps the name association simple. The RFC’s broader alias and referral cases are outside this worksheet.
Require an independently supported, complete classification receipt before applying these rules. A UI’s “DNS failed” label cannot supply it. Actual provenance, resolver behavior and current policy are unknown prerequisites; this historical document establishes none of them for a deployment.
Use a typed lookup worksheet
Invent entry E-A, classified as NODATA for Q-A, IN and A. Its name, class, result category and lifetime evidence are already independently established in the paper scenario. This is a stipulated teaching receipt, not a captured DNS answer.
| Entry kind | Entry type | Requested type at Q-A/IN | Key scope |
|---|---|---|---|
| NODATA | A | A | Matches. |
| NODATA | A | AAAA | Does not match. |
| NXDOMAIN | Not a key dimension | A or AAAA | Same name/class scope. |
The second row leaves the other query unestablished. It neither asserts that AAAA exists nor silently performs another lookup. A different name or class also needs its own supported association. Do not replace exact identity with a friendly service label.
The useful positive is conditional reuse of E-A for its matching lookup under a supported current resolver policy and every independent prerequisite. A correctly scoped negative answer is useful information; it is not an application success, connection result or permission to disclose a document.
Give the negative answer its own lifetime evidence
The RFC’s lifetime rule uses the smaller of SOA.MINIMUM and the SOA TTL. Remaining lifetime decreases with cache age; at zero the cached negative answer must not be reused. It advises against caching negative responses without an SOA.
For an original teaching receipt, assume the supported initial allowance is twenty seconds and an established age is seven seconds. The paper remainder is thirteen seconds, subject to the separately supported actual cache policy. Those invented numbers are arithmetic labels, not measured time, a DNS configuration or recommended production values.
Store the evidence for the original allowance and its age association separately. Refreshing a display must not relabel an old receipt as newly obtained. If the timebase, provenance or remaining lifetime is unavailable, this worksheet cannot establish reuse eligibility. It supplies no timer, clock adapter, cache-expiry implementation or fallback lookup.
Do not borrow an HTTP response’s cache policy or a certificate’s validity dates for this decision. They govern different objects and do not repair missing E-A evidence.
Walk eight inert cache-admission cards
| Invented condition | Proposed disposition |
|---|---|
| 1. E-A matches the first row, remains eligible and all actual prerequisites hold | Conditionally reuse only that typed negative answer. |
| 2. E-A is offered for the second row | Keep that requested result unestablished. |
| 3. A complete eligible entry matches the third row | Apply only the stated key scope under the admitted policy. |
| 4. Name or class differs | Reject the association. |
| 5. Lifetime has expired or is unknown | No current reuse eligibility; no automatic retry is authorized. |
| 6. SOA, provenance or age evidence is missing | Hold the selected receipt rather than invent an allowance. |
| 7. A timeout or server/transport failure is offered as this result | Reject the category substitution; failure caching is outside this profile. |
| 8. Classification fits but destination, data or current rights fail | Deny the application use independently. |
Keep the historical scope and current unknowns visible
This guide supplies no current resolver implementation recommendation, DNSSEC validation, aggressive denial proof, subtree inference, serve-stale policy, alias processing or failure-cache procedure. A narrow historical key rule is not a complete modern DNS specification. Actual adoption needs independently established supported behavior and policy.
Actual resolver support, complete response classification, trusted provenance, SOA association, cache ownership, age and timebase, exact requested identity and current rights are unimplemented or unknown. Missing evidence blocks real admission. No RCODE parser, DNS query, record, operating-system inspection, network fixture, API or model operation was exercised.
The outage playbook still governs separate uncertain attempts and fallback authority. Boundary remains prelaunch with planned request-path checks; its synthetic policy evidence does not implement or validate a resolver. No service-availability, authentication, global nonexistence or permanent failure result is claimed.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.