A Missing DNS Name, a Missing Record Type and a Failed Lookup Mean Different Things

Identify the question behind the missing address

A report that an AI endpoint has no address leaves the DNS outcome unresolved. RFC 9499, published in March 2024, distinguishes NXDOMAIN, the name-error response code, from NODATA, which is inferred from a NOERROR response with no relevant answer. An empty answer section alone is insufficient: a referral can also have that shape. The response's authority information helps distinguish them.

Consider two fictional names under the documentation-only .example domain: ready.example and missing.example. Use Internet class IN throughout. Stipulate direct answers without aliases or wildcard substitution, with the appropriate zone SOA in each negative response's authority section. SOA means Start of Authority; it is the zone record that supplies the negative-cache timing information used below.

At the initial observation, ready.example exists with an AAAA record but no A record. Its A question receives NOERROR/NODATA. For missing.example, stipulate that the name does not exist: its A question receives NXDOMAIN. These are different findings even if a summary display renders both as no address.

References: [T1][N1][E1]

NXDOMAIN and NODATA: compare record types at the same name

RFC 2308 section 5 stores NXDOMAIN against QNAME and QCLASS, while NODATA also includes QTYPE. Here those fields mean the queried name, class and record type. The examples avoid aliases, so the name in the question is also the name whose absence is being discussed.

For ready.example, the retained NODATA entry answers the question ready.example / A / IN. It does not answer ready.example / AAAA / IN. A separately stipulated successful AAAA lookup would therefore be compatible with the missing A answer. It would still leave an application that specifically needs A without that record.

For missing.example, the retained NXDOMAIN entry applies to missing.example / IN. A change from an A question to an AAAA question does not escape this name-error entry's scope. The distinction explains why evidence of one missing type cannot be promoted into evidence that the whole name is absent.

This is an interpretation of two retained answers, not a proposal to change a client's query behavior. The useful purchasing question is which of these questions the supplied observation actually answered.

References: [N1]

A record can be published while an earlier absence remains cached

RFC 2308 sections 3 and 5 derive the negative-answer lifetime from the lower of the zone SOA record's TTL and its MINIMUM field. Section 6 carries the remaining lifetime in a cached negative response. TTL means time to live.

Extend the ready.example case with one resolver R and clients that use R. At time 0 seconds, stipulate that R receives the authoritative A NODATA answer. The zone SOA has a TTL of 600 seconds before negative-response trimming and a MINIMUM of 120 seconds. R accepts an initial negative lifetime of min(600, 120) = 120 seconds.

At time 20 seconds, stipulate that an A record is added and is available from the authoritative service. R retains its original negative entry without replacement, refresh or eviction. Assume no shorter local cache limit, no additional client cache and ordinary unexpired-cache handling; exceptional stale-answer behavior is outside this example.

At time 50 seconds, another A lookup through R can still receive NODATA. The retained entry has 120 - 50 = 70 seconds remaining. Only 30 seconds have passed since the authoritative addition, but the cache entry's age is 50 seconds: its clock began when R received the earlier negative answer.

The new A record and the retained absence can coexist because they describe different places at different times. Stipulate a successful direct authoritative observation at time 50 seconds; that observation can show the new A record while R still supplies its earlier answer. Publication has not retroactively replaced the retained entry.

The 120-second value bounds the stipulated entry's ordinary lifetime. It supplies no observation of what R or an application does afterward. All names, times, cache choices and successful observations here are invented premises for the calculation, not a measured rollout, recommended TTL or recovery deadline.

References: [N1][E1]

A failed resolution leaves the absence question unanswered

RFC 9520, published in December 2023, treats resolution failure separately. It occurs when none of the available servers supplies useful information for the name, type and class; a valid NXDOMAIN or NODATA answer counts as useful information. One server timing out does not by itself establish that the whole resolution failed.

SERVFAIL can reflect several conditions, and a timeout means no response was received within the relevant wait. Neither observation proves that ready.example lacks A or that missing.example does not exist. RFC 9520 also requires caching resolution failures. Such a retained failure remains different evidence from a retained answer asserting absence.

Consequently, the 120-second SOA calculation above cannot explain an unspecified SERVFAIL or timeout. A report that groups all three outcomes as DNS failure has discarded the distinction needed to interpret its own claim.

References: [F1]

Match an endpoint claim to the population actually observed

In the fictional case, a publication report at time 20 seconds establishes the stipulated authoritative addition. A direct authoritative result at time 50 seconds supports that record's availability there. Neither report establishes what clients using R received at the same moment. Conversely, R's NODATA result at time 50 seconds does not refute the authoritative addition.

For a newly published endpoint or a recovery offer, useful evidence names the queried name, record type and class; distinguishes the response code from a timeout; and identifies the observation time and the resolver path used by the relevant clients. Where a retained absence is the explanation, the response and its remaining cache lifetime should support that explanation. A result from one resolver population leaves other populations unexamined.

The buying decision follows the gap in that evidence. A report about authoritative publication answers the publication question. A report covering the intended clients through their actual resolver path supports a claim about those clients' DNS results. Application recovery requires its own evidence of the required task outcome. These observations alone identify no faulty cable, network device or GPU.

Use the related DNS TTL article for positive address caching and reuse of existing connections, and the cross-Region inference article for model routing versus application continuity. Those decisions begin where this article's classification of the lookup outcome ends.

Scope physical cabling only when the plan includes physical work

If the endpoint project also includes installed fiber or copper connections, the related Structured Cabling & Fiber Installation service and project inquiry provide a route to discuss that physical package. Share a nonconfidential outline of equipment endpoints, approved routes, materials responsibilities, labels and required connection records. DNS operation and application recovery remain with the appointed platform and application teams.

References: [L1]