Resumen

  • next-hop-aliases permite que el intermediario informe los CNAME y nombres canónicos observados durante la resolución del siguiente salto.
  • Ausencia, cadena vacía, lista parcial y error de análisis son estados distintos; ninguno certifica por sí solo la identidad del recurso.
  • La decisión fiable requiere identificar al proxy y al resolvedor, conservar DNS y DNSSEC por separado, autenticar el extremo y registrar quién autorizó la acción.

La política leyó una cadena vacía y concluyó: «no hay alias». La frase parecía razonable. También borraba tres preguntas: qué resolvedor consultó el proxy, qué registros pudo ver y si el software era capaz de recuperar la cadena completa.

El RFC 9532 crea el parámetro next-hop-aliases de Proxy-Status. Su función es devolver al cliente los alias y nombres canónicos que el intermediario recibió en registros CNAME al resolver el siguiente salto. El mecanismo es valioso porque un cliente de proxy puede perder esa vista de DNS y porque las cadenas CNAME pueden usarse para ocultar rastreadores o destinos maliciosos detrás de un nombre aparentemente inocuo.

Pero el campo informa una observación. No certifica una identidad.

Cuatro estados que una interfaz no debe fusionar

El parámetro puede no estar presente. El proxy puede enviar una cadena vacía para indicar que no encontró CNAME. Puede enviar una lista con uno o más nombres. También puede producir un valor que el cliente no logra analizar con seguridad.

Cada estado responde a una pregunta diferente. Ausente puede significar no compatible, no aplicable, eliminado por otro intermediario o simplemente no emitido. Vacío significa que ese proxy declara no haber encontrado CNAME en esa resolución. Poblado significa que declara algunos nombres recibidos. Inválido significa que no existe una interpretación fiable.

La tentación operativa es convertir todos los estados que no muestran un alias sospechoso en verde. Esa normalización fabrica certeza. El propio RFC advierte que clientes deben tolerar la ausencia y que un proxy puede incluir información incompleta.

La causa práctica está en las API. getaddrinfo puede ofrecer el último nombre canónico mediante AI_CANONNAME, pero no necesariamente la cadena de alias. Un proxy puede ser conforme y, aun así, observar sólo el final. Por eso una lista bien formada no es una historia exhaustiva.

La serialización conserva diferencias importantes

El valor exterior es una cadena de Structured Fields conforme al RFC 8941. Dentro de ella, RFC 9532 define una lista separada por comas. Los nombres deberían conservar el orden recibido: primero el alias al que apuntó el nombre original y al final el nombre que resolvió a direcciones.

Una coma que forme parte del nombre debe codificarse como porcentaje. Un punto dentro de una etiqueta DNS debe escapar primero con barra inversa, que después se codifica. La barra inversa literal requiere otro nivel de escape. Es posible cumplir el transporte HTTP y aun interpretar mal el nombre si se mezclan estas etapas.

El recibo de análisis debe guardar el campo original, las operaciones de decodificación y las etiquetas resultantes. Guardar sólo la visualización final impide distinguir un dato raro de un parser defectuoso.

El proxy no entrega una prueba DNSSEC

RFC 9532 afirma que el parámetro no incluye información DNSSEC ni implica que DNSSEC haya sido utilizado. El cliente sólo puede confiar en la lista hasta donde confíe en el proxy y en los resolvedores que éste empleó. Debe tratarla como pista y no usarla para determinar la identidad del recurso.

DNSSEC tiene otra cadena de evidencia. Los RFC 4033 y RFC 4035 describen cómo validar origen e integridad de datos DNS y negaciones autenticadas. next-hop-aliases no transporta firmas, prueba de cadena ni estado de validación.

Tampoco una respuesta DNS validada decide la capa de aplicación. La conexión puede requerir certificado, clave o autenticación adicional. La política de cookies del RFC 6265, un control de acceso o una divulgación de datos tienen dueños y criterios propios.

La omisión también pertenece al modelo de amenaza

Inspeccionar CNAME puede revelar cloaking. Sin embargo, un resolvedor recursivo o autoritativo puede omitir esos registros. Un proxy malicioso puede no reportarlos. El dato presente y el dato ausente dependen del mismo conjunto de actores.

Por eso el registro comienza con la procedencia. ¿Qué proxy generó el elemento de Proxy-Status? ¿Cómo lo confía el cliente? ¿Qué resolvedor y caché se usaron? ¿Qué versión de configuración estaba vigente? ¿Otro intermediario pudo modificar el campo?

Después se conservan consulta, respuesta, CNAME, nombre terminal, direcciones, TTL y pruebas DNSSEC capturadas por separado. Luego vienen transformación, escape y serialización. Finalmente se registran conexión, autenticación, regla local y resultado.

La disciplina de Heng Lu sobre las capas de realidad evita comprimir esa secuencia. El nombre no es la respuesta; la respuesta no es el informe; el informe no es la validación; la validación no es permiso. El código en ejecución debe cerrar cada transición.

Un estándar mínimo para decisiones locales

El estándar común debe ser pequeño. RFC 9532 coordina cómo comunicar la vista del proxy. No dicta una política universal de bloqueo ni de cookies. Un cliente puede usar el campo para elevar vigilancia, comparar con otra observación o explicar un incidente. La decisión final sigue siendo local, reversible y atribuida.

El registro IANA hace descubrible el parámetro. No prueba que un producto lo implemente ni que una lista sea completa. Las fuentes tampoco ofrecen cifras de adopción, comportamiento de navegadores concretos o prevalencia del cloaking. Los ejemplos son didácticos, no incidentes.

El valor del campo está en convertir una zona opaca en evidencia disponible sin fingir que esa evidencia tiene más autoridad de la que realmente posee.

Fuentes