Qué es mDNS, cómo funciona y por qué es tan importante en tu red

Inicio » Internet » Qué es mDNS, cómo funciona y por qué es tan importante en tu red

En las redes actuales estamos rodeados de dispositivos que quieren hablar entre ellos sin que tengamos que tocar casi nada: impresoras en red, televisores, altavoces, Chromecast, móviles, asistentes de voz… Todos ellos se apoyan en mecanismos de descubrimiento automático como mDNS para encontrarse dentro de la red local sin que el usuario tenga que configurar un servidor DNS ni conocer direcciones IP.

Si alguna vez has visto instrucciones del tipo “abre el navegador y escribe impresora.local o raspberrypi.local” estabas usando, sin saberlo, el protocolo multicast DNS, más conocido como mDNS. Este estándar forma parte del ecosistema Zeroconf y es la base de tecnologías tan populares como Bonjour de Apple, Avahi en Linux o muchas funciones de descubrimiento en red local, routers, AP y equipos de IoT.

Qué es mDNS y para qué sirve

El protocolo mDNS (multicast DNS) es un sistema de resolución de nombres pensado para redes locales pequeñas sin servidor DNS dedicado. Su objetivo es convertir nombres de host (por ejemplo, impresora.local) en direcciones IP de forma automática, sin necesidad de configurar un servidor de nombres tradicional.

A diferencia del DNS clásico, donde un cliente envía una petición unicast a un servidor concreto, en mDNS las consultas se lanzan por multicast a toda la red local. Todos los equipos del segmento reciben la solicitud, y solo el dispositivo cuyo nombre coincide responde anunciando su dirección IP al resto.

Este comportamiento hace que mDNS encaje como anillo al dedo en entornos domésticos, oficinas pequeñas y redes donde se quiere descubrir dispositivos como impresoras, escáneres, teléfonos IP, Apple TV o Chromecast sin montar infraestructura adicional. Es especialmente útil en redes con pocos equipos, donde instalar y mantener un servidor DNS sería un sobreesfuerzo injustificado.

En este contexto, mDNS actúa como una especie de “DNS local automático”: los dispositivos se anuncian y resuelven nombres entre sí usando el dominio especial .local, reservado para este propósito y no válido para resolver sitios web de Internet (como .com o .es).

Origen de mDNS y relación con Zeroconf

El nacimiento de mDNS está ligado al concepto de Zero Configuration Networking (Zeroconf), un conjunto de tecnologías que persiguen que los dispositivos de una red local se configuren y descubran solos, sin intervención manual ni servidores centralizados. Apple fue uno de los grandes impulsores de esta filosofía a principios de los años 2000.

Dentro de ese esfuerzo, Apple desarrolló Bonjour, una tecnología de descubrimiento de servicios basada en mDNS que permite a Macs, impresoras, Apple TV y otros dispositivos identificarse y publicar servicios automáticamente. Bonjour se apoya en mDNS para la resolución de nombres .local y en DNS-SD (DNS Service Discovery, RFC 6763) para anunciar servicios como impresión, AirPlay o compartición de archivos.

El protocolo mDNS quedó documentado y estandarizado en el RFC 6762 de la IETF, lo que facilitó su adopción progresiva en el resto de sistemas operativos. Linux lo usa principalmente a través de Avahi y otras implementaciones libres (configurar una red local en Linux), y Microsoft lo incorporó en Windows 10 como alternativa interoperable a su tecnología anterior LLMNR.

Fabricantes como Google también lo han adoptado: por ejemplo, Chromecast utiliza mDNS para anunciarse y ser descubierto por móviles y navegadores en la misma red, haciendo que la configuración sea casi automática para el usuario.

De NetBIOS y LLMNR a mDNS en Windows

En entornos Windows, la historia de la resolución de nombres en redes pequeñas ha pasado por varias etapas. Durante años, los equipos en grupos de trabajo se identificaban mediante NetBIOS Name Service, un sistema anterior incluso a la adopción generalizada de TCP/IP en Windows.

