Posted in

MikroTik issues with DNS Redirect (DoH/DoT) and how to fix them properly

by dagorret••0

A practical technical guide for network administrators

Click here for the Spanish version

Introduction

In many home and professional networks, MikroTik RouterOS is used to centralize control of DNS traffic.
The typical goals are:

  • Redirect all DNS queries to an internal resolver (Unbound, Technitium, AdGuard, etc.)
  • Avoid DNS leaks to external servers (Google, Cloudflare, Quad9, etc.)
  • Prevent modern devices from using encrypted DNS (DoH/DoT) to bypass network policies
  • Consolidate filtering, logging and browsing control

However, RouterOS cannot handle all DNS traffic in the way many administrators expect.
There is confusion about:

  • what can be redirected,
  • what cannot,
  • and why.

This article explains these limitations, the technical reasons behind them, and presents a functional and robust solution based on:

  • Traditional DNS redirect (port 53),
  • specific blocking of DoH/DoT,
  • and an internal resolver (for example Unbound or Technitium).

1. How DNS Redirect works in MikroTik

RouterOS can redirect only traditional DNS, that is:

  • UDP/53
  • TCP/53

At the NAT level something like this is usually used:

/ip firewall nat add chain=dstnat src-address=192.168.88.0/24 dst-port=53 protocol=udp action=dst-nat to-addresses=192.168.50.2 comment="DNS Redirect UDP -> NUC" add chain=dstnat src-address=192.168.88.0/24 dst-port=53 protocol=tcp action=dst-nat to-addresses=192.168.50.2 comment="DNS Redirect TCP -> NUC"

In this example:

  • The Home LAN is 192.168.88.0/24.
  • The infrastructure (for example a NUC with Unbound/Technitium) is in 192.168.50.0/24.
  • The internal DNS server has IP 192.168.50.2.

With these rules:

  • Any packet that originates from 192.168.88.0/24 and goes to port 53 (DNS),
  • regardless of which destination IP it points to (8.8.8.8, 1.1.1.1, ISP DNS, etc.),
  • will be silently redirected to 192.168.50.2.

✔ Redirecting port 53 works very well

From the client’s point of view:

dig @8.8.8.8 google.com

will show something like:

SERVER: 8.8.8.8#53(8.8.8.8)

But in reality:

  • the packet never reached 8.8.8.8,
  • MikroTik intercepted it (dst-nat) and sent it to 192.168.50.2,
  • the response was generated by the internal DNS (Unbound/Technitium).

In other words: NAT “lies” about who replied, but that is precisely the idea behind redirect.

2. The problem: modern devices don’t use only DNS 53

The previous model worked perfectly when everything was classic DNS.
Today it no longer does.

Many operating systems and browsers implement encrypted DNS:

2.1. DoT (DNS over TLS)

  • Port: TCP 853
  • Example: Android (Private DNS), some routers, systemd-resolved, etc.
  • The content (the DNS query) travels inside a TLS tunnel.

2.2. DoH (DNS over HTTPS)

  • Port: TCP 443 (same port as HTTPS)
  • Format: DNS encapsulated in HTTP/2 or HTTP/3 inside TLS
  • Used by:
    • Firefox (DoH enabled by default in several countries),
    • Chrome / Edge / Opera (Secure DNS),
    • Windows 10/11 (Encrypted DNS),
    • some mobile phones and apps.

Consequence

  • DNS traffic is no longer a UDP/TCP 53 packet,
  • it is encrypted and hidden inside a TLS session.

Therefore:

Redirect rules based on dst-port=53 do not touch DoH/DoT.
In other words: DoH/DoT “sneak past” our classic DNS control.

3. Why MikroTik cannot redirect DoH/DoT to 53

It is tempting to try:

/ip firewall nat add chain=dstnat protocol=tcp dst-port=853 action=dst-nat to-addresses=192.168.50.2 add chain=dstnat protocol=tcp dst-port=443 action=dst-nat to-addresses=192.168.50.2

and expect that:

  • RouterOS receives the TLS flow,
  • “understands” the DNS inside,
  • and converts it into traditional (53) queries to the internal DNS.

❌ This is technically impossible in MikroTik (and in almost all routers).

