Resumen

  • El 18 de agosto, el grupo DNSSD aprobó draft-ietf-dnssd-uld-00 y lo vinculó como sustituto del borrador individual anterior. El cuerpo técnico normalizado no cambió.
  • ULD concentra registro, DNS y funciones de proxy en un servidor local preferente. Puede aliviar el coste de mDNS sobre Wi-Fi, pero todavía carece de una sección de seguridad y de evidencia de despliegue.

Hay dos noticias distintas que podrían confundirse. La primera sería una modificación del protocolo. La segunda es que la IETF ha puesto una propuesta existente bajo la responsabilidad formal de un grupo de trabajo. Solo la segunda ocurrió el 18 de agosto.

El registro del nuevo documento muestra a las 16:22:50 UTC la aprobación de la versión -00, su disponibilidad pública y la relación de reemplazo con draft-tlmk-infra-dnssd. Al eliminar nombres, fechas, caducidad y encabezados de página, la versión nueva y la anterior tienen el mismo contenido. El cambio de nombre crea una ruta institucional para desarrollar el texto; no permite atribuirle prestaciones que antes no tuviera.

La historia del borrador individual añade contexto sobre esa ruta. Un presidente registró inicialmente la adopción después de una muestra de manos en IETF 126, luego deshizo el paso al reconocer que debía celebrarse antes una llamada de adopción en la lista. La llamada se abrió el 21 de julio y el estado definitivo de adopción llegó el 6 de agosto. Es una corrección documentada de gobernanza, no una votación sobre el resultado final del diseño.

¿Qué diseño asumió DNSSD? El borrador de Unicast Local Discovery parte de un problema cotidiano. mDNS hace que cada dispositivo que anuncia un servicio escuche y responda en multicast. En Wi-Fi, esas tramas no reciben acuse ni retransmisión de la capa MAC, no quedan almacenadas para estaciones dormidas y se emiten a una velocidad obligatoria baja. Así, una pequeña cantidad de tráfico puede ocupar mucho tiempo de radio, y un dispositivo con batería debe elegir entre despertarse con frecuencia o perder consultas.

ULD crea un intermediario local. Un servidor combina un registrador SRP, DNS autoritativo, un Discovery Proxy y un Advertising Proxy. Los clientes compatibles registran allí sus servicios y consultan .local por unicast. El servidor sigue hablando con equipos mDNS, lo que permite conservar nombres y aplicaciones existentes mientras parte del trabajo repetitivo deja de recaer sobre todos los extremos.

La propuesta reutiliza estándares publicados. RFC 9665 define el registro de servicios mediante SRP y sus arrendamientos. RFC 8766 define el proxy que contesta consultas DNS unicast con información de enlaces mDNS. ULD aporta la envoltura operativa: cómo encontrar el servidor, cuál debe preferirse, cuándo abandonarlo y cómo mantener la convivencia.

El RFC 6762 no desaparece. Es la base de Multicast DNS que ULD pretende actualizar si algún día se aprueba. El servidor se anuncia mediante DNS-SD sobre mDNS, traduce para dispositivos que solo conocen multicast y permite a los clientes volver a mDNS si no encuentran un servicio ULD funcional. La transición propuesta es selectiva y reversible, no una retirada inmediata del protocolo instalado.

La preferencia convierte al servidor en parte del plano de control. En redes administradas, el operador debe habilitar expresamente la condición de infraestructura. Solo un equipo debería anunciar la opción ULD en Router Advertisements dentro de un enlace. Otros dispositivos pueden prestar el servicio en modo ad hoc con menor prioridad. El cliente vigila su elección, busca alternativas mejores y vuelve a registrar todo cuando cambia de servidor.

Esa disciplina responde a un fallo concreto. Dos servidores independientes podrían aceptar el mismo nombre para clientes distintos, y el conflicto aparecería después en la capa mDNS sin retroalimentación útil para quien registró. El texto evita obligar a que todos los servidores repliquen su estado y, en su lugar, fuerza a los clientes a converger de forma determinista. El precio es que una elección equivocada, una detección lenta o una migración incompleta afectan a la visibilidad de servicios.

IPv6 ofrece una señal adicional: una opción en los anuncios del router identifica al servidor de infraestructura y permite proteger esa designación con RA Guard. Un cliente IPv6 debe usarla para descubrir o verificar la autoridad anunciada. Un cliente solo IPv4 depende de mDNS para encontrar servidores, y el servidor debe comprobar que la consulta .local procede de una subred conectada directamente.

El borrador deja sin cerrar precisamente las preguntas que harían segura esa autoridad. “Security Considerations” contiene TODO. La sección sobre routers SNAC también está pendiente. El nombre de servicio para IANA sigue siendo un marcador. No hay resultados públicos de interoperabilidad, consumo de batería, tiempo de radio, pérdida de consultas ni recuperación ante fallos. Es un Internet-Draft, no un RFC.

La carta de DNSSD recuerda que el objetivo del grupo es escalar DNS-SD más allá de las limitaciones del multicast local y que ampliar el alcance crea riesgos de seguridad y privacidad. ULD, por ahora, sigue limitado al enlace, pero concentra una vista de los servicios que antes construían muchos participantes. Por eso la seguridad no es una formalidad editorial que pueda añadirse al final.

La aprobación del grupo es una señal de trabajo organizado. No es un sello de producción. A partir de ahora será posible evaluar revisiones, objeciones, código e interoperabilidad bajo un nombre estable. Hasta que aparezca esa evidencia, solo puede afirmarse que la IETF ha abierto una vía formal para sustituir parte del tráfico local multicast por un servicio unicast preferente.

Fuentes