Servidor DNS MikroTik: caché y filtrado para ISP y empresas

En una red de ISP o empresa, el DNS es de esas piezas invisibles hasta que falla: cuando el resolver externo se pone lento en hora peak, cada carga de página arrastra cientos de milisegundos de resolución antes de siquiera abrir la conexión TCP, y el NOC empieza a recibir tickets de «internet lento» que en realidad son consultas DNS colgadas. Un DNS MikroTik bien montado resuelve buena parte de eso: RouterOS trae un resolver con caché incorporado que responde localmente las consultas repetidas, reduce la dependencia de resolvers de terceros y, bien configurado, te da un punto de control para filtrar dominios y encriptar el tráfico DNS de tu red.

En esta guía vemos cómo funciona el caché DNS de RouterOS, cómo configurarlo sin dejar un resolver abierto a internet, y qué puedes hacer con entradas estáticas, listas de bloqueo y DNS sobre HTTPS. Todo con comandos reales de RouterOS v7, pensado para responsables de TI y operadores que ya administran routers MikroTik en producción.

Configurar el servidor DNS MikroTik como caché local

Cada router MikroTik con RouterOS incluye un resolver DNS. Por defecto lo usa el propio router para sus consultas (actualizaciones, NTP, fetch, DoH), pero puedes convertirlo en el servidor DNS de toda tu red LAN. La idea es simple: en lugar de que cada equipo consulte directamente a un resolver público, todos apuntan al router, y este mantiene una caché de las respuestas.

Las ventajas para una red en producción son concretas:

• Latencia de resolución baja y estable: las consultas repetidas (los dominios que tu red visita todo el día) se responden desde la caché en el router, sin salir a internet.
• Menos carga sobre el enlace WAN: en hora peak, un caché que sirve el 60-80% de las consultas localmente descongestiona el uplink y el resolver upstream.
• Un punto único de control: defines qué servidores upstream se usan, qué dominios se bloquean y qué se resuelve de forma estática, todo en un solo lugar.
• Resiliencia: ante un cambio de proveedor de tránsito o un resolver upstream caído, cambias la configuración en un punto y no en cientos de clientes.

El menú central es /ip/dns. La configuración mínima de un DNS MikroTik que sirva a la red tiene dos partes: definir los resolvers upstream y habilitar allow-remote-requests para que el router acepte consultas de sus clientes.

/ip/dns
set servers=1.1.1.1,8.8.8.8 allow-remote-requests=yes

# Ver el estado y el uso del cache
/ip/dns/print

# Inspeccionar y vaciar el cache cuando haga falta
/ip/dns/cache/print
/ip/dns/cache/flush

Con allow-remote-requests=yes, el router escucha en el puerto 53 y responde a los equipos que lo tengan configurado como DNS. Ese valor lo entregas por DHCP apuntando el dns-server del pool a la IP del router, para que los clientes lo tomen automáticamente.

El caché tiene parámetros que conviene dimensionar según el tamaño de la red. Estas son las propiedades clave del menú /ip/dns:

Propiedad	Qué controla	Nota operativa
servers	Resolvers upstream a los que consulta el router	Lista ordenada; usa dos o más para redundancia
allow-remote-requests	Habilita al router como servidor DNS de la LAN	Sin esto, el caché solo sirve al propio router
cache-size	Tamaño del caché en KiB (por defecto 2048)	Súbelo en redes grandes con muchos dominios distintos
cache-max-ttl	TTL máximo que una entrada permanece en caché	Por defecto 1 semana; acótalo si necesitas propagación rápida
max-concurrent-queries	Consultas simultáneas que atiende el resolver	Relevante en redes con muchos clientes concurrentes

Un detalle importante: el caché respeta el TTL que entrega cada dominio, pero cache-max-ttl le pone un techo. Si necesitas que un cambio de registro se propague rápido en tu red, baja ese valor o vacía el caché con /ip/dns/cache/flush tras el cambio.

Seguridad: no dejes tu resolver DNS abierto a internet

Esta es la parte que más se descuida. Al activar allow-remote-requests=yes, si el router tiene una IP pública y no filtras el puerto 53, acabas de publicar un resolver DNS abierto hacia toda internet. La propia documentación de MikroTik lo advierte de forma explícita: un resolver expuesto puede ser abusado para amplificar ataques DDoS por reflexión, usando tu router como amplificador contra terceros.

La regla es clara: el DNS solo debe responder a tu red interna. Eso se resuelve en el firewall, permitiendo el puerto 53 (UDP y TCP) desde la LAN y bloqueándolo desde la WAN:

/ip/firewall/filter
add chain=input in-interface-list=WAN protocol=udp dst-port=53 action=drop \
  comment="Bloquear DNS desde WAN"
add chain=input in-interface-list=WAN protocol=tcp dst-port=53 action=drop \
  comment="Bloquear DNS-over-TCP desde WAN"

