DNS connects familiar domain names to the network information devices use to reach services. When it fails, a browser can report that a site is unavailable even though the computer's Wi-Fi connection is healthy. DNS is often blamed for every connectivity problem, however, and changing resolvers blindly can hide rather than solve the root cause. A few small tests help you distinguish a local cache issue, a misconfigured name, and a larger internet outage.
What DNS does—and what it does not
A DNS resolver answers queries such as 'What address is associated with this hostname?' It does not guarantee that a web server at that address is listening, that its TLS certificate is valid, or that a firewall permits the connection. A successful DNS response can accompany a broken website; a failed DNS response can accompany otherwise functioning internet access. Keep those distinct when interpreting browser errors.
A domain may have several types of records. Address records such as A and AAAA relate names to IPv4 and IPv6 addresses. CNAME aliases point one name toward another name. MX records describe mail routing. TXT records often support ownership verification and email authentication, among other purposes. Changing one record without understanding the service that uses it can break websites or email.
Begin with one failing hostname
Record the exact name, error message, device, and network. Test whether other unrelated websites open. Check whether a coworker on a different network sees the same problem. If only one domain fails everywhere, the site or its authoritative DNS may be affected. If many unrelated names fail only on one laptop, local DNS configuration, security software, VPN routing or resolver reachability are stronger suspects.
Do not enter company or private internal hostnames into public DNS-checking websites. For sensitive systems, use approved internal diagnostics. If the network is managed by an employer or school, ask administrators before changing resolver settings.
Use a simple lookup tool
On Windows, Command Prompt supports nslookup example.com; other systems often provide dig or a similar utility. Look at whether an answer arrives and which DNS server replied. A timeout suggests the selected resolver may not be responding, although transient network loss can produce a similar symptom. An NXDOMAIN response generally means that, from that resolver's perspective, the requested name does not exist; it does not automatically prove someone has removed the entire website.
Compare queries from a second approved network or resolver where policy permits. If one resolver returns an outdated address and another returns the current one, caching or propagation may be involved. DNS changes can take time to become consistent due to caching, but there is no universal 'always exactly 24 hours' rule.
Clear a local cache only when justified
A resolver cache speeds repeated lookups and can retain records until they expire. If you have reason to suspect stale local data, Windows allows ipconfig /flushdns. Clearing a local cache cannot correct a wrong record at the authoritative DNS provider, an expired domain registration or a disconnected server. Restarting the browser may also help with application-level caches, but do not change many settings at once.
On managed devices, DNS may be controlled by a VPN, security client or enterprise policy. A manual public DNS setting may break internal company names or content filtering. Respect network requirements and document any authorized temporary changes before reverting them.
Website owners: check the whole path
If you run a site and change its hosting provider, inspect nameservers, current authoritative records, TTLs, redirects and HTTPS configuration. A domain that resolves to the right IP can still show a hosting placeholder if the web server does not recognize the hostname. Conversely, changing nameservers without copying the existing MX, SPF, DKIM and verification records can interrupt email service while the website appears normal.
Before migration, export the DNS zone where possible. Make one controlled change, check the intended service, and keep a rollback plan. Avoid deleting unfamiliar records because they 'look old'; they may be needed by a payment gateway, search verification or another company service.
How to tell whether DNS was really the fix
After the service returns, verify both the lookup and the application: open the website, confirm its correct content, check HTTPS errors and test essential forms or email where relevant. Note whether you updated a record, corrected a typo, switched an approved resolver or waited for an outage to end. A fixed browser page is useful evidence, but it does not on its own identify which layer caused the incident.
Common questions
Can changing DNS make slow Wi-Fi faster? It may affect name-lookup time in some cases; it does not increase wireless signal strength or ISP bandwidth.
Does a DNS lookup prove a website is working? No. It confirms name resolution, not server, application or TLS availability.
Should I remove all TXT records during a migration? No. Many support email and ownership verification; audit them before modifying.
Reference
Cloudflare's DNS explanation introduces recursive resolvers and authoritative name service. Always verify record changes with your actual DNS hosting provider.