Dagorret

Notas

Problemas de Mikrotik con DNS Redirect (DoH/DoT) y cómo solucionarlos correctamente

por · Publicado · Actualizado

Una guía técnica práctica para administradores de red

Introducción

En muchas redes domésticas y profesionales se utiliza MikroTik RouterOS para centralizar el control del tráfico DNS.
El objetivo típico es:

  • Redirigir todas las consultas DNS hacia un resolvedor interno (Unbound, Technitium, AdGuard, etc.)
  • Evitar fugas de DNS hacia servidores externos (Google, Cloudflare, Quad9, etc.)
  • Impedir que dispositivos modernos utilicen DNS cifrado (DoH/DoT) para saltarse las políticas de red
  • Consolidar el filtrado, registro y control de navegación

Sin embargo, RouterOS no puede manejar todo el tráfico DNS de la forma que muchos administradores esperan.
Existe confusión sobre:

  • qué se puede redirigir,
  • qué no,
  • y por qué.

Este artículo explica estas limitaciones, los motivos técnicos de fondo y presenta una solución funcional y robusta basada en:

  • DNS redirect tradicional (puerto 53),
  • bloqueo específico de DoH/DoT,
  • y un resolvedor interno (por ejemplo Unbound o Technitium).

1. Cómo funciona el DNS Redirect en MikroTik

RouterOS puede redirigir solo DNS tradicional, es decir:

  • UDP/53
  • TCP/53

A nivel NAT suele utilizarse algo como:

/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"

En este ejemplo:

  • La LAN Home está en 192.168.88.0/24.
  • La infraestructura (por ejemplo una NUC con Unbound/Technitium) está en 192.168.50.0/24.
  • El servidor DNS interno tiene IP 192.168.50.2.

Con estas reglas:

  • Todo paquete que sale de 192.168.88.0/24 y va al puerto 53 (DNS),
  • sin importar a qué dirección IP de destino apunte (8.8.8.8, 1.1.1.1, DNS del ISP, etc.),
  • será redirigido silenciosamente a 192.168.50.2.

✔ Redirigir puerto 53 funciona muy bien

Desde el punto de vista del cliente:

dig @8.8.8.8 google.com

mostrará algo como:

SERVER: 8.8.8.8#53(8.8.8.8)

Pero en realidad:

  • el paquete nunca llegó a 8.8.8.8,
  • MikroTik lo interceptó (dst-nat) y lo mandó a 192.168.50.2,
  • la respuesta la generó el DNS interno (Unbound/Technitium).

Es decir: el NAT “miente” sobre quién respondió, pero esa es precisamente la idea del redirect.

2. El problema: dispositivos modernos no usan solo DNS 53

El modelo anterior funcionaba perfecto cuando todo era DNS clásico.
Hoy ya no.

Muchos sistemas operativos y navegadores implementan DNS cifrado:

2.1. DoT (DNS over TLS)

  • Puerto: TCP 853
  • Ejemplo: Android (Private DNS), algunos routers, systemd-resolved, etc.
  • El contenido (la consulta DNS) viaja dentro de un túnel TLS.

2.2. DoH (DNS over HTTPS)

  • Puerto: TCP 443 (mismo puerto que HTTPS)
  • Formato: DNS encapsulado en HTTP/2 o HTTP/3 dentro de TLS
  • Usado por:
    • Firefox (DoH por defecto en varios países),
    • Chrome / Edge / Opera (Secure DNS),
    • Windows 10/11 (Encrypted DNS),
    • algunos móviles y apps.

Consecuencia

  • El tráfico DNS ya no es un paquete UDP/TCP 53,
  • está cifrado y oculto dentro de una sesión TLS.

Por eso:

Las reglas de redirect basadas en dst-port=53 no tocan DoH/DoT.
Dicho de otra forma: DoH/DoT “pasan por el costado” de nuestro control DNS clásico.

3. ¿Por qué MikroTik no puede redirigir DoH/DoT a 53?

Es tentador intentar:

/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

y esperar que:

  • RouterOS reciba el flujo TLS,
  • “entienda” el DNS interno,
  • y lo convierta en consultas tradicionales (53) hacia el DNS interno.

❌ Esto es técnicamente imposible en MikroTik (y en casi todos los routers).

3.1. DoT (TCP 853)

  • El payload está completamente cifrado con TLS.
  • MikroTik ve solo:
    • IP origen,
    • IP destino,
    • puerto (853),
    • y que es un flujo TLS.
  • No puede:
    • leer el mensaje DNS,
    • decodificarlo,
    • rearmar una consulta UDP/TCP 53,
    • y luego volver a cifrar.

3.2. DoH (TCP 443)

  • Va encapsulado en HTTPS,
  • cifrado con TLS 1.2/1.3,
  • mezclado con el resto del tráfico web.

Para manipularlo habría que:

  1. Hacer interceptación TLS (Man-in-the-Middle),
  2. Instalar un certificado raíz propio en todos los clientes,
  3. Desencriptar, inspeccionar, modificar y re-encriptar todo el tráfico HTTPS.

MikroTik NO hace TLS intercept ni DPI a ese nivel.

Solo firewalls corporativos muy avanzados (Palo Alto, Fortigate, Sophos, etc.)
pueden realizar algo parecido, y aun así no “convierten” DoH a port 53, simplemente inspeccionan o bloquean.

4. Problemas adicionales en MikroTik al armar DNS redirect

Además de las limitaciones lógicas anteriores, hay varios detalles prácticos que suelen romper el diseño.

4.1. Hairpin NAT y tráfico entre subredes

Si la LAN Home está en 192.168.88.0/24
y el servidor DNS interno está en 192.168.50.2 (otra subred / otro bridge),
es común necesitar reglas tipo:

/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"

