HTTPS DNS PROXY Issue

Hi, I was speaking to first line support Vilius, -We have HTTPS Proxy enabled, and users are being randomly disconnected at various intervals, resulting in a loss of internet access.

When we check the event logs on the Teltonika device, they indicate that DNS resolution starts to fail, and after some time it reports that DNS resolution has been restored.

This issue is affecting multiple locations for our customer.

We have to restart the HTTPS-DNS-PROXY to get the site back online.

Can you advise if there any bug or known issue?

Teltonika Affected - X11, X956

Firmware - R_00.07.19.4, R_00.07.14.3, and R_00.07.20.3

This is the System logs from the teltonika -

150160 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):432032 BCB2: curl response code: 400, content length: 80
150161 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):432167 BCB2: 0000: 7b 63 6c 65 61 6e 62 72 6f 77 73 69 6e 67 2d 64 {cleanbrowsing-d
150162 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):432252 BCB2: 0010: 6f 68 2d 73 65 72 76 65 72 7d 3a 20 65 72 72 6f oh-server}: erro
150163 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):432334 BCB2: 0020: 72 20 78 30 32 35 3a 20 55 6e 61 62 6c 65 20 74 r x025: Unable t
150164 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):432416 BCB2: 0030: 6f 20 67 65 74 20 72 65 73 70 6f 6e 73 65 20 66 o get response f
150165 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):432965 BCB2: 0040: 72 6f 6d 20 44 4e 53 20 73 65 72 76 65 72 2e 0a rom DNS server..
150166 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):434491 2D58: curl response code: 400, content length: 80
150167 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):434694 2D58: 0000: 7b 63 6c 65 61 6e 62 72 6f 77 73 69 6e 67 2d 64 {cleanbrowsing-d
150168 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):434879 2D58: 0010: 6f 68 2d 73 65 72 76 65 72 7d 3a 20 65 72 72 6f oh-server}: erro
150169 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):434978 2D58: 0020: 72 20 78 30 32 35 3a 20 55 6e 61 62 6c 65 20 74 r x025: Unable t
150170 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435095 2D58: 0030: 6f 20 67 65 74 20 72 65 73 70 6f 6e 73 65 20 66 o get response f
150171 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435185 2D58: 0040: 72 6f 6d 20 44 4e 53 20 73 65 72 76 65 72 2e 0a rom DNS server..
150172 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435354 2D58: curl response code: 400, content length: 80
150173 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435452 2D58: 0000: 7b 63 6c 65 61 6e 62 72 6f 77 73 69 6e 67 2d 64 {cleanbrowsing-d
150174 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435535 2D58: 0010: 6f 68 2d 73 65 72 76 65 72 7d 3a 20 65 72 72 6f oh-server}: erro
150175 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435617 2D58: 0020: 72 20 78 30 32 35 3a 20 55 6e 61 62 6c 65 20 74 r x025: Unable t
150176 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435699 2D58: 0030: 6f 20 67 65 74 20 72 65 73 70 6f 6e 73 65 20 66 o get response f
150177 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):435788 2D58: 0040: 72 6f 6d 20 44 4e 53 20 73 65 72 76 65 72 2e 0a rom DNS server..
150178 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):538590 F821: curl response code: 400, content length: 80
150179 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):539058 F821: 0000: 7b 63 6c 65 61 6e 62 72 6f 77 73 69 6e 67 2d 64 {cleanbrowsing-d
150180 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):539398 F821: 0010: 6f 68 2d 73 65 72 76 65 72 7d 3a 20 65 72 72 6f oh-server}: erro
150181 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):539723 F821: 0020: 72 20 78 30 32 35 3a 20 55 6e 61 62 6c 65 20 74 r x025: Unable t
150182 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):540015 F821: 0030: 6f 20 67 65 74 20 72 65 73 70 6f 6e 73 65 20 66 o get response f
150183 Thu Mar 5 11:44:50 2026 daemon.info https-dns-proxy[29081]: [E] 4750620.1772711090 (null):540301 F821: 0040: 72 6f 6d 20 44 4e 53 20 73 65 72 76 65 72 2e 0a rom DNS server..

Hello,

Thank you for your detailed description of the issue.

From the information shared, the connectivity loss appears to be caused by the HTTPS DNS Proxy (DNS-over-HTTPS) failing to receive valid responses from the upstream DoH server. The logs show repeated errors such as curl response code: 400 and “Unable to get response from DNS server” , which indicates the proxy is unable to successfully query the configured DoH provider. When this happens, DNS resolution on the router stops, which results in a loss of internet connectivity until the service is restarted.

