Diagnose a website failure after changing nameservers

A nameserver change modifies the parent delegation. It does not copy the zone, prepare the destination website, issue a certificate, remove a stale DS record, or make existing caches forget the old delegation. Diagnose from parent to child to application, one layer at a time.

Scope the symptom

Capture:

• registered domain and affected hostnames;
• old and new nameserver sets;
• change time and previous delegation TTL;
• parent NS, glue, and DS before and after the change;
• zone exports from both DNS providers;
• exact DNS response seen by affected and unaffected clients;
• whether email or other names also fail; and
• the rollback owner and maximum acceptable interruption.

The registrant or authorized registrar account controls parent delegation and DS. Each DNS provider controls its authoritative service and zone data. The web host, CDN, and certificate owners control the layers after DNS.

Read-only checks

1. Review the Domain Registration Lookup pathway to capture available registration status and nameserver fields.
2. Use the DNS Lookup pathway to capture parent-facing NS, A, AAAA, CNAME, SOA, DS, and DNSKEY observations as applicable.
3. Query every old and new authoritative server directly for the apex, www, email, verification, and other required records.
4. Compare SOA serials and zone inventories. Confirm the new servers answer authoritatively from reachable IPv4 and IPv6 paths where published.
5. Compare parent NS with child-apex NS and inspect glue for in-bailiwick nameserver targets.
6. If DNS returns the intended destination, review the SSL/TLS Checker, Redirect Checker, HTTP Headers Checker, or HTTPClarity pathway for the next layer.

DNS delegation creates an administrative boundary between parent and child zones [1]. Glue address records in a referral support nameserver names that would otherwise create a resolution dependency [4]. Authoritative data ranks above non-authoritative referral or additional data, which is why the verifier must label each observation’s source [2].

Interpret the observations

Observation	Supported interpretation	Responsible owner
Parent still lists old NS	Delegation has not changed at the observed parent path or is cached	Registrar or recursive-resolver owner
Parent lists new NS; new servers lack required records	Zone migration or publication is incomplete	New DNS provider and zone owner
New servers disagree or are non-authoritative	New authoritative service is not ready	New DNS provider
Parent DS remains; new keys do not match	DNSSEC validation failure is supported	Registrar/parent DS and new signing owner
DNS is correct; TLS name or chain fails	Investigation has moved beyond DNS	Certificate, CDN, or web owner
DNS and TLS work; HTTP response is wrong	Redirect, virtual host, CDN, or origin is implicated	Web application owner

DNSSEC authenticates the chain from parent data into the child. A delegation can be reachable while validation still fails [3].

Likely causes

• incomplete zone import, including apex, www, email, or verification data;
• the new nameservers are not authoritative or do not agree;
• parent and child NS sets differ unexpectedly;
• missing or incorrect glue for in-bailiwick nameservers;
• a stale parent DS points to unrelated child keys;
• recursive caches still hold the old delegation;
• the new DNS answer points to an unprepared CDN, host, or origin;
• certificate hostname coverage or chain is incomplete;
• redirect, virtual-host, proxy, or origin configuration is wrong; or
• the domain is expired, on hold, or otherwise blocked at registration.

Safe next actions

Stop before further changes if the current zone cannot be exported, new authorities disagree, required records are missing, DS state is unknown, or the rollback owner is unavailable.

• Read-only: preserve the parent, each authority, resolver, TLS, and HTTP evidence with timestamps.
• Reversible: add a missing reviewed RRset to the new zone only when the source of truth and prior export are known.
• Availability-impacting: if the new service is not ready and the old service remains intact, execute the pre-approved delegation rollback to the complete old nameserver set. Keep the new service online for caches that already learned it.
• Availability-impacting: use a reviewed DNSSEC recovery sequence for a DS and DNSKEY mismatch. Parent DS and child signing are separate changes.
• Reversible: when DNS is verified, correct the certificate, CDN, redirect, virtual host, or origin at its own control plane without further DNS edits.

Do not mix registrar transfer, nameserver migration, DNSSEC repair, and website reconfiguration into one improvised recovery.

Verification

Verify in order:

1. the parent publishes the intended NS, glue, and DS;
2. every intended authority answers consistently with the complete zone;
3. named recursive resolvers return explainable delegation and record states;
4. DNSSEC is secure or intentionally insecure according to the reviewed plan;
5. the certificate covers the hostname and validates;
6. redirects, status, headers, CDN, and origin behavior are correct; and
7. email and other non-web services survived the delegation change.

After rollback, verify both old and new authoritative services remain safe for clients with different cached delegations until the overlap window ends.

What this evidence does not prove

A website failure after a nameserver change does not prove:

• the registrar lost the domain;
• DNS “has not propagated”;
• the new provider copied every record;
• DNSSEC is the cause of every SERVFAIL;
• a correct address record means TLS or HTTP works; or
• restoring the parent delegation instantly clears resolver caches.

Next protocol layer

If authorities agree but resolvers differ, use resolver disagreement diagnosis. If validating resolvers return SERVFAIL, use the SERVFAIL path. When DNS is correct, hand the evidence to HTTPClarity or the relevant TLS, redirect, headers, CDN, or origin owner instead of changing delegation again.