3.1. DoT (TCP 853)

  • The payload is fully encrypted with TLS.
  • MikroTik sees only:
    • source IP,
    • destination IP,
    • port (853),
    • and that it is a TLS flow.
  • It cannot:
    • read the DNS message,
    • decode it,
    • rebuild a UDP/TCP 53 query,
    • and then re-encrypt it.

3.2. DoH (TCP 443)

  • It is encapsulated in HTTPS,
  • encrypted with TLS 1.2/1.3,
  • mixed with the rest of the web traffic.

To manipulate it, you would need to:

  1. Perform TLS interception (Man-in-the-Middle),
  2. Install your own root certificate on all clients,
  3. Decrypt, inspect, modify and re-encrypt all HTTPS traffic.

MikroTik does NOT do TLS intercept or DPI at that level.

Only very advanced corporate firewalls (Palo Alto, Fortigate, Sophos, etc.)
can do anything similar, and even then they do not “convert” DoH to port 53, they simply inspect or block.

4. Additional problems in MikroTik when building DNS redirect

On top of the logical limitations above, there are several practical details that often break the design.

4.1. Hairpin NAT and traffic between subnets

If the Home LAN is 192.168.88.0/24
and the internal DNS server is 192.168.50.2 (another subnet / another bridge),
it is common to need rules like:

/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.50.2 action=masquerade comment="Hairpin NAT for DNS redirect"

You may also see more general rules such as:

/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.50.0/24 action=masquerade comment="LAN->Infra NAT bugfix"

From the DNS server’s point of view:

  • It never sees 192.168.88.39,
  • it always sees 192.168.50.1 (the MikroTik IP in the Infra network).

This can be confusing when running tcpdump on the server,
because you expect to see the real client but only see the router.

4.2. FastTrack and Layer 7 filters

RouterOS uses FastTrack to accelerate established,related traffic.
If the DoH/DoT blocking rules are after FastTrack,
packets never get evaluated with tls-host, and DoH passes freely.

That’s why it is critical to:

  • Place DoH/DoT blocking rules before the FastTrack rule,
  • and, if more complex inspection is needed, disable FastTrack on those flows.

4.3. The “lying DNS” in tools like dig

When redirect (dst-nat) is used for DNS, tools like dig show:

SERVER: 8.8.8.8#53(8.8.8.8)

even though the packet never left to the Internet.

This is because:

  • the client builds the packet to 8.8.8.8,
  • MikroTik redirects it internally to 192.168.50.2,
  • but the response comes back with the original IP preserved from the client’s perspective.

It is not a bug, it is the expected behavior of NAT.

5. Solution design: redirect + selective blocking

The architecture that actually works, and that we have tested in detail, is based on three pillars:

  1. Force all traditional DNS to the internal resolver (DNS redirect on port 53),
  2. Block DoT (TCP 853),
  3. Block DoH (TCP 443) to public providers using TLS SNI (tls-host).

5.1. Traditional DNS redirection

Example for Home LAN 192.168.88.0/24 and NUC 192.168.50.2:

/ip firewall nat add chain=dstnat src-address=192.168.88.0/24 dst-port=53 protocol=udp action=dst-nat to-addresses=192.168.50.2 comment="DNS Redirect UDP -> NUC" add chain=dstnat src-address=192.168.88.0/24 dst-port=53 protocol=tcp action=dst-nat to-addresses=192.168.50.2 comment="DNS Redirect TCP -> NUC"

Additionally:

/ip dns set servers=192.168.50.2 allow-remote-requests=yes

so that the MikroTik itself uses the internal DNS as a resolver.

5.2. Hairpin NAT between LAN and Infra

To allow Home clients to access the NUC in Infra without routing issues:

/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.50.2 action=masquerade comment="Hairpin NAT for DNS redirect"

In many scenarios a broader variant is used:

/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.50.0/24 action=masquerade comment="LAN->Infra NAT bugfix"

5.3. Blocking DoT (DNS over TLS, 853/TCP)

Directly block port 853:

/ip firewall filter add chain=forward protocol=tcp dst-port=853 action=drop comment="Block DoT (DNS over TLS)"

With this, any attempt to use DNS-over-TLS to the Internet will fail.

5.4. Blocking DoH using SNI (TLS Host)

RouterOS v7 allows you to filter by the SNI (Server Name Indication) field of the TLS ClientHello using tls-host.

