Configure DNS-over-HTTPS on MikroTik RouterOS
Encrypt DNS queries between the router and a DoH resolver, verify the TLS certificate, secure the cache for the LAN, and diagnose resolution failures.
When the MikroTik resolves a name with classic DNS, the request generally leaves the router via UDP or TCP on port 53. The requested name then remains visible along the path to the resolver, and an unprotected response can be altered by an intermediate device. DNS-over-HTTPS, or DoH, transports these exchanges within an encrypted HTTPS connection.
RouterOS can act as a DNS cache for LAN devices while using DoH externally. Computers, phones, and connected objects continue to query the router on port 53; the router then aggregates these requests and contacts the remote resolver on port 443 with TLS. This distinction is essential to understand what DoH actually protects.
What is encrypted — and what is not
In the configuration of this guide, the path consists of two distinct segments.
| Segment | Transport | Protection |
|---|---|---|
| LAN Client → MikroTik | Classic DNS, UDP/TCP 53 | Not encrypted by DoH, but limited to the local network |
| MikroTik → DoH resolver | HTTPS, TCP 443 | Encrypted by TLS and authenticated by certificate |
| Client with its own DoH | Direct HTTPS from the device | Bypasses the MikroTik cache and DNS rules |
Why this guide targets RouterOS 7.21 or later
RouterOS has supported DoH for a long time, but certificate authority management has evolved. Since branch 7.19, the system contains an integrated root authority store. Version 7.21 replaced the old builtin-trust-anchors parameter with builtin-trust-store and allows selecting the services authorized to use this store.
On a current installation, the default profile notably allows the DNS service to use the integrated authorities. It is therefore no longer necessary to manually download a root certificate from a URL that could become obsolete. For an older version, use the instructions corresponding exactly to that version or plan an upgrade after reading the release notes and testing the configuration.
Before you begin
Work from the LAN, enable Safe Mode with Ctrl+X, and keep an export as well as a binary backup off the router.
/export file=avant-doh
/system backup save name=avant-doh
/system resource print
/system clock print
/system ntp client print
/ip dns print
/certificate settings printThe date and time must be correct. TLS validation compares the certificate validity period with the router clock: a significantly offset clock can cause DoH to fail while Internet connectivity works.
Also verify that the router can reach the Internet via IPv4 and resolve a name before the modification.
/ping 1.1.1.1 count=4
:put [:resolve example.com]1. Choose a compatible resolver
RouterOS only accepts a single global server in use-doh-server. The chosen service must therefore be compatible with the HTTP implementation of your RouterOS version and have a certificate recognized by the store used.
Current MikroTik documentation cites Cloudflare, Google, NextDNS, and OpenDNS among compatible services. It also notes that some resolvers enforcing HTTP/2 may not work. Check this list before every provider change: a valid endpoint in a browser is not automatically compatible with the RouterOS DoH client.
The following commands use the standard Cloudflare resolver:
https://cloudflare-dns.com/dns-queryThis URL follows the RFC 8484 format. It does not correspond to a web page intended to be opened manually: RouterOS sends DNS messages there in the format expected by the service.
2. Prepare bootstrap resolution
Before establishing HTTPS, the router must know the address of cloudflare-dns.com. This is the bootstrap problem: DoH cannot resolve its own server's name as long as the DoH connection does not exist.
Temporarily or permanently configure the classic DNS addresses of the same provider. When use-doh-server is active and reachable, RouterOS uses DoH for normal queries; classic servers remain necessary for bootstrapping the endpoint.
/ip dns
set servers=1.1.1.1,1.0.0.1Another method is to create a correct static entry for the DoH server name, but it requires tracking the provider's address changes. Bootstrapping via classic resolvers is generally simpler to maintain.
3. Verify the integrated certificate store
Display the current setting. Under RouterOS 7.21+, default includes the dns service. If you have intentionally created a custom service list, ensure that dns is present before enabling TLS verification.
/certificate settings print
/certificate builtin printTo revert to the default integrated profile:
/certificate settings
set builtin-trust-store=defaultThis command should not blindly replace a custom certificate policy. Note the previous value in your operations folder. In a controlled infrastructure, you can also keep manually imported authorities and limit their trust-store property to the dns service.
4. Enable DoH with TLS validation
Now configure the HTTPS endpoint and imperatively enable verify-doh-cert=yes. Without validation, the request is encrypted, but the router does not correctly verify the server's identity: an intermediary capable of presenting its own certificate could then hijack the connection.
/ip dns
set use-doh-server=https://cloudflare-dns.com/dns-query \
verify-doh-cert=yes doh-timeout=5s \
cache-size=8192KiBRouterOS does not automatically failover to a second global DoH endpoint. If the server becomes unavailable, resolution may fail. Redundancy must therefore be considered at the level of the chosen endpoint, an intermediate local resolver, or a dedicated DNS architecture.
5. Distribute the MikroTik as the LAN DNS
If clients are to benefit from the router's cache and DoH upstream, advertise the MikroTik's LAN address via DHCP and allow remote requests. Adapt the network and address to your configuration.
/ip dns
set allow-remote-requests=yes
/ip dhcp-server network
set [find where address="192.168.88.0/24"] dns-server=192.168.88.1Then renew the DHCP lease of the devices or reconnect them to the network. An old DNS configuration may remain in memory until renewal.
6. Close the DNS cache to the WAN
allow-remote-requests=yes allows the router to respond on UDP and TCP 53. This service must be restricted to trusted networks. The default RouterOS firewall already drops new connections coming from the WAN, but check the actual rule order before relying on it.
/ip firewall filter
add chain=input action=accept in-interface-list=LAN \
protocol=udp dst-port=53 comment="DNS: allow LAN"
add chain=input action=accept in-interface-list=LAN \
protocol=tcp dst-port=53 comment="DNS: allow LAN TCP"
add chain=input action=drop in-interface-list=WAN \
protocol=udp dst-port=53 comment="DNS: deny WAN"
add chain=input action=drop in-interface-list=WAN \
protocol=tcp dst-port=53 comment="DNS: deny WAN TCP"Place the two authorizations before the final input drop. The two WAN drops are explicit and facilitate auditing; if an equivalent general rule already exists, do not create an unnecessary duplicate.
A DNS cache open to the Internet can participate in amplification attacks. Test from an external network that the router's public address does not respond on port 53.
7. Test resolution and the certificate
Flush the cache, force a new resolution, and check the logs.
/ip dns cache flush
:put [:resolve example.com]
/ip dns cache print where name="example.com"
/ip dns print
/log print where topics~"dns"The :resolve command must return an address and the cache must contain the name. In /ip dns print, check:
- the exact URL in
use-doh-server; verify-doh-cert: yes;- a correct clock;
- the absence of repeated TLS or DNS errors in the logs.
To confirm the transport, briefly observe the WAN interface. New resolutions should produce an HTTPS connection to the resolver, not a series of classic DNS queries to external servers. The initial bootstrap on port 53 remains normal, however.
/tool torch interface=ether1 port=53,443
/ip firewall connection print where dst-port=443Replace ether1 with the actual WAN interface. Do not use Torch as absolute proof of content: it confirms the transport and the destination, not the encrypted message inside TLS.
Redirecting clients' classic DNS: an option to handle with care
Some devices ignore the DNS provided by DHCP and directly contact a public resolver on port 53. You can redirect this traffic to the router's cache.
/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 \
action=redirect to-ports=53 comment="DNS: redirect LAN UDP"
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 \
action=redirect to-ports=53 comment="DNS: redirect LAN TCP"This redirection captures neither DNS-over-TLS on port 853, nor DoH hidden within HTTPS 443. Blocking all of port 443 to prevent DoH would break the Web. Controlling DNS encrypted directly by clients requires a policy adapted to the devices: MDM configuration, browser control, documented endpoint lists, or an enterprise resolver.
DoH and static FWD DNS entries
Old instructions sometimes claim that FWD entries are incompatible with DoH. Current RouterOS documentation indicates that FWD entries are supported and even proposes forwarders combining classic DNS servers and DoH endpoints.
Exact compatibility depends on the version, however. If you use FWD rules for split DNS, internal domains, or dynamic lists, test them before migration and after every upgrade. A DNS policy should never rely on a statement only valid for an old RouterOS branch.
Troubleshooting
| Symptom | Likely cause | Verification |
|---|---|---|
| Certificate error | Incorrect clock or DNS service missing from the trust store | Check the time and /certificate settings print |
| Endpoint name does not resolve | DNS bootstrap missing | Configure classic servers then test :resolve |
| DoH works then stops | Incompatible or unavailable endpoint | Compare with the MikroTik compatibility list and logs |
| Router resolves, clients do not | Incorrect allow-remote-requests, DHCP, or firewall | Test TCP/UDP 53 from the LAN and renew the lease |
| WAN can query the router | input rule too permissive | Check the order, interface lists, and test from the outside |
| Queries still go elsewhere | Direct DoH/DoT on some clients | Inspect device policies and 443/853 connections |
| Latency increases | Distant resolver, TLS reconnections, or cache too small | Observe times, cache, and persistent connections |
Revert to classic DNS
Keep the previous values before any modification. To disable DoH while keeping the bootstrap resolvers as classic DNS:
/ip dns
set use-doh-server="" verify-doh-cert=no \
servers=1.1.1.1,1.0.0.1
/ip dns cache flushThen remove, if you had added them solely for this project, the redirection rules and explicit DNS rules by searching for them by comment.
/ip firewall nat remove [find where comment~"DNS: redirect"]
/ip firewall filter remove [find where comment~"DNS: allow"]
/ip firewall filter remove [find where comment~"DNS: deny"]Conclusion
Configuring DoH on MikroTik is not just about pasting a URL. A reliable setup has a DNS bootstrap, a correct clock, a compatible endpoint, active TLS validation, and an authority store adapted to the RouterOS version. The cache must be advertised to LAN clients while remaining inaccessible from the WAN.
The result protects queries between the router and the DoH resolver. It does not automatically encrypt the LAN segment, does not prevent applications from using their own DNS, and does not hide IP connections. Considered for what it is — an upstream DNS transport protection — DoH nevertheless constitutes a useful and measurable improvement.
Technical references
Read next
About the author
Jeremy Kraft runs the infrastructure and the self-hosted services of the IBCSC. These guides describe configurations that were actually deployed and re-checked before publication.
Discussion
Comments
No comment yet. Feel free to open the discussion with a question or your own experience.