NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Orbi (RBR50) DNS keeps failing.
Hi, I'm have an RBR50 running Firmware V2.7.2.104 that has been working fine for a couple years now. Very recently, devices connected to the Orbi have started getting failed DNS queries, causing th...
Ran into this issue as well. This Reddit thread has the best workaround I've found for the bug(s) that Netgear pushed out with its most recent release for this model.
https://www.reddit.com/r/orbi/comments/m5l3vk/orbi_dropping_dns/
There are several options. I think the best one is to use the debug.htm page to enable telnet, log in, and modify the DHCP settings to tell clients to contact external DNS servers directly thus bypassing the failing proxy on the router. This change sticks until the router is rebooted which is rare for me. All devices will renew theri DHCP lease within 24 hours (or less) to get the new setting. I recommend forcing devices to renew their DHCP lease to get the new settings sooner. You can unplug the LAN connection, toggle wifi on/off, reboot a device, or issue the command to renew specific to your device/OS. However if you have one computer plugged directly into a LAN port, one simpler way to reset all the wifi attached device's DNS config is to change the wifi name configured on the Orbi, wait a few minutes, and then change it back. I judged "a few minutes" by monitoring my phone to see when it decided the wifi connection was lost. Once back to the original name, my (Android) phone took a couple of minutes to accept the wifi was stable.
There are also reports that the bug is an interaction issue between the DNS process (dnsmasq) and the traffic measuring/metering feature, and that disabling the traffic measuring feature will avoid the bug. Since I don't *need* the measuring feature, I disabled it just in case a thunderstorm glitches the power, there's a chance the Orbi will remain reliable afterwards without the effort/distraction of the reconfiguration workaround.
I had this identical problem recently, also on the 2.7.2.104 firmware, multiple times per day, for about the last week or so, which seems to have been resolved since yesterday by doing a factory reset and reconfiguration. To add to what you've observed, the problem seems specific to DNS queries passing through an Orbi satellite (RBS50). Unplugging the satellite appeared to solve the issue for as long as the satellite remained unplugged (all devices then being forced to connect directly to the router), though, admittedly, I never left it unplugged longer than a few hours to see for sure whether it truly addressed the problem.
It may be that merely doing a factory reset on the satellite is sufficient to fix it. But doing a full factory reset on the router (RBR50) appears to have fixed it for me for going on 24 hours now, though it's a much bigger pain, and, unfortunately, I'd already done a full factory reset on the router before it occured to me to just try it on the satellite. So I don't know that only factory resetting the satellite will work, but it's low-cost and high-reward, so I'd give it a shot before factory resetting the router.
As an aside, the Orbi configuring connected devices to use it as the DNS server, rather than passing on the configured DNS servers, serves multiple purposes. One is it allows orbilogin.com to work for accessing the router's web interface, as someone else pointed out. Another is that it allows DNS recursion, which generally improves performance. If multiple users/devices on your network want to use the same services (FB, YouTube, Netflix, whatever), instead of each device independently querying your DNS server (say, Cloudflare's 1.1.1.1), the first one queries the Orbi, the Orbi queries Clouflare, gets the response, passes it back to the requesting device, and, this is the important part, stores the result in the cache, so when another device makes the same request, instead of it going all the way to Cloudflare a second time, the Orbi already has the answer in the cache, and just immediately responds to the DNS request without needing to query outside your own LAN. In addition to resolving the DNS request to an IP address sooner for subsequent queries for your devices, it also reduces traffic to and queries of the DNS server, improving performance for everyone else. This is also what your DNS server (whether you use your ISP's, or Google's, Cloudflare's, etc.) does, caching results for faster turnaround, rather than having to pass each request up the chain to an authoritative DNS server.
There is next to zero benefit from running your own local DNS caching server. Your ISPs caching name server speeds are sufficiently fast, as are any of the major player's caching resolvers. Additionally, you're not relying on a device that isn't as well maintained as the major player's resolvers. If your Orbi is compromised, your local cache could be poisened by an attacker, opening up all kinds of security issues.
It's fine if you don't know, or simply don't mind using the local resolver, but I prefer systems that at least give me the option to fully configure my local services.
As for using "orbilogin.com" to logon, I've never done that, nor was I even aware it was an option. Simply browsing to the gateway address and/or using the ORBI app is typically how I access the router.
I had tried a factory reset already, and the problem reoccured not long after. (Same or the next day, if I recall.)
For what it's worth, since I have manually set the DNS servers in the udhcp settings, I have had no issues on the network. I'll deal with re-configuring it should the Orbi ever need to be reset.
Your local cache could be poisoned, yes. But the cache automatically clears itself, either by regarding old entries as stale, and/or by newer cache entries pushing the oldest ones out. You should probably run your own DNS service locally, point the Orbi to it, and have it use DoT/DoH (neither of which the Orbi currently supports) to resolve queries securely from only authoritative DNS resolvers. This is the logical endpoint of your concern about DNS poisoning.
And I discovered after posting my previous reply that the issue was with the traffic meter and daylight saving time settings. The factory reset disabled the traffic meter, which I hadn't gotten around to re-enabling. Subsequently, I restored my saved configuration, disabled DST, changed time zones so the displayed time would be correct, and enabled the traffic meter, and no problems since.