Estas reglas asumen que tienes una interface-list llamada WAN agrupando tus interfaces de salida, que es la práctica recomendada en RouterOS. Si tu diseño de firewall aún no distingue bien input de forward ni agrupa interfaces por listas, vale la pena revisarlo: el resolver DNS es solo uno de varios servicios (Winbox, API, SSH) que nunca deberían quedar expuestos. Si quieres endurecer la capa de borde completa, revisa nuestros servicios de firewall RouterOS.

Entradas estáticas y regexp: DNS a medida

El menú /ip/dns/static te permite definir respuestas propias, sin depender del upstream. Los casos de uso típicos en una red empresarial o de ISP:

• Resolver nombres internos: mapear nas.empresa.cl o el hostname de un servidor a su IP privada, sin montar un DNS separado.
• Split-DNS: que un dominio público resuelva a una IP interna cuando la consulta viene de la LAN.
• Reenvío condicional (type FWD): mandar todas las consultas de un dominio específico a otro resolver, útil para dominios corporativos servidos por un AD o un DNS interno.
• Bloqueo puntual: apuntar un dominio no deseado a una IP nula o de portal.

Las entradas estáticas soportan coincidencia por expresiones regulares (regexp) y la opción match-subdomain, lo que permite capturar un dominio y todos sus subdominios con una sola regla. Un ejemplo de reenvío condicional y una entrada interna:

/ip/dns/static
# Nombre interno -> IP privada
add name=nas.empresa.cl address=192.168.10.20 type=A

# Reenviar un dominio corporativo a un resolver interno
add name=corp.empresa.cl type=FWD forward-to=192.168.10.5 match-subdomain=yes

Ojo con el orden y la especificidad: cuando usas regexp y match-subdomain, una regla demasiado amplia puede capturar más consultas de las que esperas. Prueba siempre contra el caché real (/ip/dns/cache/print) antes de dar por cerrada la configuración.

Filtrado de dominios con Adlist

Desde RouterOS 7.15, el servidor DNS de MikroTik incorpora Adlist: listas de bloqueo de dominios que el router descarga y aplica automáticamente. En vez de mantener a mano cientos de entradas estáticas, cargas una URL con una lista de dominios (formato hosts o dominios en texto plano) y RouterOS bloquea todas las resoluciones que coincidan.

/ip/dns/adlist
add url="https://example.com/lista-bloqueo.txt" ssl-verify=yes

# Ver el estado de las listas cargadas
/ip/dns/adlist/print

Para un ISP esto habilita un servicio de filtrado a nivel de red (bloqueo de dominios de malware, C2, phishing) sin appliances externos; para una empresa, una capa básica de higiene de navegación centralizada en el router. Es filtrado por dominio, no un reemplazo de un firewall de aplicación, pero resuelve el 80% de los casos con configuración mínima. Ten presente que las listas grandes consumen memoria y CPU en el momento de la carga, así que dimensiona el equipo según el volumen de dominios que vayas a bloquear.

DNS encriptado: DoH sobre el caché

Por defecto, las consultas del router hacia sus resolvers upstream viajan en texto plano por el puerto 53, expuestas a inspección y manipulación en el camino. RouterOS soporta DNS over HTTPS (DoH), que encapsula esas consultas dentro de una conexión HTTPS hacia un resolver compatible. Combinado con el caché local, obtienes lo mejor de ambos mundos: privacidad en el tramo router-upstream y velocidad en el tramo router-LAN.

Un punto que MikroTik destaca: con DoH puedes usar la validación de certificado del trust store integrado, sin tener que importar manualmente la CA raíz del resolver. Eso simplifica el despliegue y evita el error común de habilitar DoH sin verificar el certificado, que dejaría la conexión vulnerable a interceptación. Si vas a habilitar DoH en producción, verifica que el use-doh-server apunte a un resolver confiable y que la validación de certificado esté activa.

Configurar bien el caché, el filtrado y DoH sin romper la resolución de la red en producción tiene matices —orden de reglas, dimensionamiento del equipo, interacción con DHCP y con el firewall— que conviene resolver con criterio de ingeniería. Si necesitas una mano puntual con una configuración que se está comportando raro, revisa nuestro soporte técnico MikroTik.

Conversemos sobre tu diseño de DNS

Un servidor DNS bien montado en MikroTik es de esas mejoras de bajo costo y alto impacto: baja la latencia percibida, descongestiona el enlace en hora peak y te da un punto de control para seguridad y filtrado. Pero en una red de misión crítica el DNS no vive solo: se cruza con tu diseño de firewall, tu esquema de VLANs, tu política de DHCP y, si eres ISP, con cómo entregas el servicio a tus abonados.

En MikroTik Chile diseñamos, implementamos y operamos esa capa completa para ISPs y empresas con infraestructura crítica. Si estás evaluando centralizar el DNS de tu red, montar filtrado a nivel de operador o simplemente quieres una segunda opinión de ingeniería sobre tu configuración actual, conversemos sobre tu caso en consultoría.