Reboot the router and the internet heals. By tomorrow it is broken again — same error, same time of day, every device in the house together. A fault that keeps a schedule is telling you where it lives. This page teaches you to read that rhythm and replace guessing with proof.
Intermittent faults are the most expensive kind, because every temporary fix feels like success. The daily-comeback shape of ERR_NAME_NOT_RESOLVED has a specific anatomy: name resolution degrades over hours of router uptime — lookups slow, then fail, then every site reports its name cannot be resolved — while a router reboot restores perfection instantly. The usual author is the router's built-in DNS forwarder, the small relay that accepts your devices' questions and passes them to the provider. In cheap and ageing routers this component leaks memory, overheats, or simply has buggy firmware, so it dies by inches across the day. A second author lives upstream: a provider whose DNS servers buckle at peak hours. Either way, the fix is not another reboot ritual — it is to route around the dying component and prove, with a simple log, that the rhythm has stopped.
Before changing anything, check your experience against the pattern:
A fourth, confirming test during an outage: ping 8.8.8.8 still answers (the line is alive) and nslookup example.com 1.1.1.1 — asking a public resolver directly, past the router's relay — succeeds while your normal lookups fail. That combination acquits your provider's line and convicts the relay in one step.
Intermittent problems eat weekends because memory edits them. Counter with a boring little log: time the failure starts, which devices are affected, whether numbers still ping, and what fixed it. Two or three entries are enough to see the rhythm — always after long uptime, always all devices, always cured by reboot.
The log also protects you in the other direction. If entries show failures hitting one device at random times, or surviving router reboots, the router is innocent and you are back to per-device causes — cache, adapter settings, security software — covered by the other guides in this series. Diagnosis is the art of letting the pattern fire the suspects it does not match.
You do not have to replace the router to escape its DNS relay. Take the relay out of the path:
1.1.1.1 and 8.8.8.8 — instead of the router's own addressDevices now ask strong resolvers directly; the router only has to route packets, the job it can still do. If the router offers no such setting, the same change on your main PC's adapter proves the concept for a day, and a healthy result makes the case for the permanent step: update the router's firmware (forwarder bugs are classic firmware fixes), check its ventilation — a router cooking in a closed cabinet fails exactly like this — and, if the rhythm survives all of it, replace the router. Hardware that dies daily is not having bad days; it is dying.
One pattern mimics the router fault: failures that arrive at the same clock times daily — the evening streaming peak — and lift by themselves without any reboot. That rhythm points past your router to the provider's DNS servers sagging under load. The distinguishing test is the bypass: during an episode, if nslookup through 1.1.1.1 answers instantly while your normal (provider) servers time out, your equipment is exonerated.
The cure is the same shape as the router fix — hand your devices public resolvers in the router's DHCP settings so the provider's DNS is simply never asked — but the verdict matters for your expectations: no new router will fix a provider-side sag, and the log you kept is exactly what the provider's support needs if you choose to report it. Judge the change over three ordinary days. A rhythm that ran for weeks does not get to call itself fixed after one good evening.
Watch the video for the outage test done live — numbers answering, names failing, and the direct-resolver lookup that proves which box is guilty.
▶️ Watch Full VideoBecause the fault builds up over time. The router's DNS forwarder slowly degrades — leaking memory, overheating or hitting a firmware bug — until lookups fail. A reboot clears that state, so resolution works again until the same slow failure rebuilds over the following hours.
During an outage, check the pattern: all devices failing together, ping to 8.8.8.8 still answering, and nslookup through 1.1.1.1 succeeding while normal lookups fail. That combination means the line and the public DNS are healthy and the shared relay in the middle — the router — is the failing piece.
Remove the weak link from the path: set public DNS servers in the router's DHCP settings so devices stop using its forwarder, update the router firmware, and give it ventilation. If the daily rhythm survives those steps, the router itself is failing hardware and replacement is the honest end.