Resumen

  • ULD propone que todos los clientes de un enlace converjan en un servidor preferido y exige que, al migrar, cada cliente vuelva a registrar todos sus servicios en el nuevo servidor.
  • Ese mandato no acredita por sí solo que el inventario sobrevivió. Hace falta un recibo de relevo que una la elección, el motivo del cambio, los registros esperados, sus resultados y la visibilidad posterior por unicast, mDNS, IPv4 e IPv6.

El servicio que falta detrás de un relevo correcto

draft-ietf-dnssd-uld-00 es la primera revisión como documento del grupo DNSSD de la IETF, fechada el 18 de agosto de 2026. Define Unicast Local Discovery como una combinación de registro SRP, DNS autoritativo y dos proxies. Su objetivo es que los dispositivos puedan anunciar y descubrir servicios del enlace con tráfico unicast, sin aislar a los equipos que siguen usando mDNS.

La propuesta conserva .local como ámbito semántico del enlace. Un servidor mantiene una zona con los registros SRP; el Discovery Proxy incorpora lo que observa por mDNS y el Advertising Proxy publica hacia mDNS lo que llegó por SRP. Para datos compartidos, el servidor suele responder con la unión de esas fuentes. Por tanto, «servidor operativo» y «catálogo completo» no son sinónimos.

El documento sigue siendo un borrador de Standards Track. Si llegara a aprobarse, actualizaría RFC 6762. Hoy no es un RFC, no contiene resultados de despliegue y mantiene pendientes las consideraciones de seguridad, una parte sobre routers SNAC y la asignación IANA del nombre de servicio. Esa situación permite examinar el mecanismo, pero no presentarlo como práctica consolidada.

El punto decisivo aparece cuando cambia el servidor elegido. Todos los servidores anuncian un valor pri; gana el menor. La infraestructura usa 0 y los servidores ad hoc reciben valores superiores según capacidad y medio. Si dos anuncios empatan, la dirección IPv6 link-local numéricamente menor decide. Un servidor de infraestructura añade una opción ULD a los Router Advertisements, que los clientes IPv6 deben usar para descubrirlo o para verificar una designación conocida por DNS-SD.

En una red gestionada, el operador activa expresamente esa condición y debe impedir que más de un router anuncie la opción de infraestructura en el mismo enlace. En una red doméstica, el router de borde puede declararse infraestructura si ya actúa como puerta de enlace de hecho. Otro dispositivo no debe atribuirse ese rango sin configuración explícita.

Convergencia sin transferencia automática

Un cliente busca primero infraestructura, luego compara alternativas ad hoc y, si ninguna sirve, retorna a mDNS. Tras adoptar ULD debería dejar de participar directamente en mDNS en ese enlace. También debe vigilar la disponibilidad: consultas que expiran persistentemente, renovaciones SRP fallidas o la pérdida de una sesión DNS Push obligan a descubrir de nuevo. Quien usa un servidor ad hoc continúa buscando otro de mayor prioridad.

El resultado es una elección dinámica. Un fallo puede expulsar al servidor actual; la llegada de infraestructura puede desplazar a un servidor ad hoc que todavía funciona. En ambos casos el texto ordena al cliente migrante volver a registrar todos sus servicios en el nuevo servidor.

La arquitectura eligió deliberadamente ese reparto de trabajo. El apéndice C advierte que varios registradores independientes pueden aceptar el mismo nombre y enterarse del conflicto demasiado tarde, a través de mDNS, incluso sin avisar correctamente a los clientes. ULD evita ese estado dividido haciendo que los clientes converjan de forma determinista en un único candidato. No exige que los servidores se entreguen entre sí el estado anterior.

Existe un proyecto histórico de replicación SRP que perseguía otra solución: conservar copias del estado, reducir conflictos y ocultar ciertos cambios de servidor al cliente. Está expirado y no forma parte de ULD 00. La comparación sirve para ubicar la carga probatoria. En un sistema replicado habría que demostrar la convergencia de las réplicas. En el modelo ULD actual hay que demostrar que cada cliente detectó el cambio y reconstruyó todo aquello que debía anunciar.

Un «registro aceptado» no basta. Puede corresponder a uno de varios servicios. Tampoco basta contar filas en la zona nueva si no existe una referencia del inventario previsto. Una consulta DNS exitosa prueba una vista en un momento dado; no acredita que el Advertising Proxy haga visible el mismo conjunto a clientes mDNS ni que el Discovery Proxy haya reunido todos los anuncios ajenos.

El peligro más difícil es el éxito parcial. Tres cámaras reaparecen, la cuarta choca con un nombre ya ocupado y el cliente no muestra el conflicto. La zona responde, la mayoría de las aplicaciones funciona y el panel marca el relevo como correcto. Sin una conciliación explícita, la excepción queda fuera de la historia operativa.

