El DNS multicast ( mDNS ) es un protocolo de red informática que resuelve nombres de host a 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) unicast. Fue diseñado para funcionar como un protocolo independiente o compatible con servidores DNS estándar. [ 1 ]
mDNS utiliza multidifusión IP y paquetes del Protocolo de Datagramas de Usuario (UDP), y está implementado por Apple, Microsoft y la mayoría de las distribuciones de Linux .
mDNS puede funcionar junto con DNS Service Discovery (DNS-SD), una técnica de red complementaria de configuración cero especificada por separado en RFC 6763. [ 2 ]
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 , un estándar, por Stuart Cheshire y Marc Krochmal trece años después. [ 1 ] [ 3 ]
Implementaciones
mDNS es implementado por Apple Bonjour , Microsoft desde Windows 10 y por los paquetes de software de código abierto Avahi incluidos en la mayoría de las distribuciones de Linux . Aunque la implementación de Windows 10 en versiones anteriores (versión 1703) [ 4 ] se limitaba a descubrir impresoras en red, dispositivos de duplicación de pantalla, altavoces inalámbricos, etc., las versiones posteriores (Windows 10 versión 1903 y posteriores) también resolvieron nombres de host. [ 5 ]
Descripción general del protocolo
Cuando un cliente mDNS necesita resolver un nombre de host, envía un mensaje de consulta multicast IP que solicita al host con ese nombre que se identifique. El equipo de destino envía entonces un mensaje multicast que incluye su dirección IP. Todos los equipos de esa subred pueden usar esa información para actualizar sus cachés mDNS . Cualquier host puede renunciar a su derecho sobre un nombre enviando un paquete de respuesta con un tiempo de vida (TTL) igual a cero.
Por defecto, 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 pueden encontrarse mediante un servidor DNS unicast convencional. Resolver estos conflictos requiere cambios en la configuración de red, algo que mDNS se diseñó para evitar.
Estructura del paquete
Un mensaje mDNS es un paquete UDP de multidifusión enviado utilizando el siguiente direccionamiento:
- Dirección IPv4 224.0.0.251 o dirección IPv6 ff02::fb
- Puerto UDP 5353
- Cuando se utilizan 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: la cabecera y los datos. [ 6 ]
El encabezado es idéntico al que se encuentra en DNS unicast, al igual que las subsecciones en la parte de datos: consultas, respuestas, servidores de nombres autoritativos y registros adicionales. El número de registros en cada subsección coincide con el valor del campo *COUNT correspondiente en el encabezado.
Consultas
El formato de transmisión para los registros en la sección de consulta se modifica ligeramente con respecto al de DNS unicast, añadiendo 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 llamados etiquetas . Cada etiqueta representa una de las subcadenas separadas por puntos en un nombre de dominio completo (FQDN). La lista finaliza con un byte nulo que representa la raíz del DNS, o con un byte con los dos bits de orden superior activados (valor 192) para indicar un puntero indirecto a otra ubicación en el mensaje. Esto se conoce como compresión de nombres en la RFC 6762.
El campo UNICAST-RESPONSE se utiliza para minimizar las transmisiones innecesarias en la red: si el bit está activado, los respondedores DEBEN enviar una respuesta unicast 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 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 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 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 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 (en particular, los registros TXT).
Véase también
Referencias
- 1 2 3 DNS multicast . Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6762 . RFC 6762 .
- ↑ Descubrimiento de servicios DNS . IETF . doi : 10.17487/RFC6763 . RFC 6763 .
- ↑ Manning, Bill; Woodcock, Bill (agosto de 2000), "Servicio de nombres de dominio multidifusión" , IETF Datatracker , IETF
- ↑ mDNS en la empresa
- ↑ mDNS y DNS-SD se abren paso lentamente en Windows 10 , blog de Ctrl, 21 de octubre de 2015 , consultado el 30 de agosto de 2017.
- ↑ 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 multicast : sitio web informativo mantenido por el diseñador de mDNS, Stuart Cheshire.
- LLMNR, DNS multicast y nombres en su LAN
- Sistema de nombres de dominio
- protocolos de la capa de aplicación