Feature Request: Native DNS-over-TLS (DoT, RFC 7858/8310) resolver in RouterOS

RouterOS General
1

Dear MikroTik Team,

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):

  1. 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).

  2. 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).

  3. Health checks & failover:

    • Active probes; mark upstream up/down.

    • Policies: round-robin, latency-based, or priority order.

  4. 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).

  5. Security knobs:

    • require-tls=yes|no (hard fail vs opportunistic).

    • verify-certificate=yes|no with clear logging on failures.

    • Per-upstream allow-plain-fallback=no (default).

  6. Observability:

    • Per-upstream stats: queries, RTT p50/p95, failures, TLS errors.

    • Log topics for TLS handshake/auth failures.

    • /tool profile visibility of DNS resolver CPU usage.

Example CLI sketch (RouterOS-style):

/ip/dns/tls-resolver
add name=cloudflare address=1.1.1.1 auth-name=cloudflare-dns.com \
    verify-certificate=yes pin-spki="" keepalive-timeout=30s
add name=quad9 address=9.9.9.9 auth-name=dns.quad9.net verify-certificate=yes
add name=google address=8.8.8.8 auth-name=dns.google verify-certificate=yes

/ip/dns
set use-dnssec=no cache-size=4096KiB query-minimization=yes \
    servers="" tls-servers=cloudflare,quad9,google tls-require=yes

/ip/firewall/filter
add chain=output action=accept protocol=tcp dst-port=853 \
    dst-address-list=DOT_RESOLVERS comment="Allow DoT to approved resolvers"

/ip/firewall/address-list
add list=DOT_RESOLVERS address=1.1.1.1
add list=DOT_RESOLVERS address=9.9.9.9
add list=DOT_RESOLVERS address=8.8.8.8

API & WinBox/WebFig:

  • New resource: /ip/dns/tls-resolver (fields: name, address, auth-name, verify-certificate, pin-spki, keepalive-timeout, status, rtt, 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.

6 Likes