Start with the exact symptom

Write down the complete URL, hostname, error message, timestamp and affected network. “DNS_PROBE_FINISHED_NXDOMAIN”, a connection timeout, a certificate warning and an HTTP 502 are different failures. Test the bare domain and www separately because they may use different DNS records.

Map the request path before changing anything

A browser request normally passes through DNS resolution, IP routing, TCP, TLS, HTTP and the origin application. A DNS answer only proves that a name returned data; it does not prove that the returned server is reachable or that the application is healthy. Keep the original symptom so you can tell whether each change helped.

Check delegation with NS and SOA

Use DNS Lookup to inspect NS and SOA records. Compare the authoritative nameservers shown by the parent zone with the nameservers configured at the registrar. Check the SOA serial and primary server as well. Mixed delegation, an expired domain or a recently changed nameserver can make different resolvers return different answers.

Read A, AAAA and CNAME together

A records provide IPv4 addresses, AAAA records provide IPv6 addresses and CNAME records create hostname aliases. Confirm that each returned address belongs to the intended service. If IPv4 works but IPv6 fails, inspect the IPv6 listener, route, firewall, load balancer and certificate before deleting an AAAA record. If a CNAME is present, follow it to its final address and check for stale aliases.

Use TTL as an explanation, not a repair

TTL controls how long recursive resolvers may reuse an answer. It does not fix a wrong record or clear an existing cache immediately. During a planned change, record the old value, lower TTL before the change, keep the old service available, and wait for the previous cache window before declaring the migration complete.

Separate DNS from HTTPS

When the hostname resolves to the expected public IP, run Website Diagnostics. Check the HTTPS status, response time, final URL, redirect chain and response headers. A certificate mismatch points to TLS or virtual-host configuration; a timeout points to routing, firewall or service reachability; a 502, 503 or 504 usually requires checking the proxy and origin application.

Compare more than one viewpoint

A recursive resolver may have an older cached answer while an authoritative server already has the new record. Compare authoritative data with results from more than one resolver or network, and test both root and www. A mobile network working while office Wi-Fi fails often indicates a resolver, firewall or routing difference rather than a universal DNS outage.

Worked diagnostic sequence

For a website that will not open, first record the symptom; then query NS, SOA, A, AAAA and CNAME; compare the address with the expected provider; inspect IP and ASN context; test HTTPS and redirects; review origin logs using the matching timestamp; change one layer at a time; and retest after caches and services update.

When to contact the provider

Contact the registrar when delegation, domain status or nameserver settings are wrong. Contact the DNS provider when authoritative records or zone serials are incorrect. Contact the hosting, CDN or server provider when DNS is correct but TLS, HTTP, firewall or upstream responses fail. Include the hostname, time, resolver result and diagnostic status instead of only saying that the site is down.

Common mistakes and safety limits

Do not change DNS repeatedly while caches are still converging, treat a successful lookup as proof that the website is healthy, or publish an AAAA record before IPv6 is tested end to end. Only diagnose domains and systems you are authorized to inspect; do not submit credentials, private URLs or secrets to a public lookup tool.

Check real data now

Use the live IIPP tool to inspect the domain or IP address you are working with.

DNS Record Lookup →