A DoH connection error can occur before HTTPS starts, during certificate verification or after the server accepts a connection. Separate those stages. Do not disable verify-doh-cert as a general remedy, and do not assume the ordinary DNS server list is an automatic fallback while DoH is selected.
Applies to: RouterOS 7 using /ip/dns use-doh-server. Current DNS manual and CLI property reference, with architecture-dependent service compatibility checked on 12 September 2026. No minimum release for HTTP/2 or universal provider-specific bug fix is asserted. Browser-managed DoH is a separate resolver path.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Read the router’s intended resolver path
/system/resource/print
/ip/dns/print
/system/clock/printRecord the build, architecture, DoH URL, ordinary static/dynamic DNS servers and verify-doh-cert setting. Keep account-specific DoH URLs private. Confirm the configured URL is the provider’s DNS query endpoint, not its normal website.
The DNS manual explains that the DoH hostname needs bootstrap resolution using a configured ordinary resolver or a suitable static entry. Once DoH is in use, the ordinary server list is not a general per-query fallback. The CLI reference identifies the relevant properties without implying every value is a safe default.
Use the error as a branch, not a diagnosis
| Observed error or result | Next evidence |
|---|---|
| DoH server connection error: resolving error | Can the router resolve the DoH endpoint hostname without depending on that same unresolved service? |
| SSL/certificate validation error | Correct time, hostname, trusted chain and required revocation information |
| while reading - Connection reset by peer | Connection/endpoint/protocol compatibility and underlay stability; not automatically a missing certificate |
| Idle timeout - waiting data | Correlate with failed client queries and server/network behavior; an isolated idle event is not proof of a total DNS outage |
| Router answers correctly; browser uses another answer | Inspect the browser/VPN resolver independently of RouterOS DoH |
Repair bootstrap or trust without disabling verification
If bootstrap is missing, configure the approved ordinary resolver or a provider-verified static endpoint address according to the DNS documentation. A manually pinned address needs maintenance when the provider changes it. Verify the hostname still matches the HTTPS certificate; replacing the URL hostname with an arbitrary IP can break that check.
For a trust failure, verify the router clock and the certificate chain required by the chosen provider. Use the documented trusted-authority mechanism for your release. Where CRL checking is enabled, the DNS guide calls out the need for the full chain. Keep certificate checking enabled; a connection that works only after skipping verification has not resolved the trust failure.
Check architecture and release before blaming the provider
The current DNS documentation distinguishes services supported on all listed architectures from those limited to ARM64, x86 and CHR, and describes HTTP/2 negotiation on those platforms. Older forum claims that RouterOS never supports HTTP/2 cannot be carried forward as a current universal statement. Check both the current compatibility table and your installed release before changing providers or planning an upgrade.
A reset from the peer can also reflect a network or server condition. Compare one authorized query at the same time as the logged error and check the underlay. Do not increase every timeout or concurrency limit to conceal missing bootstrap or an incompatible endpoint.
Verify resolution and retain an explicit rollback
Test uncached names through the router, then use the intended client resolver to open an application by name. Check A and AAAA answers where the service uses both. Verify that an unrelated browser resolver is not making the test appear successful while the router still fails.
Record the old DNS settings before edits. Restore the exact previous working DoH URL, bootstrap and trust configuration if the trial fails. A temporary switch to approved ordinary DNS changes the privacy/transport policy and must be an explicit operational choice, not a hidden automatic fallback. Stop captures, which can disclose queried names, and retain only a redacted error summary.
Router resolves but clients do not · Investigate an unstable cellular path
Technical references
Found an issue? Send a correction with a reproducible example.