Planteamiento
Diseña una migración de registros HTTPS (SVCB) para un dominio que sirve HTTP/2 y HTTP/3. El plan debe admitir despliegues canary, rollback y diagnóstico cuando la configuración de los resolutores, los clientes y los certificados no coincidan.
Escenario y restricciones
El DNS autoritativo está alojado en múltiples proveedores, mientras que los clientes heredados solo consultan A/AAAA. Los clientes no compatibles deben permanecer disponibles. El TTL de DNS es de 300 segundos y el servicio no puede quedar fuera de línea durante el cambio.
Qué evalúa esto
El candidato debe comprender AliasMode, ServiceMode, SvcPriority y el procesamiento de parámetros de la RFC 9460, para luego conectar la propagación de DNS, los certificados TLS, la negociación de HTTP/3 y el rollback con pasos de lanzamiento observables.
Enfoque de referencia
Mantén primero la configuración existente de A/AAAA y TLS, y verifica que los servidores autoritativos respondan al tipo 65. Utiliza AliasMode (prioridad 0 con un destino distinto de la raíz) para un alias en el apex; utiliza ServiceMode para ALPN, puerto o parámetros de endpoint alternativos. Publica alpn=h2,h3 en un subdominio de bajo tráfico, mide el éxito de resolución, los errores de handshake y la mezcla de protocolos, y luego expándelo al dominio principal.
Los clientes que ignoran los registros HTTPS deben continuar usando A/AAAA. El rollback elimina el nuevo registro y espera el TTL anterior más la retención del resolutor recursivo; eliminarlo a nivel autoritativo no borra las cachés de inmediato.
Detalles críticos
SvcPriority=0 significa AliasMode; ServiceMode utiliza una prioridad distinta de cero. El destino necesita un certificado coincidente, y port y alpn deben coincidir con los listeners y firewalls. Consulta varios resolutores recursivos antes y después del cambio y compara clientes que admitan o no el tipo 65.
Errores comunes
Eliminar A/AAAA porque los registros HTTPS se parecen a los CNAME; probar únicamente una caché local; considerar el anuncio de h3 como prueba de que QUIC funciona; pasar por alto los SAN del certificado para un destino en AliasMode; usar una sola región como evidencia de propagación global.
Rúbrica de evaluación
Las respuestas sólidas rastrean el DNS autoritativo, los resolutores recursivos, los clientes y los endpoints TLS; definen métricas de canary, ventanas de rollback y una matriz de compatibilidad; y predicen síntomas ante errores de prioridad y parámetros. Las respuestas más débiles proporcionan un solo registro sin explicar los clientes heredados o el almacenamiento en caché.
Preguntas de seguimiento
¿Cómo validas el destino y el certificado de un AliasMode?
Consulta los registros A/AAAA y HTTPS del destino, verifica que el host utilizado por el cliente cumpla con las restricciones de nomenclatura del certificado e inspecciona el SNI en los registros de TLS.
¿Qué revisas cuando HTTP/3 falla solo en algunas regiones?
Desglosa las muestras por resolutor recursivo, sitio DNS Anycast y red de acceso. Compara los registros HTTPS devueltos, la accesibilidad de UDP 443, las versiones de QUIC y las cadenas de certificados antes de considerar un rollback global.
¿Cuándo deberías evitar publicar alpn=h3?
Cuando los listeners de QUIC, los certificados, el path MTU o los firewalls no hayan sido validados en las redes de destino. Anuncia únicamente el protocolo estable hasta que las métricas de extremo a extremo cumplan con el criterio de pase del despliegue.