Building Resilient DoH Failover on MikroTik RouterOS to Handle Unreachable Cloudflare Responses

A branch office network suddenly stopped loading certain pages such as the Tailwind CSS CDN build that had worked reliably for weeks, while the rest of the internet remained accessible. Investigation on the MikroTik router revealed that :resolve returned valid addresses, DoH responded with Status:0, and the health monitor reported the upstream as healthy, yet clients experienced timeouts.

The root cause was two specific IP addresses returned by Cloudflare: 8.6.112.0 and 8.47.69.0. These were legitimate responses, but no route existed from the affected network segment to those prefixes. Standard resolver health checks that only verify whether an IP was received cannot detect this class of failure.

Initial DoH Deployment and Its Limitations

By default, RouterOS routes local DNS queries in plaintext toward the provider. Enabling DoH required a single command: /ip dns set use-doh-server=... verify-doh-cert=yes. The administrator selected the Cloudflare Family filtering resolver and initially considered the task complete.

Within days, reports arrived from the branch. Disabling DoH and testing plain DNS produced identical addresses, confirming the issue was not filtering but reachability. Client-side verification using curl --resolve demonstrated that the same IP worked from the main gateway yet timed out from the branch.

Requirements and RouterOS Constraints

The administrator defined three core requirements: all router-to-upstream traffic must use HTTPS with certificate validation, local clients must be forced through the router resolver, and automatic failover to a secondary DoH endpoint must occur on failure with automatic return on recovery.

RouterOS natively supports only one active DoH upstream. The often-recommended /ip dns static-server type=doh syntax does not exist in current versions. Bootstrap servers listed under servers= are used solely for initial name resolution of the DoH hostname and are not treated as fallback resolvers when DoH fails.

Health Monitor Evolution and Key Fixes

• Version 0.1.0 incorrectly accepted any IP-typed response, including the unreachable Cloudflare pair.
• Version 0.2.0 introduced content validation against known stub prefixes and switched to out-of-band HTTPS JSON probes to avoid disrupting active DoH sessions.
• Later versions added dual-threshold logic (failureThreshold=2, recoveryThreshold=2) to implement hysteresis and prevent flapping.
• Clock validation rejects dates outside 2025-2035 because an invalid system time breaks certificate verification and mimics upstream failure.

Static DNS entries were added for both primary and secondary DoH hostnames plus dns.google bootstrap addresses to break circular dependencies. The trust anchor SSL.com TLS ECC Root CA 2022 had to be imported because the built-in trust store does not cover the Cloudflare chain.

Current Architecture

The production configuration maintains four ordered stages: primary DoH, secondary DoH, optional tertiary DoH, and optional plain DNS as last resort. Only one stage is active at any time due to RouterOS limitations. The monitor script stores state in global variables, logs only on transitions, and performs pre-switch validation of the candidate endpoint plus post-switch verification before finalizing the change.

Testing confirmed that route injection or static hostname-to-reachable-IP mappings were the only effective remedies; merely changing the resolver brand never resolved the unreachable-prefix problem.