El Problema de Descubrimiento de HTTP/3 que Nadie Menciona

Aquí tienes una situación que se repite en millones de sitios web: un visitante escribe tu dominio en el navegador. El navegador resuelve el DNS, abre una conexión TCP, completa el handshake de TLS, envía una petición HTTP... y solo entonces descubre "¡oye, también soporte HTTP/3!" Ese protocolo que lo habría acelerado todo llega demasiado tarde.

Esto no es una limitación del navegador. Es una restricción arquitectónica de base. La forma tradicional de publicar el soporte HTTP/3 es mediante el header HTTP Alt-Svc, que solo puede llegar a los clientes después de que ya establecieron una conexión. Para ese momento, ya se comprometieron con HTTP/1.1 o HTTP/2.

El Registro DNS HTTPS (RFC 9460)

Aquí es donde la cosa se pone interesante. El registro de recursos HTTPS, estandarizado en noviembre de 2023, hace algo remarkable: te permite anunciar el soporte HTTP/3 antes de que el navegador abra ninguna conexión.

Cuando un cliente realiza la resolución DNS —algo que iba a hacer de todas formas— puede aprender al mismo tiempo:

• Qué protocolos ALPN soportas (h3, h2, http/1.1)
• Tus claves públicas de ECH (Encrypted Client Hello)
• Sugerencias de IP para empezar a conectar inmediatamente

Esto significa que la primera conexión a tu sitio puede usar QUIC y HTTP/3 desde el inicio. Sin handshake desperdiciado. Sin ida y vuelta extra para descubrir un protocolo que podrías haber usado desde el principio.

Por Qué Esto Importa Más de lo que Crees

Piensa en cada visitante que llega por primera vez a tu sitio. No tiene conexiones en caché. No ha aprendido nada sobre tu soporte HTTP/3 de visitas anteriores. Empieza desde cero, y con el enfoque antiguo del Alt-Svc, paga una penalización de latencia solo para descubrir qué soportas.

Con un registro HTTPS, ese descubrimiento ocurre durante la consulta DNS que ya estaba realizando. La negociación del protocolo sucede antes de establecer la conexión, no después.

Pero Hay Más: Encrypted Client Hello

El registro HTTPS resuelve otro problema crítico que los headers HTTP simplemente no pueden tocar. ECH encripta el propio ClientHello de TLS, incluyendo el nombre del servidor SNI. Esto impide que observadores de red vean a qué sitio específico estás accediendo.

Aquí está el detalle: necesitas la clave pública de ECH antes de enviar el primer ClientHello. Pero no hay conexión todavía para recibir esa clave. Este es un problema de chicken-and-egg que solo un canal fuera de banda puede resolver — y el registro DNS HTTPS es ese canal.

Los headers HTTP nunca podrán entregar ECH. El DNS sí puede.

Publicando Tu Registro HTTPS

¿Curioso por ver cómo luce? Aquí tienes un registro HTTPS completo en modo servicio:

tudominio.com.  3600  IN  HTTPS  1  .  alpn="h3,h2"  ipv4hint=203.0.113.10  ipv6hint=2001:db8::10

Desglosándolo:

• tudominio.com. — Tu dominio (completo con el punto al final)
• 3600 — TTL en segundos (cuánto tiempo los resolvers pueden cachéar esto)
• HTTPS — El tipo de registro
• 1 — Prioridad de 1 o más significa modo servicio (transporta parámetros)
• . — Host destino; un punto significa "usa el nombre del propietario"
• alpn="h3,h2" — Protocolos soportados, el mejor primero
• ipv4hint / ipv6hint — Sugerencias de direcciones para iniciar la conexión temprano

En NameOcean, facilitamos cada vez más gestionar estos registros junto con el resto de tu configuración DNS. Es una señal más de que prestamos atención a hacia dónde va el rendimiento web.

¿Qué Pasa con los Clientes Antiguos?

Publicar un registro HTTPS es estrictamente aditivo. Los clientes que no lo entienden simplemente lo ignoran y vuelven a las consultas A/AAAA normales. Pueden perderse la optimización de HTTP/3, pero nada se rompe.

Esto significa que puedes publicar tu registro HTTPS hoy sin preocuparte por la compatibilidad. Es una mejora progresiva: los navegadores modernos lo leen, los antiguos ni lo notan.

¿Deberías Eliminar Tu Header Alt-Svc?

No. Sigue enviándolo.

Piensa en el header Alt-Svc como un respaldo para todo lo que no reciba tu registro HTTPS: navegadores legacy, ciertas configuraciones de resolvers, o redes que filtran respuestas DNS. Con ambos en su lugar, estás cubierto desde todos los ángulos:

• Navegadores modernos + resolvers conscientes del HTTPS → Descubren HTTP/3 desde DNS, conectan inmediatamente con QUIC
• Clientes antiguos o DNS filtrado → Recurren al header Alt-Svc después de la conexión inicial
• Visitas siguientes → Aún mejor; las conexiones HTTP/3 pueden reanudarse con 0-RTT, poniendo la primera petición en la red sin handshake

La Conclusión

El registro DNS HTTPS es una de esas optimizaciones raras que cuesta casi nada implementar pero que puede mejorar significativamente el rendimiento de conexión para cada nuevo visitante de tu sitio. Es un pequeño cambio de configuración que coloca el descubrimiento de HTTP/3 justo donde debe estar: antes del primer byte enviado, no después.

Si usas un CDN, verifica si ya están publicando esto por ti — Cloudflare lo hace automáticamente para zonas proxied. Si gestionas tu propio DNS, agregar un registro HTTPS es una tarea de quince minutos que tus visitantes apreciarán en cada conexión fría.

La web se mueve hacia HTTP/3. Asegúrate de que tu DNS también vaya en ese viaje.

¿Listo para optimizar tu configuración DNS? En NameOcean te damos las herramientas y orientación para mantener tu infraestructura en la cresta de la ola. Las primeras conexiones de tus visitantes no tienen por qué esperar.