En las redes de computadoras , el protocolo de multidifusión DNS ( mDNS ) resuelve los 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 Servicio 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]
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 IETF RFC 6762 de seguimiento de estándares por Stuart Cheshire y Marc Krochmal trece años después. [2] [1] Utiliza paquetes IP multicast User Datagram Protocol (UDP) y está implementado por Apple Bonjour y los paquetes de software 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 nombres de host. [3] mDNS puede funcionar junto con DNS Service Discovery (DNS-SD), un complementotécnica de red de configuración cero especificada por separado en RFC 6763. [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 le pide al host que tiene ese nombre que se identifique. Luego, esa máquina de destino transmite un mensaje 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 forma predeterminada, mDNS resuelve exclusivamente nombres de host que terminan con el dominio de nivel superior .local . Esto puede causar problemas si .local incluye hosts que no implementan mDNS pero que se pueden encontrar a través de un servidor DNS de unidifusión convencional. La resolución de estos conflictos requiere cambios en la configuración de la red para los que se diseñó mDNS.
Estructura del paquete
Un mensaje mDNS es un paquete UDP de multidifusión que se envía 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 01: 00: 5E: 00: 00: FB (para IPv4 ) o 33: 33: 00: 00: 00: FB (para IPv6 )
La estructura de carga útil se basa en el formato de paquete DNS unidifusión , que 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 en 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.
Consultas
El formato de conexión para los registros en la sección de consulta se modifica ligeramente del del DNS unidifusión, agregando el campo UNICAST-RESPONSE de un solo bit. [1]
Campo | Descripción | Bits de longitud |
---|---|---|
QNAME | Nombre del nodo al que pertenece la consulta | Variable |
CANTIDAD | El tipo de consulta, es decir, el tipo de RR que se debe devolver en las respuestas. | dieciséis |
RESPUESTA UNICAST | Bandera booleana que indica si se desea una respuesta de unidifusión | 1 |
QCLASS | Código de clase, 1 también conocido como "IN" para Internet y redes IP | 15 |
Como en DNS unicast, el campo QNAME consiste en 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 solo byte nulo, que representa la "raíz" del DNS.
El campo UNICAST-RESPONSE se utiliza para minimizar las difusiones innecesarias en la red: si el bit está establecido, los respondedores DEBEN enviar una respuesta de unidifusión dirigida directamente al nodo que realiza la consulta en lugar de difundir la respuesta a toda la red.
El campo QCLASS es idéntico al que se encuentra en DNS unidifusión.
Registros de recursos
Todos los registros de 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 unidifusión:
Campo | Descripción | Bits de longitud |
---|---|---|
RRNAME | Nombre del nodo al que pertenece el registro | Variable |
RRTYPE | El tipo de registro de recursos | dieciséis |
CACHÉ-FLUSH | Indicador booleano que indica si se deben purgar los registros en caché obsoletos | 1 |
RRCLASS | Código de clase, 1 también conocido como "IN" para Internet y redes IP | 15 |
TTL | Intervalo de tiempo (en segundos) que el RR debe almacenarse en caché | 32 |
RDLENGTH | Número entero que representa la longitud (en octetos) del campo RDATA | dieciséis |
RDATA | Datos de recursos; la estructura interna varía según RRTYPE | Variable |
El bit CACHE-FLUSH se usa 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 se encuentran en el DNS unidifusión. Sin embargo, DNS Service Discovery (DNS-SD), el caso de uso más común de mDNS, especifica ligeras modificaciones en algunos de sus formatos (en particular, registros TXT).
Ver también
Referencias
- ^ a b c DNS de multidifusión . Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487 / RFC6762 . RFC 6762 .
- ^ Manning, Bill; Woodcock, Bill (agosto de 2000), Servicio de nombres de dominio de multidifusión , IETF
- ^ mDNS y DNS-SD se abren camino lentamente en Windows 10 , blog Ctrl, 21 de octubre de 2015 , consultado el 30 de agosto de 2017
- ^ Descubrimiento de servicios DNS . IETF . doi : 10.17487 / RFC6763 . RFC 6763 .
- ^ P. Mockapetris (noviembre de 1987). NOMBRES DE DOMINIO - IMPLEMENTACIÓN Y ESPECIFICACIÓN . Grupo de trabajo en red, IETF . doi : 10.17487 / RFC1035 . RFC 1035 ..
enlaces externos
- DNS de multidifusión : sitio de información mantenido por el diseñador de mDNS, Stuart Cheshire
- LLMNR, DNS multidifusión y nombres en su LAN