Request. Please add first-class DNS-over-TLS (DoT) resolver support to RouterOS (port 853/TCP), alongside the existing DNS-over-HTTPS (DoH) client.
Why DoT (in addition to DoH):
Multi-upstream resilience. DoT is naturally multi-homable across any number of resolvers (853/TCP) without relying on any one HTTPS endpoint or CDN path. If one provider or hostname fails, RouterOS can fail over to others seamlessly.
Operational simplicity. DoT runs directly to resolver IPs on 853, avoiding HTTP stacks, proxies, and URL semantics. This reduces moving parts and improves debuggability for NOC teams.
Performance & jitter. Fewer protocol layers than HTTPS; easier connection reuse and lower header overhead for sustained query loads.
Policy control. Easier to steer/ACL (e.g., allow only :853 to approved resolvers) and simpler to monitor via Netwatch/metrics.
Standards alignment. DoT per RFC 7858 and RFC 8310 is widely deployed (e.g., Quad9, Cloudflare, Google Public DNS, many ISPs). Many enterprise environments standardize on DoT for egress DNS encryption.
Minimum viable implementation (suggested):
Resolver list (multiple upstreams):
Configure by IP and optional auth name (Subject/SAN hostname).
Example providers users might add: 1.1.1.1, 9.9.9.9, 8.8.8.8 (and their auth names).
TLS authentication modes (RFC 8310):
PKIX validation using system CA store + subject-name match.
Optional SPKI pin or certificate pinning per upstream.
Optional DANE TLSA validation (if feasible later).
Health checks & failover:
Active probes; mark upstream up/down.
Policies: round-robin, latency-based, or priority order.
Caching & features:
Reuse existing RouterOS DNS cache.
Support TCP keepalive, connection pooling, Happy-Eyeballs for multiple upstreams.
Optional QNAME minimization toggle (on by default, RFC 9156).
Security knobs:
require-tls=yes|no (hard fail vs opportunistic).
verify-certificate=yes|no with clear logging on failures.
In /ip/dns set: tls-servers (list), tls-require, query-minimization.
Status page showing upstream health and latency.
Migration notes (from DoH):
Many users currently use DoH to encrypt DNS. Adding DoT lets operators:
Keep DoH where needed, and also add multiple DoT servers for redundancy.
Prefer DoT for lower overhead and easier ACLing, while retaining DoH as a fallback if desired.
Thank you for considering this. DoT support would materially improve RouterOS deployments in ISP and enterprise networks that require encrypted, resilient DNS without single-endpoint dependency.
I think the reason to use DoH and move away from DoT is in the use case for encrypted DNS for home users: they want to circumvent the DNS interception done by their ISP.
DoT is easy to block for the ISP, with DoH that is much more difficult (of course “well known DoH providers” are still easy to block).
Of course a lot can be improved in the RouterOS DNS resolver, the option for having multiple upstream resolvers being one of them. And to protect against interception, DNSSEC support would be great as well.
My opinion remains: ditch the DNS resolver, switch to using “unbound” as an existing resolver that has the required features.
MikroTiks DNS works well enough for everything I set up at SOHO Places. I’m very averse to setting up an extra Device or Containers.
And Containers need to be maintained to some Degree, while the integrated Service is pretty Hassle free and the more qualified Users can even handle it themselves.
UseCases for DoT
DNSoverHTTPS is nice to have, but overly complicated for most Use Cases in my Opinion.
I usually use Quad9 and as you said well known Servers are as easy to spot without having Details from inside the Connection.
I only see People using big public Resolvers or they just have a VPN to the Server.
I'll note unbound is still worthwhile advice for DoT, if that's your pleasure.
What kills me here, unbound is still not yet an /app that make deployment trivial. Since I fear either DoT and/or DoQ are a long way off, since RouterOS just got caught up to HTTP/2...
Availability of features really should not depend on architecture but only on available storage.
There should be a separate "RouterOS lite" version for architectures where storage is an issue, e.g. ARM32 devices with 16MB flash. ARM32 devices with lots of flash (e.g. RB4011) should just get all features.
As @rextended and @Amm0 are right I quickly created Tickets for Feature Requests with an old Account on their Helpdesk Portal help.mikrotik.com
—————
SUP-223338 Native DNS-over-QUIC (DoQ, RFC-9250) resolver in RouterOS
SUP-223337 Native DNScrypt resolver in RouterOS
SUP-223336 Native DNS-over-TLS (DoT, RFC 7858/8310) resolver in RouterOS
—————
If anyone wants to Support the Feature Request it should be enough to write a short Message to help@mikrotik.com and reference the Ticket Numbers applying.
(At the Moment these Tickets just Link to the Forum. Should be enough seeing it’s their own, but I will discuss with them if necessary…)
I’m not so sure it’s an Issue with the Storage.
I can imagine their Implementation being based on some Instruction Sets not available outside of x86 and ARM64.
RouterOS being not modular enough and in Turn being pretty big for what’s inside some not-so-old Devices is another Issue.
I’d prefer not having Code that could be a Package on the Devices for Security Reasons.
You can see that the other libraries have similar unpacked sizes between ARM64 and ARM (identical for many), but the libuhttp.so library has a whooping 116KiB size difference (but it will be smaller after compression). That grow is without a doubt from the HTTP/2 support.
But 7.25beta3 could reduce the wifi-qcom-ac by 300KB, so maybe there is now room left to grow the size of the libuhttp.so for ARM.
Of course the reason is storage. Any processor that is Turing-complete can perform any task you can imagine, that does not depend on details of the instruction set. When ARM64 has some special instruction that optimizes encryption (for example), a replacement in C or asm can be used on ARM32 instead.
We have seen several storage limit problem in history, mainly on ARM32 with 16MB flash and wireless interface available, like hAP ac2. Lots of effort is spent to reduce the image size, and part of this is omitting features. That has also happened with SMIPS where the devices not only have 16MB flash, but also only 32MB RAM so the workaround for installing updates from RAMdisk does not work there and the downloaded .npk files have to fit in the flash (together with the running version).
With SMIPS it is not an issue because those are low-end devices, but ARM32 is used in flagship routers with 512MB of flash space, and it is really a pity that features are omitted just to keep hAP ac2 working.
