Resumen

  • El borrador de REGEXT sobre extensiones RDAP impide que un servidor copie sin criterio los parámetros recibidos en la URL de redirección. Debe saber que el destino puede procesarlos y que corresponde entregarle su contenido.
  • Una extensión concebida para descubrir servidores autorizados entre distintas autoridades no puede depender de que sobreviva un parámetro de consulta. Una búsqueda enviada directamente a un servidor conocido sí puede utilizarlo.

La dirección correcta no conserva el encargo

Supongamos que un cliente consulta un recurso numérico y pide, mediante un parámetro de extensión, una vista adicional. El primer servidor devuelve una redirección HTTP hacia quien posee la respuesta autorizada. El registro básico llega; la vista solicitada quizá no. Es un ejemplo de diseño, no la narración de una caída real. El salto identifica a dónde seguir, pero no concede al primer servidor permiso para reenviar todo lo que recibió.

La RFC 9224 establece un método de descubrimiento basado en los registros de asignaciones de IANA. El borrador REGEXT señala un límite de ese mapa: no refleja las transferencias posteriores de recursos entre registros regionales. Por eso las redirecciones son relevantes para hallar al RIR autorizado. El problema del parámetro aparece en una ruta normal de búsqueda, precisamente cuando el cliente más necesita saber quién puede responder.

La RFC 7480 ordena a los servidores ignorar parámetros desconocidos. El borrador añade una exigencia al servidor que emite la redirección: no copiar parámetros a ciegas. Un parámetro puede llevar credenciales de seguridad o información de seguimiento ajena al destino. Para incluirlo en la nueva URL, el origen debe conocer la capacidad técnica del destino y comprobar que ese destino es receptor adecuado del contenido. Una máquina capaz de interpretar un campo no adquiere por ello derecho a recibir su valor.

Esta doble prueba produce una situación comercialmente incómoda. El servidor puede retirar el parámetro por una razón sólida y aun así entregar la respuesta básica. Una pantalla que celebre «consulta completada» oculta que el usuario pidió más. La solución contraria, reenviar siempre para preservar la funcionalidad, puede entregar datos a quien nunca debió verlos. Hay dos fallos distintos detrás del mismo indicador verde.

La búsqueda directa tiene otras reglas de juego

El borrador permite usar parámetros cuando el cliente conoce de antemano al servidor autorizado y consulta allí directamente. Menciona las búsquedas RDAP como ejemplo. Una extensión pensada para funcionar durante el descubrimiento entre autoridades debe diseñarse con una premisa más dura: el parámetro podría quedarse en el primer salto. La información imprescindible para interpretar el recurso necesita otro vehículo.

También existe la tentación de trasladar el trabajo al cliente: leer el contenido de la respuesta de redirección, reconstruir la consulta y decidir qué parámetros conservar. El texto enumera fricciones concretas. Algunos clientes en navegadores no pueden acceder al contenido RDAP del salto; otros necesitan resolver bucles, conflictos de parámetros y codificación de URL. Una demostración contra un único servidor conocido no prueba que la extensión funcione durante ese recorrido.

La ficha del IETF registra la revisión 17 del 27 de octubre de 2026 como borrador activo del grupo REGEXT, con estado IESG «I-D Exists». Todavía no es un RFC. La regla de redirección ya figuraba en una revisión anterior; su importancia reside en la elección operativa que deja expuesta, no en atribuirla a un cambio reciente de redacción.

Los documentos citados no identifican una fuga o pérdida real de parámetros en un operador concreto. Una transacción capturada con petición, URL Location, capacidad del destino y regla de recepción permitiría pasar del riesgo de diseño a una constatación operativa.

Fuentes