Kernaali Tools
MikroTik

MikroTik “DoH server connection error”: DNS over HTTPS Checks

Diagnose resolving error, SSL errors and connection reset by peer using DoH bootstrap DNS, endpoint compatibility and certificate validation.

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

Read-only • RouterOS 7
/system/resource/print
/ip/dns/print
/system/clock/print

Record 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 resultNext evidence
DoH server connection error: resolving errorCan the router resolve the DoH endpoint hostname without depending on that same unresolved service?
SSL/certificate validation errorCorrect time, hostname, trusted chain and required revocation information
while reading - Connection reset by peerConnection/endpoint/protocol compatibility and underlay stability; not automatically a missing certificate
Idle timeout - waiting dataCorrelate 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 answerInspect 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.

Technical references

Found an issue? Send a correction with a reproducible example.