Resumen

  • Una SvcPriority menor expresa preferencia solo entre registros utilizables. Antes se eliminan datos mal formados, incoherentes o incompatibles; una clave obligatoria desconocida puede dejar fuera al supuesto primer destino.
  • AliasMode delega descubrimiento sin cambiar el origen. ServiceMode une destino y parámetros, pero los hints, el ALPN anunciado e incluso DNS autenticado son insumos; A/AAAA, el certificado del nombre original, el ALPN negociado y la respuesta de aplicación son pruebas posteriores.

Primero en la lista, fuera de la elección

Una organización publica dos registros HTTPS en ServiceMode. El de prioridad 1 dirige a un borde nuevo y marca como obligatorio un parámetro experimental. El de prioridad 2 conserva el borde anterior con parámetros entendidos por los clientes instalados. El panel operativo etiqueta el primero como destino preferente.

Para un cliente que desconoce esa extensión, el registro de prioridad 1 no es candidato. RFC 9460 exige ignorar un ServiceMode si no se reconocen todas sus claves obligatorias. El cliente evalúa el segundo y puede conectarse. No desobedeció el orden: determinó la elegibilidad antes de aplicar la preferencia.

El ejemplo no atribuye un incidente a ningún navegador o CDN. Sirve para separar una publicación de una ejecución. El titular de DNS puede armar opciones de conexión. No puede hacer que todo software comprenda una extensión, que una red permita el puerto, que un servidor negocie lo anunciado ni que un certificado represente al origen.

AliasMode no entrega la identidad

RFC 9460 define SVCB como tipo 64 y HTTPS como tipo 65. Cada registro contiene SvcPriority, TargetName y SvcParams opcionales. Cero activa AliasMode; un valor distinto de cero activa ServiceMode.

AliasMode delega el descubrimiento de un servicio a otro nombre y permite un alias específico en el ápice, donde CNAME no encaja. Su alcance es estrecho: no modifica los demás tipos de registro del nombre. Los parámetros en ese modo se ignoran y la cadena total de alias debe tener un límite para evitar ciclos.

Seguir el alias tampoco cambia el origin. Aunque el cliente llegue a un TargetName del proveedor, presenta el nombre original en SNI, valida el certificado con ese nombre y conserva el mismo Host o :authority en HTTP. Se delega una ruta operativa, no la identidad ante el lector.

ServiceMode une en un solo candidato el objetivo, puerto, protocolos, indicaciones de dirección y extensiones. En un despliegue multi-CDN, cada proveedor puede expresar su combinación real y evitar que una consulta mezcle su dirección con los parámetros de otro. La unión describe el plan; no demuestra que el borde esté activo o sincronizado.

Las puertas anteriores a la prioridad

Los registros pasan primero por validación. Un RR mal formado puede invalidar todo el RRset y conducir al método sin SVCB. Parámetros conocidos que se contradicen hacen que un registro no sea autoconsistente. Una clave desconocida normal puede omitirse, mientras que una clave desconocida en mandatory invalida ese candidato para el cliente.

Solo entonces se comparan prioridades. Los números menores se prueban antes; dentro del mismo nivel hay orden aleatorio equilibrado, no el peso configurable de SRV. Prioridad baja significa «preferir si es compatible», no una orden absoluta.

mandatory tampoco obliga al servidor. Advierte que ignorar una clave rompería el sentido del registro. Las claves nombradas deben existir en ese mismo RR y la lista no puede contenerse a sí misma. En HTTPS, port y no-default-alpn son automáticamente obligatorios cuando aparecen: pasar por alto el puerto elegiría otro servicio, y restaurar el protocolo predeterminado alteraría la oferta.

Lo anunciado no es lo negociado

alpn enumera las suites que el destino dice ofrecer. Así un cliente puede preparar HTTP/3 sobre QUIC sin visitar antes el borde predeterminado. La selección efectiva sigue ocurriendo durante el handshake. DNS puede haberse desplegado antes que el servidor, UDP puede estar bloqueado o una región puede conservar otra versión.

Por eso la evidencia guarda dos campos: ALPN obtenido en DNS y ALPN realmente negociado. Con port sucede lo mismo: el registro indica dónde intentar, pero una política del cliente o un firewall puede rechazarlo.

ipv4hint e ipv6hint también son provisionales. Si ya existen respuestas A/AAAA para TargetName, se deberían ignorar los hints. Si no existen, el cliente todavía consulta el nombre y debería usar las respuestas autoritativas en conexiones futuras. Una conexión puede arrancar con el hint y después migrar a una dirección diferente por balanceo geográfico.

Un registro de auditoría necesita la procedencia: hint, Answer, Additional, caché o resolución del proxy, además de TTL y red. Anotar solamente la IP borra la diferencia entre carrera deliberada, dato antiguo, división entre proveedores y desvío hostil.

La autenticación vuelve al nombre original

SVCB/HTTPS puede viajar por DNS no confiable. DNSSEC refuerza origen e integridad del RRset, pero RFC 9460 no lo exige. Incluso una respuesta DNSSEC correcta no afirma que el servicio esté vivo, hable el protocolo indicado o entregue contenido correcto.

El destino alternativo debe autenticarse para el nombre original. Un certificado válido solo para el TargetName del proveedor no sirve. DNS controla descubrimiento; TLS controla identidad del peer; ALPN prueba el acuerdo de esa conexión; HTTP mantiene la autoridad y el resultado de aplicación.

Como HTTP ya existía, SVCB es normalmente opcional y el cliente puede conservar el camino clásico. Pero el fallo de una consulta SVCB protegida —error criptográfico, SERVFAIL, transporte protegido interrumpido o timeout— debería detener el intento para evitar que un atacante elimine parámetros selectivamente. La ausencia en DNS no autenticado admite otra decisión local.

En un entorno multi-CDN, CNAME, HTTPS y A/AAAA pueden observar versiones de proveedores diferentes. El cliente debe resolver la dirección del TargetName que realmente seleccionó. La primacía del código en funcionamiento aparece aquí con precisión: el valor común reside en reglas mínimas que implementaciones compatibles pueden ejecutar, no en convertir una declaración DNS en soberanía sobre TLS, HTTP o todas las políticas de fallback.

Fuentes