Resumen

  • DNS compara las letras ASCII sin distinguir mayúsculas y minúsculas, aunque muchos servidores conservan la forma de la pregunta al copiarla en la respuesta. DNS-0x20 propuso convertir esa copia exacta en estado temporal de la transacción.
  • El espacio adicional variaba con cada nombre y podía desaparecer en servidores o intermediarios. Además exigía restaurar la pregunta antes de descomprimir y diseñar un repliegue que no se dejara forzar. La propuesta caducó y nunca ofreció autenticación.

El nombre no cambiaba; la expectativa sí

Un resolvedor puede enviar una pregunta con una combinación imprevisible de mayúsculas y minúsculas. El servidor autoritativo debe buscar el mismo RRset que habría buscado si todas las letras estuvieran en minúscula. En cambio, al recibir el paquete de vuelta, el resolvedor puede comparar la grafía exacta con la que guardó para esa consulta.

Así, una sola secuencia de letras cumple dos funciones sin mezclarlas. Ante la base DNS, identifica un nombre con comparación insensible a la caja. Ante la tabla de consultas pendientes, representa una elección efímera que la respuesta debe devolver. Quien falsifica a ciegas puede saber qué nombre se pregunta y aun así desconocer la variante enviada en ese instante.

DNS-0x20 no pretendía otorgar significado administrativo a una mayúscula. Pretendía cobrar una vez por una diferencia que el sistema de nombres ya había decidido no usar como identidad.

La especificación conservaba más de lo que comparaba

RFC 1035 estableció en 1987 que las comparaciones oficiales de DNS no distinguen la caja. Dos nombres con la misma ortografía y distinta capitalización son idénticos. A la vez, pidió preservar la forma original cuando fuera posible y minimizar su pérdida.

La combinación tenía sentido operativo. Una red global no podía depender de que cada usuario recordase una capitalización exacta. Pero tampoco había razón para destruir la presentación introducida por una persona o transportada por un paquete si el almacenamiento permitía conservarla.

RFC 4343 acotó el comportamiento a las letras ASCII. Las reglas de IDNA y las transformaciones propias de cada lengua son otra cuestión. También dejó claro que la salida puede no conservar la caja: dos grafías pueden compartir ubicación de almacenamiento y la compresión de nombres puede reutilizar una representación alojada en otra parte del mensaje.

La propuesta de 2008 encontró su materia prima en esa separación entre equivalencia obligatoria y conservación frecuente, pero no garantizada.

Un bit por letra, si el trayecto colaboraba

El Internet-Draft Use of Bit 0x20 in DNS Labels, fechado en marzo de 2008, describió cómo variar al azar el bit 0x20 de cada letra ASCII del QNAME. Ese bit distingue las dos cajas. Para la autoridad, todas las combinaciones debían resolver igual; para el solicitante, cada combinación podía marcar una transacción distinta.

Los autores se apoyaban en la costumbre de copiar la sección de pregunta, byte por byte, desde la solicitud a la respuesta. Informaron que los servidores autoritativos probados entonces lo hacían, pero admitieron excepciones que normalizaban a minúsculas. La especificación vigente no obligaba a preservar aquellos bits durante la copia.

La defensa complementaba el conjunto de coincidencias. RFC 5452 exige que la pregunta sea equivalente y que coincidan identificador, direcciones, puertos, clase y tipo. El ID de 16 bits ofrece por sí solo un objetivo limitado; un puerto de origen imprevisible amplía el espacio. La caja aleatoria podía añadir más decisiones que una respuesta falsa debía acertar antes que la legítima.

Pero acertar es distinto de estar autorizado. No había clave compartida, firma ni nueva prueba de origen. El método elevaba el precio estadístico de una falsificación fuera de ruta y nada más.

El nombre fijaba su propio techo

Solo una letra ASCII aporta una elección entre dos cajas. Un dígito, un guion o una etiqueta sin letras elegibles no añade ese bit. Por eso los nombres largos y alfabéticos podían cargar más reto que los cortos o numéricos. El propio borrador mostraba ejemplos con seis y doce bits adicionales.

La protección no podía resumirse correctamente en “función habilitada”. Había que contar las letras del nombre concreto, verificar que la aleatoriedad no fuera predecible y comprobar cuántos bits regresaban sin modificación. La configuración era común; el presupuesto de cada consulta, no.

Tampoco cabía extender el cálculo mediante reglas de mayúsculas de otros alfabetos. RFC 4343 separa la equivalencia ASCII en DNS de IDNA. Transformar una etiqueta internacionalizada según convenciones locales puede alterar el objeto procesado, no crear otra opción segura de representación.