Este mecanismo se basaba en mensajes broadcast para anunciar y resolver nombres, lo que generaba bastante tráfico en red, sobre todo en segmentos con muchos equipos. Aun así, NetBIOS se mantuvo disponible en versiones como Windows XP por motivos de compatibilidad con entornos antiguos.

A partir de Windows Vista, Microsoft introdujo LLMNR (Link-Local Multicast Name Resolution) como evolución de NetBIOS, sustituyendo el broadcast por multicast para reducir el impacto en la red. Sin embargo, al ser un protocolo propio de Microsoft, su interoperabilidad con sistemas Unix, macOS o dispositivos de otros fabricantes era bastante limitada.

Con la llegada de Windows 10, Microsoft dio un paso más y empezó a apostar claramente por mDNS como solución de descubrimiento más compatible y estándar. Gracias a esto, equipos Windows pueden integrarse mejor con dispositivos Bonjour, Avahi y otros elementos típicos de entornos mixtos donde conviven sistemas *nix, routers inteligentes e IoT.

Cómo funciona mDNS a nivel técnico

El funcionamiento interno de mDNS se basa en el uso de multicast IP y el protocolo UDP. Cuando un dispositivo quiere resolver un nombre del tipo host.local, envía una consulta a una dirección multicast reservada para este fin:

• IPv4: dirección multicast 224.0.0.251, puerto UDP 5353.
• IPv6: dirección multicast ff02::fb, puerto UDP 5353.

Todos los equipos del segmento de red que estén escuchando en esa dirección de multicast reciben la consulta. El dispositivo cuyo nombre coincide con el que se consulta (host.local) responde también mediante un paquete multicast a la misma dirección, indicando su dirección IP.

De esta forma, no solo obtiene la respuesta el equipo que hizo la consulta: todos los dispositivos que están escuchando pueden actualizar su caché mDNS con la asociación entre ese nombre y la IP anunciada. Mientras la información no caduque, no será necesario repetir la consulta para ese nombre de host.

Este enfoque reduce considerablemente las peticiones repetidas, pero aun así mDNS puede generar bastante tráfico en redes con muchos dispositivos. Por eso, el protocolo introduce mecanismos de ahorro de recursos: por ejemplo, el propio cliente que hace la consulta puede enviar la respuesta que crea correcta según su caché actual, y el dispositivo “dueño” del nombre solo intervendrá si la información es incorrecta o está a punto de caducar.

Hay un detalle crucial: mDNS se limita prácticamente a nombres de host bajo el TLD .local. Los dominios públicos como .com, .es o similares no se resuelven con este sistema, por lo que no sirve para navegar por Internet, solo para identificar máquinas y servicios dentro de una red local.

Relación de mDNS con Zeroconf y direcciones enlace-local

Para que mDNS tenga sentido, suele convivir con otras piezas de la familia Zeroconf, especialmente con los mecanismos de autoconfiguración de direcciones IP de enlace local. En muchas redes pequeñas, los equipos están configurados para usar DHCP, pero si no encuentran servidor, activan un modo de autoasignación.

En IPv4 esto se traduce en el uso del rango conocido como APIPA, 169.254.0.0/16, definido como direcciones de enlace local. Cuando no hay DHCP, cada máquina se asigna una IP aleatoria dentro de ese rango y comprueba que no esté duplicada. Con IPv6 se utiliza el rango de enlace local fe80::/10 (o variantes muy próximas).

En este tipo de escenarios, los dispositivos podrían “verse” en la misma red, pero no sabrían quién es quién. Por eso entra en juego mDNS: permite que cada equipo publique su nombre y lo asocie a la IP que se ha autoconfigurado, de forma que el usuario pueda acceder con un nombre amigable tipo router.local o impresora.local.