To further troubleshoot the issue, please try the following steps:

  1. Verify the DoH server configuration
  • Ensure the configured DoH URL is correct and complete.
  • Confirm that the selected CleanBrowsing DoH endpoint is valid.
  1. Check bootstrap DNS configuration
  • Make sure a reliable bootstrap DNS server is configured (for example 1.1.1.1 or 8.8.8.8).
  • The router uses this to resolve the DoH server hostname before the proxy can operate.
  1. Test connectivity from the router
  • If possible, access the router via SSH and verify connectivity to the DoH endpoint using a curl test.
  1. Restart related services
  • Instead of rebooting the device, restart the DNS services to confirm whether the proxy is the cause:
    • /etc/init.d/openvpn restart dnsmasq
  1. Test with a different DoH provider
  • Temporarily switch to another provider (e.g., Cloudflare or Google DoH) to determine whether the issue is specific to the current upstream server.
  1. Check firmware and configuration state
  • If the issue began after a firmware upgrade, test after performing a configuration reset (after backing up settings) and reconfigure the DoH settings manually.

If the issue persists, please provide:

  • A screenshot of the HTTPS DNS Proxy configuration
  • Confirmation of the configured DoH URL and bootstrap DNS servers

This information will help determine whether the issue originates from the proxy configuration, connectivity to the upstream DoH server, or the service itself.

Kind regards,
V.

Hi Vilius,

We have verified the DoH server configuration and everything appears to be correct. However, we have a few sites where DNS resolution has started failing without showing any specific errors.

I also tried running the following command, but it does not work:
/etc/init.d/openvpn restart dnsmasq

/etc/init.d/dnsmasq restart works…

/etc/init.d/https-dns-proxy restart dnsmasq - doesnt work…

Additionally, we are experiencing this issue across multiple firmware versions: R_00.07.19.4, R_00.07.14.3, and R_00.07.20.3.

Furthermore, we attempted to configure DNS Status and Event Logs on the dashboard, but it does not seem to be working properly. It detects some sites, while most others appear blank. Could this be a bug?

Also, is there a way to trigger an alert whenever there is a change in DNS status? When we try to set up an alert, we receive an error indicating that some fields are not supported.

Hi Vilius,

Do you have any update on the DNS Status and Event Logs on the dashboard, We have 38 online and 65 still no reporting status update in RMS. We can see the internet status is online on the device itself.

Also, is there a way to trigger an alert whenever there is a change in DNS status? When we try to set up an alert, we receive an error indicating that some fields are not supported

Thanks

Greetings,

I hope this message finds you well,

Regarding the commands, I am sorry that I provided with a faulty command. Correct syntax of the command to restart the service is:

Example: /etc/init.d/<service> restart

Regarding the DNS Status and Event Logs in RMS, currently this feature does not always report consistently for all devices. If a router shows internet connectivity locally but RMS displays “no reporting status”, it usually means the device is still connected to RMS but the DNS monitoring data is not being collected or forwarded correctly. This can happen when:

  • DNS-over-HTTPS (DoH) is enabled, since DNS queries are handled by https-dns-proxy and are encrypted. RMS may therefore receive limited DNS visibility.
  • The router still has internet connectivity, but the DNS status metric itself is not updated or supported by the firmware/RMS combination.

Because you are seeing this across multiple firmware versions, it is more likely related to RMS reporting limitations rather than the router losing connectivity.

For confirmation, check:

  • RMS connection status (device should show Online)
  • Whether DNS monitoring works when standard DNS (without DoH) is used.

DNS status alerts

At the moment, RMS does not support a direct alert trigger for DNS status changes, which is why the alert configuration returns the message about unsupported fields.

Workaround

A practical approach is to use Connectivity Monitoring with a hostname (for example google.com):

  • The router periodically resolves and pings the host.
  • If DNS resolution fails, the connectivity check fails.
  • This can then trigger an RMS alert.

This indirectly alerts you when DNS resolution stops working.

Kind regards,
V.

Hi Vilius,

Thank you for the update.

However, it is still unclear to us why this feature is working on some sites but not on others. The network design and configuration are the same across all of our locations, so technically we would expect it to behave consistently at every site.

Could you please clarify whether this is a known limitation or bug within RMS, or if it is related to the Teltonika device firmware or functionality? Any additional insight into why this discrepancy occurs would be appreciated.

Thanks