A stale DNS record can make one device cling to the wrong website address, but failures across an entire network point to the router or an upstream resolver.
When a website refuses to load, the first question is not whether DNS is broken, but where the bad answer is being stored. The practical order is usually to clear the device’s local DNS cache first and only then move to the router if the same failure appears across several machines. That sequence is faster, less disruptive and better aligned with how DNS faults normally present themselves in the real world.
DNS exists to translate a domain name into an IP address, and both operating systems and network equipment cache those answers so they do not have to ask again every time. According to DNSimple and ShowDNS, that caching improves speed and cuts repeated lookups, but it also means a device can cling to an outdated record after a site changes hosting, a DNS entry is edited or a resolver briefly fails. In practice, that is why a page may work on mobile data while still failing on a particular Wi-Fi network.
The local cache on a laptop, phone or browser is the right place to start when the problem is isolated. DNSimple notes that flushing the cache forces the system to fetch fresh records rather than reusing stale data, and MacMyths and DNScale both emphasise the same first step when only one device is affected. Typical signs include one machine opening the wrong site, a browser reporting that a server IP cannot be found, or an error such as DNS_PROBE_FINISHED_NXDOMAIN appearing while other devices on the same network continue to work normally.
Windows users can clear the resolver cache with ipconfig /flushdns, a step documented by Microsoft and repeated in several support guides. On macOS and Linux, the equivalent involves the local resolver service, while some browsers also keep their own host data, which means a system-level flush may not be enough if the fault appears only in one browser. That is why technicians often test another browser, another device or a private window before deciding whether the issue is truly local.
A router-level cache becomes the more likely culprit when multiple devices fail together. MacMyths, RouterVia and other guides describe the router as a shared DNS hop in many homes and small offices, especially when it forwards queries to an ISP resolver or a public DNS service. If a phone, laptop and smart TV all reach the same wrong address, the fault is probably not confined to one device. In that case, restarting the router, saving the DNS settings again or toggling DNS relay options may clear the stale entry. In a work environment, that reset should be handled carefully because even a short reboot can interrupt calls, payment terminals and security devices.
There are limits to what a cache reset can fix. If the domain has broken authoritative records, expired registration, failed DNSSEC validation or blocked DNS traffic, clearing the local or router cache will not solve the underlying problem. Split DNS can also complicate diagnosis, particularly when a company domain resolves differently on office networks, on VPN and at home. Negative caching can create another false lead by temporarily remembering that a record did not exist, even after it has been added correctly. For that reason, the safest troubleshooting method is to note the exact domain, device, network and error message before changing anything. Start with the smallest scope, then move outward only if the evidence points to the router or upstream resolver.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.





