Resumen

  • El IESG abrió el 3 de septiembre de 2026 la revisión comunitaria de un nuevo mandato propuesto para DNSSD, con comentarios hasta el día 13. El aviso dice expresamente que todavía no hay una decisión.
  • El mandato incorpora el paso de registros SRP a mDNS y los conflictos entre actualizaciones del mismo nombre. Su hito más próximo es una última llamada del grupo en noviembre para draft-ietf-dnssd-tsr-03: una propuesta para reconocer copias antiguas de proxies redundantes, no para autenticar dispositivos o certificar que un servicio responde.

La antigüedad solía ser una señal útil. Si una impresora ya ocupa un nombre en el enlace local y aparece otra máquina con datos incompatibles, mDNS protege el anuncio existente. Así evita que el último en llegar sustituya silenciosamente a quien estaba primero.

El problema nace cuando quien habla no es la impresora, sino un intermediario. Un dispositivo registra su servicio mediante SRP. El registrar proyecta esos datos en mDNS como advertising proxy. Más tarde, una partición o un cambio de anycast lleva la siguiente actualización a otro registrar. Los dos proxies anuncian el mismo origen en momentos distintos. El viejo sigue ahí; el nuevo contiene el estado vigente.

La regla de protección interpreta las dos copias como rivales y conserva la anterior. La lógica no ha fallado dentro de su modelo original. Lo que cambió fue la relación entre voz y autoridad: el proxy no es el dueño del servicio.

Ese cambio aparece en el aviso de revisión emitido por el IESG el 3 de septiembre. El mandato propuesto amplía la labor de DNSSD para descubrimiento escalable en uno o varios enlaces. Incluye publicar en mDNS nombres registrados con SRP, mejorar eficiencia y disponibilidad y resolver o evitar actualizaciones concurrentes de un mismo nombre.

El aviso no aprueba esa agenda. Solicita comentarios hasta el 13 de septiembre y afirma que el IESG no ha tomado una determinación. Tampoco el calendario es una prueba técnica: la llamada de grupo prevista para noviembre no ha ocurrido. La ficha de TSR muestra la revisión 03 como Internet-Draft activo en Standards Track; no es un RFC ni evidencia de despliegue.

La diferencia entre DNS delegado y mDNS explica la necesidad. RFC 1034 describe la jerarquía y los servidores autoritativos del DNS. RFC 6762 resuelve nombres en el enlace mediante multicast, sin una única fuente de autoridad. RFC 6763 usa registros DNS para descubrir instancias y tipos de servicio.

La arquitectura moderna conecta ámbitos que antes estaban separados. RFC 8766 permite que un Discovery Proxy publique por DNS unicast servicios aprendidos en mDNS. RFC 9665 define SRP: el solicitante registra servicios con una actualización vinculada a su clave. El borrador Advertising Proxy proyecta registros SRP en el sentido inverso, hacia mDNS.

Con dos registrars, una actualización nueva puede llegar por un camino mientras el anuncio viejo sobrevive por otro. El borrador señala que el criterio «el más antiguo gana», correcto para dos anunciantes que hablan por sí mismos, resulta exactamente equivocado cuando los datos son generaciones de una sola fuente.

La revisión 03 de TSR añade una opción EDNS Time Since Received por cada owner name. La opción identifica el RRset cubierto, lleva un checksum asociado a la clave pública del solicitante y comunica cuánto tiempo ha transcurrido desde que el proxy recibió el dato. El receptor traduce ese offset a su tiempo local y compara copias.

No se trata simplemente de colocar una fecha. El checksum permite comprobar que dos anuncios corresponden a la misma fuente; el tiempo distingue sus generaciones. Con ello, el registro actualizado puede desplazar a la copia obsoleta sin parecer un intruso. El mecanismo también busca reducir sondeos redundantes, renombres innecesarios y mensajes de despedida que borrarían datos todavía válidos a través de otro proxy.

Hay límites de implementación. La comparación depende del reloj local y de cómo se conserva el instante de recepción. La latencia afecta a los offsets. Un reinicio puede crear otra época de observación. En un dispositivo multihomed, una misma fuente puede anunciar directamente por una interfaz y mediante SRP por otra. Las indicaciones de proxy primario o secundario reducen respuestas; no entregan una autoridad universal.

RFC 6891 proporciona el formato extensible de EDNS. El formato común hace posible interoperar, pero no certifica que un software calcule bien el tiempo, mantenga bien la clave o retire bien un dato.

La sección de seguridad de TSR corta una inferencia especialmente peligrosa. Un equipo malicioso en el mismo enlace puede intervenir en conflictos y provocar denegación de servicio. El borrador no convierte mDNS en un sistema seguro o privado. Si una aplicación necesita autenticación, autorización o secreto, debe proporcionarlos por separado o usar descubrimiento con DNSSEC donde corresponda.

La privacidad tampoco mejora por elegir la copia reciente. RFC 8882 explica que el descubrimiento puede revelar dispositivos, servicios y actividad. Cuando el alcance salta de un enlace a varios, aumenta quién puede observar la información. Un anuncio puede ser fresco y estar expuesto al público equivocado.

La operación debe conservar pruebas de cada unión: identidad y clave del solicitante, SRP Update original, registrar receptor, proxy anunciante, nombre, RRset completo, hora de recepción, base del reloj, checksum, offset, paquete de sondeo, conflicto detectado, registro seleccionado, renombre y goodbye. Después debe guardar la respuesta recibida por el cliente, el destino real, la conexión, la autenticación de aplicación y el resultado visible.

El registro seleccionado sólo prueba el resultado del arbitraje. No prueba que el endpoint esté activo. Una conexión no prueba identidad. La autenticación no demuestra que todos los caches hayan eliminado la copia antigua. La retirada necesita recorrer el sistema al revés y comprobar que el tráfico deja de llegar al destino anterior después de expiraciones y despedidas.

El principio de especificación inicial mínima de Heng Lu favorece un dato compartido estrecho que permita coordinar sin capturar las decisiones futuras. Sus capas de realidad mantienen separados timestamp, identidad y servicio. La primacía del código en ejecución exige observar la respuesta y la aplicación, no declarar éxito desde el borrador.

DNSSD afronta, por tanto, una consecuencia de escalar la visibilidad. Al insertar registrars y proxies, la edad deja de representar posesión. TSR puede devolver a cada copia su orden correcto. La autoridad y el resultado siguen necesitando recibos propios.

Fuentes