Resumen

  • RFC 3397 asignó la opción DHCP 119 a una lista ordenada de dominios de búsqueda. Primero se concatenaban los fragmentos conforme a RFC 3396 y después se resolvían los punteros de compresión RFC 1035 dentro del agregado completo.
  • La lista actuaba antes que DNSSEC. Un sufijo hostil pero aceptado podía construir un FQDN distinto, cuyo operador publicara registros legítimamente firmados: una respuesta verdadera para una pregunta que el usuario no pretendía hacer.

Entre escribir myhost y consultar DNS había una decisión de autoridad. El texto corto no decía por sí solo a qué dominio pertenecía. Un resolver necesitaba una regla para añadir sufijos, ordenar candidatos y convertir esa intención incompleta en una pregunta concreta. RFC 3397 permitió que DHCP suministrara esa regla.

El documento apareció en noviembre de 2002 en la vía de estándares y definió Domain Search como la opción DHCP 119. Su alcance se limitó al DNS. No ordenaba varios sistemas de nombres ni indicaba cuándo usar uno u otro; RFC 2937 se ocupaba de aquella función diferente. La opción 119 solo llevaba la lista de dominios que completaría nombres dentro del DNS.

La lista aprovechaba cada octeto. Searchstring concatenaba nombres en la representación de etiquetas de RFC 1035 y permitía comprimir sufijos repetidos. Si dos entradas acababan en apple.com., la segunda podía apuntar a los octetos donde la primera ya lo había escrito. La compresión era especialmente útil en el espacio reducido de las opciones DHCP.

Ese puntero vivía en un universo local. Su desplazamiento se contaba desde el inicio de los datos de la opción, sin el código ni el octeto de longitud. No consultaba un nombre externo, no saltaba a otro paquete y no representaba una dirección de red. Solo reutilizaba bytes anteriores del objeto lógico.

El objeto, sin embargo, podía venir cortado. RFC 3397 empleó la concatenación de RFC 3396: ante varias instancias del código 119, el cliente debía reunir primero todas sus porciones de datos. Solo sobre ese agregado era lícito interpretar la compresión DNS. Por eso un puntero podía cruzar la frontera física de un fragmento.

El ejemplo normativo codificaba eng.apple.com. y marketing.apple.com. en tres instancias. C004 cerraba el segundo nombre apuntando al desplazamiento cuatro del agregado, donde empezaba apple.com.. Un lector que validara cada instancia por separado vería una referencia imposible. La gramática solo existía después de recomponer el valor.

La terminación también era una frontera de evidencia. Todo dominio debía finalizar con la etiqueta raíz de longitud cero o con un puntero válido de dos octetos. Si el agregado terminaba mientras quedaba un nombre incompleto, esa entrada se descartaba. El cliente no debía completar mentalmente un sufijo por el contexto ni convertir bytes parciales en configuración.

Después de decodificar la lista llegaba la política del resolver. RFC 3397 remitía a RFC 1535 y RFC 1536: las listas debían declararse explícitamente, no deducirse del nombre del host. Una entrada con un punto se probaba primero como FQDN y solo tras fallar se le añadían dominios locales. Una entrada sin puntos podía recibir el sufijo desde el principio.

Aquí aparecía el desvío. Una persona esperaba que myhost significara myhost.bigco.com. Un servidor DHCP fraudulento ofrecía roguedomain.com y la máquina preguntaba por myhost.roguedomain.com. La respuesta posterior no necesitaba ser falsa; había cambiado el objeto sobre el que se pediría verdad.

El propio RFC advertía que DNSSEC no evitaba el ataque. El propietario del dominio desviado podía publicar sus registros y firmarlos correctamente. La validación demostraría que la información recibida pertenecía al nombre consultado y conservaba su integridad. No probaría que aquel nombre representaba la intención del usuario ni la política autorizada de la organización.

DNSSEC, por tanto, no había fallado. Había respondido a una afirmación más estrecha. La aceptación de DHCP, la elección del sufijo, la construcción del FQDN, la consulta, la validación y la conexión pertenecían a autoridades distintas. Usar el resultado de una como recibo universal borraba precisamente el cambio de dominio que importaba.

RFC 3397 consideraba este camino más provechoso que anunciar simplemente un servidor DNS ilegítimo. El atacante podía usar servidores autoritativos normales y datos válidos de un dominio bajo su control. No hacía falta falsificar una firma ni mantener un resolver visiblemente extraño. La automatización del cliente realizaba el desplazamiento.

Las defensas apuntaban a la capa adecuada: aplicar las recomendaciones de búsqueda de RFC 1536, impedir que DHCP sobrescribiera parámetros DNS configurados manualmente y, cuando correspondiera, exigir autenticación DHCP antes de aceptar la opción. Aun así, autenticar el mensaje no demostraba que el sufijo expresara la intención de una persona concreta.

Una investigación operativa necesita recibos separados. Debe guardar la entrada original, las listas manuales y adquiridas, su prioridad, el servidor y su autenticación. También las instancias 119, el agregado de RFC 3396, los punteros, los nombres descartados y el orden de candidatos. Después debe enlazar la pregunta emitida con la respuesta, el resultado DNSSEC, la dirección y la conexión de la aplicación.

Ver una opción en la captura no demuestra aceptación. Reconstruirla bien no demuestra que el resolver la usó. Observar una pregunta no revela necesariamente lo que escribió el usuario. Una firma válida no explica de dónde salió el sufijo. Estos límites convierten una traza completa en una historia causal y evitan que “resolución exitosa” oculte un desvío.

IANA conserva el código 119 en el registro de parámetros BOOTP/DHCP; eso prueba coordinación del número, no despliegue ni corrección. La búsqueda actual del RFC Editor no encuentra erratas para RFC 3397, pero tampoco certifica analizadores, precedencias o resolvers instalados.

La Especificación Inicial Mínima de Lu Heng ayuda a leer el diseño: fijar solo lo que sistemas independientes debían compartir —alcance DNS, codificación, espacio de punteros y final válido— sin ordenar sus estructuras internas. La Primacía del Código en Ejecución exige completar esa norma con pruebas en vivo: fragmentar justo donde cruza un puntero y observar hasta el paquete DNS y la conexión.

La lección de RFC 3397 no es desconfiar de toda respuesta firmada. Es precisar lo que la firma afirma. Autentica datos para un nombre ya seleccionado. Para saber si ese era el nombre correcto hace falta otro recibo: quién construyó la pregunta.

Fuentes