Resumen

  • Un registro DNS HTTPS publica instrucciones de conexión; no ejecuta una prueba.
  • La selección depende de la prioridad, los parámetros comprendidos, la resolución y las capacidades del cliente.
  • Las pistas de dirección, el anuncio ALPN y el éxito por fallback son pruebas distintas.
  • La preparación operativa requiere un registro de validación que vincule el RRset observado con una respuesta autenticada para cada cohorte relevante.

Imaginemos un panel de despliegue que se pone verde en cuanto aparece un registro HTTPS nuevo. El registro anuncia HTTP/3 e incluye una pista de dirección IPv6. Una sonda convencional sigue cargando la página, así que la migración se da por terminada. Sin embargo, todos los intentos HTTP/3 de una cohorte móvil fallan. Esos usuarios llegan al servicio porque sus clientes vuelven a HTTP/2 en el endpoint original.

El registro DNS no era falso. El error fue confundir publicación con entrega.

El RFC 9460 define los registros SVCB y HTTPS para que un cliente conozca endpoints alternativos y parámetros de conexión antes de abrir la conexión habitual. El mecanismo puede reducir latencia, permitir HTTP/3 directo, anunciar puertos no predeterminados y agrupar parámetros coherentes. Es información útil del plano de control, no una transacción sintética.

La estructura del registro importa. SvcPriority cero indica AliasMode, que delega la resolución a otro nombre. Un valor distinto de cero indica ServiceMode, que asocia TargetName con parámetros. Se prefieren números bajos, pero las entradas con igual prioridad se barajan. Registrar solamente «HTTPS RR presente» no conserva qué opción podía usar el cliente, cuál eligió ni por qué.

La compatibilidad crea otra frontera. mandatory señala las claves que el cliente debe entender. Si desconoce una, la entrada no es utilizable para ese cliente. alpn anuncia protocolos de aplicación y no-default-alpn puede eliminar el que normalmente implica el esquema. Un RRset perfectamente formado puede ofrecer decisiones distintas a navegadores, sistemas, bibliotecas y políticas de dispositivos diferentes.

Las pistas ipv4hint e ipv6hint suelen recibir una autoridad excesiva. Permiten empezar de forma optimista. Según RFC 9460, el cliente debería dar preferencia a los registros A o AAAA ya disponibles; si no los tiene, debería consultar el TargetName y usar después las direcciones obtenidas. Una pista no prueba que exista ruta, que UDP esté permitido, que el NAT o el cortafuegos conserven el flujo, ni que el destino acepte el protocolo. Indica dónde intentar; no demuestra que los paquetes hayan llegado.

Tampoco cambia la autoridad TLS. Un alias SVCB no modifica el origen que debe autenticarse: el certificado se valida para el nombre de servicio original. La respuesta DNS puede estar presente y bien interpretada mientras fallan el certificado, SNI o el handshake TLS en el destino anunciado.

Para HTTP/3, el RFC 9114 coloca la aplicación sobre QUIC, definido por el RFC 9000. Después de resolver DNS aún quedan el establecimiento QUIC, la autenticación TLS, el intercambio de ajustes HTTP/3 y la respuesta de la aplicación. Cada transición puede fallar por separado. Reducirlas a un indicador «HTTP/3 habilitado» elimina la evidencia necesaria para localizar el problema.

El fallback hace que esa pérdida resulte invisible. RFC 9460 contempla casos en los que el cliente rechaza registros malformados o incompatibles y vuelve al establecimiento sin SVCB. Una petición puede tener éxito aunque el endpoint alternativo nunca se intentara o fallara. Es una ventaja de disponibilidad, no una prueba de aceptación.

La inferencia contraria tampoco es válida. Un fallo aislado no demuestra que el registro sea defectuoso en general. El cliente puede no admitir el ALPN, recibir una respuesta específica de su resolvedor DNS, elegir otro destino de igual prioridad, utilizar un proxy, sufrir bloqueo UDP local o conservar datos DNS antiguos. La preparación operativa se afirma por cohortes, no a partir de un único dispositivo.

El registro probatorio de preparación operativa debe empezar con el nombre consultado, resolvedor DNS, red, versión del cliente, punto de observación y hora. Debe conservar el RRset HTTPS completo, resultado de validación DNS, TTL y edad de caché; prioridad y destino elegidos; parámetros comprendidos; direcciones resueltas o sugeridas; y el motivo por el que cada registro fue aceptado, omitido o rechazado.

Después sigue la ejecución: dirección, protocolo y puerto intentados; resultado QUIC o TCP; ALPN negociado; nombre y validación del certificado; estado HTTP y huella de la representación; y cualquier fallback. El registro termina con cohorte, duración, resultado final y componente autorizado para declarar la preparación operativa.

Así, «RR HTTPS observado» solo significa que un resolvedor DNS devolvió el conjunto. «Alternativa elegida» significa que un cliente aceptó una opción ServiceMode. «HTTP/3 conectado» significa que QUIC, TLS y HTTP/3 se establecieron. «Servicio entregado» significa que terminó la transacción de aplicación prevista. Los eventos pueden compartir cronología, pero el primero no crea los demás.

La separación orienta la respuesta. Registros ignorados llevan a revisar compatibilidad y claves obligatorias. Dirección resuelta con fallo QUIC apunta al camino o a la política de transporte. Un fallo TLS remite a la autenticación del origen y al despliegue. Éxito solo tras fallback conserva la disponibilidad, pero deja pendiente la validación del endpoint alternativo.

Dentro de su límite, el registro HTTPS aporta evidencia útil: muestra el enlace publicado y observado. La preparación operativa empieza cuando un cliente identificado sigue ese enlace y devuelve un resultado de aplicación autenticado.

Fuentes

RFC 9460 — Registros SVCB y HTTPS; RFC 9114 — HTTP/3; RFC 9000 — QUIC.