Un recibo delimitado por enlace

La prueba debe empezar por el ámbito. ULD mantiene una instancia separada por enlace; un equipo con varias interfaces puede usarlo en una y recurrir a mDNS en otra. El recibo ha de indicar enlace, interfaz, familia de direcciones y ventana de observación. No debería declarar que «el dispositivo migró» cuando solo se comprobó una de sus superficies locales.

Después debe fijar las partes del relevo: servidor anterior y nuevo, direcciones link-local, prioridad anunciada, condición de infraestructura o ad hoc y desempate aplicado. Debe nombrar la causa: fallo persistente, renovación de arrendamiento perdida, sesión push cerrada, aparición de un candidato mejor o decisión del operador.

También importa la legitimidad local del nuevo rol. El registro de cambio de una red administrada puede demostrar quién habilitó la infraestructura. En un hogar puede consignarse que el equipo ya era la puerta de enlace. La opción RA observada y la política RA Guard aportan evidencia sobre el anuncio, pero no autentican por sí solas el servicio. El borrador permite certificados autofirmados, aconseja no rechazarlos y dice expresamente que la autenticación del servidor no es el objetivo de este uso oportunista de TLS.

El núcleo del recibo es un inventario antes y después. El cliente compromete una huella de las descripciones que espera repetir. Para cada una registra aceptación, rechazo, conflicto, espera agotada, arrendamiento concedido y reintento. El servidor puede aportar una huella de la zona correspondiente. Las pruebas posteriores consultan la vista unicast, la contribución del Discovery Proxy y la salida mDNS del Advertising Proxy.

En redes duales conviene observar IPv4 e IPv6 por separado. La designación mediante RA es IPv6, mientras que un cliente solo IPv4 descubre los servidores mediante mDNS y puede necesitar volver a este mecanismo si el preferido no es alcanzable. Un único ensayo desde un portátil moderno no demuestra continuidad para todo el enlace.

Las diferencias deben tener nombre. Retirada voluntaria, cambio de nombre por conflicto, servicio que aún espera un arrendamiento o cliente que volvió a mDNS son estados distintos. Ninguno debería ocultarse dentro de un porcentaje general.

La privacidad impone una prueba mínima

Guardar indefinidamente la lista completa de servicios sería desproporcionado. Los nombres locales pueden revelar personas, salas, electrodomésticos y hábitos. El recibo no debe transformarse en una base de datos de la vida cotidiana.

Una técnica más prudente es conservar una huella con sal sobre descripciones normalizadas, recuentos por tipos amplios y códigos de excepción. El conjunto completo y la sal pueden permanecer durante un tiempo corto en el cliente o en un entorno de operación restringido. Para auditoría duradera bastan el identificador del relevo, los totales, las divergencias, los tiempos y el compromiso criptográfico que impide reescribir el punto de partida.

La retención debe cubrir el plazo en que caducan arrendamientos y cachés y pueden llegar avisos tardíos. Después, los nombres que ya no aportan valor a una investigación deben eliminarse. Se trata de probar una transición, no de catalogar a los usuarios.

Qué puede afirmarse hoy

Las fuentes permiten decir que ULD separa dos actos: elegir y volver a registrar. No permiten atribuir a la IETF el formato de recibo propuesto aquí. Tampoco permiten afirmar una tasa de pérdidas, un tiempo de recuperación o interoperabilidad universal.

RA Guard tiene limitaciones descritas en RFC 7113. Las firmas de SRP protegen el control de un registro, no la integridad agregada de una migración. La autoridad del DNS ULD se limita a .local en el enlace y no equivale a una delegación del DNS público.

El criterio de cierre debe ser más exigente que un servidor nuevo que contesta. El relevo concluye cuando cada servicio previsto reaparece, se retira de manera intencional o queda señalado como excepción verificable. Esa diferencia convierte un cambio técnico en una decisión operativa que puede rendir cuentas.

Fuentes

  1. Documento ULD vigente
  2. Historial del documento
  3. Revisión 00 en HTML
  4. Revisión 00 en texto
  5. API de Datatracker
  6. Repositorio de trabajo DNSSD
  7. Presentación ULD de IETF 126
  8. Carta del grupo DNSSD
  9. RFC 6762 — Multicast DNS
  10. RFC 6763 — DNS-Based Service Discovery
  11. RFC 9665 — Service Registration Protocol
  12. RFC 8766 — Discovery Proxy
  13. RFC 8765 — DNS Push Notifications
  14. RFC 8490 — DNS Stateful Operations
  15. RFC 6105 — RA Guard
  16. RFC 7113 — Recomendaciones para RA Guard
  17. RFC 4861 — Neighbor Discovery para IPv6
  18. Borrador Advertising Proxy
  19. Borrador Time Since Received
  20. Borrador expirado de replicación SRP