DNS Caches and the Boundaries of a Failed Answer

Two clients can ask about the same hostname and receive different observations without either transcript being fabricated. They may use different resolvers, ask for different record types or look at different points in a cached record's lifetime. A useful DNS investigation preserves those differences instead of combining them into a single statement that the domain works or fails.

Write down the question first. Include the full name, record type, class, resolver endpoint and observation time. If the client uses an encrypted DNS service, record that route too. The question sent by a browser is not necessarily the question sent by a command-line tool using the system resolver.

Separate answer kinds

A positive answer can supply records for the requested type. A negative answer can indicate that the name does not exist, or that the name has no data of the requested type. A resolver failure or an unanswered query is a different result. Do not translate every empty answer section into a nonexistent domain.

Keep the response code, answer section and relevant authority information together. An address query with no address records requires more interpretation than a quick glance at the answer count. A timeout supplies no DNS response code at all. The distinction changes the next useful question.

Illustrative notebook entries, not captured DNS traffic:
name            type  resolver  observation
service.example A     R1        positive address answer
service.example AAAA  R1        no data for this type
absent.example  A     R1        name does not exist
service.example A     R2        resolver failure

These entries do not predict actual answers for the reserved example names. They show the minimum categories a notebook should retain. Add the actual response fields when performing an authorized check; keep a failed command's exit status and stderr alongside its output.

Read the lifetime of the observation

A record's TTL gives a cache lifetime, not a promise that every client refreshes simultaneously. A recursive answer can show the remaining lifetime of a cached record. Comparing that value to a newly served authoritative record without noting the different sources makes normal cache behavior look like an unexplained disagreement.

Negative caching also matters. RFC 2308 describes using the lower of the SOA record's TTL and its MINIMUM field for the negative answer's initial lifetime. That mechanism helps explain why adding a previously absent record does not immediately change every resolver's answer. It does not turn a failure transcript into a universal countdown for all clients.

Keep failure caching distinct from that negative-answer example. Resolver implementations and applicable standards can also govern cached failures. A SERVFAIL result should not be labeled NXDOMAIN, and an investigator should not assume it must disappear merely because an address record's TTL has elapsed.

Compare like questions

Choose one resolver and repeat the same name and type with a bounded tool. Record when each query starts. Then compare another permitted resolver using the same question. Differences now have a limited interpretation: these resolvers supplied different observations at these times. That is a better starting point than a claim that the whole internet has inconsistent DNS.

An authoritative query answers another question. It helps inspect what the selected authoritative server currently serves; it does not reproduce the client's complete recursive resolution path. Delegation, resolver validation, transport reachability and client caching can still differ. Keep authoritative and recursive transcripts in separate notebook entries.

Check A and AAAA separately when the client can use both address families. A working address in one family does not prove the other path is reachable. Likewise, inspect any relevant alias chain without treating every name in that chain as having the same cache lifetime or certificate identity.

Plan changes around existing caches

Before a planned address move, identify the records being changed, their existing lifetimes and the period during which both old and new destinations can serve valid responses. Lowering a TTL shortly before the move does not rewrite copies already held in remote caches. The transition plan must account for those earlier observations.

Use a change log with the previous value, replacement value, intended publication time and rollback condition. After the change, inspect the authoritative state and a small, named set of resolver observations. Report that sample honestly. Avoid inventing a global propagation percentage from a few convenient public probes.

Removing the old service too early can turn a routine cached answer into a user-visible failure. Keep the old route available for the planned overlap where feasible, and verify that it still presents the expected HTTPS identity. An address transition and a certificate transition are related operational tasks with separate acceptance conditions.

Respect the resolver boundary

Encrypted DNS can protect the lookup exchange on the route between client and resolver. It does not make the resolver unable to see the queried names, establish application identity or remove the need to choose a resolver deliberately. Use the actual configured route when assessing where names and metadata are observable.

Do not embed sensitive query names in public incident notes. Internal service names can reveal structure even when no secret token appears in them. Use a sanitized example in a shared explanation and keep the detailed authorized transcript in the appropriate operational record.

The final finding should name the boundary. For example: a selected resolver returned a cached negative answer while the selected authoritative server returned the new address. That finding supports a cache explanation for that sample. It does not establish that every failed browser request has the same cause.

References and related notes

Primary background: RFC 1034 for DNS concepts and RFC 2308 for negative answers. The comparison method and change notebook are editorial procedures.

Next, follow the separate request paths or inspect the identity checked after resolution.