Resumen

  • Los registros SVCB y HTTPS permiten que el titular publique alternativas con parámetros ligados a cada destino y una prioridad recomendada. DNSSEC autentica el anuncio cuando se valida, no su viabilidad para cada cliente.
  • El cliente conserva la decisión efectiva: descarta datos incompatibles, interpreta claves obligatorias, distribuye empates, aplica política de proxy y direcciones, negocia TLS/ALPN y decide cuándo replegarse.

Una plataforma migra su tráfico principal a HTTP/3. Publica un HTTPS de prioridad 1 y deja un destino HTTP/2 en prioridad 2. El primer día, el panel DNS muestra la zona correcta y firmada. Sin embargo, parte de los usuarios sigue entrando por la segunda ruta. Unos tienen UDP bloqueado; otros no entienden un parámetro obligatorio; algunos reutilizan una conexión que ya estaba abierta.

No es necesario elegir entre “el DNS falló” y “los clientes desobedecieron”. La tercera posibilidad es la arquitectura real: el editor recomienda un conjunto; cada cliente solo puede convertir en conexión aquello que comprende y alcanza.

RFC 9460 define SVCB como tipo 64 y HTTPS como tipo 65. SVCB sirve de base general; HTTPS adapta el formato a los orígenes HTTP y permite obtener información útil antes del primer intercambio de aplicación. La mejora consiste en unir datos que deben viajar juntos, no en sustituir el juicio del extremo.

Con SvcPriority cero, AliasMode delega el servicio a un TargetName. Con un valor positivo, ServiceMode vincula ese TargetName con sus SvcParams. Así, un puerto, un conjunto ALPN y unas pistas de dirección describen el mismo destino. AliasMode, a diferencia de CNAME, solo afecta al tipo compatible consultado y no cambia los demás registros del nombre.

Esa limitación preserva la compatibilidad. Los clientes que conocen HTTPS RR pueden seguir el alias de servicio, incluso en un apex; los que no lo conocen aún necesitan A y AAAA útiles. La adopción no ocurre porque la zona exista, sino cuando cada implementación incorpora el algoritmo.

El filtro de compatibilidad es central. Un registro malformado puede invalidar todo el RRset. Un registro coherente todavía puede quedar fuera si el cliente no reconoce una clave declarada en mandatory o si su valor no permite establecer la conexión. Las claves desconocidas que no son obligatorias pueden ignorarse, lo que hace posible ampliar el formato sin romper automáticamente a los clientes antiguos.

El registro SVCB de IANA, actualizado el 25 de junio de 2026, muestra esa expansión. Además de mandatory, ALPN, puerto y pistas IPv4/IPv6, contiene ECH, ruta DoH, OHTTP, grupos TLS, DNS sobre CoAP, PvD y un parámetro de confianza por transporte para servidores de nombres. Registrar una clave no prueba que todos los navegadores, proxies o bibliotecas la implementen. Mucho menos que sea apropiada para cualquier mapping.

La prioridad tampoco equivale a una orden de enrutamiento. El número positivo menor expresa la preferencia del titular. Cuando varios registros comparten valor, el cliente debe barajarlos para repartir carga, sin pesos como los de SRV. Después puede intentar prioridades inferiores si las superiores fallan.

RFC 9460 autoriza más matices: pruebas en paralelo, precarga de varios TargetName, preferencia por una alternativa que no exige otra consulta y reutilización de una conexión compatible ya iniciada. Por eso la distribución observada no tiene que copiar el porcentaje que alguien imaginó al ordenar la zona.

El parámetro ALPN ofrece protocolos, pero no los negocia. El cliente filtra lo que soporta y RFC 7301 resuelve la selección dentro del handshake TLS. Que DNS anuncie h3 no abre UDP ni activa QUIC en un entorno administrado. La negociación sigue siendo evidencia de ejecución.

Las pistas de IP tienen una frontera igual de clara. RFC 9460 recomienda ignorarlas si ya están disponibles A o AAAA y consultar esas direcciones para conexiones futuras. Un cliente puede abandonar la dirección de una pista cuando llega la respuesta real. Después puede usar Happy Eyeballs v2 para competir entre familias. La pista reduce espera; no adquiere soberanía sobre el balanceo geográfico.

DNSSEC autentica la capa de publicación. Los HTTPS RR no traen autenticidad incorporada; RFC 9460 considera el canal DNS potencialmente hostil y hace opcional la validación. Si el cliente protege A/AAAA, debe aplicar una política equivalente a SVCB para que una falsificación no desvíe una dirección validada. RFC 4035 define esa cadena de estados.

Un resultado Secure dice que la zona firmada publicó esos bytes. No dice que el servidor responda, que el proxy acepte el destino o que la clave obligatoria exista en el cliente. Tampoco sustituye TLS. La autenticidad del anuncio es necesaria en ciertos modelos de amenaza y, al mismo tiempo, insuficiente para declarar éxito.

El TargetName no se convierte en el origen HTTPS. El SNI y Host o :authority siguen indicando el origen solicitado. RFC 9525 confirma que SVCB y HTTPS no cambian las reglas PKIX vigentes para HTTP ni DNS sobre TLS. El destino alternativo debe presentar una identidad válida para el servicio original.

Lo mismo ocurre con Alt-Svc: puede variar host, puerto y protocolo, pero no reemplaza el origen y el cliente elige según su política de seguridad. La diferencia operativa es temporal. HTTPS RR llega por DNS antes de hablar HTTP y usa TTL; Alt-Svc llega por HTTP y usa ma. La definición de origen de RFC 9110 permanece por encima de ambas rutas.

El repliegue ofrece continuidad durante una migración gradual. Para protocolos existentes, SVCB suele ser opcional: el cliente prueba alternativas compatibles y puede volver a su conexión ordinaria. Pero si la ruta preferida ofrecía ECH, HTTP/3 u otra propiedad, provocar su fallo puede degradar privacidad o seguridad. La disponibilidad no convierte esa pérdida en aceptable por defecto.

Los proxies cambian además quién ve y resuelve el destino. Si un proxy de nombres hará A/AAAA, una consulta SVCB separada puede revelar el sitio a otro actor. RFC 9460 exige desactivar SVCB en clientes opcionales cuando no existe un procedimiento privado adecuado. Si se usa, la compatibilidad incluye al proxy y sus decisiones de red.

RFC 9461 aplica el mismo formato a DoT, DoH y DoQ. Su existencia evita una generalización peligrosa: cada protocolo necesita un mapping que diga qué claves son seguras, qué identidad se valida y cómo funciona el repliegue. La sintaxis compartida no decide toda la semántica.

La disciplina de Heng Lu sobre primacía del código en ejecución, especificación mínima y decisión futura localizada y capas de realidad ayuda a no mezclar pruebas. La norma habilita. La zona publica. El resolutor entrega. El cliente selecciona. TLS autentica y negocia. La petición final muestra el efecto.

La auditoría completa une RRset, DNSSEC, versión de cliente, claves entendidas, modo de proxy, registro elegido, direcciones probadas, ALPN, certificado, motivo de repliegue y respuesta de aplicación. Consultar el tipo 65 es el principio del diagnóstico, no su conclusión.