One DNS change fixed the "internet is slow" complaint I'd been chasing for months

Published Sep 8, 2026, 8:00 AM EDT Samir Makwana is a technology journalist and editor from India since past 18 years and his work appears on MakeUseOf, HowToGeek, GSMArena, BGR, GuidingTech, The Inquisitr, TechInAsia, TechWiser, and others. He has written news, features, and gadget reviews for national technology media publications. His passion is to help people with their technology problems and gadget purchases. For that, he has worked for some of the biggest international technology publications, covering news, explainers, how-to guides, listicles, and product-buying guides. He has worked as an editor and managed teams since 2015. His expertise broadly covers computers, smartphones, game consoles, headphones, smart home products, browsers, and apps. For about three months, my mother told me the internet was slow. I’d ask her to restart her phone, and that’d be a temporary fix. But after a day, the pages would take too long to open, YouTube kept buffering, and occasionally froze. Video calls kept freezing for a second on my computer. That’s when I ran a speed test and got the same result: full bandwidth on the paid plan and barely any packet loss. Next, I rebooted my router, an ASUS RT-AX88U, and then the ISP sent a technician to inspect the line and found nothing wrong. So I added a second router as an AiMesh node to improve reach in the areas where the complaints usually come from. I also upgraded my internet plan to a higher tier to rule that out. In the end, none of that solved the actual recurring problem, which was sitting a few clicks deep into the router’s menu. It’s just that I hadn’t looked at it since it had nothing to do with spare capacity at all. At least, that’s what I thought. Clean speed test results don’t rule out a DNS problem Speed tests hit one server, but a real page hits several domains Every time I run a speed test, it picks up a server close to my location. That server has already been resolved and cached. Then the test measures how fast the data moves between that server and my home connection. That’s one way to measure it, but a real web page doesn’t work like that. Loading a web page can trigger a dozen separate DNS lookups. One can be the page’s own domain, another for the ad network, another for an analytics script, the font CDN, and any tracking pixels. The browser has to wait for each query before downloading the data. When the resolver is slow or inconsistent, the extra delay never shows up in the bandwidth test. That’s why the speed test results and complaints about how slow the web felt did not line up. The command line confirmed the delay that the browser showed In Microsoft Edge, I opened the Developer Tools from the three-dot menu in the top-right corner and went to the Network tab to reload a web page with a bunch of third-party requests. From there, I learned that all new sites took a couple of seconds to load the first time, and after that, the numbers dropped quickly. The pages loaded faster, even after disabling the cache on the Network tab. That detail mattered because Developer Tools’ Disable Cache option only clears the browser’s HTTP cache, copies of scripts, images, and stylesheets. So if a page still loaded fast with the box checked, the speed was coming from cached DNS responses rather than cached files. That ruled out ordinary browser caching as the explanation. So the pattern became obvious: a slow first load, then a faster cache load. It suggested that the bandwidth was in the clear and it might be a resolver problem. To confirm whether that was the case, I ran the dig command against a bunch of domains, once using my ISP’s DNS server by default and once using a public DNS resolver. Running several dig commands on the mini PC confirmed the problem wasn’t specific to Wi-Fi, as the wired mini PC experienced the same erratic timing. To put it straight, the ISP’s DNS is faster when it’s behaving, but it can randomly take longer to respond. For example, one query might return at 40ms for one query and the next at 1200ms. In comparison, Cloudflare public DNS is a little slower, but its response times are much more consistent and predictable. In the end, I lean more towards a predictable experience compared to an erratic one. One WAN DNS change fixed things and held them together The router’s WAN DNS field changed the browsing experience The fix was a single change in the router’s settings. Most consumer routers bury the DNS settings a few menus deep, because ISPs would rather you leave it alone. On my ASUS RT-AX88U router, I set Cloudflare’s Public DNS IPs (1.1.1.1 and 1.0.0.1) on the WAN side of DNS. I set the same in the LAN’s DHCP DNS fields since those only control which DNS addresses the router hands to devices on the LAN. Every device on the network automatically picks up the new public DNS resolver, without changing the Wi-Fi settings. Following that, the results from the dig command and the numbers in the browser's Developer Tools were consistently under 30ms. Once I set a public DNS in the WAN settings, the complaints about a sluggish browsing experience and streaming buffering stopped. Video calls no longer froze, and nothing else on the network changed. That confirmed that the inconsistency and unpredictability of the DNS were the cause, not a coincidence. Perform a few checks before replacing the hardware Next time someone in your house complains about the internet being slow, test the router before you buy new gear or bump your internet plan up a tier. Spending ten minutes running a dig comparison and peeking into the Network tab of a browser’s Developer Tools will tell you more than any speed test. If a public DNS resolver isn’t enough for you, then you may go further to run your own recursive resolver. For starters, you can use Unbound as a DNS resolver instead of Google or Cloudflare. That setup isn’t necessary to fix the problem I had. All I had to do was change the DNS in the router’s WAN settings.