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

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

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.

Developer Tools and dig pointed at the same problematic resolver

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.

One WAN DNS change fixed things and held them together

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.