También pueden aparecer reglas más generales como:

/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"

Desde el punto de vista del servidor DNS:

  • Nunca ve a 192.168.88.39,
  • ve siempre a 192.168.50.1 (la IP del MikroTik en la red Infra).

Esto puede confundir a la hora de hacer tcpdump en el servidor,
porque uno espera ver el cliente real y solo ve al router.

4.2. FastTrack y filtros de capa 7

RouterOS utiliza FastTrack para acelerar tráfico established,related.
Si las reglas de bloqueo DoH/DoT están después de FastTrack,
los paquetes nunca llegan a evaluarse con tls-host, y DoH pasa libremente.

Por eso es crítico:

  • Colocar las reglas de bloqueo DoH/DoT antes de la regla de fasttrack,
  • y, si hace falta inspección más compleja, deshabilitar fasttrack en esos flujos.

4.3. El “DNS mentiroso” en herramientas como dig

Cuando se usa redirect (dst-nat) para DNS, herramientas como dig muestran:

SERVER: 8.8.8.8#53(8.8.8.8)

aunque el paquete nunca haya salido a Internet.

Esto se debe a que:

  • el cliente arma el paquete hacia 8.8.8.8,
  • MikroTik lo redirige internamente a 192.168.50.2,
  • pero la respuesta vuelve con la IP original preservada desde la perspectiva del cliente.

No es un bug, es el comportamiento esperado de NAT.

5. Diseño de solución: redirección + bloqueo selectivo

La arquitectura que realmente funciona, y que probamos en detalle, se basa en tres pilares:

  1. Forzar todo DNS tradicional hacia el resolutor interno (DNS redirect en port 53),
  2. Bloquear DoT (TCP 853),
  3. Bloquear DoH (TCP 443) hacia proveedores públicos usando TLS SNI (tls-host).

5.1. Redirección de DNS tradicional

Ejemplo para LAN Home 192.168.88.0/24 y 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"

Además:

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

para que el propio MikroTik use el DNS interno como resolver.

5.2. Hairpin NAT entre LAN e Infra

Para permitir que los clientes Home accedan a la NUC en Infra sin problemas de routing:

/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"

En muchos escenarios se utiliza una variante más amplia:

/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. Bloqueo de DoT (DNS over TLS, 853/TCP)

Bloquear directamente el puerto 853:

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

Con esto, cualquier intento de usar DNS-over-TLS hacia Internet fallará.

5.4. Bloqueo de DoH usando SNI (TLS Host)

RouterOS v7 permite filtrar por el campo SNI (Server Name Indication) del TLS ClientHello usando tls-host.

Lista recomendada de proveedores DoH comunes:

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

Reglas de ejemplo:

/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"

Orden de las reglas

Estas reglas deben ir antes de fasttrack, por ejemplo:

...
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. Resultado final de la arquitectura

Con este diseño:

  1. Todo DNS clásico (53) de la LAN Home se redirige al servidor interno.
  2. No hay escapatoria a DNS externos tradicionales, aunque los clientes configuren 8.8.8.8, 1.1.1.1 o cualquier otro.
  3. Todo intento de DoT (853) hacia Internet es bloqueado.
  4. Todo intento de DoH hacia proveedores públicos es bloqueado usando SNI.
  5. Si se desea, se puede levantar un servidor DoH/DoT interno (por ejemplo Technitium DNS) y permitir solo ese, bloqueando el resto.

El efecto práctico es:

  • Toda la red está obligada a usar el DNS interno.
  • No hay fugas hacia servidores externos, ni en texto plano ni cifrado.
  • El administrador tiene control absoluto sobre:
    • registros,
    • filtrado,
    • listas de bloqueo,
    • y privacidad.

7. ¿Y si quiero ofrecer DoH/DoT interno?

Si se desea que los clientes usen DNS cifrado, pero sin perder control:

  1. Se puede instalar Technitium DNS Server o solución equivalente en la NUC.
  2. Technitium ofrece:
    • DNS clásico (53),
    • DoT (853),
    • DoH (HTTPS),
    • DoQ.
  3. En MikroTik se bloquea todo DoH/DoT hacia Internet, pero:
    • se permite DoH/DoT solo hacia la NUC.

De esta forma:

  • Los clientes pueden configurar DoH/DoT apuntando al servidor local.
  • Todo el tráfico DNS cifrado sigue siendo interno y controlado.
  • Ninguna consulta DNS se escapa a terceros.

Conclusión

MikroTik no puede:

  • interceptar,
  • descifrar,
  • ni “convertir” tráfico DoH/DoT en consultas DNS tradicionales.

Esto no es una limitación específica de MikroTik, sino una consecuencia del diseño de TLS y de los protocolos DoH/DoT.

Lo que sí puede hacer, y lo hace muy bien, es:

  1. Redirigir todo DNS tradicional (UDP/TCP 53) hacia un resolvedor interno.
  2. Bloquear DoT (TCP 853) por puerto.
  3. Bloquear DoH (TCP 443) por SNI (tls-host).
  4. Combinado con un servidor DNS interno moderno (Unbound, Technitium, etc.), ofrecer una arquitectura sólida, sin fugas, con políticas de filtrado centralizadas.

El resultado es un entorno:

  • predecible,
  • seguro,
  • auditado,
  • y alineado con prácticas de redes profesionales.

¿Comentarios, dudas o mejoras?
Podés dejar tus aportes en los comentarios del blog o contactar directamente para seguir profundizando en diseño de redes seguras con MikroTik y DNS avanzados.

Discover more from Dagorret

Subscribe to get the latest posts sent to your email.

Etiquetas:

También puede gustarle...

Dejá una respuesta

Discover more from Dagorret

Subscribe now to keep reading and get access to the full archive.

Continue reading