Troubleshoot a domain that does not resolve: build an evidence handoff before changing anything

Write a blank question card before collecting conclusions

Start with one hostname and one question, not every service behind a domain. A browser message alone is not a DNS response receipt. If authorized evidence already exists, preserve its context; otherwise request it from the responsible operator. Do not paste credentials, private account details or unrelated network data into a shared worksheet.

Keep five evidence rows, not five assumed causes

Use “recorded,” “pending” and “not checked” as evidence states. Recorded means a receipt is available for the stated question, not that its interpretation is correct or the domain is healthy. A pending answer is not a negative result. Reuse the question card for each receipt, keeping collection time and scope attached.

Blank handoff: recorded rows ____; pending ____; not checked ____; unresolved interpretation ____; supporting receipts ____; requested next check and authorized owner ____; changes performed ____. Keep an unfilled field visible rather than turning it into a guessed result.

A registration restriction is not interchangeable with another

ICANN distinguishes inactive, where no name servers are associated and the domain is not active in DNS, from serverHold set by a registry and clientHold set by a registrar, which suppress DNS activation. clientTransferProhibited instead restricts transfer. A generic “locked” label therefore does not itself explain DNS failure. Record the exact observed code and source; do not translate every restriction into a DNS hold or assume you may remove it.[3]

Google’s domain troubleshooting guidance treats NXDOMAIN for a registered domain as a reason to check registration, expiry and hold possibilities. It does not establish that every NXDOMAIN means expiration or an available name. Route account-status questions to the authorized account/registrar owner; the public guidance cannot establish your ownership, account state or entitlement to a status change.[1]

Read the question, answer and referral together

RFC 2308, published in March 1998, distinguishes Name Error/NXDOMAIN from NODATA. NODATA is a response-inferred pseudo-code for a valid name in the given QCLASS without records of the requested QTYPE. A CNAME chain can change the name ultimately being resolved. An empty answer with NOERROR is not automatically NODATA: the answer, authority SOA/NS and referral context matter. Record these details before giving an empty answer a diagnosis. This uses Sections 1 and 2, not a claim about every current implementation.[4]

Keep NXDOMAIN, SERVFAIL and no response separate in the record. Google’s domain guide discusses conditional checks for these different outcomes; an extended DNS error, if supplied, can add a clue but is not guaranteed to exist or have identical wording or client presentation. Preserve the original message and who obtained it, rather than rewriting a clue as a confirmed cause.[1]

Route missing delegation and validation evidence without weakening security

Google’s guide discusses parent referrals, name-server names and glue as conditional places to investigate delegation problems. A mismatch or absent receipt needs the relevant operator’s interpretation. Keep the parent’s information separate from an authoritative server’s answer; a resolver result alone is not a complete record of either. Ask which exact question and source are still needed, not for an unapproved nameserver edit.[1]

The same guide discusses DNSSEC validation clues, including stale DS information after a provider change. That makes change history and validation evidence relevant, not proof of this case’s cause. Hand those questions to the authorized DNSSEC/domain operator. This worksheet gives no recipe or authorization to disable validation, remove DS records, bypass a failure or weaken security.[1]

Compare matched observations, not isolated screenshots

Google’s domain guide uses comparisons between recursive resolvers and authoritative answers as conditional evidence. Match hostname, CNAME context, QTYPE and QCLASS, then retain observation times, resolver/network context and complete receipts. Different results identify a comparison to investigate; they do not alone identify which layer is wrong. An unchecked authoritative row stays unchecked even if two recursive answers agree.[1]

The general Google troubleshooting page discusses differing SOA serials and stale authoritative data after server changes as possibilities. Its displayed update date is September 3, 2024, distinct from the October 14, 2026 access record. Do not turn this historical guidance into a universal propagation deadline, a cache-clearing recipe or a promise that waiting will repair the domain. Record the specific evidence and next responsible owner instead.[2]

Fictional Meadow Lantern Day: three receipts do not close five rows

Everything below is invented: Meadow Lantern Day, symbolic Domain C, its web hostname, statuses, receipts and people. The scenario is dated October 15, 2026 at 09:00, UTC−06:00—a future fictional timestamp relative to this October 14 draft, not an actual observation. No query, account access or change occurred. P1 and P2 ask for the same fictional web hostname, QTYPE A and QCLASS IN; no CNAME is recorded.

The ledger contains 3 recorded + 1 pending + 1 not checked = 5 rows. Agreement between P1 and P2 does not fill D or A. The recorded clientHold is a reason to route the registration question, not proof of every causal step or a guaranteed remedy. There is no evidence here of expiry, an available domain or authority to remove the hold.

Return the unresolved question, not a success claim

The fictional handoff is: registration-status interpretation goes to the authorized account/registrar owner; parent-delegation evidence remains not checked; the authoritative receipt is pending; two recursive NXDOMAIN receipts cover only the stated A/IN question. Request the missing evidence within the owner’s authorization and agree a review time. Changes performed: none. This is an invented example, not a message sent to a provider.

For your real handoff, attach the exact question card, receipt locations, evidence-state counts, known change history and named next owner. Keep observation separate from interpretation and permission separate from technical possibility. Stop short of an unsupported diagnosis or edit. A completed worksheet does not establish domain ownership, restore resolution, or prove that a website, email service or TLS configuration works.