Resumen

  • El 5 de septiembre, la revisión 01 de DNS and mDNS Discovery for MOQT incorporó normalización de URI y reglas de correspondencia X.509. La revisión 02 solo corrigió el enlace al repositorio fuente.
  • El texto conserva el host de la URI moqt original como identidad del certificado cuando SVCB o SRV envían la conexión a otro destino. En mDNS, en cambio, aún no define cómo el servicio descubierto obtiene esa identidad de referencia ni quién autoriza a anunciar _moqt._udp; la sección de seguridad sigue diciendo TODO.

El dato más importante de una respuesta mDNS es el que no transporta. PTR puede enumerar una instancia. SRV puede entregar host y puerto. TXT puede declarar alpn=moqt. El origen IP puede demostrar que el paquete no vino de fuera del enlace. Falta saber si el equipo tenía derecho a presentarse como el relé de esta aplicación.

El registro de Datatracker fecha la revisión actual el 5 de septiembre de 2026. Es un Internet-Draft individual: su ficha no asigna stream IETF ni nivel de norma. Aunque la cabecera propone Standards Track y remite el debate a la lista Media over QUIC, no debe describirse como adopción del grupo, consenso ni aprobación.

La secuencia de versiones importa. La revisión 00, de agosto, ya ofrecía SVCB, HTTPS, SRV y descubrimiento local. La revisión 01 añadió el 5 de septiembre el contrato de identidad. La revisión 02 cambió después únicamente la URL del código fuente. Su anuncio I-D no convierte el documento en una norma ni prueba que exista una implementación.

El destino resuelto no se convierte en el principal

Para QUIC nativo, el borrador usa SVCB; para WebTransport, HTTPS; y como alternativa más pobre, SRV. Los dos primeros pueden expresar ALPN y otros parámetros. SRV se limita a un objetivo y un puerto. Si la respuesta es utilizable, el cliente abre el socket hacia ese objetivo.

Ahí termina la autoridad del objetivo. El host de la URI moqt original debe seguir en SNI y en la validación del certificado. La máquina que recibe los paquetes no adquiere el nombre del servicio por haber sido seleccionada por DNS. Esa separación es coherente con el RFC 9460, que trata SVCB/HTTPS como indirectiones sin alterar el origen.

También coincide con el RFC 9525: un identificador de referencia nace de una entrada segura o configurada, no de cada nombre intermedio que produzca la resolución. Si la aplicación no define otra autenticación, el nombre intermedio sigue siendo un localizador.

La nueva sección hace comparaciones deterministas. Normaliza mayúsculas y codificación porcentual, añade el puerto 443, elimina el punto terminal y convierte nombres internacionales conforme al RFC 5890. No acepta comodines ni CN-ID. Usa identificadores subjectAltName, incluido SRVName del RFC 4985, y la sintaxis del RFC 3986.

Es una mejora concreta: el DNS no puede decidir simultáneamente dónde conectar y qué identidad debe aceptar el cliente. Pero el método parte de una URI original. La navegación de servicios locales puede empezar antes de que esa URI exista para el usuario.

Estar en el mismo enlace solo demuestra proximidad

El apartado mDNS permite que un relé anuncie PTR, SRV y TXT bajo .local. Un ALPN reconocido filtra ofertas incompatibles; no autentica al operador. El RFC 6762 explica que la resolución de conflictos funciona entre participantes cooperativos y sin autoridad central. Su comprobación de procedencia local reduce la suplantación remota, pero no resuelve la presencia de un host antagonista dentro de la misma red.

El propio RFC advierte que los nombres .local no tienen autoridad global y que, cuando la confianza importa, hacen falta mecanismos criptográficos de extremo a extremo. El RFC 6763 organiza la gramática de DNS-SD y recomienda DNSSEC cuando la autenticidad sea necesaria. Ninguno concede a un registro permiso para representar una organización o un contenido.

El borrador MOQT actual deja sus Security Considerations en TODO. Tampoco explica todavía cómo una instancia descubierta produce la URI moqt original que gobernará el certificado, o qué política admite al anunciante. Una aplicación puede recurrir a configuración previa, anclaje de certificado, descubrimiento firmado o confirmación humana. Son decisiones posibles, no obligaciones del texto actual.

Un TLS correcto no concede derechos sobre el vídeo

El borrador MOQT Transport 20 usa QUIC o WebTransport para confidencialidad, integridad y autenticación del extremo. La autorización para suscribirse, publicar o actuar en un espacio de nombres se decide aparte. Por eso un certificado correcto puede coexistir con una publicación no autorizada; y un relé autorizado puede estar caído o entregar un resultado equivocado.

La trazabilidad necesita entradas separadas para el anuncio, la interfaz, el objetivo elegido, la URI de referencia, la cadena X.509, la política local, el permiso sobre el namespace, el establecimiento de sesión y el objeto multimedia observado. “Descubrimiento satisfactorio” no es un recibo compuesto.

La especificación inicial mínima de Heng Lu favorece un invariante pequeño: la indirection no reasigna autoridad. Las capas de realidad impiden que registro, certificado y resultado se presten legitimidad. La primacía del código en funcionamiento exige comprobar qué nombre y qué política usó el cliente real.

Fuentes

  1. Registro IETF Datatracker
  2. Descubrimiento MOQT, revisión 02
  3. Revisión 01
  4. Revisión 00
  5. Anuncio de la revisión 02
  6. MOQT Transport, revisión 20
  7. RFC 9460: SVCB y HTTPS
  8. RFC 6762: Multicast DNS
  9. RFC 6763: DNS-Based Service Discovery
  10. RFC 9525: identidad de servicio en TLS
  11. RFC 4985: SRVName
  12. RFC 3986: sintaxis URI
  13. RFC 5890: IDNA
  14. Heng Lu: especificación inicial mínima
  15. Heng Lu: capas de realidad
  16. Heng Lu: primacía del código en funcionamiento