Recommended list of common DoH providers:

  • dns.google
  • cloudflare-dns.com
  • mozilla.cloudflare-dns.com
  • dns.adguard.com
  • dns.quad9.net
  • dns.nextdns.io
  • doh.opendns.com
  • cleanbrowsing.org

Example rules:

/ip firewall filter add chain=forward protocol=tcp dst-port=443 tls-host="*dns.google" action=drop comment="Block DoH Google" add chain=forward protocol=tcp dst-port=443 tls-host="*cloudflare-dns.com" action=drop comment="Block DoH Cloudflare" add chain=forward protocol=tcp dst-port=443 tls-host="*mozilla.cloudflare-dns.com" action=drop comment="Block DoH Firefox" add chain=forward protocol=tcp dst-port=443 tls-host="*dns.adguard.com" action=drop comment="Block DoH AdGuard" add chain=forward protocol=tcp dst-port=443 tls-host="*dns.quad9.net" action=drop comment="Block DoH Quad9" add chain=forward protocol=tcp dst-port=443 tls-host="*dns.nextdns.io" action=drop comment="Block DoH NextDNS" add chain=forward protocol=tcp dst-port=443 tls-host="*doh.opendns.com" action=drop comment="Block DoH OpenDNS" add chain=forward protocol=tcp dst-port=443 tls-host="*cleanbrowsing.org" action=drop comment="Block DoH CleanBrowsing"

Order of the rules

These rules must go before FastTrack, for example:

... 11 defconf: accept in ipsec policy 12 defconf: accept out ipsec policy 13 Block DoT (DNS over TLS) 14 Block DoH Google 15 Block DoH Cloudflare 16 Block DoH Firefox 17 Block DoH AdGuard 18 Block DoH Quad9 19 Block DoH NextDNS 20 Block DoH OpenDNS 21 Block DoH CleanBrowsing 22 defconf: fasttrack 23 defconf: accept established,related,untracked 24 defconf: drop invalid 25 defconf: drop all from WAN not DSTNATed

6. Final result of the architecture

With this design:

  1. All classic DNS (53) from the Home LAN is redirected to the internal server.
  2. There is no escape to external traditional DNS, even if clients configure 8.8.8.8, 1.1.1.1 or any other.
  3. Every attempt to use DoT (853) to the Internet is blocked.
  4. Every attempt to use DoH to public providers is blocked using SNI.
  5. If desired, you can run an internal DoH/DoT server (for example Technitium DNS) and allow only that one, blocking the rest.

The practical effect is:

  • The entire network is forced to use the internal DNS.
  • There are no leaks to external servers, neither in plain text nor encrypted.
  • The administrator has full control over:
    • logging,
    • filtering,
    • blocklists,
    • and privacy.

7. What if I want to offer internal DoH/DoT?

If you want clients to use encrypted DNS, but without losing control:

  1. You can install Technitium DNS Server or an equivalent solution on the NUC.
  2. Technitium offers:
    • Classic DNS (53),
    • DoT (853),
    • DoH (HTTPS),
    • DoQ.
  3. On MikroTik you block all DoH/DoT to the Internet, but:
    • you allow DoH/DoT only to the NUC.

In this way:

  • Clients can configure DoH/DoT pointing to the local server.
  • All encrypted DNS traffic remains internal and under control.
  • No DNS query leaks to third parties.

Conclusion

MikroTik cannot:

  • intercept,
  • decrypt,
  • or “convert” DoH/DoT traffic into traditional DNS queries.

This is not a specific limitation of MikroTik, but a consequence of the design of TLS and the DoH/DoT protocols.

What it can do, and does very well, is:

  1. Redirect all traditional DNS (UDP/TCP 53) to an internal resolver.
  2. Block DoT (TCP 853) by port.
  3. Block DoH (TCP 443) by SNI (tls-host).
  4. Combined with a modern internal DNS server (Unbound, Technitium, etc.), provide a solid architecture with no leaks and centralized filtering policies.

The result is an environment that is:

  • predictable,
  • secure,
  • audited,
  • and aligned with professional networking practices.

Comments, questions, or improvements?
You can leave your input in the blog comments or get in touch directly to continue exploring secure network design with MikroTik and advanced DNS.

Leave a Reply