En redes de computadoras , el protocolo DNS de multidifusión ( mDNS ) resuelve nombres de host en direcciones IP dentro de redes pequeñas que no incluyen un servidor de nombres local . Es un servicio sin configuración , que utiliza esencialmente las mismas interfaces de programación, formatos de paquetes y semántica operativa que el sistema de nombres de dominio (DNS) de unidifusión. Fue diseñado para funcionar como protocolo independiente o de forma compatible con servidores DNS estándar. [1] Utiliza paquetes de protocolo de datagramas de usuario (UDP) de multidifusión IP y se implementa mediante los paquetes de software Apple Bonjour y Avahi de código abierto , incluidos en la mayoría de las distribuciones de Linux. Aunque la implementación de Windows 10 se limitó a descubrir impresoras en red, las versiones posteriores también resolvieron los nombres de host. [2] mDNS puede funcionar junto con DNS Service Discovery (DNS-SD), una técnica de red complementaria sin configuración especificada por separado en RFC 6763. [3]
El DNS de multidifusión fue propuesto por primera vez por Bill Woodcock y Bill Manning en el IETF en 2000, y finalmente fue publicado como estándar RFC 6762 por Stuart Cheshire y Marc Krochmal trece años después. [1] [4]
Cuando un cliente mDNS necesita resolver un nombre de host, envía un mensaje de consulta de multidifusión de IP que solicita al host que tiene ese nombre que se identifique. Luego, esa máquina de destino multidifunde un mensaje que incluye su dirección IP. Todas las máquinas en esa subred pueden usar esa información para actualizar sus cachés mDNS. Cualquier host puede renunciar a su derecho a un nombre enviando un paquete de respuesta con un tiempo de vida (TTL) igual a cero.
De forma predeterminada, mDNS resuelve exclusivamente los nombres de host que terminan en el .localdominio de nivel superior. Esto puede causar problemas si .localincluye hosts que no implementan mDNS pero que se pueden encontrar a través de un servidor DNS de unidifusión convencional. Resolver tales conflictos requiere cambios en la configuración de la red para los cuales mDNS fue diseñado para evitar.
Un mensaje mDNS es un paquete UDP de multidifusión enviado utilizando el siguiente direccionamiento:
La estructura de carga útil se basa en el formato de paquete DNS de unidifusión y consta de dos partes: el encabezado y los datos. [5]
El encabezado es idéntico al que se encuentra en el DNS de unidifusión, al igual que las subsecciones de la parte de datos: consultas, respuestas, servidores de nombres autorizados y registros adicionales. El número de registros en cada subsección coincide con el valor del campo *COUNT correspondiente en el encabezado.
El formato de conexión para los registros en la sección de consulta se modifica ligeramente con respecto al DNS de unidifusión, agregando el campo UNICAST-RESPONSE de un solo bit. [1]
Como en DNS de unidifusión, el campo QNAME consta de una serie de subcampos de longitud/valor llamados "etiquetas". Cada etiqueta representa una de las subcadenas separadas por puntos en un nombre de dominio completo (FQDN). La lista termina con un único byte nulo que representa la "raíz" del DNS, o con un byte con los dos bits de orden superior configurados (valor 192) para señalar un puntero indirecto a otra ubicación en el mensaje. Esto se conoce como compresión de nombres en RFC 6762.
El campo UNICAST-RESPONSE se utiliza para minimizar transmisiones innecesarias en la red: si el bit está configurado, los respondedores DEBEN enviar una respuesta de unidifusión dirigida directamente al nodo solicitante en lugar de transmitir la respuesta a toda la red.
El campo QCLASS es idéntico al que se encuentra en DNS de unidifusión.
Todos los registros en las secciones de respuestas, servidores de nombres autorizados y registros adicionales tienen el mismo formato y se conocen colectivamente como Registros de recursos (RR).
Los registros de recursos en mDNS también tienen un formato general ligeramente modificado en comparación con el DNS de unidifusión:
El bit CACHE-FLUSH se utiliza para indicar a los nodos vecinos que el registro debe sobrescribir, en lugar de agregarse, cualquier entrada almacenada en caché existente para este RRNAME y RRTYPE.
Los formatos de los campos RDATA son los mismos que los que se encuentran en DNS de unidifusión. Sin embargo, DNS Service Discovery (DNS-SD), el caso de uso más común para mDNS, especifica ligeras modificaciones en algunos de sus formatos (en particular, registros TXT).