DNS is one step in reaching a website

When you enter a hostname such as www.example.com, the device needs information to reach the destination. DNS supplies records associated with names. An A record can give an IPv4 address, while an AAAA record can give an IPv6 address. Other record types support other jobs.

An answer does not prove the website is working. The device still needs a route, a connection to the server and a valid encrypted session for HTTPS. The application can then return an error or require authentication. “DNS resolves” and “the page loads” are different findings.

This simplified diagram separates the name question from the website connection. A cache may already supply the answer. The browser may use a different resolver from the operating system, so a local command and a browser need not follow the same DNS path.

Resolvers, authoritative servers and caches

A recursive resolver finds answers for clients, following DNS information when it lacks a cached answer. An authoritative nameserver publishes the records for a zone. A home router may forward questions to a resolver elsewhere rather than publishing the website’s records itself.

Caching avoids repeating work. A record’s time to live, or TTL, influences how long an answer can be retained. Different resolvers can hold answers obtained at different times, which helps explain why one connection sees an edited record before another.

“Propagation” does not mean a worldwide switch flips at a fixed time. The record, its previous TTL, delegation changes and resolver behaviour affect what people see. Repeated edits during testing can make the evidence harder to interpret.

Start with a controlled comparison

1. Record the exact hostname, browser error and time. Check spelling and whether the address requires www.
2. Try an unrelated site on the same device.
3. Compare another browser and, where possible, another device on the same connection.
4. Try another permitted connection if useful. Record VPN and browser secure-DNS settings.

A mobile-data comparison changes both the network path and probably DNS. A successful result there narrows the problem but does not prove DNS caused it. Another browser may also differ in extensions, sessions or proxy configuration.

Use a read-only lookup for supporting evidence

On Windows, nslookup can ask the configured DNS server for a name. Some other operating systems provide it too. If it is absent, follow the system’s own documented tools rather than installing unknown troubleshooting software.

nslookup www.example.com

This makes a DNS request for a documentation domain. Replace it with the public hostname you are investigating. Do not send confidential internal names to public resolvers or online tools. A company may deliberately use internal or split DNS over its network or VPN.

Read errors as well as answers. Multiple addresses can be normal for a distributed service. An IPv6 answer does not demonstrate usable IPv6 connectivity, and an IPv4 answer does not prove the server accepts a connection.

Compare the public view with your device’s view

The domain and DNS lookup provides another public view, including registration information when available. Its location and resolver are not your device’s, and it does not inspect your home DNS cache.

If that view looks correct while browsing fails, compare the local lookup and exact browser error. A proxy, VPN, certificate issue or blocked connection may be involved. Report those observations instead of declaring the whole site healthy because a remote lookup returned an address.

Treat a DNS change as an experiment

On your own network, another reputable resolver can help investigate some name-resolution failures. Record the old automatic or manual setting and know how to restore it. Ask IT before changing a managed device because DNS may provide internal names or filtering.

Repeat the original comparison afterwards where appropriate. A cache may also have expired or a destination recovered. Do not change the router, browser and device simultaneously and then assume which change fixed it.

A raw IP address is not a reliable replacement for a website name. HTTPS certificates and shared hosting depend on hostnames. Never bypass a certificate warning just because an address looks plausible.

If you manage the website

Identify the active authoritative DNS provider first. Registration, DNS hosting and website hosting can be separate services. Editing an inactive provider’s panel will not change the live zone.

After an intended change, check the exact hostname, record type and destination. Preserve unrelated records such as mail settings. Working email does not establish working web DNS, or vice versa.

A useful ticket includes the public hostname, expected answer, observed error, time, connection and VPN state. For the next stage after name resolution, use the website-not-loading guide.