Una caja intermedia podía borrar el reto sin romper DNS

Supongamos que un reenviador pone todas las preguntas en minúscula. El nombre sigue conduciendo al destino correcto y la respuesta puede contener datos válidos. Desde la semántica tradicional, el dispositivo funciona. Desde el verificador 0x20, destruye la señal.

Esta tensión revela que el mecanismo dependía de una propiedad de extremo a extremo que ningún extremo controlaba solo. El resolvedor elegía el patrón; cada servidor, reenviador y dispositivo de inspección decidía en la práctica si sobrevivía. Las pruebas de 2008 no podían comprometer a futuras implementaciones.

Una discrepancia tampoco diagnosticaba por sí misma un ataque. Podía ser normalización, un camino particular o un error. El borrador proponía registrar el suceso, descartar esa respuesta y probar otras direcciones autoritativas. Convertir todo cambio de caja en una alerta de envenenamiento habría confundido evidencia con conclusión.

Antes del caché había que devolver la grafía

La limpieza planteaba un problema más profundo que la generación. DNS comprime nombres mediante punteros. Una etiqueta de las secciones de respuesta, autoridad o información adicional puede apuntar a bytes de la pregunta. Si el resolvedor descomprime mientras la combinación aleatoria sigue allí, puede copiarla a datos almacenados y luego emitirla en otras respuestas.

DNS-0x20 pedía guardar la pregunta original, cotejar el patrón devuelto y, tras el éxito, restaurar la pregunta antes de descomprimir el resto. La aleatoriedad pertenecía a una operación pendiente, no al RRset ni a la identidad del nombre.

El orden expresa una regla amplia de ingeniería. Cuando un formato tolerante se reutiliza como nonce, el sistema debe marcar el instante en que deja de serlo. Si el valor efímero alcanza un almacén compartido, la medida de defensa modifica el comportamiento que prometía no alterar.

Replegarse demasiado pronto regalaba un interruptor

El rechazo estricto podía causar fallos frente a autoridades que plegaban la caja. El repliegue inmediato podía permitir una degradación provocada: producir discrepancias hasta que el resolvedor dejase de comprobarlas.

La propuesta sugirió agotar las otras autoridades y repetir la secuencia con nuevos identificadores, nuevas partes aleatorias y, si era posible, otro orden de servidores. Varias respuestas que conservaran correctamente lo demás y modificaran la caja de manera estable darían más base para declarar incompatibilidad.

El procedimiento generaba carga y demora. Una autoridad normalizadora podía recibir varias veces su tráfico. También se exponían más salidas del generador aleatorio. Disponibilidad y resistencia a la falsificación no quedaban resueltas por el bit: pasaban a depender de la política de intentos y de la memoria de compatibilidad.

DNSSEC necesita una operación opuesta

Para construir la forma canónica de un RR, RFC 4034 elimina la compresión y convierte en minúsculas las letras ASCII pertinentes. DNSSEC exige que firmante y verificador produzcan la misma secuencia, sin que la presentación accidental modifique el objeto firmado.

0x20 preservaba una diferencia aleatoria durante una ida y vuelta. DNSSEC borra diferencias para autenticar datos canónicos. Que una respuesta repita la caja demuestra, como máximo, que acertó un estado temporal; una firma válida puede vincular el RRset a una cadena de autorización. Confundir ambos resultados atribuiría al reto una autoridad que nunca tuvo.

El valor histórico de un borrador caducado

El Internet-Draft expiró en septiembre de 2008. No es una RFC ni demuestra que la técnica esté hoy desplegada de manera universal. Sus listas de productos son observaciones históricas del documento.

Su enseñanza permanece porque formula un patrón de diseño poco visible. Una distinción descartada para la identidad puede conservar utilidad como estado de una transacción. Para usarla responsablemente hay que medir su capacidad, enumerar las dependencias, borrar el estado antes de almacenarlo y tratar la compatibilidad como una superficie de degradación.

Las mayúsculas no cambiaron el nombre. Durante una sola consulta, cambiaron lo que el resolvedor estaba dispuesto a aceptar como respuesta.

Fuentes y límites

Este artículo se basa en RFC 1035, RFC 4343, RFC 5452, RFC 4034 y el Internet-Draft DNS-0x20 de marzo de 2008. Estas fuentes no establecen la cuota de despliegue, los valores predeterminados ni la compatibilidad universal actual.