Un ejemplo clásico: en su día, muchos routers domésticos SpeedTouch se podían administrar simplemente abriendo el navegador y escribiendo speedtouch.local, incluso cuando el PC tenía una dirección 169.254.x.x por no haber conseguido configuración por DHCP. El descubrimiento del router se apoyaba, precisamente, en mecanismos de Zeroconf y mDNS.

En el mundo de la virtualización y soluciones hiperconvergentes también es común ver este tipo de funciones. Plataformas como Nutanix, por ejemplo, pueden aprovechar Bonjour o servicios similares para facilitar el descubrimiento de nodos y paneles de gestión en instalaciones iniciales.

Descubrimiento de servicios: Bonjour, Avahi y DNS-SD

mDNS no solo resuelve nombres de host, también actúa como base para el descubrimiento de servicios en la red local. Aquí entra en juego DNS Service Discovery (DNS-SD, RFC 6763), que utiliza nombres de dominio con un formato especial para identificar servicios concretos.

Un servicio típico se identifica con un patrón del tipo _<service-type>._<transport-protocol>.local. Algunos ejemplos serían:

• _http._tcp.local para servicios web locales.
• _printer._tcp.local o _ipp._tcp.local para impresión en red (IPP).
• _airplay._tcp.local para dispositivos compatibles con AirPlay.
• Otros tipos específicos definidos por fabricantes o estándares.

Cuando un dispositivo ofrece un servicio (por ejemplo, una impresora IPP), lo anuncia a través de mDNS usando el nombre de servicio correspondiente. Los clientes que buscan ese servicio envían consultas mDNS con ese identificador y reciben información como la IP, el puerto y datos adicionales necesarios para conectarse.

Apple Bonjour es una de las implementaciones más conocidas de este mecanismo, pero no la única. En Linux, Avahi es la pieza más común para gestionar mDNS y DNS-SD, y en Windows, muchas aplicaciones y dispositivos se comunican con ese ecosistema gracias a la compatibilidad añadida en versiones recientes.

La IANA mantiene un registro oficial de nombres de servicio y puertos donde se listan los tipos estándar utilizados por Bonjour y otros sistemas. Además de los RFC, fabricantes y proyectos de código abierto documentan los identificadores que emplean para que desarrolladores y administradores puedan integrarlos correctamente.

mDNS en redes segmentadas: repetidores y gateways

Por diseño, el tráfico multicast como el de mDNS no suele atravesar routers entre VLANs o subredes. Esto es bueno para contener el ruido en redes grandes, pero es un problema cuando queremos que un móvil en una VLAN de usuarios detecte, por ejemplo, un Apple TV o un Chromecast alojado en una VLAN de IoT.

Para resolverlo, muchos fabricantes de equipos de red han introducido funciones específicas de repetidor o proxy mDNS que reenvían selectivamente solicitudes y respuestas entre interfaces o VLANs concretas. Es el caso, por ejemplo, de Mikrotik RouterOS y del ecosistema TP-Link Omada.

mDNS Repeater en Mikrotik RouterOS

En Mikrotik, la función mDNS Repeater permite propagar tráfico UDP 5353 entre varias interfaces (Ethernet, VLAN, bridges), superando el límite natural del multicast que se queda en un solo segmento de red.

La configuración se basa en indicar en qué interfaces se debe repetir el tráfico mDNS, algo típico en entornos con VLAN separadas para usuarios y dispositivos audiovisuales o IoT. Por ejemplo, tener una VLAN para portátiles y otra para Apple TV y Chromecast y aun así permitir que los usuarios descubran los dispositivos de streaming.

Entre los aspectos técnicos más relevantes de esta función destacan:

• Solo se soportan interfaces tipo Ethernet, VLAN o Bridge; no es compatible con túneles como WireGuard, GRE o EoIP.
• Se replica todo el tráfico mDNS (UDP 5353) entre las interfaces seleccionadas, sin filtros por servicio o nombre concreto.
• En redes con muchos dispositivos puede aumentar el volumen de tráfico multicast, por lo que conviene usarlo con cabeza.
• Se pueden complementar con reglas de firewall que limiten o controlen UDP 5353 entre ciertas redes, aunque el propio repetidor no inspecciona el contenido.

