Diagnose a website failure after DNS resolves

Once the affected client resolves the intended hostname to the intended DNS answer, the investigation has crossed into another protocol layer. TLS can reject the service identity, HTTP can route by authority and path, redirects can loop, a CDN can fail to reach its origin, and a browser can apply cache or security policy. Further DNS edits can hide the evidence without fixing the failure.

Scope the symptom

Capture the exact:

• URL, including scheme, hostname, port, path, query, and fragment;
• browser or client, network, time, and error text;
• DNS answer and resolver used by that client;
• destination address or CDN edge reached;
• TLS alert or certificate result;
• HTTP method, status, redirect chain, and selected response headers;
• working and failing hostnames, such as apex versus www;
• affected region, protocol, or user segment; and
• recent DNS, certificate, CDN, redirect, origin, or deployment changes.

The DNS owner controls name-to-destination data. The certificate or CDN owner controls TLS service identity. The CDN, load balancer, proxy, web server, and application owners control HTTP routing and responses.

Read-only checks

1. Use the DNS Lookup pathway to confirm the affected hostname and resolver return the intended A, AAAA, or CNAME chain.
2. Review the SSL/TLS Checker pathway for hostname coverage, validity, issuer, chain, and negotiated endpoint evidence.
3. Use the Redirect Checker pathway on the exact URL to capture each server-side hop and final destination.
4. Review the HTTP Headers Checker pathway for one live status, final URL, and response-header observation.
5. Compare apex and www, HTTP and HTTPS, IPv4 and IPv6, and an affected and unaffected network without changing production state.
6. Continue into the HTTPClarity pathway to interpret request, connection, TLS, redirect, cache, and HTTP boundaries.

A URL contains more than a DNS name; parsing and serialization follow the URL Standard [1]. HTTP uses the scheme and authority to identify an origin and route a request [2].

Interpret the observations

Observation	Supported interpretation	Responsible owner
DNS is intended; TLS certificate lacks the hostname	Service identity or certificate deployment is wrong	Certificate, CDN, or edge owner
TLS succeeds; redirects loop or reach the wrong hostname	Redirect or canonical-host configuration is implicated	CDN, proxy, or application owner
One address family fails	IPv4/IPv6 path, edge, firewall, or origin coverage differs	Network, CDN, or origin owner
Edge returns 502, 503, or 504	Upstream availability or gateway routing is implicated	CDN, proxy, or origin owner
Direct origin works; public hostname fails	Edge configuration, TLS, routing, or policy is implicated	CDN or load-balancer owner
HTTP is correct in a fresh client; one browser fails	Browser cache, HSTS, extension, service worker, or local policy is supported	Client or application owner
Content works but migration URLs or canonicals are wrong	Search and navigation verification is now required	Web and SEO owners

TLS service identity matching uses the reference identity and certificate identifiers; a valid chain alone is not enough if the hostname does not match [3].

Likely causes

• the exact hostname is missing from the certificate;
• the certificate is expired, not yet valid, incomplete, or deployed on only some edges;
• apex and www route to different services;
• IPv4 and IPv6 destinations are not equally prepared;
• HTTP-to-HTTPS or canonical-host redirects loop;
• CDN custom-hostname, route, proxy, or cache configuration is stale;
• origin virtual-host routing does not recognize the requested authority;
• CDN-to-origin TLS or firewall policy fails;
• the application returns a 4xx or 5xx response;
• a browser cache, HSTS rule, extension, or service worker changes behavior; or
• migration canonicals, internal links, or redirects point to the wrong URL.

Safe next actions

• Read-only: preserve the exact URL, DNS answer, certificate, redirect chain, status, headers, edge identifiers, and timestamps.
• Reversible: correct one certificate, redirect, virtual-host, CDN, or origin setting in its owning control plane with the prior value captured.
• Reversible: purge only the scoped cache layer supported by evidence; avoid broad cache deletion as a diagnostic substitute.
• Availability-impacting: stop a rollout or execute the approved application-layer rollback if errors are increasing and the prior configuration is known healthy.

Stop before changing DNS when it already returns the approved destination. Stop application changes if the failing URL, responsible layer, prior configuration, or rollback owner is unknown.

Verification

Verify in order:

1. the affected resolver returns the intended DNS chain;
2. every intended IPv4 and IPv6 endpoint negotiates TLS for the exact hostname;
3. the redirect chain is finite and reaches the approved canonical URL;
4. HTTP status, headers, content, cache behavior, CDN, and origin are correct;
5. apex, www, important paths, regions, and representative clients behave as intended; and
6. migration redirects, canonical signals, and internal navigation are reviewed where URLs changed.

Preserve before-and-after observations from the same vantage points.

What this evidence does not prove

A correct DNS answer does not prove:

• the certificate covers the hostname;
• the endpoint serves the intended virtual host;
• redirects terminate at the right URL;
• one CDN edge represents every edge;
• a 200 response contains the correct application;
• every browser has the same cache or policy state; or
• search engines have processed a migration correctly.

Next protocol layer

Continue with HTTPClarity for protocol interpretation. When redirects, canonicals, or discoverability changed, use the NavSEO pathway after DNS, TLS, and HTTP are verified. If the affected client still resolves a different answer, return to resolver disagreement diagnosis.