I’ve been using a B One for over a year, and have had a stable configuration for months without issue.
One day last week, out of the blue, all clients started experiencing delayed DNS resolution. My configuration has the following settings:
- The single active WAN has assigned DNS addresses (Cloudflare and Quad9)
- The WLAN and LAN clients have the B One as the DNS source
- DNS Caching enabled
- DNS over HTTPS enabled (via Quad9)
- In Service Forwarding, Forward Outgoing DNS Requests to Local DNS Proxy is enabled
After a great many experiments, including updating firmware to 8.5.2, I discovered that the only way to eliminate the timeouts was to either cut the B One out of the DNS loop (manually assigning DNS servers to clients plus disabling the forwarding of DNS requests), or by simply switching away from Quad9 in the DNS over HTTPS setting.
Anyone else experiencing something like this? Thanks!
1 Like
Have you disabled the DNS proxy on the B One? it is enabled by default.
If you’re referring to the DNS Proxy in the Service Forwarding section, then yes, I played around with it. Is there another setting I overlooked?
With Quad9 as the DNS-over-HTTPS setting, if I enabled that DNS proxy but left the B One as the assigned DNS source for clients then I still get timeouts. I had to also have DHCP assign explicit external DNS servers to avoid the timeouts under these circumstances.
Whereas if I instead simply switched from Quad9 to Cloudflare as the DNS-over-HTTPS destination, the timeouts disappeared.
Disable the DNS Proxy. Sorry, I’m not sure what you mean by “[playing] around with it,” did you disable it?
I meant I tried enabling and disabling the DNS proxy.
When I disabled the proxy and set up DHCP to assign external DNS providers to the LAN clients directly, everything worked.
When I enabled the DNS proxy and had Quad 9 as the DNS-over-HTTPS source, then clients experienced timeouts. When I changed from Quad 9 to Cloudflare in DNS-over-HTTPS, then the timeouts disappeared.
Everything is working fine for me right now since I switched to Cloudflare, but didn’t know whether I was the only one seeing this issue, which came up suddenly for no apparent reason.
Sounds like there is an issue with Quad9 or the way it was configured, but since it’s working fine with Cloudflare it seems it’s not a Peplink issue.
I had major issues with Quad9 as my DNS on my peplink. The only solution I could find was switching to a different DNS. Quad9 was adamant it wasn’t their issue. Peplink was adamant it wasn’t theirs. I kind of wondered if my ISP was blocking it but they said they weren’t and they don’t seem to block any other DNS. So all three parties said it wasn’t their issue. I ran out of time playing around with it but may try again. I have multiple WANs including Starlink active now so I may be able to see if the issue is just with one ISP.
We have a case open with Peplink support over the DNS Proxy feature breaking on a MBX device when we disable NAT on the FusionHub’s VPN connection.
The DNS Proxy feature works great when the setting is on “NAT” (default configuration), but when changing the setting to “Network → Connection Settings → IP Forwarding” (and disabling the other NAT checkbox), then it breaks DNS resolution for the clients behind the MBX.
What the support has seen is that the MBX uses its “Untagged LAN” IP for DNS resolutions, which we do not use and cannot disable (and is not routed on our network). I don’t understand why the MBX would not use the client-facing IP by default, and there seems to be no way to change this behaviour either. We’ve tried changing this IP with a NAT rule on the MBX, but it still breaks DNS somehow. We’re kind of accepting that this feature isn’t as flexible as we’d want it.
My issue may not be the same as A_Mandel’s, but I thought I’d put it out there, in case this sheds some light for someone. We are trying to get a feature request to make it possible to choose the IP the MBX uses for the DNS Proxy feature, but the support people don’t seem to be inclined to do so.