Para diagnosticar problemas o comprobar que el descubrimiento funciona entre VLANs, se pueden usar comandos y herramientas como ping <dispositivo>.local, utilidades tipo dns-sd o avahi-browse en los clientes, y sniffers de tráfico en el propio router escuchando en el puerto 5353.

mDNS y Bonjour en TP-Link Omada

En el ecosistema TP-Link Omada (controladores software, hardware o en la nube, junto con sus gateways y puntos de acceso) también existe una función de reenvío mDNS orientada a servicios Bonjour, pensada especialmente para redes con múltiples VLAN.

El controlador permite crear reglas mDNS donde se definen:

• Un nombre de regla y su estado (habilitada o no).
• El tipo de dispositivo al que aplica (AP o gateway).
• El tipo de servicio Bonjour que se quiere reenviar (por ejemplo, AirPlay).
• La red de servicios (VLAN o LAN donde se encuentran los dispositivos que ofrecen el servicio).
• La red de clientes (VLAN o LAN desde la que los usuarios acceden).

De este modo, se puede permitir que dispositivos en una VLAN específica descubran solo ciertos servicios mDNS en otra VLAN, sin abrir todo el multicast entre ellas. El sistema incluso permite definir servicios Bonjour personalizados indicando uno o varios identificadores como _iot-http._tcp.local, siempre respetando el formato estándar de DNS-SD.

Una vez creados los servicios personalizados, se asocian a nuevas reglas mDNS para controlar qué tipo de tráfico de descubrimiento se va a reenviar. Esta granularidad es muy útil cuando se quiere separar redes de invitados, redes corporativas y redes IoT sin perder la comodidad del descubrimiento automático.

La documentación de Omada detalla además cómo consultar registros oficiales de tipos de servicio en sitios como IANA, documentación de Apple, RFCs de la IETF, proyectos de código abierto y guías de proveedores de servicios específicos, para asegurarse de que los identificadores utilizados son correctos.

Riesgos de seguridad: mDNS como vector en ataques DrDoS

Aunque mDNS está diseñado para funcionar dentro de la red local y no exponerse a Internet, en la práctica muchos dispositivos vienen mal configurados o quedan accesibles desde el exterior, lo que abre la puerta a que se utilicen en ataques de denegación de servicio distribuida (DrDoS).

En un escenario de ataque típico, un ciberdelincuente envía consultas mDNS masivas desde el exterior, falsificando (spoofing) la IP de origen para que parezca que las peticiones proceden de la víctima. Los dispositivos mDNS expuestos responden con paquetes mucho más grandes que las consultas, multiplicando el tráfico que acaba llegando a la IP suplantada.

Este tipo de ataque aprovecha el carácter “reflejado y amplificado”: un paquete inicial de unos 46 bytes puede transformarse en respuestas 4 a 10 veces mayores, generando un volumen considerable de datos hacia la víctima, que puede terminar saturando su ancho de banda o sus recursos de procesamiento.

Además de provocar denegaciones de servicio, la exposición indebida de mDNS puede filtrar información sensible sobre la red interna, como nombres de host, tipos de servicios disponibles, direcciones IP internas y otros datos que ayuden a un atacante a planificar ataques más dirigidos.

Para identificar si un servidor o dispositivo está exponiendo un servicio mDNS vulnerable hacia Internet, se pueden usar herramientas como nmap con scripts especializados, por ejemplo:

nmap -Pn -sU -p5353 --script=dns-service-discovery <IP-del-servidor>

La revisión de logs, sistemas de monitorización y consumo de recursos (CPU, RAM, disco) también puede dar pistas de que un equipo está siendo utilizado como parte de un ataque DrDoS basado en mDNS, sobre todo si se observa un flujo anómalo de tráfico UDP hacia o desde el puerto 5353.