Explain a cached missing name before changing the domain again
A new customer portal can be present in the authoritative DNS configuration while one staff connection still reports that its name does not exist. Repeatedly editing the domain in response can obscure the evidence and introduce a second problem.
This fictional handover exercise examines a cached negative answer for a newly introduced hostname. It is a DNS diagnosis, followed by a bounded receiving check. It does not assume that every connection failure is a cache problem or that a successful DNS answer proves the whole portal is ready.
Record the question that failed
The team is preparing a new catalogue hostname, catalogue.example.test, in an isolated exercise. Before the record exists, resolver R-1 asks for it and receives NXDOMAIN: a response saying that the queried name does not exist. The response supplies a negative caching lifetime of 300 seconds in this fixture.
At minute two, the authorised administrator creates the intended address record. A direct query to the correct authoritative server now returns the approved address. At minute three, however, a staff workstation using R-1 still receives the earlier NXDOMAIN response with 120 seconds remaining.
Those observations are compatible. They concern different sources of an answer at different moments. The first question is not whether someone should type the address into the domain panel again. It is whether the staff result comes from the earlier cached absence.
Compare authority with the resolver actually being used
The handover record identifies the full queried name, record type, authoritative server, staff resolver, response code and remaining lifetime. It does not compare two screenshots labelled only “DNS result”. A query for another hostname or record type would not establish the same fact.
The authoritative response confirms the newly created record and its intended value. The staff resolver's answer retains the negative response and a decreasing lifetime. The reviewer also checks that the workstation is using the resolver identified in the record; querying an unrelated public resolver would not explain the employee's actual path.
| Observation | Result in the exercise | Meaning |
|---|---|---|
| Before record creation, through R-1 | NXDOMAIN, 300-second negative lifetime | R-1 can retain the absence for the stated interval |
| After creation, direct to authority | Approved address | The authoritative configuration now contains the record |
| Minute three, through R-1 | NXDOMAIN, 120 seconds remaining | The earlier negative answer remains in this inspected cache |
| After expiry and a fresh query through R-1 | Approved address | That resolver has obtained the current positive answer |
RFC 2308 explains negative caching and the lifetime derived from the SOA information. It also specifies that an expired cached negative answer must not be reused. The numerical lifetime above belongs to the example; it is not a universal DNS waiting period.
Complete the receiving check
The team keeps the correct authoritative record unchanged and schedules the next check against the recorded expiry. After that interval, a fresh query through R-1 returns the approved address. The staff workstation can then reach the intended test portal using the same hostname.
The reviewer separately checks HTTPS identity and the expected catalogue page. Those are subsequent checks, not conclusions inferred from DNS alone. A valid address could still lead to a server with the wrong certificate, an incorrect application route or unavailable content.
The completed record contains both DNS responses and the later application observation. It explains why the earlier failure occurred and shows the actual result after the relevant cache interval. “It works for me now” would leave the cause and affected route less clear.
Retain a comparison that could disprove the diagnosis
An unrelated existing hostname continues to return its original address before and after the exercise. No nameserver replacement, bulk zone rewrite or unrelated record change is performed. The new catalogue name is the only intended addition.
If R-1 still returns a negative response after the recorded interval, the team reopens the investigation. It checks the complete resolver chain, actual response, delegation and authoritative state rather than asserting that waiting longer must solve it. A fresh NXDOMAIN obtained from current authority is different from the old cached answer.
Likewise, a timeout, refusal or DNSSEC validation failure should not be relabelled NXDOMAIN merely because the browser cannot open the site. Preserve the actual diagnostic result and involve the responsible DNS administrator where required.
Leave instructions someone else can follow
The handover names who controls the registrar account, who maintains DNS and who can inspect the affected resolver path. It records the approved hostname and destination, evidence locations, the bounded recheck and the condition requiring further investigation. Avoid putting credentials or private network details in a public support document.
For a website or portal handover, the useful outcome is a repeatable explanation of one observed failure and its resolution. Retaining the correct configuration while examining cached absence is often more informative than making another change simply to make the dashboard look active.