A Practical Network Diagnostics Guide

Separate DNS resolution, IP ownership and website reachability before deciding what is broken, with the checks to run in the order that avoids chasing the wrong layer.

By Net Insight Published 2026-09-16 Updated 2026-09-17

Start with the symptom, not the tool

A browser failing to load a page does not identify a failing layer. The name might not resolve, the server might refuse a connection, TLS might fail, or the application might return an error. Four different problems produce one symptom, and the tools that investigate them do not overlap.

This site covers two of those layers: DNS answers, and public metadata about addresses. It deliberately does not send arbitrary web requests to addresses a visitor supplies, and it does not scan ports. Knowing what a diagnostic cannot see is as useful as knowing what it can, because it stops a clean result from being read as a diagnosis.

The order below is the order that avoids the most common mistake: investigating a layer above the one that is actually broken.

Check the name and the record type first

Use the DNS lookup page with the host name that actually fails, not with the domain you assume is equivalent. The bare domain and its www host name are separate sets of records and frequently differ, which is why a site that loads at one address can fail at the other.

Compare A and AAAA separately. A working IPv4 path does not prove that an IPv6 path works, and an empty AAAA answer is a normal configuration rather than an error. Where the family itself is the question, the IPv6 test reports which one this connection used, and the record type reference explains which types a normal zone publishes.

Read the response status as carefully as the answer. A successful response with no records of the requested type is a different finding from a name that does not exist, and both are different from a resolver that failed to answer. Conflating those three produces most of the confusion in this area.

Read differences in context, not as failures

After changing a record, keep the previous time to live in mind. Different public resolvers can hold old and new answers simultaneously until caches expire, and a difference between them is the expected state for the duration of that window rather than evidence of a broken zone.

A lower time to live set after a change does not retroactively shorten every cached copy of the old record, and a name that previously did not exist is cached on a different timer again. The arithmetic is worth doing rather than estimating: the TTL calculator turns the old value and the elapsed time into the actual window, and the propagation checker shows whether two resolvers currently agree.

Record the queried name, type, response status, answers and timestamp. The JSON download includes these together, which makes a before-and-after report more useful than a screenshot of an address without context.

Inspect the resulting address

Once a name resolves, the address it returns is the next thing worth understanding. IP check reports the address this connection uses together with its approximate network ownership and region, and ASN lookup reports which organisation announces a given range.

Hosting ownership does not identify which tenant operates a website. Shared hosting and content delivery addresses serve many unrelated domains, so an organisation name that does not match the brand you expected is normal rather than suspicious. A city label describes where the range is registered or routed, and for a hosted service that is a data centre rather than the owner’s office.

Two cautions are worth carrying forward. An address is shared and reassigned, so any observation attached to one is a statement about a network attachment point at a moment in time. And whether an address appears on a blocklist has no bearing on whether a page loads; that question belongs to mail, not to this layer.

Keep the mail layer separate

Mail questions look like network questions and mostly are not. For a domain that should receive mail, the MX record check shows where mail is routed and whether a single host is a point of failure. For a domain that sends, the SPF checker reads the record that declares which hosts may send, the DKIM checker probes the published signing keys, and the DMARC checker reads the policy that decides what happens when authentication fails.

None of those proves that a message will be delivered, and none of them is improved by reading it out of order. The email deliverability test runs the four together and returns a list ordered by dependency rather than by ease, which is the sequence worth following when more than one is missing.

There is also a difference between mail that is refused and mail that is filed away. A refusal is usually a configuration problem, and it is visible in the checks above. Being placed in a spam folder is a reputation outcome, and authentication is a precondition for fixing it rather than a cause. The two look identical from the sending side, which is why it is worth establishing which one is happening before changing anything.

Know when another tool is needed

If DNS looks correct and the page still fails, the browser’s own network error is the next source of information, and it names a layer this site does not test. Whether a response was encrypted, whether a certificate was valid and whether a server redirected correctly are all outside the scope of a DNS and address diagnostic.

For the records that govern which certificate authorities may issue for a name, the SSL and CAA check reads them from DNS. For the configuration of a response you already have, the header audit parses it locally. For whether this device is reachable from outside, the NAT type check reports what translation is doing to outbound connections.

Where an address has been flagged as belonging to a hosting provider or an anonymity service, VPN and proxy detection explained covers why that inference is produced, why providers disagree about it and why it should never be read as a conclusion about a person.

Missing reputation data stays unknown. No combination of country, organisation and the absence of a reported flag yields a trustworthy cleanliness percentage, and a report that offers one has compressed independent observations into a figure with no defined meaning.

Keep observations and conclusions in different sentences. “This address resolves to a cloud provider’s range” is an observation. “This connection is therefore not a real customer” is a conclusion the observation does not support, and writing the first without the second is the habit that makes a diagnostic report usable by somebody else.

Questions worth asking

A website will not load. Where should I start?

With the name, because a name that does not resolve makes every later step meaningless. Query the exact host name that fails, compare A and AAAA separately, and only then move on to the address and the mail configuration.

The DNS answer looks correct but the page still fails. What next?

That answer only proves the name resolves. Whether a server accepts a connection, whether TLS completes and whether the application responds are separate layers, and none of them is visible in DNS.

Why do two resolvers give different answers?

Resolvers cache independently, so during a change one can still hold the previous answer. That is the normal state for the duration of the old time to live, and it needs no action beyond waiting it out.

Is an IP address location the location of the website owner?

No. It describes where an address range is registered or routed, which for hosted sites is a data centre and for virtual private networks is the exit node. It locates a network attachment point, never a person.

Should I check for blocklists first?

Only if the symptom is mail being rejected. A blocklist has no bearing on whether a page loads, and starting there for a mail problem usually means skipping the authentication records that matter more.