El DNS de multidifusión ( mDNS ) es un protocolo de red informática que resuelve nombres de host en direcciones IP dentro de redes pequeñas que no incluyen un servidor de nombres local . Es un servicio de configuración cero , 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 un protocolo independiente o 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 de código abierto Bonjour de Apple y Avahi , 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 nombres de host. [2] El mDNS puede funcionar junto con el Descubrimiento de servicios DNS (DNS-SD), una técnica de red complementaria de configuración cero especificada por separado en RFC 6763. [3]
Historia
El DNS multicast fue propuesto por primera vez por Bill Woodcock y Bill Manning en el IETF en 2000, y finalmente fue publicado como RFC 6762 de vía estándar por Stuart Cheshire y Marc Krochmal trece años después. [1] [4]
Descripción general del protocolo
Cuando un cliente mDNS necesita resolver un nombre de host, envía un mensaje de consulta de multidifusión IP que solicita al host que tiene ese nombre que se identifique. Luego, esa máquina de destino envía un mensaje de multidifusión que incluye su dirección IP. Todas las máquinas de 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 manera predeterminada, mDNS resuelve exclusivamente nombres de host que terminan con 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 unicast convencional. Resolver tales conflictos requiere cambios en la configuración de red que mDNS fue diseñado para evitar.
Estructura del paquete
Un mensaje mDNS es un paquete UDP de multidifusión enviado utilizando la siguiente dirección:
- Dirección IPv4 224.0.0.251 o dirección IPv6 ff02::fb
- Puerto UDP 5353
- Al utilizar tramas Ethernet , la dirección MAC de multidifusión IP estándar es 01:00:5E:00:00:FB (para IPv4 ) o 33:33:00:00:00:FB (para IPv6 ).
La estructura de la carga útil se basa en el formato de paquete DNS unicast , que consta de dos partes: el encabezado y los datos. [5]
El encabezado es idéntico al que se encuentra en el DNS unicast, al igual que las subsecciones en la parte de datos: consultas, respuestas, servidores de nombres autorizados y registros adicionales. La cantidad de registros en cada subsección coincide con el valor del campo *COUNT correspondiente en el encabezado.
Consultas
El formato de cable para los registros en la sección de consulta se modifica ligeramente con respecto al del DNS unicast, y se agrega el campo UNICAST-RESPONSE de un solo bit. [1]
Al igual que en el DNS unicast, el campo QNAME consta de una serie de subcampos de longitud/valor denominados etiquetas . Cada etiqueta representa una de las subcadenas separadas por puntos de 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 establecidos (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 las transmisiones innecesarias en la red: si el bit está configurado, los respondedores DEBERÍAN enviar una respuesta de unidifusión dirigida directamente al nodo que realiza la consulta en lugar de transmitir la respuesta a toda la red.
El campo QCLASS es idéntico al que se encuentra en el DNS unicast.
Registros de recursos
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 unicast:
El bit CACHE-FLUSH se utiliza para indicar a los nodos vecinos que el registro debe sobrescribir, en lugar de agregarse, a cualquier entrada en caché existente para este RRNAME y RRTYPE.
Los formatos de los campos RDATA son los mismos que los que se encuentran en DNS unicast. 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 (especialmente los registros TXT).
Véase también
- Bonjour, proxy del sueño
- Resolución de nombres de multidifusión de enlace local (LLMNR)
- Conmutador de servicio de nombres (NSS)
Referencias
- ^ abc DNS de multidifusión. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6762 . RFC 6762.
- ^ mDNS y DNS-SD se están incorporando lentamente a Windows 10, blog de Ctrl, 21 de octubre de 2015 , consultado el 30 de agosto de 2017
- ^ Descubrimiento de servicios DNS. IETF . doi : 10.17487/RFC6763 . RFC 6763.
- ^ Manning, Bill; Woodcock, Bill (agosto de 2000), "Servicio de nombres de dominio de multidifusión", Ietf Datatracker , IETF
- ^ P. Mockapetris (noviembre de 1987). NOMBRES DE DOMINIO - IMPLEMENTACIÓN Y ESPECIFICACIÓN. Grupo de trabajo de redes, IETF . doi : 10.17487/RFC1035 . RFC 1035..
Enlaces externos
- DNS multidifusión: sitio de información mantenido por el diseñador de mDNS, Stuart Cheshire
- LLMNR, DNS multicast y nombres en su LAN